Es tritt auch offenbar nur dann auf, wenn ich ein neues Gerät anschließe oder der Lease einen angeschlossenen Geräts abgelaufen ist.
netspy schrieb:
die Einstellungen zum DHCP-Server ändern (bspw. den Bereich, momentan .20-160 und 31 Tage)
netspy schrieb:
In allen Labor-Versionen der 06.50 gab es solche Probleme nicht. Die sind erst in der Release aufgetreten [...]
http://www.ip-phone-forum.de/showthread.php?t=282924&page=23 => FRITZ!Box 7490 Firmware Version 113.06.50 vom
10.12.2015
Code:
# date
[COLOR="#FF0000"]Thu Dec 24[/COLOR] 13:05:18 CET [COLOR="#FF0000"]2015[/COLOR]
:gruebel:
Ich bin etwas verwirrt ob der (vermeintlichen?) Widersprüche ... aber vielleicht habe ich ja auch etwas fundamental falsch verstanden?
Ich würde das WLAN der Box abschalten, die LAN-Verbindungen - so vorhanden - kappen und in der Box (die Frage wäre dann, womit ... komme ich gleich drauf zurück) alle bekannten Clients löschen, notfalls nach Neustart, falls die Box den Verlust des Kontaktes zu einigen Clients nicht sofort mitbekommt und sich weigert, diese zu löschen. Dann den DHCP-Server auf sinnvolle Werte konfigurieren (das ist in der Regel sogar eine
kürzere Lease-Time als die 10 Tage, die AVM vorgibt) und die Geräte der Reihe nach wieder anmelden, Clients mit fester IP-Adresse zuerst.
"Anmelden" meint hier nicht nur die Herstellung einer WLAN-Verbindung für die so verbundenen Geräte, sondern einen Internet-Zugriff von einem solchen, damit die FRITZ!Box auch bei fester IP-Adresse von dem Gerät "Notiz nehmen" kann.
Wenn das Gerät dann noch von sich aus z.B. mDNS benutzt, sollte auch der passende Client-Name irgendwann in der FRITZ!Box auftauchen - ob LLMNR noch in 06.50 unterstützt ist, weiß ich nicht ... das findet man beim Vorhandensein passender Clients aber in den Support-Daten der Box zu den "neighbors" sehr schnell heraus.
Ohne solche Dienste verwendet FRITZ!OS m.W. eine DHCP-Client-ID, sofern vorhanden, zur Anzeige des Namens und natürlich auch zur DNS-Auflösung für die lokale Domain (Standard "fritz.box") - die sollte man bei Geräten mit fester IP-Adresse auch als Kandidatin für eine Suchdomain hinterlegen, weil diese Geräte natürlich nicht per DHCP entsprechend konfiguriert werden.
Je nachdem, wie ein Client DNS-Abfragen macht, fügt die FRITZ!Box einer Namenssuche ja nicht selbst die passenden Domains hinzu und so klappen Abfragen für "NAS" o.ä. auf DNS-Ebene meist nur dann, wenn der Client selbst entsprechende Suchdomains "abklappert" - in diesem Falle dann eben auch nach "NAS.fritz.box" fragt. WINS/NetBIOS-Namensauflösung ist wieder etwas anderes, da werden auch Broadcasts mit genutzt.
Die schon angesprochenen Support-Daten sollten vor dieser ersten Neuanmeldung jedenfalls keine bekannten LAN-/WLAN-Clients aufweisen (auch der Abschnitt "landevices" der ar7.cfg nicht). Wenn AVM nicht in letzter Minute noch geändert hat, wirkt sich die eingestellte Lease-Time nicht direkt auf das automatische Löschen einen Eintrags für einen bekannten Client in der FRITZ!Box aus, aber sie hat eben (m.E. negative) Auswirkungen auf die Annahmen eines Clients, nach welcher Zeit er seinerseits seine Reservierung erneuern muß.
Da sind 31 Tage - noch dazu bei einem Client, der mehr oder weniger regelmäßig die Verbindung zur Box kappt, wenn er Strom sparen will - in meinen Augen geradezu prädestiniert für künftige Probleme. Ein Client, der sich regelmäßig bei der Box meldet und seine Lease erneuert, kriegt in der Regel auch ohne "immer dieselbe Adresse"-Checkbox eine "relative feste" IP-Adresse vom FRITZ!Box-DHCP-Server. Will man das in eine "richtige feste" IP-Adresse verwandeln, setzt man die richtige Checkmark.
Mal grundsätzlich (wer nicht will, springt über den Absatz) ... das DHCP-Protokoll sieht eigentlich vor, daß ein Client - nachdem er seine Adresse erhalten hat - diese auch bis zum Ablauf der bei der Akquise übermittelten Lease-Time ohne erneute Anfrage beim DHCP-Server verwenden
darf, solange er sie nicht vorher in irgendeiner Form wieder freigegeben hätte (DHCPRELEASE). Selbst wenn der Client also keine Antwort von einem (genauer seinem, denn er muß sich merken, welcher Server ihm die Adresse gab) DHCP-Server erhalten sollte - immer unter der Voraussetzung, daß er überhaupt nachfragt -, könnte er also problemlos innerhalb der Lease-Time des letzten Requests dieselbe Adresse weiterhin verwenden. Schon von daher ist es keine so richtig gute Idee, eine so extrem lange Lease-Time zu verwenden. Wird zwischendrin aus irgendeinem Grund der DHCP-Server neu gestartet und führt der nicht ordentlich Buch über die vergebenen Adressen, kann auf diesem Weg die Situation eintreten, daß zwei Clients dieselbe Adresse verwenden. Nirgendwo steht geschrieben, daß ein Client bei jeder Aktivierung seiner Netzwerkverbindung eine neue Adresse akquirieren
muß, wenn die alte noch nicht abgelaufen ist oder von ihm explizit freigegeben wurde. Kriegt also ein Client die .20 und die Box notiert das nicht richtig, die FRITZ!Box wird neu gestartet und jetzt erhält der nächste Client die .20 von der FRITZ!Box, ist das Chaos vorprogrammiert. Am Ende ist es jetzt Sache des Clients, wie er mit einer solchen Lease umgeht ... wenn er nach dem Aufwachen aus einem "sleep state" eine neue Adresse anfordern will, sollte er eben vor dem Einschlafen die alte auch wieder freigeben. Das machen m.E. die wenigsten Clients, beim Verlust des Kontaktes zum DHCP-Server geht das ja auch unter Umständen gar nicht. Dann sollte sich eben so ein Client seinerseits merken, wann er die letzte Adresse erhalten hat und wie lange diese für ihn reserviert ist (
RFC 2131, Seite 41, Abs. 2 - T1 und T2 und deren Berechnung auf der Basis der Lease-Time). Die Empfehlung lautet also auch, daß so ein Client nach der Hälfte der angegebenen Lease-Time die Reservierung bereits verlängert. Kriegt er dann keine Antwort, darf er sie trotzdem weiterhin bis zum Ablauf der Lease-Time verwenden. Selbst wenn also der DHCP-Server der FRITZ!Box tatsächlich einem WLAN-Client nicht antworten sollte, ist eigentlich dieser Client selbst daran schuld, wenn er eine vorher geleaste Adresse (immer wieder unter der Einschränkung, daß er sie nicht freigegeben hat) nicht einfach weiter verwendet, solange die Lease-Time nicht um ist. Ob das allerdings tatsächlich so ist, kannst Du ja eigentlich ohne entsprechenden Netzwerk-Mitschnitt nicht wirklich sicher sagen ... Du machst die Schlußfolgerung, der DHCP-Server wäre schuld, ja daran fest, daß die Clients nicht ins Internet (oder ins LAN) kommen. Solange die nicht ihrerseits die vorher verwendete IP-Adresse nach dem letzten Request wieder freigegeben haben und es noch innerhalb der Lease-Time ist,
muß der Server nicht unbedingt antworten (auch wenn er es natürlich sollte) - das wäre also zumindest mal ein I14Y-Problem, an dem
nicht nur die FRITZ!Box schuld ist. Meines Wissens "notiert" die FRITZ!Box selbst sich die Lease-Time gar nicht ... jedenfalls nicht in der /var/flash/multid.leases und wohl auch nicht in "landevices" in der ar7.cfg. Damit wäre dann die Lease-Time im GUI ausschließlich als Angabe für die Clients relevant, wie sie ihrerseits T1 und T2 einrichten sollen. Spätestens nach einem Neustart der FRITZ!Box müßten meines Erachtens sämtliche Informationen,
wann eine bestimmte IP-Adresse von der FRITZ!Box vergeben wurde, verloren sein ... ich wüßte jedenfalls nicht, wie und wo diese einen Neustart überleben sollten. Damit muß die FRITZ!Box entweder eine bereits vergebene IP-Adresse für die anfragende MAC-Adresse in ihrem Büchern finden oder sie muß zwangsläufig eine neue vergeben, weil sie bei den bisher verwendeten keine Ahnung hat, ob deren Clients nicht auf die Idee kommen dürfen, diese weiterhin (und sei es nach deren nächstem Start, die müssen ja aktuell gar nicht aktiv sein) zu verwenden. Wie AVM das handhaben will, wenn die Range "voll" ist, würde mich auch interessieren ... ich vermute mal, dann zählt das, was gerade in Benutzung ist, als reserviert und die erste inaktive Adresse als frei. Wenn also der DHCP-Server tatsächlich "spinnen" sollte, kann er das auf zwei möglichen Wegen ... entweder er antwortet gar nicht (dann hätte der Client das Recht, die alte Adresse weiter zu verwenden und er sollte damit trotzdem arbeiten können) oder der Server lehnt ein solches Ansinnen ab. Wie die Box da aber tatsächlich reagiert, kann man von außen schlecht sehen ... das braucht schon einen Packet-Dump entweder auf dem Client oder auf der FRITZ!Box.
Ich weiß nicht genau, was Du mit der oberen Beschränkung der DHCP-Range bezweckst und was Du mit den anderen Adressen zwischen 160 und dem von AVM vorgesehenen Wert von 200 machst ... aber ich kann (pauschal) jedem, der an den DHCP-Servereinstellungen dreht, nur empfehlen, dabei auch event. vorhandene VPN-Verbindungen nicht aus den Augen zu verlieren, wenn er solche Änderungen
nachträglich vornimmt.
Bei der 06.50 habe ich noch nicht getestet, wo und wie sich AVM die Adressen für VPN-Clients "besorgt" ... früher ging das direkt nach der DHCP-Range los, die beim Anlegen der VPN-Einstellungen aktuell war und wenn dann nachträglich diese Range geändert wird, kann das je nach Änderung unterschiedliche Auswirkungen auf das LAN und/oder VPN-Clients haben. Ob AVM inzwischen bei einer nachträglichen DHCP-Änderung auch die VPN-Konfiguration überprüft und ggf. korrigiert bzw. anpaßt, weiß ich nicht.
Meine Empfehlung für den DHCP-Server in der FRITZ!Box lautet (nur für Leute, die eine solche Empfehlung überhaupt brauchen, man
kann das auch anders lösen und mein Vorschlag ist nur eine solche mögliche Lösung), den auf den originalen Einstellungen zu belassen (wenn man ihn schon braucht) und feste Clients
vor der DHCP-Range zu konfigurieren. Wenn die möglichen 18 Adressen (.2-.19) dafür nicht ausreichen (AVM hat da - in meinen Augen auch "dummerweise" - einen "menschlichen" Ansatz für die Adressen gewählt, ich würde auch von 33 (also 32 + 1) beginnend besser finden, weil man das notfalls noch weiter segmentieren könnte), dann verschiebt man
den Anfang der Range nach hinten.
Ich kann auch nachvollziehen, daß sich Leute (feste) IP-Adressen wie 192.168.100.100 besser merken können als z.B. 192.168.100.129 ... aber aus Netzwerksicht wäre eine 129 (als erste Adresse in einem (denkbaren) Segment 192.168.100.128/25) die "logischere Wahl", wenn man sein internes Netz irgendwie weiter unterteilen will in dynamische oder feste Adressbereiche (und den DHCP-Server entsprechend konfigurieren will). Da ist die 160 schon kein wirklich guter Ansatz (128+32, also 192.168.178.160/27 wäre ein denkbares Segment, aber direkt die 160 wäre in diesem Segment eben die Netzadresse und als Hostadresse ungeeignet) ... eine Begrenzung auf 158 wäre da "logischer" (159 wäre die Broadcast-Adresse im Netz 192.168.178.128/27) und würde die Nutzung eines Subnetzes (direkt) dahinter vereinfachen.
Für Portweiterleitungen u.ä. bietet das FRITZ!OS auch bei Geräten mit festen IP-Adressen, die nicht in die DHCP-Range der FRITZ!Box fallen, die Zuordnung über den Client-Namen (so die FRITZ!Box ihn kennt, was nicht zwingend der Fall sein muß, dann heißt der nur "PC-
mac-address") an. Braucht man für einen DHCP-Client im LAN eine feste IP-Adresse (z.B. für ein NAS, weil die DNS-Auflösung prinzipbedingt eben nur funktionieren kann, wenn das NAS sich gegenüber der FRITZ!Box mit einem Namen zu erkennen gibt), damit andere LAN-Clients ihn zuverlässig auch ohne DNS finden, hilft "diesem Gerät immer dieselbe Adresse zuordnen" in der FRITZ!Box, was dann die gerade zugewiesene IP-Adresse permanent für diesen Client reserviert, selbst wenn sie in der Range liegt und der Client länger als "lease time" Tage nicht zu sehen war.
Wie weit sich die Unterscheidung in der FRITZ!Box zwischen "name" (das ist der Name, den man einem Client im GUI der (Router-)Box geben
kann) und "neighbour_name" (das ist der "erlernte" Name des Clients) nun irgendwann mal endgültig durchsetzt (da ändert sich ja alle Nase lang etwas, wie man auch in den Labor-Reihen bemerken konnte), muß man vielleicht noch abwarten ... zumindest hat sich bei AVM jetzt die Schreibweise "neighbour" offenbar weitestgehend durchsetzen können, mit ganz wenigen Ausnahmen:
Code:
# grep -r eighbor
Binary file bin/avmike matches
bin/supportdata:echo "##### BEGIN SECTION neighbours Neighbors"
bin/supportdata:echo "##### BEGIN SECTION neigh_tracking Neighbor tracking"
bin/supportdata:echo "##### BEGIN SECTION neigh_tracking Neighbor tracking"
:mrgreen:
Bleibt also noch die Frage, wie man eine FRITZ!Box noch "dirigieren" kann, wenn man doch keine (W)LAN-Clients angemeldet haben soll ... dafür bietet sich der Fern(wartungs-)zugang an oder auch eine VPN-Verbindung. Dort angemeldete Clients sind nicht lokal und sollten in der Liste auch nicht als solche auftauchen.
