Warum vergibt Fritzbox dhcp jedesmal eine neue Adresse?

[Bauform B. (bauformb)]

Schönen Rosenmontag miteinander!

Meine FRITZ!Box 7530 vergibt einem Debian bullseye mit isc-dhcp-client 
bei jedem Boot eine neue Adresse. Und nicht einmal fortlaufend, aber 
auch nicht zufällig: 55, 56, 24, 25, 26. MAC-Adresse und Hostname sind 
konstant, also, wozu ist das gut und wie stellt man das ab? Und warum 
bin ich anscheinend der einzige, dem das passiert?

Kann der dhcp-client das provozieren, auch wenn anscheinend alles 
konstant ist?

Natürlich würde Debian auch ohne dhcp funktionieren und natürlich könnte 
ich in der Fritzbox "immer die gleiche Adresse" ankreuzen. Aber ich mag 
dhcp und finde das Verhalten nicht normal.

[Doomer (Gast)]

Bauform B. schrieb:
> Natürlich würde Debian auch ohne dhcp funktionieren und natürlich könnte
> ich in der Fritzbox "immer die gleiche Adresse" ankreuzen. Aber ich mag
> dhcp und finde das Verhalten nicht normal.

Das ist doch weiterhin DHCP. Du sagst deiner FritzBox nur, dass du 
diesen Eintrag fixieren möchtest. Quasi wie der fixed Eintrag bei der 
Server Version deines DHCP Dienstes...

https://wiki.archlinux.org/title/Dhcpd

[Oliver S. (phetty)]

Hast du vielleicht ein paar Smartphones im Netz? Die würfeln seit 
einiger Zeit eine Mac Adresse aus und bekommen dann eine neue IP.
Dadurch könnte die IP deines Linux belegt sein.

[(prx) A. K. (prx)]

Bauform B. schrieb:
> MAC-Adresse und Hostname sind konstant

Aus Fritz'scher Sicht auch? Also im dortigen DHCP-Eintrag.

[Hmmm (Gast)]

Bauform B. schrieb:
> Kann der dhcp-client das provozieren, auch wenn anscheinend alles
> konstant ist?

Er kann sich eine bestimmte IP-Adresse wünschen, das muss nicht zwingend 
die angebotene sein.

Sofern nichts dagegen spricht (passt zum Pool, nicht belegt, keine 
statische IP hinterlegt), wird der DHCP-Server sich nicht querstellen.

[Ingo W. (uebrig)]

Grundsätzlich darf sich der Client auch eine Adresse "wünschen" (Request 
ohne vorheriges Discover/Offer). Hab ich schon oft gesehen, dass Geräte 
das tun um ihre "letzte" Adresse wieder zu bekommen.
Würde daher vermuten, dass der Server eine gewünschte, freie und gültige 
Adresse auch bestätigen würde.
Ob es wirklich so ist, sieht man in der Paketaufzeichnung.

[(prx) A. K. (prx)]

Wird der Debian-Rechner nur in grösseren Abständen genutzt, und ist 
damit länger weg, als die Lease Time vom DHCP Serever?

[asd (Gast)]

> Natürlich würde Debian auch ohne dhcp funktionieren und natürlich könnte
> ich in der Fritzbox "immer die gleiche Adresse" ankreuzen.

Ist das nicht genau das was du willst? DHCP funktioniert wie gewohnt, 
aber wenn die Fritzbox einen Client wiedererkennt und sich erinnert 
(Anzahl Speicherplätze begrenzt auf ein paar Duzend) dann bekommt der 
Client die gleiche Adresse wie beim letzten mal, ansonsten bekommt er 
irgendeine.

[(prx) A. K. (prx)]

Innerhalb der Lease-Time erhält ein Gerät über DHCP üblicherweise von 
alleine stets die gleiche IPv4 Adresse. Ist die (konfigurierbare) 
Lease-Time abgelaufen, gibts irgendeine. Das ist das gewohnte Verhalten 
- sofern die im DHCP genutzte MAC-Adresse nicht jedes Mal neu 
ausgewürfelt wird.

Wie vorhin schon erwähnt wurde, gibt es immer mehr Clients, die 
besonders im WLAN eine zufällige MAC-Adresse verwenden, um nicht 
wiedererkannt zu werden, um nicht darüber verfolgt werden zu können. Von 
stationären Geräten im Ethernet habe ich das so nicht in Erinnerung, 
aber es kann durchaus sein, dass es da mittlerweile auch verwendet wird. 
Ist ja die gleiche Basis.

In solchen Fällen hat das Gerät zwar irgendwo eine feste MAC-Adresse, 
verwendet sie aber nicht, sondern die verwendete Adresse ist zufällig. 
Deshalb meine Frage nach der MAC-Adresse, die Fritz sieht. Steht dort ja 
drin.

Bei Android kann man beispielsweise für jedes WLAN einzeln wählen, ob 
die feste oder eine zufällige MAC-Adresse genutzt wird. Im eigenen Netz 
wird man gerne die feste nehmen, in Fremdnetzen eher die zufällige.

[Onkel Hotte (Gast)]

Bauform B. schrieb:
> natürlich könnte
> ich in der Fritzbox "immer die gleiche Adresse" ankreuzen. Aber ich mag
> dhcp und finde das Verhalten nicht normal.

Der dhcpd in der Fritte ist seit Jahren buggy, nur fällt das nicht immer 
auf. Der Haken geht i.O., es bleibt ja dhcp. Stelle zusätzlich die lease 
time auf den kleinsten Wert, damit verschwinden viele Merkwürdigkeiten.

[Bauform B. (bauformb)]

Oliver S. schrieb:
> Hast du vielleicht ein paar Smartphones im Netz?

Ja, eins, aber da ist alles konstant.

(prx) A. K. schrieb:
> Bauform B. schrieb:
>> MAC-Adresse und Hostname sind konstant
>
> Aus Fritz'scher Sicht auch? Also im dortigen DHCP-Eintrag.

Ja, da steht zwar nur hostname, mac- und ip-adresse drin, aber die sind 
konstant.

Hmmm schrieb:
> Bauform B. schrieb:
>> Kann der dhcp-client das provozieren, auch wenn anscheinend alles
>> konstant ist?
>
> Er kann sich eine bestimmte IP-Adresse wünschen, das muss nicht zwingend
> die angebotene sein.

