Hi, ik ben nu al een paar dagen bezig een DHCP configuratie te troubleshooten, en ik dacht dat het hier posten van het probleem misschien nieuwe inzichten kan verschaffen.
De setup:
Een Sun solaris 8 bak en een Unixware 7 bak draaien beide ISC DHCPD versie 3 patchlevel 12 met zo goed als dezelfde configuratie (de een heeft wat meer clients die een vast ip adres moeten krijgen dan de ander). Echter, waar de sun bak zonder problemen dynamische ips uitdeelt aan windows DHCP clients weigeren diezelfde windows DHCP clients ten enen male een ip aan te pakken van de DHCPD op de UnixWare bak.
Bestudering van het DHCP Handbook van Droms & Lemon bracht naar voren dat het probleem zou kunnen zitten in een "bug" in de tcp/ip stack van onder andere UnixWare, die op eigen houtje de DHCPOFFER naar het broadcast adres zou ombouwen naar een broadcast op het netwerkadres. Nu heb ik eens zitten kijken wat er over de lijn gaat met tcpdump, en dan blijkt inderdaad dat de UnixWare machine zijn antwoord stuurt naar het netwerk-broadcast adres. De workaround om het antwoord toch naar 255.255.255.255 te sturen die zowel in dat handbook als in de README bij de source staat werkt niet op UnixWare. Het opvallende is echter dat de Sun bak zijn antwoord helemaal niet naar 255.255.255.255 of <netwerkadres>.255 stuurt maar gewoon direkt naar het hardware adres van de client die een DHCPDISCOVER deed. Dat is m.i. ook veel logischer, want de server kan die info toch al uit het request van de client halen. Nu zit ik me dus een ongeluk te zoeken om de DHCP server op UnixWare ook gewoon zijn antwoord naar het hardware adres van de requesting client te laten sturen, maar tot op heden zonder succes. Iemand die een oplossing weet?
Oh enne... de DHCP server die standaard bij UnixWare 7 zit heeft voor ons weer andere problemen. Die valt dus ook af.
De setup:
Een Sun solaris 8 bak en een Unixware 7 bak draaien beide ISC DHCPD versie 3 patchlevel 12 met zo goed als dezelfde configuratie (de een heeft wat meer clients die een vast ip adres moeten krijgen dan de ander). Echter, waar de sun bak zonder problemen dynamische ips uitdeelt aan windows DHCP clients weigeren diezelfde windows DHCP clients ten enen male een ip aan te pakken van de DHCPD op de UnixWare bak.
Bestudering van het DHCP Handbook van Droms & Lemon bracht naar voren dat het probleem zou kunnen zitten in een "bug" in de tcp/ip stack van onder andere UnixWare, die op eigen houtje de DHCPOFFER naar het broadcast adres zou ombouwen naar een broadcast op het netwerkadres. Nu heb ik eens zitten kijken wat er over de lijn gaat met tcpdump, en dan blijkt inderdaad dat de UnixWare machine zijn antwoord stuurt naar het netwerk-broadcast adres. De workaround om het antwoord toch naar 255.255.255.255 te sturen die zowel in dat handbook als in de README bij de source staat werkt niet op UnixWare. Het opvallende is echter dat de Sun bak zijn antwoord helemaal niet naar 255.255.255.255 of <netwerkadres>.255 stuurt maar gewoon direkt naar het hardware adres van de client die een DHCPDISCOVER deed. Dat is m.i. ook veel logischer, want de server kan die info toch al uit het request van de client halen. Nu zit ik me dus een ongeluk te zoeken om de DHCP server op UnixWare ook gewoon zijn antwoord naar het hardware adres van de requesting client te laten sturen, maar tot op heden zonder succes. Iemand die een oplossing weet?
Oh enne... de DHCP server die standaard bij UnixWare 7 zit heeft voor ons weer andere problemen. Die valt dus ook af.
). Zodra je deze in een andere subnet hangt en hem via DHCP een iptje wil geven moet je handmatig met winipcfg ff renewen.