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 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

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"

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