aber gerade dann wäre die ja konstant. Hier gibt es zwei PCs und ein 
Telefon, also ist auch reichlich Platz in den Tabellen. Also erstmal 
vielen Dank miteinander.

(prx) A. K. schrieb:
> Wird der Debian-Rechner nur in grösseren Abständen genutzt, und ist
> damit länger weg, als die Lease Time vom DHCP Serever?

Im Gegenteil, der muss heute alle paar Minuten neu booten; Experimente 
mit Bootloadern...

(prx) A. K. schrieb:
> Innerhalb der Lease-Time erhält ein Gerät über DHCP üblicherweise von
> alleine stets die gleiche IPv4 Adresse. Ist die (konfigurierbare)
> Lease-Time abgelaufen, gibts irgendeine. Das ist das gewohnte Verhalten
> - sofern die im DHCP genutzte MAC-Adresse nicht jedes Mal neu
> ausgewürfelt wird.

Eben, so kenne ich das und so mag ich das.

Onkel Hotte schrieb:
> Der dhcpd in der Fritte ist seit Jahren buggy, nur fällt das nicht immer
> auf. Der Haken geht i.O., es bleibt ja dhcp. Stelle zusätzlich die lease
> time auf den kleinsten Wert, damit verschwinden viele Merkwürdigkeiten.

In der Firma mache ich das genau so, aber das ist auch keine Fritzbox. 
Ich hatte gehofft, es gibt einen vernünftigen Grund, aber "buggy" muss 
heutzutage wohl als Erklärung reichen ;)

[Walter K. (walter_k488)]

Bauform B. schrieb:
> Schönen Rosenmontag miteinander!
>
> Meine FRITZ!Box 7530 vergibt einem Debian bullseye mit isc-dhcp-client
> bei jedem Boot eine neue Adresse.
…
Im privaten LAN - außer für iPhone oder iPad - DHCP zu nutzen, ist in 
meinen Augen vollkommen sinnfrei!

Desktoptechner, Drucker etc. bekommen eine statische IP und fertig … 
dann muss man sich auch keine Gedanken um eine viel zu kurze lease-Time 
machen

[Bauform B. (bauformb)]

Walter K. schrieb:
> Im privaten LAN - außer für iPhone oder iPad - DHCP zu nutzen, ist in
> meinen Augen vollkommen sinnfrei!

Eher umgekehrt ;) Sobald das iPhone anfängt, zufällige MAC-Adressen zu 
erzeugen, bekommt es eine feste (falls das dann noch möglich ist). DHCP 
ist doch praktisch überall Default und funktioniert (normalerweise). Von 
älteren Windows-Versionen weiß ich noch, dass die mit DHCP sofort 
problemlos liefen und feste Adressen immer irgendwo hakelig waren.

> Desktoptechner, Drucker etc. bekommen eine statische IP und fertig …
> dann muss man sich auch keine Gedanken um eine viel zu kurze lease-Time
> machen

Normalerweise bekommen die auch per DHCP eine feste Adresse und 
normalerweise ist die lease-Time ziemlich egal, weil sich der Rechner 
die letzte Adresse merkt und wünscht. Gerade im privaten LAN 
funktioniert das -- nur bei meiner Fritzbox nicht :(

[(prx) A. K. (prx)]

Walter K. schrieb:
> Im privaten LAN - außer für iPhone oder iPad - DHCP zu nutzen, ist in
> meinen Augen vollkommen sinnfrei!

Und in meinen Augen kann es sehr wohl Sinn ergeben. Spätestens dann, 
wenn darin installierte Geräte nicht vor Ort festgeklebt oder 
-geschraubt sind, ist DHCP mit ggf fixierter Adresse recht praktisch. 
Ebenso wenn Kleingeräte und Blackboxes nur umständlich auf eine feste 
IP-Adresse konfiguriert werden können, etwa IoT-Kram oder NAS-Devices.

[mm (Gast)]

Bauform B. schrieb:
> MAC-Adresse und Hostname sind
> konstant, also, wozu ist das gut und wie stellt man das ab? Und warum
> bin ich anscheinend der einzige, dem das passiert?

Was sagen denn die Logdateien auf Deinem Debian zum Thema DHCP?
Ein Blick da rein hilft meist mehr als alle Glaskugeln des Forums 
zusammen...

[Onkel Hotte (Gast)]

Bauform B. schrieb:
> Ich hatte gehofft, es gibt einen vernünftigen Grund, aber "buggy" muss
> heutzutage wohl als Erklärung reichen ;)

Ich habe das nicht näher untersucht und bin eigentlich zufällig drüber 
gestolpert. Ich mache doch nicht AVMs Hausaufgaben, insofern muss 
"buggy" hier in der Tat reichen ;)

In der Grundkonfiguration steht die leasetime auf IIRC 10 Tage. Das in 
Kombination mit dem von dir beobachteten Verhalten und vielen Clients 
sorgte dafür, dass der dhcpd irgendwann ausstieg, weil er wohl seine 
Tabelle nicht weiterschreiben konnte. Das ging bis zum eigenständigem 
Neustart der Box. Stellt man die leasetime auf den kleinsten Wert, 
verschwindet der eigentlich unnötige Spuk und sämtliches seltsames dhcp- 
Verhalten.

[Jim M. (turboj)]

Walter K. schrieb:
> Im privaten LAN - außer für iPhone oder iPad - DHCP zu nutzen, ist in
> meinen Augen vollkommen sinnfrei!

Diese Art von Geräten ist bei modernen Haushalten die Mehrheit.

> Desktoptechner, Drucker etc. bekommen eine statische IP und fertig

Bei modernen Druckern hat man oft keine Möglichkeit mehr die IP Adresse 
von Hand einzugeben, die haben nur noch einen Knopf und den 
Ein/Ausschalter.

Bei IPv6 ist die dynamische Adressvergabe ohnehin Pflicht.

Mit vernünftigem DHCP Server (wie etwa in einer FritzBox) kann man aber 
immer noch quasi statische IP Addresszuweisunge machen, d.h. einfach 
Adressen fest zuweisen.

Das ist in meinen Augen erheblich besser als das manuelle Gefummel an 
jedem Device einzeln.

[(prx) A. K. (prx)]

