Fritz Box 6690 - Statische IP lässt sich für raspberry nicht zuordnen

[Raijin]

Ob man einem Server-Gerät nun via statischer DHCP-Reservierung immer dieselbe IP-Adresse zuweist oder ob man am Gerät selbst eine statische IP festlegt, gibt immer wieder Anlass für Diskussionen. Beides hat Vor- und Nachteile und spaltet die Gesellschaft - fast schon eine Glaubensfrage. Richtig oder falsch gibt es da nicht, sondern nur Abwägen der Vor- bzw. Nachteile sowie persönliche Präferenz.

Ich kenne es zwar eigentlich anders herum, also dass auch ohne feste Vorgaben bekannte Geräte immer wieder die gleiche IP-Adresse bekommen

Bei einer Fritzbox hat man natürlich keinen Einfluss darauf wie der DHCP-Server agiert und deswegen wird er sich mit 99,999999%iger Sicherheit wie die meisten DHCP-Server verhalten: +1 hochzählen bis er gar keine andere Wahl hat als alte Leases zu überschreiben.

DHCP definiert aber nur das Protokoll und nicht das Verhalten bzw. Verwalten von IP-Adressen. Dies obliegt der jeweiligen Implementierung, also dem DHCP-Server selbst. Wer mag, kann sich das Folgende gerne durchlesen, aber da es etwas OffTopic ist, im Spoiler.

Spoiler: Beispiel dnsmasq

Hat man Zugriff auf das Hostsystem und kann dort zwischen verschiedenen DHCP-Implementierungen umschalten und sie konfigurieren, kann man auch deren Verhalten anpassen soweit der Dienst entsprechende Optionen bietet. Diese können zB das Verfahren für "frische" DHCP-IPs umfassen (+1 ist nicht der einzige Weg) oder beispielsweise auch ob vor der Vergabe ein Kontroll-Ping erfolgen soll oder nicht. Beides ist wie erwähnt in keinster Weise durch das DHCP-Protokoll vorgegeben, da selbiges lediglich den Prozess des Nachrichtenaustauschs definiert (zB DHCP-Discover oder -Offer) .

Hier mal ein Auszug aus der manpage von dnsmasq:

--dhcp-sequential-ip
Dnsmasq is designed to choose IP addresses for DHCP clients using ahash of the client's MAC address. This normally allows a client's address to remain stable long-term, even if the client sometimes allows its DHCPlease to expire. In this default mode IP addresses are distributed pseudo-randomly over the entire available address range. There aresometimes circumstances (typically server deployment) where it is more convenient to have IP addresses allocated sequentially, starting from the lowest available address, and setting this flag enables this mode. Note that in the sequential mode, clients which allow a lease to expire are much more likely to move IP address; for this reason it should not be generally used.

-5, --no-ping
(IPv4 only) By default, the DHCP server will attempt to ensure that an address is not in use before allocating it to a host. It does this by sending an ICMP echo request (aka "ping") to the address in question. If it gets a reply, then the address must already be in use, and another is tried. This flag disables this check. Use with caution.

 

[Incanus]

Mit der aktuellen Inflation an Smart-Home-Geräten mag man an Grenzen des DHCP-Pools stoßen, in einem durchschnittlichen Heim-Netzwerk kam man sonst eigentlich damit aus .

 

[Lora]

Weil das Pi-Hole noch von der Alten Fritzbox die IP selbst statisch im Raspberry gespeichert hat, ging es erst nachdem ich die Hacken entfernt habe. Dann habe ich das Pi-Hole Setup nochmal durchlaufen lassen, da wird man ja gefragt ob man die IP Statisch gemacht hat, wenn man es bestätigt wird im Raspberry die IP durch das Pi-Hole Setup auch statisch eingetragen. Die Alte Fritzbox lief so immer und ich konnte da keine Probleme feststellen. Aber scheint echt schon eine Glaubensfrage zu sein

 

[Incanus]

