Hallo Liste. Hier ist ein Auszug aus meiner dhcpd.conf: ---schnipp authoritative; [...] subnet 192.168.66.0 netmask 255.255.255.0 { range 192.168.66.95 192.168.66.98; } [...] ---schnapp Warum schickt der dhcpd trotz des authoritative;-Statements in der ersten Zeile auf diese Anfrage hin kein DHCPNAK: Feb 10 09:30:17 mailsrv dhcpd: DHCPREQUEST for 192.168.66.91 from 00:00:b4:30:6e:44 via eth0: unknown lease 192.168.66.91. Wenn ich die manpage richtig verstehe, ist es eine Kindersicherung, daß der dhcpd per default kein NAK schickt, und kann durch das authoritative-Statement überwunden werden. Aber das funktioniert bei mir nicht. Und ja, ein rcdhcpd restart hab ich gemacht... Gruß. Andy -- Antworten an lists@feile.net werden in /dev/null archiviert! Bitte ggf. lists... durch mail... ersetzen. Andreas Feile www.feile.net
Hallo, Andreas Feile schrieb:
Hallo Liste.
Hier ist ein Auszug aus meiner dhcpd.conf:
---schnipp authoritative; [...] subnet 192.168.66.0 netmask 255.255.255.0 { range 192.168.66.95 192.168.66.98; } [...] ---schnapp
Wenn ich es recht in Erinnerung habe, dann wertet der DHCP-Server nicht den range-Eintrag, sondern den subnet-Eintrag aus, wenn es um das Senden eines NAK auf Anfragen geht. Das "authoritative" ist also eigentlich nur dann hilfreich, wenn z.B. ein Laptop eine Adresse aus einem völlig anderen Subnetz anfordert. HTH, Anke -- Think before you ...
Andreas Feile wrote:
Hallo Liste.
Hier ist ein Auszug aus meiner dhcpd.conf:
---schnipp authoritative; [...] subnet 192.168.66.0 netmask 255.255.255.0 { range 192.168.66.95 192.168.66.98; } [...]
Warum schickt der dhcpd trotz des authoritative;-Statements in der ersten Zeile auf diese Anfrage hin kein DHCPNAK:
Weil die angefragte IP-Adresse eben NICHT in dem Bereich liegt, für den der DHCP-Server zuständig ist. Der Bereich umfasst ja nur x.x.x.95 - x.x.x.98.
Feb 10 09:30:17 mailsrv dhcpd: DHCPREQUEST for 192.168.66.91 from 00:00:b4:30:6e:44 via eth0: unknown lease 192.168.66.91.
Eindeutige Antwort, finde ich. (^-^) Ein besseres Testscenario wäre es, die IP-Adresse des Clients zu löschen, dann eine korrekte aus dem Bereich anzufordern, das leases-file zu löschen und dann zu beobachten, ob der DHCP-Server nach einem Neustart die Adresse ablehnt oder immer noch behauptet "unknown lease".
Wenn ich die manpage richtig verstehe, ist es eine Kindersicherung, daß der dhcpd per default kein NAK schickt, und kann durch das authoritative-Statement überwunden werden. Aber das funktioniert bei mir nicht.
IMHO ist das "authoritative" eher das Attribut, welcher DHCP-Server der entscheidende ist, wenn einmal mehrere sich verständigen müssen. Ich hatte mal einen Fall, wo der zweite nur einspringen durfte, falls der erste nicht antwortet. Sandy
On Thu, Feb 10, 2005 at 04:20:50PM +0100, Sandy Drobic wrote:
IMHO ist das "authoritative" eher das Attribut, welcher DHCP-Server der entscheidende ist, wenn einmal mehrere sich verständigen müssen. Ich hatte mal einen Fall, wo der zweite nur einspringen durfte, falls der erste nicht antwortet.
Das ist nicht ganz richtig, verstaendigen tun sich mehrere DHCP-Server niemals -- es sei denn in einem failover Setup. Ansonsten antworten einfach alle DHCP-Server, und der Client entscheidet sich fuer einen Server, mit dem er die Transaktion durchfuehrt. Peter -- the pink machine that goes "ping" imitated the little can of spam
On Thu, Feb 10, 2005 at 09:36:50AM +0100, Andreas Feile wrote:
Hallo Liste.
Hier ist ein Auszug aus meiner dhcpd.conf:
---schnipp authoritative; [...] subnet 192.168.66.0 netmask 255.255.255.0 { range 192.168.66.95 192.168.66.98; } [...] ---schnapp
Warum schickt der dhcpd trotz des authoritative;-Statements in der ersten Zeile auf diese Anfrage hin kein DHCPNAK:
Feb 10 09:30:17 mailsrv dhcpd: DHCPREQUEST for 192.168.66.91 from 00:00:b4:30:6e:44 via eth0: unknown lease 192.168.66.91.
Wenn ich die manpage richtig verstehe, ist es eine Kindersicherung, daß der dhcpd per default kein NAK schickt, und kann durch das authoritative-Statement überwunden werden. Aber das funktioniert bei mir nicht.
Ich wuerd sagen, der Grund warum er kein NAK schickt ist dass die Adresse fuer das Subnet korrekt ist, sprich, es besteht kein Grund sie nicht zu verwenden, sie wuerde technisch funktionieren etc. Probier doch mal ob es einen Unterschied macht ob Du das authoritative ins subnet mit reinschreibst, aber ich vermute dass das nichts aendert. Der DHCP-Client duerfte nach einer Weile (rechtzeitig bevor die Adresse ablaeuft), wenn der DHCPREQUEST nicht zum Erfolg fuehrt, mit einem DHCPDISCOVER eine neue Adresse beantragen. Vermutlich stammt die Adresse aber aus einem anderen Netzwerk und Du haettest gern, dass der Client sich eine aus diesem Netz holt? Peter -- the big can of spam got the little cardinal
poeml@cmdline.net, Samstag, 12. Februar 2005 01:00:
Vermutlich stammt die Adresse aber aus einem anderen Netzwerk und Du haettest gern, dass der Client sich eine aus diesem Netz holt?
Es ist so, daß ich manchmal den range verschieben muß. Also zB vergebe ich an Clients zweistellige IPs, etwa 10-99, und stelle dann fest, daß das nicht ausreicht. Also vergebe ich dreistellige, zB 100-230, und möchte zugleich erreichen, daß 10-99 frei wird für fixe IPs. Jetzt lege ich also den neuen range fest, und dann kommt ein Client mit einem Request für sagen wir 85. Und auf diese Anfrage brauch ich halt ein NAK, damit der Client als nächstes ein Discover macht. -- Antworten an lists@feile.net werden in /dev/null archiviert! Bitte ggf. lists... durch mail... ersetzen. Andreas Feile www.feile.net
On Sat, Feb 12, 2005 at 05:52:50PM +0100, Andreas Feile wrote:
poeml@cmdline.net, Samstag, 12. Februar 2005 01:00:
Vermutlich stammt die Adresse aber aus einem anderen Netzwerk und Du haettest gern, dass der Client sich eine aus diesem Netz holt?
Es ist so, daß ich manchmal den range verschieben muß. Also zB vergebe ich an Clients zweistellige IPs, etwa 10-99, und stelle dann fest, daß das nicht ausreicht. Also vergebe ich dreistellige, zB 100-230, und möchte zugleich erreichen, daß 10-99 frei wird für fixe IPs. Jetzt lege ich also den neuen range fest, und dann kommt ein Client mit einem Request für sagen wir 85. Und auf diese Anfrage brauch ich halt ein NAK, damit der Client als nächstes ein Discover macht.
So funktioniert das DHCP Protokoll aber nicht. Ist eine Adresse einmal vergeben, darf der Client sie verwenden so lange sie gueltig ist. Es gibt keine Moeglichkeit der spaeteren Benachrichtigung Server->Client dass die Adresse ungueltig wird. Eine gaengige Methode bei solchen Verschiebungsaktionen ist, die Lease-Zeit rechtzeitig vorher voruebergehend zu verkuerzen, um alle Clients darauf einzustimmen dass sie demnaechst was neues holen sollen. Nachher kann man sie wieder hochsetzen. (Oder eben von vornherein kuerzere Zeiten verwenden.) Ansonsten wartest Du halt einfach, bis der Client von selbst drauf kommt, irgendwann laeuft seine Lease ja ab. Peter -- the pink cardinal imitated the pink can of spam
poeml@cmdline.net, Montag, 14. Februar 2005 14:25:
So funktioniert das DHCP Protokoll aber nicht. Ist eine Adresse einmal vergeben, darf der Client sie verwenden so lange sie gueltig ist. Es gibt keine Moeglichkeit der spaeteren Benachrichtigung Server->Client dass die Adresse ungueltig wird.
Das habe ich schon verstanden. Im vorliegenden Fall ist es aber doch so, daß der Client freiwillig einen Request an den Server schickt. Und wenn der Server daraufhin ein NAK zurückgäbe, weil ich mittlerweile die Range verschoben habe, dann wäre ja alles in Butter, weil der Client als nächstes ein Discover machen würde. Aber der Server gibt einfach gar nix zurück. -- Antworten an lists@feile.net werden in /dev/null archiviert! Bitte ggf. lists... durch mail... ersetzen. Andreas Feile www.feile.net
On Mon, Feb 14, 2005 at 03:05:42PM +0100, Andreas Feile wrote:
poeml@cmdline.net, Montag, 14. Februar 2005 14:25:
So funktioniert das DHCP Protokoll aber nicht. Ist eine Adresse einmal vergeben, darf der Client sie verwenden so lange sie gueltig ist. Es gibt keine Moeglichkeit der spaeteren Benachrichtigung Server->Client dass die Adresse ungueltig wird.
Das habe ich schon verstanden. Im vorliegenden Fall ist es aber doch so, daß der Client freiwillig einen Request an den Server schickt.
Das tut jeder Client nach 0.5*t, wobei t = Gueltigkeitsdauer der Lease. Nach 0.75*t wird er ins naechste Stadium wechseln, DHCPDISCOVER. In dem Moment wird er dann auch eine neue Adresse bekommen. Die beiden Zeiten werden auch T1 und T2 genannt (aus dem Kopf, nicht schlagen wenn leicht inexakt). Diese beiden Zeiten koennen sogar vom Server vorgegeben werden, sind es aber in der Regel nicht, und der Client verwendet dann das 0.5/0.75-fache der Lease.
Und wenn der Server daraufhin ein NAK zurückgäbe, weil ich mittlerweile die Range verschoben habe, dann wäre ja alles in Butter, weil der Client als nächstes ein Discover machen würde. Aber der Server gibt einfach gar nix zurück.
Warte einfach noch 0.25*t -- und naechstes Mal weisst Du's :-) Peter -- the little can of spam got the little machine that goes "ping"
poeml@cmdline.net, Montag, 14. Februar 2005 20:38:
Das tut jeder Client nach 0.5*t, wobei t = Gueltigkeitsdauer der Lease.
Nach 0.75*t wird er ins naechste Stadium wechseln, DHCPDISCOVER. In dem Moment wird er dann auch eine neue Adresse bekommen.
Die beiden Zeiten werden auch T1 und T2 genannt (aus dem Kopf, nicht schlagen wenn leicht inexakt). Diese beiden Zeiten koennen sogar vom Server vorgegeben werden, sind es aber in der Regel nicht, und der Client verwendet dann das 0.5/0.75-fache der Lease.
Wo kann man denn dazu mehr nachlesen? zB interessiert mich, was der Client macht, wenn das Lease abgelaufen ist, und er es nicht verlängert bekommt, weil der dhcpd down ist. Gruß. Andy -- Antworten an lists@feile.net werden in /dev/null archiviert! Bitte ggf. lists... durch mail... ersetzen. Andreas Feile www.feile.net
On Tue, Feb 15, 2005 at 12:47:11AM +0100, Andreas Feile wrote:
poeml@cmdline.net, Montag, 14. Februar 2005 20:38:
Das tut jeder Client nach 0.5*t, wobei t = Gueltigkeitsdauer der Lease.
Nach 0.75*t wird er ins naechste Stadium wechseln, DHCPDISCOVER. In dem Moment wird er dann auch eine neue Adresse bekommen.
Die beiden Zeiten werden auch T1 und T2 genannt (aus dem Kopf, nicht schlagen wenn leicht inexakt). Diese beiden Zeiten koennen sogar vom Server vorgegeben werden, sind es aber in der Regel nicht, und der Client verwendet dann das 0.5/0.75-fache der Lease.
Wo kann man denn dazu mehr nachlesen? zB interessiert mich, was der
Das DHCP Handbook ist sehr gut, aber im Prinzip steht alles wichtige hier: ftp://ftp.rfc-editor.org/in-notes/rfc2131.txt
Client macht, wenn das Lease abgelaufen ist, und er es nicht verlängert bekommt, weil der dhcpd down ist.
Dann muss er das Interface runterfahren. rfc 2131, section 4.4.5: If the lease expires before the client receives a DHCPACK, the client moves to INIT state, MUST immediately stop any other network processing and requests network initialization parameters as if the client were uninitialized. Peter -- the big machine that goes "ping" got the pink cardinal
participants (4)
-
Andreas Feile -
Anke Boernig -
poeml＠cmdline.net -
Sandy Drobic