Um im Fritz nicht mit einer endlosen Liste von Eintagsadressen der immer 
gleichen Smartphones konfrontiert zu werden, kann es sinnvoll sein, 
diese Geräte innerhalb des Heimnetzes mit ihrer echten MAC arbeiten zu 
lassen. Mindestens in Android ist das für jede SSID konfigurierbar. Das 
schont die Ressourcen vom Fritz und die eigenen Nerven.

[Bauform B. (bauformb)]

Onkel Hotte schrieb:
> Stellt man die leasetime auf den kleinsten Wert, verschwindet der
> eigentlich unnötige Spuk und sämtliches seltsames dhcp-Verhalten.

Also ein Software-Problem, kann man nichts machen :)

mm schrieb:
> Was sagen denn die Logdateien auf Deinem Debian zum Thema DHCP?

Feb 19 19:48:00  DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 8
Feb 19 19:48:00  DHCPOFFER of 192.168.178.25 from 192.168.178.1
Feb 19 19:48:00  DHCPREQUEST for 192.168.178.25 on eth1 to 255.255.255.255 port 67
Feb 19 19:48:00  DHCPACK of 192.168.178.25 from 192.168.178.1
Feb 19 19:48:00  bound to 192.168.178.25 -- renewal in 345211 seconds.
--
Feb 20 07:24:08  DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 17
Feb 20 07:24:08  DHCPOFFER of 192.168.178.26 from 192.168.178.1
Feb 20 07:24:08  DHCPREQUEST for 192.168.178.26 on eth1 to 255.255.255.255 port 67
Feb 20 07:24:08  DHCPACK of 192.168.178.26 from 192.168.178.1
Feb 20 07:24:08  bound to 192.168.178.26 -- renewal in 389333 seconds.
--
Feb 20 08:06:09  DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 4
Feb 20 08:06:09  DHCPOFFER of 192.168.178.27 from 192.168.178.1
Feb 20 08:06:09  DHCPREQUEST for 192.168.178.27 on eth1 to 255.255.255.255 port 67
Feb 20 08:06:09  DHCPACK of 192.168.178.27 from 192.168.178.1
Feb 20 08:06:09  bound to 192.168.178.27 -- renewal in 359949 seconds.
--
Feb 20 08:13:53  DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 7
Feb 20 08:13:53  DHCPOFFER of 192.168.178.28 from 192.168.178.1
Feb 20 08:13:53  DHCPREQUEST for 192.168.178.28 on eth1 to 255.255.255.255 port 67
Feb 20 08:13:53  DHCPACK of 192.168.178.28 from 192.168.178.1
Feb 20 08:13:53  bound to 192.168.178.28 -- renewal in 409596 seconds.

[(prx) A. K. (prx)]

Um den Verdacht auszuräumen, dem Fritz seien irgendwelche Ressourcen 
ausgegangen, kann man darin die Leichen verbrennen. Also alle toten 
Geräte in der Liste löschen (gibt wohl einen Knopf eigens dafür). Und 
ihn dann durchstarten.

[Bauform B. (bauformb)]

Hatte ich auch schon, aber nach dem Essen probiere ich es nochmal.

[Onkel Hotte (Gast)]

(prx) A. K. schrieb:
> kann man darin die Leichen verbrennen. Also alle toten
> Geräte in der Liste löschen (gibt wohl einen Knopf eigens dafür).

Ja, gibt es. In dem von mir beobachteten Fall hat das am Verhalten 
nichts geändert, die so frei gewordenen IPs wurden nicht erneut 
vergeben. Noch aktive Clients wurden weiter mit Daten versorgt, bis sich 
wohl irgendwann zuviele dhcp-Requests gestapelt hatten. Darauf folgte 
der selbstständige Neustart der Box.

> Und ihn dann durchstarten.

Witzigerweise (naja) reichte der manuelle Neustart, um die Box auch 
wieder IPs vergeben zu lassen, die noch in der Liste der ungenutzten 
Verbindungen standen. Gaga.


Bauform B. schrieb:
> Also ein Software-Problem, kann man nichts machen :)

So in der Art :)

Ich will gar nicht behaupten, dass das hier das Problem ist. Das oben 
beschriebene Verhalten konnte ich seinerzeit auf der 7390, 7490 und 7590 
nachstellen. Bei allen waren alle Merkwürdigkeiten mit kürzest möglicher 
Leasetime verschwunden. Da ich glücklicherweise nicht so wirklich viel 
mit Fritten zu tun habe, habe ich das nicht weiter untersucht. In diesem 
Sinne: Versuch macht kluch.

[Bauform B. (bauformb)]

Onkel Hotte schrieb:
> (prx) A. K. schrieb:
>> kann man darin die Leichen verbrennen. Also alle toten
>> Geräte in der Liste löschen (gibt wohl einen Knopf eigens dafür).
>
> Ja, gibt es. In dem von mir beobachteten Fall hat das am Verhalten
> nichts geändert

Hier auch nicht. "Reboot tut gut" wird oft überschätzt.

Übrigens taucht die alte Adresse nicht in der unbenutzt-Liste auf. 
Irgendwie ist Debian-Rechner doch nicht ganz vergessen???

[(prx) A. K. (prx)]

Bauform B. schrieb:
> "Reboot tut gut" wird oft überschätzt.

Erzähl mir nix. Ich arbeite in der IT. ;-)

[Bauform B. (bauformb)]

Jetzt läuft als dhcp-Server ein dnsmasq statt der Fritzbox und jetzt 
sieht alles normal aus.

[Schlaumaier (Gast)]

Ich habe einiger ältere Geräte die eine Feste IP brauchen.

Also habe ich in meiner Fritzbox ein Festen IP-Block angelegt.

Sobald ich ein Gerät benutze, was eine Zwangs-IP (die ich in den Block 
lege) braucht, vergebe ich diese im Gerät, in der Fritzbox anmelde, sage 
ich der Fritzbox bei den Gerät, "Dieses Gerät immer mit der selben IP 
anmelden".

Und schon ist alles o.k.  Mir ist es dann egal ob der DHCP ihm die 
richtige IP gibt, oder es die Anforderung des Gerätes nimmt. In der Box 
bekommt es IMMER die richtige IP.

[Onkel Hotte (Gast)]

Schlaumaier schrieb:
> Ich habe einiger ältere Geräte die eine Feste IP brauchen.

