[Problem] 7590 7.21 Vergisst dns name von Engerät

[disorganizer]

Hallo zusammen, ich habe ein kleines Problem mit einem Endgerät welches auf einem ESP32 basiert.

Dieses hängt per WLAN an einem AVM1200 AP an einem Zyxel Switch.
Dort hängt die 7590 mit sw 7.21
Die 7590 ist dhcp und dns server.

Der AP ist nicht mit im Mesh und hat eine komplett eigenständige ssid an der nur der entsprechende Client hängt.

Der Client hat ein kleines Fehlverhalten: Er schickt alle 4h ein dhcp release und erneuert seine IP.
Er sendet allerdings den Hostnamen korrekt mit.

Wird der Client ans wlan verbunden funktioniert alles.
Der name des Clients wird zu seiner ip aufgelöst von der fritzbox.
Auch der release/renew alle 4h funktioniert und er bekommt immer die selbe ip von der fritzbox.
Namensauflösung ist stabil.

Nach einigen Tagen (2-4) vergisst die fritzbox aber den namen!
Der name ist danach nicht mehr auflösbar, wird aber in der Oberfläche unter Netzwerk weiterhin korrekt angezeigt.
Der Client ist auch über seine IP immer noch erreichbar.

Wird der Client physikalisch neu connected (wlan am ap aus, wlan am ap an) dann geht wieder alles für mehrere Tage.

Hat jemand eine Idee?

Die DHCP Requests sehen (wie gesagt ausser dem release/discover statt nur renew) gut aus.
Das Problem ist reproduzierbar (dauer aber halt... sehr lästig)

Nicht probiert da nicht zielführend zur Problemfindung:
Fixe ip und fixer name. Das geht ja, und ich will ja das eigentliche Problem finden und keinen Workaround basteln

 

[HabNeFritzbox]

Also Name ist gesetzt in FB so wie diesen verwenden möchtest?

Teils ist Gerätename in FB etwas anders als echte Hostname.

ein nslookup auf abc.fritz.Box bringt gleiche Ergebnis wie nur abc ?

Haken für immer gleiche IP zuweisen ist gesetzt?

 

[disorganizer]

Von der fritzbox soll der name der per dhcp vom client kommt (Feld hostname im dhcp request) automatisch gesetzt werden wie das auch für diverse andere Geräte funktioniert.

Die Adresse steht somit nicht auf fix und es ist auch kein hostname auf der fritzbox fest eingetragen.

Nslookup in dem Zustand wo es funktioniert geht mit clientname.fritz.box.

 

[HabNeFritzbox]

Dann bearbeite Gerät in Übersicht auf den Wunsch Hostnamen, und Haken dass immer gleiche IP zugewiesen werden soll.

 

[disorganizer]

Wie geschrieben, das wird ja funktionieren.

Die Frage ist warum das andere (dynamische Zuweisung) eben bei diesem Gerät nicht funktioniert. Aber bei allen anderen (30+) Geräten hier im Netz schon.

Hintergrund ist auch:
Wenn ich weiss warum es nicht funktioniert kann ich das am ESP32 eventuell abstellen (lassen).

 

[sonyKatze]

1. Könntest Du das DHCP-Renew hier als Wireshark-Log anhängen? Dateiendung in „.txt“ ändern.
2. Es passiert also nur, wenn der ESP32 über den FRITZ!Repeater läuft? Wenn der ESP32 direkt an der FRITZ!Box hängt, ist alles OK?
3. Passiert das auch, wenn der FRITZ!Repeater als LAN-Brücke direkt an die FRITZ!Box angeschlossen ist, also ohne den Fremd-Switch dazwischen?

 

[disorganizer]

Noch andere neue info:
Nach ein paar stunden ist der name wieder per fb auflösbar.
Sehr seltsam. Ich muss wohl doch einen pi als sniffer opfern und dauerhaft mitzuschneiden was da genau passiert.
ich habe da so eine vermutung das ggf auch mdns da noch mitspielt und die fritzbox verwirrt