Eher, was man bequemer findet und öfter tauscht. Bekommt der neue Router denselben IP-Bereich muss man bei fester Zuweisung im Client meist gar nichts machen.
Muss oder möchte man den IP-Bereich ändern, läuft man natürlich von Client zu Client und ändert alles.

 

[Lora]

Eher, was man bequemer findet und öfter tauscht. Bekommt der neue Router denselben IP-Bereich muss man bei fester Zuweisung im Client meist gar nichts machen.

Ich hab es mir halt auf Umwegen eingestellt, aber es war die Macht der Gewohnheit

 

[Gliese]

Sich diesbezüglich auf DHCP zu verlassen, ist gefährlich. Wenn der DHCP Server der Meinung ist, dass die IP schon vergeben ist, vergibt er eine andere.

Man kann sich schon auf DHCP verlassen, nur muss man halt den Geräten, die garantiert immer die gleiche IP haben sollen, IPs zuweisen lassen, die außerhalb der dynamischen DHCP-Range liegen.
Mit dnsmasq ist das möglich, aber ob das auch mit der FritzBox geht, weiß ich nicht.

 

[Incanus]

nur muss man halt den Geräten, die garantiert immer die gleiche IP haben sollen, IPs zuweisen lassen, die außerhalb der dynamischen DHCP-Range liegen.

Das ist ja ein Widerspruch in sich. Man kann Geräten nicht automatisch immer die gleiche IP zuweisen lassen, die gar nicht automatisch zugewiesen wird.
Also entweder automatisch aus dem DHCP-Pool oder manuell im Client eine Adresse von außerhalb des Pools.

 

[Gliese]

Wo Widerspruch?
Man hat das Netz 192.168.178.0/24 und stellt die DHCP-Range auf 192.168.178.20 bis 192.168.178.200 ein.
Dann sagt man dem DHCP-Server, die MAC-Adresse 01:23:45:67:89:AB soll die IP 192.168.178.210 kriegen.
Dann stellt man auf dem Gerät mit der MAC-Adresse 01:23:45:67:89:AB auf "IP von DHCP beziehen" ein.
Und zack bekommt das Gerät immer die IP 192.168.178.210, ohne Kollisionen befürchten zu müssen. Alle anderen kriegen eine IP der Range 192.168.178.20 bis 192.168.178.200 zugewiesen.
Ich habe zwar andere Netze, mache das gleiche mit meinen Smart-Home-Geräten so, wo ich immer per API zugreifen möchte und daher immer per DHCP eine feste IP haben sollen. Hab kein Bock immer auf den Geräten selbst zu konfigurieren.

 

[riversource]

Man kann sich schon auf DHCP verlassen, nur muss man halt den Geräten, die garantiert immer die gleiche IP haben sollen, IPs zuweisen lassen, die außerhalb der dynamischen DHCP-Range liegen.

Nein, auch das hilft im Zweifel nicht. Wenn der DHCP Server glaubt, dass die IP vergeben ist, wird er sie kein zweites Mal vergeben, völlig egal, ob sie innerhalb oder außerhalb des DHCP Ranges liegen.

 

[Gliese]

Hast du das selbst schon mal so erlebt?
Wie kann eine IP schon vergeben sein, wenn es eine eindeutige MAC<->IP-Zuordnung außerhalb der DHCP-Range gibt und es daher kein Gerät geben kann, der zufällig schon diese IP bekommen kann?
Oder meinst du etwa, ein DHCP-Server hat Probleme mit einem DHCP-Request von der selben MAC-Adresse, wenn schon ein DHCP-Lease von der selben MAC-Adresse mit der zugewiesene IP-Adresse aktiv ist?

 

[Incanus]

Wo Widerspruch?

Habe ich doch erläutert .
Wenn ich einem Gerät sage vergib bitte Adressen von 20-200 dann kann es eben nicht automatisch eine außerhalb dieses Bereiches vergeben. 210 geht also nicht statisch, da außerhalb des Pools, nach meiner Logik.