> "Dieses Gerät immer mit der selben IP anmelden".

Du hast dhcp nicht verstanden.

[Schlaumaier (Gast)]

Onkel Hotte schrieb:
> Du hast dhcp nicht verstanden.

doch hab ich.

[(prx) A. K. (prx)]

Onkel Hotte schrieb:
> Du hast dhcp nicht verstanden.

Doch, hier liegt er ausnahmsweise richtig. Ein Client kann auch 
unverbindlich beantragen, seine zuletzt verwendete Adresse zu erhalten.

[Onkel Hotte (Gast)]

Schlaumaier schrieb:
> doch hab ich.

Ach deswegen beinhalten die zwei zitierten Zeilen einen unauflösbaren 
Widerspruch. Schon klar.

[Onkel Hotte (Gast)]

(prx) A. K. schrieb:
> Ein Client kann auch
> unverbindlich beantragen, seine zuletzt verwendete Adresse zu erhalten.

Ja, natürlich. Er schreibt jedoch:

Schlaumaier schrieb:
> Ich habe einiger ältere Geräte die eine Feste IP brauchen.

Also entweder geräteseitig fixe IP, dann natürlich außerhalb des 
dhcp-Adressraumes, oder dhcp. Aber nicht beides.

[(prx) A. K. (prx)]

Vielleicht redet ihr auch aneinander vorbei. Der Client kann beim DHCP 
seine früher per DHCP erhaltene Adresse mitschicken, in der Hoffnung, 
sie zu behalten. Verlass ist darauf aber nicht, es ist kein Ersatz für 
eine feste Adresse, oder eine im DHCP-Server festgenagelte.

"The DHCP client broadcasts a DHCPDISCOVER message on the network subnet 
using the destination address 255.255.255.255 (limited broadcast) or the 
specific subnet broadcast address (directed broadcast). A DHCP client 
may also request its last known IP address. If the client remains 
connected to the same network, the server may grant the request."

https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol#Discovery

[Onkel Hotte (Gast)]

Schlaumaier schrieb:
> Ich habe einiger ältere Geräte die eine Feste IP brauchen.

> vergebe ich diese im Gerät

So ist es richtig zitiert, und damit fällt dhcp zwangsweise raus.

[Hmmm (Gast)]

Onkel Hotte schrieb:
> Also entweder geräteseitig fixe IP, dann natürlich außerhalb des
> dhcp-Adressraumes, oder dhcp. Aber nicht beides.

Auch wenn die Fritzbox das anders handhabt, weder clientseitig noch 
durch den DHCP-Server vergebene feste IP-Adressen gehören in den 
Pool-Bereich.

Ich trage auch lokal eingetragene IPs oft zusätzlich im DHCP-Server ein. 
Hat den Vorteil, dass a) auch nach einem Factory Reset mit DHCP als 
Default die IP stimmt und b) man in der Config an das Vorhandensein 
solcher Clients erinnert wird.

[(prx) A. K. (prx)]

Hmmm schrieb:
> Auch wenn die Fritzbox das anders handhabt, weder clientseitig noch
> durch den DHCP-Server vergebene feste IP-Adressen gehören in den
> Pool-Bereich.

Wie man das organisiert, wie es zum eigenen Ordnungssinn passt, kann 
jeder für sich entscheiden. Aber eine IP-Adresse auf den vergebenen 
Stand festzunageln ist von Verfahren her problemlos. Die liegt dann im 
normalen DHCP-Bereich, denn so wurde sie ja vorher vergeben, ist aber ab 
der Festlegung für die betreffende MAC-Adresse reserviert. DHCP ist es 
immer noch.

[(prx) A. K. (prx)]

Lokal im Gerät festgelegte IP-Adressen sind dort essentiell, wo man die 
Adresse auch ohne DHCP benötigt, beispielsweise um im Problemfall ran zu 
kommen. Weshalb es sich empfiehlt, die Adresse des DHCP-Server nicht per 
DHCP zu vergeben.

[Hmmm (Gast)]

(prx) A. K. schrieb:
> Wie man das organisiert, wie es zum eigenen Ordnungssinn passt, kann
> jeder für sich entscheiden.

Klar, mit der Fritzbox geht es wohl auch nur so, beim ISC dhcpd ist das 
wiederum nicht empfehlenswert:

https://docs.netgate.com/pfsense/en/latest/services/dhcp/mappings-in-pools.html

[Onkel Hotte (Gast)]

Hmmm schrieb:
> Auch wenn die Fritzbox das anders handhabt, weder clientseitig noch
> durch den DHCP-Server vergebene feste IP-Adressen gehören in den
> Pool-Bereich.

Das ist wirr. Eine am Client fest eingestellte IP gehört außerhalb des 
Pools. Eine vom dhcp-Server für einen Client festgenagelte IP ist 
selbstverständlich innerhalb des Pools, wird dann aber natürlich nicht 
mehr an andere Clients vergeben.

Alles andere ist kaputt.

[(prx) A. K. (prx)]

Beim Microsoft DHCP-Server ist es der Unterschied zwischen Kontextmenu 
"Zur Reservierung hinzufügen" und umständlichem Neueintrag einer 
MAC-Adresse, die man freundlicherweise nicht aus dem bestehenden Lease 
rauskopieren kann.

Ist also offenbar überall etwas anders.

[Hmmm (Gast)]

Onkel Hotte schrieb:
> Eine vom dhcp-Server für einen Client festgenagelte IP ist
> selbstverständlich innerhalb des Pools

Das mag in Deiner Fritzbox-Welt so sein, beim ISC dhcpd sind die Ranges 
explizit für dynamische Zuweisungen gedacht, Haken bei Nichtbeachtung 
siehe oben.

[c-hater (Gast)]

Onkel Hotte schrieb:

> Der dhcpd in der Fritte ist seit Jahren buggy, nur fällt das nicht immer
> auf.

Was soll denn daran buggy sein? Nach meiner Erfahrung tut der ganz genau 
das, was ein DHCP-Server tun sollte.

Wenn du hier von "buggy" rumschwadronierst, dann solltest du auch 
Beweise für diese Behauptung liefern können.

[Schlaumaier (Gast)]