weiss jemand wie genau die fritzbox den dynamischen namen zuweist wenn sowohl per mdns als auch per dhcp der hostname vom endgerät übertragen wird? Und wie da ggf irgendwelche aging timer stehen?


Antworten:
1.
mache ich bei gelegenheit. Kann etwas dauern.

2.
schlecht zu testen da der esp32 ausserhalb der wohnung fix montiert ist in einem gerät

3.
da passiert es auch.
Auch wenn der ap ins mesh aufgenommen wird und über das normale wlan (da habe ich noch andere probleme mit dem esp32 vermutlich aufgrund der grundlast).

 

[sonyKatze]

Passiert das auch ohne Fremd-Switch? Probiere mal ohne AVM-Mesh, also ent-meshen und ganz normal als LAN-Brücke.

 

[disorganizer]

Ist zzt lan Brücke. Das war meine erste vermutung (im Mesh selbst habe ich noch andere Probleme die ich auf hohe Grundlast bei zu niedrigen input buffers zurückführe. Aber ein Problem nach dem anderen )

Anbei 2 tracefiles von dem Bootvorgang des Gerätes. Einmal nur dhcp, einmal alles von und zu der zugeghörigen mac.

Ich lasse den trace mal mitlaufen und schaue wann genau die auflösung weg geht... kann aber ein paar Tage dauern.
In rund 4h schicke ich noch einen trace nach des dhcp "renewals", was im endeffekt aber ein release/renew ist.

 

[PeterPawn]

Parallel dazu würde ich jedesmal die Support-Datei der FRITZ!Box sichern ... da sind nämlich auch Daten zu den verwalteten (lokalen) Domains enthalten, inkl. der dynamisch erzeugten Einträge (getrennt nach "Heimnetz" und "Gastnetz"). Durch den Vergleich zwischen dem Stand bei funktionierender und bei nicht funktionierender Auflösung könnten sich weitere Hinweise auf die eigentliche Ursache ergeben - üblicherweise fügt der "multid" bei der DHCP-Zuweisung den entsprechenden Client den dynamischen Einträgen der Zone hinzu.

Die geplante Reihenfolge bei der Auflösung/Priorisierung von Namen soll wohl sein:

- selbst vergebene Namen im GUI des FRITZ!OS
- per DHCP-Request "gemeldete" Client-Namen
- aus anderen Protokollen (u.a. den mDNS-Meldungen eines Clients) "erlernte" Namen

Damit könnte man zumindest vermeiden, daß "böswillige" Clients per mDNS die Einträge anderer Clients kapern - nur scheint das auch nicht immer 100% zu funktionieren bei AVM. Was wohl ganz gut funktioniert, ist das Vermeiden von Verwirrungen, wenn zwei Clients mit derselben Client-ID beim DHCP-Request aufschlagen ... dann bleibt der erste Eintrag weiterhin bestehen und wird nicht sofort vom zweiten (neuen) wieder verdrängt (was sonst auch wieder eine Art DoS-Attacke auf den DNS-Eintrag eines Clients ermöglichen würde).

Die Support-Daten zeigen dann aber auch auf, aus welcher Quelle welcher DNS-Name kam - hat man Shell-Zugriff zum FRITZ!OS (den kann man ja erlangen, wenn man sich nur genug anstrengt), kann man dem "multid" (das ist der Daemon bei AVM, der sich um DNS/DHCP und noch manches andere kümmert) auch mittels "aicmd" noch ein paar andere interessante Informationen, die bei der Fehlersuche nützlich sein können, entlocken.

 

[disorganizer]

guter punkt. ich sicher die gleich mal mit.
kann man die per wget irgendwie automatisch in einem shell script auf einem rpi sicher lassen?
ich würde dann per cron irgendwie alle stunde oder so mal die support datei sichern. sonst bekomme ich das ja evtl nicht mit

und ja, ich weiss das der esp sich noch etwas seltsam in netz verhält
aber um den Entwickler in die richtige Richtung zu stossen Versuch ich halt zumindest mal rauszufinden warum die fritzbox genau bei der Kiste so komisch reagiert.