Ich habe aber dann mal bei AVM geschaut, es geht tatsächlich auch anders:
https://avm.de/service/wissensdaten...che-IP-Adresse-von-FRITZ-Box-zuweisen-lassen/
daraus:

Die IP-Adresse darf von keinem anderen Gerät verwendet werden und muss aus dem IP-Netzwerk der FRITZ!Box stammen (Werkseinstellung: 192.168.178.0). Die IP-Adresse darf innerhalb oder außerhalb des DHCP-Bereichs liegen (Werkseinstellung: 20 bis 200).

 

[riversource]

Hast du das selbst schon mal so erlebt?

Ja, gerade die Woche erst. Ich hab bei mir auch alle IOT Geräte in Gruppen sortiert und im DHCP Server die Adressen zugewiesen, da ich auch Geräte hab, wo man die Adresse nicht händisch einstellen kann. Ich will aber in meinem Pi-Hole wissen, wer da so mit wem reden will, also die statische Zuordnung.

Besonders die Alexas sind störrisch und tauchen immer mal wieder plötzlich mit der .20 in der Liste auf, und müssen dann von Hand wieder auf ihre IP gebracht werden. Aber auch andere Geräte sind immer mal betroffen. Schau ins IPPF in die Firmware-Threads: Praktisch jeder Thread ist voll von Fällen, wo Leute sich beklagen, dass die DHCP Adressen nicht stabil sind.

Will man eine wirklich stabile IP, dann muss man sie fest im Endgerät einstellen.

 

[Gliese]

Wenn ich einem Gerät sage vergib bitte Adressen von 20-200 dann kann es eben nicht automatisch eine außerhalb dieses Bereiches vergeben. 210 geht also nicht statisch, da außerhalb des Pools, nach meiner Logik.

Die IP-Adresse darf von keinem anderen Gerät verwendet werden und muss aus dem IP-Netzwerk der FRITZ!Box stammen (Werkseinstellung: 192.168.178.0). Die IP-Adresse darf innerhalb oder außerhalb des DHCP-Bereichs liegen (Werkseinstellung: 20 bis 200).

Also ist die 210 doch möglich.

Ja, gerade die Woche erst. Ich hab bei mir auch alle IOT Geräte in Gruppen sortiert und im DHCP Server die Adressen zugewiesen,
...
Besonders die Alexas sind störrisch und tauchen immer mal wieder plötzlich mit der .20 in der Liste auf, und müssen dann von Hand wieder auf ihre IP gebracht werden.

wtf?
Darf ich fragen, was für eine Routersoftware du verwendest?

EDIT:
...hab hier überflüssiges entfernt, da Nicht-FritzBox-Content, hier nicht weiterhilft...

 

[Lora]

Will man eine wirklich stabile IP, dann muss man sie fest im Endgerät einstellen.

Am besten in beiden Geräten ^^

 

[riversource]

Darf ich fragen, was für eine Routersoftware du verwendest?

Es geht hier um Fritzboxen. Um nichts anderes. Das grundsätzliche Problem haben aber alle DHCP Server, sie gehen nur im Zweifel unterschiedlich damit um. Die einen riskieren im Zweifel IP Konflikte, die anderen verteilen andere IPs.

 

[Raijin]

Das ist ja ein Widerspruch in sich. Man kann Geräten nicht automatisch immer die gleiche IP zuweisen lassen, die gar nicht automatisch zugewiesen wird.
Also entweder automatisch aus dem DHCP-Pool oder manuell im Client eine Adresse von außerhalb des Pools.

Das ist kein Widerspruch und es funktioniert durchaus, gesetzt den Fall der eingesetzte DHCP-Dienst unterbindet das nicht explizit. Es gibt eine lebhafte Diskussion in der Fachwelt ob statische Reservierungen im DHCP-Server innerhalb oder außerhalb der DHCP-Range anzulegen sind (sofern der DHCP-Server es eben unterstützt).