Onkel Hotte schrieb:
> Also entweder geräteseitig fixe IP, dann natürlich außerhalb des
> dhcp-Adressraumes, oder dhcp. Aber nicht beides.

Du hast es nicht richtig verstanden.

Das Zauberwort heißt "Netzwerk-Konflikt".

Ich blockiere den Bereich von 192.168.0.1 - 192.168.0.30 für DHCP.

Dann stelle ich im Gerät 192.168.0.10 ein. Das Gerät bekommt seine 
zugewiesene IP da diese NICHT durch DHCP vergeben wurde.

Ein anderes Gerät holt die IP via DHCP.  Er bekommt ein IP > 
192.168.0.30

[Onkel Hotte (Gast)]

Hmmm schrieb:
> Das mag in Deiner Fritzbox-Welt so sein

Jetzt mach dich nicht lächerlich. Das ist so gar nicht meine 
Kragenweite.

> beim ISC dhcpd sind die Ranges
> explizit für dynamische Zuweisungen gedacht

Das ist mir alles bekannt. Du ignorierst aber geflissentlich den von dir 
selbst genannten Haken:

"While ISC dhcpd will allow a static mapping to be defined inside the 
DHCP range/pool, it can result in unexpected behavior."

Hmmm schrieb:
> Ich trage auch lokal eingetragene IPs oft zusätzlich im DHCP-Server ein.

Und genau so, sofern man dieselbe IP dafür hernimmt (doppelt gemoppelt 
hält besser), macht man Netze kaputt. No-Go!

[Schlaumaier (Gast)]

(prx) A. K. schrieb:
> Weshalb es sich empfiehlt, die Adresse des DHCP-Server nicht per
> DHCP zu vergeben.

hihi.  Ist jedes mal ein Stress der Fritzbox die richtig IP zu 
verpassen. ;)

[(prx) A. K. (prx)]

Schlaumaier schrieb:
> Ich blockiere den Bereich von 192.168.0.1 - 192.168.0.30 für DHCP.

Damit das nicht wieder aneinander vorbei geht: Du schliesst diesen 
Bereich für die Nutzung durch DHCP aus. Man könnte auch sagen, du 
definiert einen anderen Bereich für DHCP, denn das ist die gängigere 
Konfigurationsmethode.

[Onkel Hotte (Gast)]

c-hater schrieb:
> Wenn du hier von "buggy" rumschwadronierst, dann solltest du auch
> Beweise für diese Behauptung liefern können.

Lerne sinnentnehmendes Lesen.

Die Umstände sind weiter oben beschrieben. Nimm dir eine Fritte und 50 
Clients und probiere es aus.

[Schlaumaier (Gast)]

(prx) A. K. schrieb:
> Schlaumaier schrieb:
>> Ich blockiere den Bereich von 192.168.0.1 - 192.168.0.30 für DHCP.
>
> Damit das nicht wieder aneinander vorbei geht: Du schliesst diesen
> Bereich für die Nutzung durch DHCP aus. Man könnte auch sagen, du
> definiert einen anderen Bereich für DHCP, denn das ist die gängigere
> Konfigurationsmethode.

Korrekt.

[Onkel Hotte (Gast)]

Schlaumaier schrieb:
> Ich blockiere den Bereich von 192.168.0.1 - 192.168.0.30 für DHCP.
> Dann stelle ich im Gerät 192.168.0.10 ein.

So weit, so normal.

Schlaumaier schrieb:
> sage
> ich der Fritzbox bei den Gerät, "Dieses Gerät immer mit der selben IP
> anmelden".

Beides geht nicht, und genau das ist der Widerspruch! Bei Geräten 
außerhalb des Pools kannst du dem dhcp-Server nicht sagen, er solle dem 
Gerät immer die geräteeigene IP geben, denn er gibt ihm ja gar keine IP.

[(prx) A. K. (prx)]

Onkel Hotte schrieb:
> Beides geht nicht, und genau das ist der Widerspruch! Bei Geräten
> außerhalb des Pools kannst du dem dhcp-Server nicht sagen, er solle dem
> Gerät immer die geräteeigene IP geben, denn er gibt ihm ja gar keine IP.

Kein Widerspruch, lediglich sondern technisch überflüssig.

Man kann es trotzdem reinschreiben. Wenn man sonst gerade nichts zur 
Hand hat, um sein Netz zu dokumentieren.

[Hmmm (Gast)]

Onkel Hotte schrieb:
> Jetzt mach dich nicht lächerlich. Das ist so gar nicht meine
> Kragenweite.

Dann unterstelle mir keine wirren Aussagen, weil Du sie nicht begreifst.

Onkel Hotte schrieb:
>> beim ISC dhcpd sind die Ranges
>> explizit für dynamische Zuweisungen gedacht
>
> Das ist mir alles bekannt. Du ignorierst aber geflissentlich den von dir
> selbst genannten Haken

Ganz im Gegenteil. Ich begründe mit dem Haken, warum feste Zuweisungen - 
auch im DHCP-Server vorgenommene - nicht in den dynamischen Poolbereich 
gehören.

Das Problem ist auch kein rein hypothetisches: Wenn so ein Client mal 
eine Weile offline ist (Laptop ausser Haus, Drucker abgeschaltet etc.), 
kann dessen Adresse anderweitig dynamisch vergeben werden.

Onkel Hotte schrieb:
> Und genau so, sofern man dieselbe IP dafür hernimmt (doppelt gemoppelt
> hält besser), macht man Netze kaputt. No-Go!

Was sollte da kaputtgehen? Solange der Client keinen DHCP-Request 
schickt, ist der Eintrag belanglos.

Du kannst es auch als Kommentar in die Config schreiben, wenn Du Dich 
damit wohler fühlst.

[(prx) A. K. (prx)]

Hmmm schrieb:
> Das Problem ist auch kein rein hypothetisches: Wenn so ein Client mal
> eine Weile offline ist (Laptop ausser Haus, Drucker abgeschaltet etc.),
> kann dessen Adresse anderweitig dynamisch vergeben werden.

Eine Adresse, die im DHCP-Server explizit als reserviert gekennzeichnet 
ist, wird von ihm nicht anderweitig vergeben. Auch nicht nach 2 Jahren. 
So ist es jedenfalls üblich.

Obacht: Eine solche Reservierung findet im DHCP-Server statt, nicht im 
Client und hat nichts mit einer manuell im Client definierten Adresse zu 
tun.