[Edit Novize: Beiträge zusammen gefasst - siehe Forumsregeln]

und schon gings wieder nicht. es ist also wohl zufall was die box draus macht:
18:58:02 ging der nslookup noch
18:59:02 ging er nicht mehr
18:58:03 war dhcp release/discover/usw.

trace des dhcp requests anbei. warum die box den namen danach nicht weiter kennt? keine ahnung.
anbei der trace des datenverkehrs. aussen rum ist von dem engerät nichts zu sehen.
nur die weiterhin stattfindenden igmp joins auf die mdns gruppe ohne weitere kommunikation und die regelmaessigen arps zum default gateway.
link los etc gab es nicht.
zugegriffen wurde auf den esp in der zwischenzeit auch nicht.... alles sehr seltsam.
die support datei habe ich nun natürlich nur von dem zeitpunkt wo es nicht mehr geht werde ich dann nochmal machen von dem zeitpunkt wenn es geschätzt in 4h wieder geht und dann vergleichen.

 

[PeterPawn]

Der Download der Support-Datei braucht eine passende Session-ID - wie man die erhält, ist hier: https://avm.de/fileadmin/user_uploa...chnical_Note_-_Session_ID_deutsch_Dez2020.pdf beschrieben. Es gibt aber bereits "fertige Implementierungen" (sowohl in Shell (also zur Verwendung mit "wget"), als auch in vielen anderen Sprachen) und man muß sich nur die zu den eigenen Kenntnissen passende aussuchen. Da hilft eine Internet-Suchmaschine dann weiter - und irgendwelche "Tipps" machen keinen Sinn, weil man die präferierte Sprache/Umgebung nicht kennt.

EDIT: Wobei die optionale Nutzung von PBKDF2 für das Challenge-Response-Verfahren noch "brandneu" ist und bisher nur in den Labor-Versionen 07.24 existiert - aber in keiner Release-Version. Du wirst also im Netz vermutlich nur Implementierungen finden, die noch MD5 zum Hashen der Zeichenkette aus Challenge, Benutzer und Kennwort verwenden.

 

[disorganizer]

und ziemlich genau 22:19 geht es wieder. ich sehe in den dhcp requests von oben wo der dns danach nicht mehr geht und den dhcp requests von jetzt wo er geht keinen unterschied.

die support files habe ich. nach was muss ich schauen?

EDIT:
aus dem post weiter obe:
ging bis: 18:58:02
ging nicht mehr ab: 18:59:01
ging wieder ab: 22:19:01

Ich schreibe mal weiter mit wann es geht und wann nicht um zu sehen ob es immer die selbe zeit ist.

 

[PeterPawn]

nach was muss ich schauen?

Wie wäre es mit "dns"? Dabei stolpert man dann früher oder später automatisch über die Zeile "##### BEGIN SECTION dns_server DNS configuration" und dann hat man praktisch schon die Darstellung der dem "multid" bekannten Zonen gefunden. Wenn da der fragliche Client nicht enthalten ist (in der Zeit, wo er nicht aufgelöst werden kann), erklärt das schon mal das negative Resultat einer Abfrage.

 

[disorganizer]

Danke hätte ich auch selbst drauf kommen können. War gestern wohl doch zu spät.

[Edit Novize: Beiträge zusammen gefasst - siehe Forumsregeln]

wie zu erwarten war er nicht enthalten (bzw beide, dns und inarpa eintrag).

interessanterweise ist er aber sowohl beim dhcpd als auch bei neighbors enthalten.
(mit der richtigen ip).

auch in der neighbors liste ist er mit indentischen Einträgen vorhanden.

die Frage ist also immer noch warum er rausfällt.

EDIT:
das einzige was mir auffällt:
wenn es geht ist in der neighbor liste bei parentuid nichts eingetragen
wenn es nicht geht ist dort der ap an dem er hängt eingetragen.
muss ich aber noch verifizieren ob das bei jedem ausfall der fall ist.
EDIT2:
hat keinen einfluss. gerade geht es immer noch und der neighbor eintrag ist drin. also ist das nicht die ursache.