Der Grundgedanke ist ja: innerhalb = dynamisch und außerhalb = statisch

Und was sind dann statische DHCP-Reservierungen? Eigentlich ja beides, oder? Daher gibt es durchaus Vertreter der Fraktion "statische Reservierungen = außerhalb".

Nein, auch das hilft im Zweifel nicht. Wenn der DHCP Server glaubt, dass die IP vergeben ist, wird er sie kein zweites Mal vergeben, völlig egal, ob sie innerhalb oder außerhalb des DHCP Ranges liegen.

Auch das ist so nicht richtig. Im Spoiler oben habe ich sogar die Option von dnsmasq zitiert, mit der man den Ping-Check explizit deaktivieren kann. Dieser Check ist in keinster Weise zwingend und schon gar nicht im DHCP-Protokoll vorgegeben. Er ist lediglich eine Art Sicherheitsmaßnahme des DHCP-Servers selbst, die er nach Belieben nutzen kann oder auch nicht. Und wie sollte der DHCP-Server ohne Ping-Check zu der Erkenntnis gelangen, dass die IP bereits belegt ist? Sofern er kein gültiges Lease in seiner Liste hat, gar nicht. Wobei das gültige Lease natürlich nur implizit eine Belegung zeigt, aber noch nichts darüber aussagt ob das Gerät aktiv ist oder nicht.



Um mich aber erneut zu wiederholen: Es gibt dabei kein richtig oder falsch.
Das sind alles Konfigurationsmöglichkeiten, die man nutzen kann oder eben nicht. Der Ping-Check ist definitiv eine sinnvolle Zusatzfunktion, aber wenn man bei DHCP-Reservierungen auf Nummer sicher gehen will, müsste man ihn streng genommen ausschalten, weil dann im Zweifelsfalle ein IP-Konflikt entsteht, der auffällt. Das kann je nach Szenario besser sein als wenn der DHCP entgegen der Reservierung eine alternative IP vergibt und das System plötzlich nicht mehr auffindbar ist, weil die IP sonstwo gelandet ist. Andersherum kann es natürlich auch schlechter sein, weil plötzlich zwei Geräte Kommunikationsprobleme haben und mehr oder weniger gar nicht mehr funktionieren. Wie gesagt, Vor- und Nachteile. Entscheidend ist, dass man weiß wie es konfiguriert ist, wie es funktioniert und was die Konsequenzen sein können. Wer sich blind darauf verlässt, dass DHCP-Server immer so funktionieren wie beim heimischen 08/15 Consumer-Router, der wird eher früher als später bestraft, wenn er denn mal vor einem DHCP steht, der es anders macht.


Dennoch würde ich behaupten, dass es ein allgemeiner Fakt ist, dass 08/15 DHCP in Consumer-Routern immer gleich arbeiten, quasi "Standard", auch wenn es keinen Standard im eigentlichen Sinne gibt.

• Neue IPs +1 hochzählen
• Alte Leases überschreiben, wenn DHCP-Pool ausgeschöpft ist
• Ping Check vor IP-Vergabe
• (optional) Blockieren von DHCP-Reservierungen außerhalb des Pools

 

[Incanus]

Das ist kein Widerspruch und es funktioniert durchaus, gesetzt den Fall der eingesetzte DHCP-Dienst unterbindet das nicht explizit. Es gibt eine lebhafte Diskussion in der Fachwelt ob statische Reservierungen im DHCP-Server innerhalb oder außerhalb der DHCP-Range anzulegen sind (sofern der DHCP-Server es eben unterstützt).

Die lebhafte Diskussion kann ich nachvollziehen, denn auch wenn statisch, ist es eine automatisch vergebene Adresse. Diese außerhalb des Pools der automatisch zu vergebenen zu wählen ist für mich ein eklatanter Widerspruch.

 

[riversource]

Auch das ist so nicht richtig. Im Spoiler oben habe ich sogar die Option von dnsmasq zitiert, mit der man den Ping-Check explizit deaktivieren kann.