Onkel Hotte schrieb:
> "While ISC dhcpd will allow a static mapping to be defined inside the
> DHCP range/pool, it can result in unexpected behavior."

Der Satz kann missverstanden werden. Vielleicht bedeutet das nur, dass 
eine manuelle IP-Konfiguration im Client nicht innerhalb der vom 
DHCP-Server verwalteten IP-Range liegen darf. Und es nicht um 
reservierte IP/MAC-Zuordnungen seitens des DHCP-Servers geht.

[c-hater (Gast)]

Onkel Hotte schrieb:

> Die Umstände sind weiter oben beschrieben. Nimm dir eine Fritte und 50
> Clients und probiere es aus.

Was soll da besonderes passieren? So lange der DHCP-Bereich der Fritzbox 
groß genug ist (also mindestens 50+<ein paar> Adressen umfaßt), passiert 
da nix abnormales. Und wenn der DHCP-Bereich zu klein für die Clientzahl 
ist, passiert dieselbe Scheiße wie bei jedem anderen DHCP-Server mit zu 
kleinem DHCP-Bereich auch. Naja, eine der beiden möglichen Varianten: 
die Fritzbox zieht es vor, das älteste inaktive (und nicht reservierte) 
Lease zu löschen und die dadurch frei werdende IP an den neuen Client zu 
vergeben. Die andere wäre: das inaktive Lease beizubehalten und den 
neuen Client leer ausgehen zu lassen.

Ich halte das Fritzbox-Verhalten da noch für die bessere Wahl. Aber 
egal: die einzig richtige Lösung wäre natürlich, ihr genug DHCP-Space 
für die zu erwartende Zahl von Clients zu geben. Alles andere ist eine 
Fehlkonfiguration des Volltrottels von Admin, nicht die Schuld der 
Fritzbox.

[(prx) A. K. (prx)]

Wobei es in einer grossen Familie mit jeweils einem Handy und einem Tab 
pro Nase schon knapp werden kann. 200 DHCP-Adressen reichen bei einer 
Lease-Time von 10 Tagen und täglich wechselnder MAC-Adresse für 10 
Personen. ;-)

[Onkel Hotte (Gast)]

c-hater schrieb:
> Was soll da besonderes passieren?

Welcher Teil von...

"Lerne sinnentnehmendes Lesen. Die Umstände sind weiter oben 
beschrieben."

...war unklar?

Lesen, verstehen, und nicht mit herbeifabulierten Umständen daher 
kommen, die nie Thema waren.

[Schlaumaier (Gast)]

(prx) A. K. schrieb:
> Wobei es in einer grossen Familie mit jeweils einem Handy und einem Tab
> pro Nase schon knapp werden kann. 200 DHCP-Adressen reichen bei einer
> Lease-Time von 10 Tagen und täglich wechselnder MAC-Adresse für 10
> Personen. ;-)

Weshalb man ja in der Fritzbox die Lebenszeit einer IP-Adresse im 
DHCP-Raum einstellen kann.

Ohne Änderung (nie gemacht) liegt die bei meiner Box bei 10 Tagen. Die 
des DHCP-Gastraum bei 6 Std.

[c-hater (Gast)]

(prx) A. K. schrieb:

> Wobei es in einer grossen Familie mit jeweils einem Handy und einem Tab
> pro Nase schon knapp werden kann. 200 DHCP-Adressen reichen bei einer
> Lease-Time von 10 Tagen und täglich wechselnder MAC-Adresse für 10
> Personen. ;-)

Die Fritzbox kann nicht nur "Klasse-C"-Netze, sondern auch größere. Ob 
aber auch der DHCP-Server das kann, da bin ich mir nicht sicher. Habe 
ich nie probiert. Ich sehe allerdings auch keine prinzipiellen Probleme.

Wenn es zu Problemen, kommt, dann höchstens durch's (dafür 
möglicherweise nicht geeignete) GUI oder schlicht durch Speichermangel. 
Die FB hängt an die Leases einen Rattenschwanz von 
Sekundärinformationen. Da könnte es im Speicher schon mal etwas eng 
werden.

[Onkel Hotte (Gast)]

(prx) A. K. schrieb:
> Wobei es in einer grossen Familie mit jeweils einem Handy und einem Tab
> pro Nase schon knapp werden kann. 200 DHCP-Adressen reichen bei einer
> Lease-Time von 10 Tagen und täglich wechselnder MAC-Adresse für 10
> Personen. ;-)

Danke, wenigstens einer denkt mit. Und nun nehmen wir dein beschriebenes 
Szenario und stellen mit Erschrecken fest, dass die Fritte nicht das 
älteste Lease verwirft und wieder neu vergibt, sobald ihr die Range 
ausgeht, sondern einfach gar keine Leases mehr raushaut. Kommen in 
diesem Zustand trotzdem noch ordentlich Anfragen, startet sie stumpf 
neu.

Jetzt gehen wir zurück zum Urspungsproblem des OP: Die Fritte gibt 
demselben Client (also identische MAC!) trotz langer Leasetime eben 
nicht wieder dieselbe IP, sondern immer wieder eine neue. Der Pool 
wird also Ruck-Zuck verbraucht, und dann sind wir wieder oben:

"und stellen mit Erschrecken fest, dass die Fritte nicht das älteste 
Lease verwirft und wieder neu vergibt, sobald ihr die Range ausgeht, 
sondern einfach gar keine Leases mehr raushaut."

[Hmmm (Gast)]

(prx) A. K. schrieb:
> Der Satz kann missverstanden werden. Vielleicht bedeutet das nur, dass
> eine manuelle IP-Konfiguration im Client nicht innerhalb der vom
> DHCP-Server verwalteten IP-Range liegen darf. Und es nicht um
> reservierte IP/MAC-Zuordnungen seitens des DHCP-Servers geht.

Einfach noch den nächsten Absatz lesen:

"Making a static mapping does not “reserve” that IP out of the pool. The 
static mapping in this case merely represents a preference for an IP and 
others are not prevented from taking the IP if it is not in use."

Heisst also, wenn ein Client eine feste IP innerhalb des Pools hat, 
bekommt er sie nur dann, wenn sie nicht zufälligerweise schon 
anderweitig vergeben wurde.