Wenn ich sehe, wie viele Geräte in meinem Netz nicht auf Pings reagieren, dann ist das reichlich nutzlos.

Und wie sollte der DHCP-Server ohne Ping-Check zu der Erkenntnis gelangen, dass die IP bereits belegt ist?

ARP Sweep? Auf ARPs reagieren sie alle.

 

[Gliese]

Diese außerhalb des Pools der automatisch zu vergebenen zu wählen ist für mich ein eklatanter Widerspruch.

Ich verstehe den Widerspruch nicht.
DHCP macht man primär dann, wenn man die Verteilung der IP-Adressen zentral verwalten will. Ob statisch oder dynamisch ist und nach welchem Muster man sie festlegt, ist erstmal egal.

Man kann das Layout z.B. auch so gestalten:
192.168.178.1-192.168.178.19: Direkt am Client ohne DHCP statisch vergebene IPs
192.168.178.20-192.168.178.200: Per DHCP dynamisch vergebene IPs ohne dem Gerät eine Garantie für eine bestimmte IP zu geben
192.168.178.201-192.168.178.254: Per DHCP statisch vergebene IPs
Das erscheint mir nicht nur "nicht widersprüchlich", sondern sogar noch sauber.

Wie gesagt, man kann es so machen wie man will.
Wenn das mit der Vergabe mit der Fritte nicht stabil läuft, dann ist das natürlich schade.

 

[Raijin]

Diese außerhalb des Pools der automatisch zu vergebenen zu wählen ist für mich ein eklatanter Widerspruch.

Für viele andere eben nicht. Versteh mich nicht falsch, ich verlasse den DHCP-Bereich auch nicht mit statischen Reservierungen, aber ich sehe es nicht unbedingt als Widerspruch, schon gar nicht als eklatanten Widerspruch, es anders zu machen. Es ist letztendlich eine Frage der Definitionsrichtung. Bei einer statischen Reservierung einer dynamischen DHCP-IP stecken nun mal beide Begriffe drin und je nachdem aus welchem Blickwinkel man es nun betrachtet, definiert man sie als statisch oder dynamisch.

Am Ende spielt es meines Erachtens auch keine große Rolle wie man es handhabt, weil statische IP-Adressen - seien sie nun tatsächlich statisch am Gerät definiert oder im DHCP statisch reserviert - so oder so gewissenhaft dokumentiert werden wollen. Tut man dies nicht, egal welchen man Weg nun gegangen ist, führt es auf die eine oder andere Weise auf kurz oder lang zu Problemen, und sei es auch nur die Vergesslichkeit des Alters

Nicht immer sind alle anderen Meinungen per Definition falsch, nur weil man es selbst anders sieht. Andersherum ist auch die eigene Meinung nicht per Definition falsch, nur weil andere es anders sehen.
Es können auch beide Meinungen richtig sein, wenn sie unter anderen Bedingungen gebildet wurden. Großes Aber: Die Bedingungen müssen dennoch mit gesundem Menschenverstand betrachtet worden sein. Das ist also keinesfalls eine Entschuldigung für Anhänger von Verschwörungstheorien, denen ich besagten Verstand explizit abspreche.

ARP Sweep? Auf ARPs reagieren sie alle.

Touché, damit hast du natürlich Recht. Wobei man theoretisch auch ARP abschalten bzw. ignorieren kann. Unter Linux ein simpler sysctl Befehl. Ich kann mir zwar kein Szenario vorstellen, in dem das sinnvoll wäre, aber die Option ist da. Wird sich wohl irgendwer was dabei gedacht haben.


Die Diskussion führt aber mittlerweile zu weit, wenn ihr mich fragt. Beitrag #1 ist geklärt und das Problem so wie ich es verstanden habe ist gelöst. Von mir aus können wir das Thema gerne noch weiterdiskutieren, aber dann vielleicht lieber in einem separaten Thread, der sich nur um dieses Thema dreht.