Und die pfSense-Leute meinen es auch ernst damit, dass das keine gute 
Idee ist:

"If assignments absolutely must be made inside the pool, and the risks 
involved are worth taking and want to do so anyway, the input validation 
check may be removed from the PHP file that drives the DHCP editor page. 
The details of this unsupported change are left out as an exercise for 
the reader."

[Onkel Hotte (Gast)]

(prx) A. K. schrieb:
> Kein Widerspruch

Doch, natürlich. Wenn die Range bei .31 beginnt, kannst du dhcp-seitig 
keine fixe Vergabe für die .10 festlegen. Punkt.

> Man kann es trotzdem reinschreiben.

Klar, als Kommentar in die entsprechende Config. Aber eben nicht als 
gültige Config und schon mal gar nicht durch "Häkchen machen" in der 
Fritte.

[Bauform B. (bauformb)]

Wenn man "range" und "pool" unterscheidet, gibt es doch drei getrennte 
Adressbereiche: 1. den Pool, 2. feste Adressen, die per DHCP vergeben 
werden und 3. Adressen, die nicht per DHCP vergeben werden. So gesehen 
sind die Warnungen doch normal und verständlich?

[c-hater (Gast)]

Onkel Hotte schrieb:

> Jetzt gehen wir zurück zum Urspungsproblem des OP: Die Fritte gibt
> demselben Client (also identische MAC!) trotz langer Leasetime eben
> nicht wieder dieselbe IP, sondern immer wieder eine neue.

Das ist bei mir noch niemals passiert. Ich sorge aber halt auch für 
einen ausreichend großen DHCP-Bereich, bezogen auf die erwartete 
Clientzahl.

[Bauform B. (bauformb)]

c-hater schrieb:
> Onkel Hotte schrieb:
>> Jetzt gehen wir zurück zum Urspungsproblem des OP: Die Fritte gibt
>> demselben Client (also identische MAC!) trotz langer Leasetime eben
>> nicht wieder dieselbe IP, sondern immer wieder eine neue.
> Das ist bei mir noch niemals passiert. Ich sorge aber halt auch für
> einen ausreichend großen DHCP-Bereich, bezogen auf die erwartete
> Clientzahl.

das dürfte bei mir garkein Problem sein, per Default stehen ca. 180 
Adressen zu Verfügung und es gibt nur 2 Telefone und in den letzten 
Monaten insgesamt 5 oder 6 verschiedene PCs.

[Onkel Hotte (Gast)]

Bauform B. schrieb:
> So gesehen sind die Warnungen doch normal und verständlich?

Natürlich. Dem hat Hmmm weiter oben jedoch widersprochen, als ich 
anmerkte, sowas sei kaputt.

Ich bleibe dabei (und so ist es auch best practice): Clientseitig fix 
eingestellte IPs gehören nicht in die Range des DHCP. Niemals.

Was ich durchaus manchmal mache, um im Falle z.B. eines Werksresets 
eines Clients nicht suchen zu müssen: Fixe IP außerhalb der Range für 
den normalen Betrieb und zusätzlich eine dhcp-seitige Reservierung 
innerhalb der Range.

[Onkel Hotte (Gast)]

c-hater schrieb:
> Das ist bei mir noch niemals passiert.

Beim OP schon, das war Ausgangspunkt dieses Threads.

> Ich sorge aber halt auch für
> einen ausreichend großen DHCP-Bereich, bezogen auf die erwartete
> Clientzahl.

Die Range war beim OP groß genug und in dem von mir geschilderten Fall 
auch. Problematisch wirds eben durch das kaputte Verhalten der Fritte, 
am Ende der IPs nicht das älteste Lease zu verwerfen und neu zu 
vergeben.

Auf die Gefahr hin, mich zu wiederholen: Stellt man die Leasetime in der 
Fritte auf die kürzeste Zeit, IIRC ein paar Stunden, macht sie es 
richtig, auch wenn die Zeit noch nicht abgelaufen ist.

[c-hater (Gast)]

Onkel Hotte schrieb:

> Ich bleibe dabei (und so ist es auch best practice): Clientseitig fix
> eingestellte IPs gehören nicht in die Range des DHCP. Niemals.

Da stimme ich zu. Aber das hat nix mit der Fritzbox zu schaffen. Die 
erlaubt es, so einen Client korrekt zu behandeln. D.h.: man kann ihm 
einen im DNS der FB sichtbaren Namen zuweisen.

Ja, es mag für Idioten verwirrend sein, dass man das im selben GUI tut, 
der sonst überwiegend für die DHCP-Verwaltung vorgesehen ist. Aber macht 
nix, das funktioniert schon. So wie es soll und wie es sinnvoll ist.

[Hmmm (Gast)]

Onkel Hotte schrieb:
> Ich bleibe dabei (und so ist es auch best practice): Clientseitig fix
> eingestellte IPs gehören nicht in die Range des DHCP. Niemals.

In dem Punkt habe ich Dir nicht widersprochen, das ist völlig korrekt. 
Aber auch serverseitig vergebene feste IPs gehören eigentlich nicht in 
die Range, aus der dynamisch vergeben wird.

Einige DHCP-Server machen es trotzdem so (z.B. Fritzbox), einige 
verzeihen es (z.B. dnsmasq, so liest sich zumindest die Man-Page), 
einige mögen es gar nicht (z.B. ISC).

Aber vielleicht reden wir auch aneinander vorbei, was die Begriffe 
angeht. Der ISC dhcpd kann prinzipiell sämtliche Adressen aus dem 
jeweiligen Subnet zuteilen, entweder aus Host-Einträgen (für statische 
IPs) oder aus Ranges (für dynamische IPs). Es ist auch kein Problem, ein 
Subnet zu konfigurieren, in dem es ausschliesslich feste Zuteilungen 
gibt, indem man keine Range konfiguriert. Aber Hosts sollten eben 
tunlichst ausserhalb von Ranges liegen.

[c-hater (Gast)]

Onkel Hotte schrieb:

> Problematisch wirds eben durch das kaputte Verhalten der Fritte,
> am Ende der IPs nicht das älteste Lease zu verwerfen und neu zu
> vergeben.

Das ist aber genau, was sie tut. Und eigentlich ist genau das das einzig 
standardwidrige. Denn lt. Standard hätte der neue Client das Nachsehen, 
d.h.: er würde keine IP bekommen.

Aber wie schon mehrfach gesagt: das ganze Problem entsteht überhaupt 
nur, wenn man den DHCP-Bereich zu klein wählt. Es ist allein Sache des 
Admin, dafür zu sorgen, das er groß genug ist. Leute, die zu doof dazu 
sind und dann angeblich "buggy"-DHCP-Server der Fritzbox dafür 
verantwortlich machen, sind einfach nur armselig.

Ende der Ansage.

[Onkel Hotte (Gast)]

c-hater schrieb:
> Das ist aber genau, was sie tut.

Reproduzierbar nicht.

c-hater schrieb:
> armselig

...bist - wie immer - nur du.

> Ende der Ansage.

ROFL. EOD.

[(prx) A. K. (prx)]

Hmmm schrieb:
> Einfach noch den nächsten Absatz lesen:
>
> "Making a static mapping does not “reserve” that IP out of the pool. The
> static mapping in this case merely represents a preference for an IP and
> others are not prevented from taking the IP if it is not in use."

Was ist dann das hier? (ISC DHCP 4.4)

RESERVED LEASES

[...]

If a standard dynamic lease, as from any range statement, is marked 
´reserved´, then the server will only allocate this lease to the client 
it is identified by (be that by client identifier or hardware address).

[Onkel Hotte (Gast)]

Hmmm schrieb:
> Aber auch serverseitig vergebene feste IPs gehören eigentlich nicht in
> die Range, aus der dynamisch vergeben wird.

Da bin ich ganz bei dir, aber das braucht eben auch die Möglichkeit der 
Konfiguration. ISC und dnsmasq können es, die Fritte nicht. Da kannst du 
einem Host außerhalb der Range nur noch einen DNS-namen aufdrücken, mehr 
nicht.

> Aber vielleicht reden wir auch aneinander vorbei, was die Begriffe
> angeht.

Ich befürchte es ;)

[(prx) A. K. (prx)]

Bintec findet auch nichts dabei, bei einer dynamisch vergebenen Lease 
aus dem dynamischen Pool ganz schlicht per Web-GUI den Schalter 
"Statische Bindung" zu aktivieren, um eine feste und reservierte Bindung 
herzustellen.

[Hmmm (Gast)]

(prx) A. K. schrieb:
> Was ist dann das hier? (ISC DHCP 4.4)
>
> RESERVED LEASES

Sieht eher nach einem spezielleren Anwendungsfall aus:

"Leases may be set ´reserved´ either through OMAPI, or through the 
´infinite-is-reserved´ configuration option (if this is applicable to 
your environment and mixture of clients)."

Also wohl nicht per Config nutzbar, sondern nur per API, denn 
"infinite-is-reserved" ist auch wieder spezieller:

"If this flag is on, the server will automatically reserve leases 
allocated to clients which requested an infinite (0xffffffff) 
lease-time."

(prx) A. K. schrieb:
> Bintec findet auch nichts dabei, eine vergebene Lease aus dem
> dynamischen Bereich ganz schlicht per Web-GUI als "Statische Bindung" zu
> aktivieren.

Solange die damit faktisch aus dem dynamischen Bereich verschwindet, ist 
das technisch kein Problem, aber elegant ist IMHO anders.

[(prx) A. K. (prx)]

Hmmm schrieb:
> aber elegant ist IMHO anders.

Von der GUI aus betrachtet ist es sehr elegant. Formale Ästhetik ist 
allerdings Ansichtssache.

Reservierungen verwende ich routinemässig, nicht nur privat auf dem 
Bintec. Mitunter auch bei Geräten mit Serverfunktion. Es ist nämlich 
sehr angenehm, Geräte ohne Konsole problemlos in ein anderes Netz 
verfrachten zu können. Und bei manchen Clients, um sie anderswo per IP 
eindeutig identifizieren zu können. Bei Clients stört mich auch nicht, 
wenn die Adresse im normalen Pool liegt.

[Bauform B. (bauformb)]

Bauform B. schrieb:
> Meine FRITZ!Box 7530 vergibt einem Debian bullseye mit isc-dhcp-client
> bei jedem Boot eine neue Adresse.

Da fehlte noch die FritzOS-Version: 7.29. Nach einem Update auf 7.50 hat 
Debian jetzt zum 3. Mal die gleiche Adresse bekommen (die letzte von vor 
dem Update). So weit so gut.

Dafür kann ich jetzt die Adress-Listen nicht mehr anschauen. Von wegen 
"mach halt ein Update". Was täte ich, wenn ich Einstellungen ändern 
müsste, damit ich einen anderen Browser downloaden kann? Vollkommen 
krank, diese HMI-Designer.

[Rene K. (xdraconix)]

Also wer irgendwelche Bastlbrowser nutzt, braucht sich doch da nicht zu 
wundern. Vielleicht kann deine Version noch kein wirkliches HTML5?!

[Bauform B. (bauformb)]

Rene K. schrieb:
> Vielleicht kann deine Version noch kein wirkliches HTML5?!

Das muss sie auch nicht, HTML konnte schon immer alles, was man für so 
eine Konfiguration braucht. Das sollte eigentlich per telnet oder 
seriell möglich sein. Oder meinetwegen per w3m. Gerade bei so 
lebenswichtigen Geräten ;)

[Rene K. (xdraconix)]

Bauform B. schrieb:
> Das muss sie auch nicht, HTML konnte schon immer alles, was man für so
> eine Konfiguration braucht. Das sollte eigentlich per telnet oder
> seriell möglich sein. Oder meinetwegen per w3m. Gerade bei so
> lebenswichtigen Geräten ;)

Hatten die damals mit der Kutsche auch gesagt als sie das erste Auto 
gesehen haben.

[(prx) A. K. (prx)]

Rene K. schrieb:
> Also wer irgendwelche Bastlbrowser nutzt, braucht sich doch da nicht zu
> wundern. Vielleicht kann deine Version noch kein wirkliches HTML5?!

Wenn eine Webseite einen Browser ablehnt, dass liegt das nicht immer an 
fehlenden Fähigkeiten des Browsers, sondern mitunter nur an:

   if Browserstring not in (Chrome, Firefox, Safari) then
      ...Schwäbischer Gruss...

Ist schlicht einfacher so.