merkwürdiges Netzwerkproblem - FritzRepeater schickt falsche ARP Respone

[darthvader]

Hallo zusammen,

ich kämpfe gerade mit einem merkwürdigen Netzwerkproblem und hoffe auf Hilfe.

Hier läuft Home Assistant auf einem ODroid Board seit Jahren Problemlos. Kürzlich habe ich das Update auf Home Assistant OS 16 eingespielt. Seither kommt es sporadisch (3-4 mal täglich) dazu, das er im Netzwerk nicht mehr erreichbar ist. Im journalctl habe ich dazu den Grund gefunden:
D.h. er stellt einen IP Adressen Konflikt für 192.168.178.2 fest, die genannte MAC Adresse gehört zu den unten erwähnten FritzRepeater 1200. Nachdem er den Konflikt festgestellt hat, scheint er das Netzwerkinterface ausser betrieb zu nehmen. Wenn ich mich direkt auf der Kiste anmelde und

nmcli device disconnect end0; sleep 5; nmcli device connect end0

ausführe, ist Home Assistant wieder erreichbar.
Es scheint so zu sein, dass HA OS 16 sich bei IP Adresskonflikten anders verhält als früher.

Interessanter wird es, wenn man nachforscht, woher dieser Konflikt kommt. Dazu kurz eine vereinfachte Darstellung meines Heimnetzes:


Die FritzBox 6660 stellt per Kabelnetz die Internetverbindung her. Als DHCP Range ist 192.168.178.20 - .255 definiert. Die FB 6660 und Home Assistant haben statische Adressen, alle anderen Geräte nutzen DHCP, teils mit dauerhaften Adressen. Im Netz gibt es zwei Fritz Repeater die mit der FB als Mesh konfiguriert sind. Einer der Repeater - ein 1200 - ist in der Garage angebracht, wohin die WLAN Verbindung gerade noch ok ist. Hin und wieder sehe kurzfristige ich Abbrüche. In der Garage sind dann eine Wallbox und ein Shelly Plug ins WLAN eingebunden.

Mit Wireshark habe ich ARP Pakete im Netz aufgezeichnet und gewartet bis der FritzRepeater 1200 mit MAC 32:91:AB:6B:68:98 entsprechende ARP Responses rausschickt. Im Screenshot unten (die letzten beiden Pakete im oberen Abschnitt) sieht man, dass die Wallbox (192.168.178.68) die MAC Adresse von 192.168.178.2 (HomeAssistant) wissen möchte. Merkwürdigerweise meldet sich hier nicht HomeAssistant mit einer Anwort, sondern der FritzRepeater (der 192.168.178.92 hat) und schickt zurück, er sei 192.168.178.2.


So, das wäre die Situation. Meine Fragen:

1) Warum nimmt Home Assistant seit dem Upgrade auf HA OS 16 das Netzinterface raus wenn ein IP Conflict erkannt wird. Hängt das ggf. damit zusammen, dass nun ein aktuellerer Kernel in OS 16 drin ist?
1a) mit `ipv4.dad-timeout=0` könnte man vermutlich die conflict detection ausschalten, das könnte das Symptom heilen aber nicht die Ursache.
2) Hat jemand eine Idee, warum der FritzRepeater eine "falsche" ARP response rausschickt? Dafür habe ich keinen Erklärungsansatz.

Danke vorab für Eure Hilfe.

 

[Lufo]

Ich kann deine Fragen zwar nicht beantworten, aber wäre nicht der einfachste Workaround erstmal zu testzwecken Home Assistent z. B. auf die 192.168.178.3 oder eine andere freie Adresse zu legen und zu testen wie sich das Problem dann verhält?
Noch eine Anmerkung, laut Google Suche gehört der MAC-Bereich 00:1E:06 zu einem Hersteller namens WIBRAIN, der Bereich 32:91:ab scheint nicht fest vergeben zu sein.
Ist evtl. ein WLAN-Gerät, z. B. Handy, Tablet, Drucker etc. (manchmal) mit dem Repeater verbunden und hat aus welchem Grund auch immer die 192.168.178.2 fest eingestellt?
Wenn du HA auf eine andere IP gelegt hast kannst du ja mal schauen ob auf der .2 noch etwas anderes antwortet

 

[Advocat]

Der zweite MAC Adressen, zum welche Gerät gehört sollte dir bekannt sein.
Einfach ändern, oder ...!
Hast du vieleicht bei die Repeater auch eigene DHCP Pool eingestellt, und der IP 192.168.178.2 ist dabei?

 

[elchmartin]

Ich hatte mal was bedingt ähnliches, hatte ein Mesh-Set von Tenda.
Die APs sollten sich per DHCP Adressen holen, gaben sich aber hin und wieder mal als IPs außerhalb des DHCP-Raumes aus, selbst wenn dort schon ein anderes Gerät manuell diese IP nutzte.

Total nervig und ein Grund, warum das Set wieder rausgeflogen ist.

Ich denke chinesische günstige Elektronik ist wenig zum Datenschnüffeln da. Mehr, um User in den Wahnsinn zu treiben.

 

[Korfox]

Einer der Repeater - ein 1200 - ist in der Garage angebracht, wohin die WLAN Verbindung gerade noch ok ist. Hin und wieder sehe kurzfristige ich Abbrüche.

Das hier könnte durchaus das Problem sein.

So, das wäre die Situation. Meine Fragen:

1) Warum nimmt Home Assistant seit dem Upgrade auf HA OS 16 das Netzinterface raus wenn ein IP Conflict erkannt wird. Hängt das ggf. damit zusammen, dass nun ein aktuellerer Kernel in OS 16 drin ist?
1a) mit `ipv4.dad-timeout=0` könnte man vermutlich die conflict detection ausschalten, das könnte das Symptom heilen aber nicht die Ursache.
2) Hat jemand eine Idee, warum der FritzRepeater eine "falsche" ARP response rausschickt? Dafür habe ich keinen Erklärungsansatz.

Danke vorab für Eure Hilfe.

Zu 1) habe ich keine Antwort. Aber die Verbundungsabbrüche können dazu führen, dass die Sync des Meshs auseinander fällt (respektive die Anfrage an die FritzBox läuft in ein Timeout oder der ARP-Request droht in ein Timeout zu laufen und der Repeater bedient einfach) und der Repeater versucht die ARP-Anfrage halt irgendwie zu beantworten.
Kannst du den Repeater Mal per Verlängerungskabel oder so näher an der FB positionieren um die Abbrüche auszuschließen und das dann testen? Im Sommer sollte das ja durchaus zumindest nicht an Regen scheitern :-/

 

[cuco]

Klar könnte der Repeater Proxy-ARP machen und behaupten, dass er derjenige sei, während er das in Wirklichkeit nur für die Rechner hinter sich beantwortet. Das wäre gar nicht mal unmöglich, aber dann hat er das natürlich auch nur für die Geräte zu tun, die an dem jeweils anderen Netzwerkinterface hängen.
Ich würde auch mal Ausschau nach den beiden MACs halten. Welche beiden Geräte sind denn das, die hier für den IP-Adresskonflikt sorgen? Das eine wird HA selbst sein. Und welches zweite Gerät (das mit der anderen MAC) ist es noch?

Das HA sich bei einem IP-Adresskonflikt zurückzieht, ist durchaus richtig und hätte vor dem Update eigentlich auch schon so sein sollen. IP-Adresskonflikte sorgen immer für Probleme.

 

[Korfox]

Lese ich sowohl den Screenshot als auch den Text falsch?
Der Repeater selbst ist das zweite Gerät. MAC: 32:91:ab:6b.68:98.
00:1e:7b..99 wird dann der HA sein.

 

[cuco]

Stimmt, sorry, zu viele Sachen gleichzeitig gemacht...

 

[darthvader]

zu testzwecken Home Assistent z. B. auf die 192.168.178.3 oder eine andere freie Adresse zu legen und zu testen wie sich das Problem dann verhält?
Noch eine Anmerkung, laut Google Suche gehört der MAC-Bereich 00:1E:06 zu einem Hersteller namens WIBRAIN, der Bereich 32:91:ab scheint nicht fest vergeben zu sein.

Gute Idee, ich ändere mal die IP des HomeAssistant entsprechend. Das 00:1E:06 Prefix kommt vom Odroid Board, dort läuft Home Assistant.

Hast du vieleicht bei die Repeater auch eigene DHCP Pool eingestellt, und der IP 192.168.178.2 ist dabei?

Nein, der Repeater ist im Mesh eingebunden und hat seine Konfiguration daher von der FritzBox (=Mesh Master) bekommen. Ich verstehe es so, dass es im Mesh genau einen DHCP Server auf dem Master gibt.

Kannst du den Repeater Mal per Verlängerungskabel oder so näher an der FB positionieren um die Abbrüche auszuschließen und das dann testen? Im Sommer sollte das ja durchaus zumindest nicht an Regen scheitern :-/

Das mit Verbindungsabbrüchen und Timeouts ist eine Idee. Kabel kann ich keines ziehen, sind ca. 15m und ginge über mehrere Nachbarsgärten. Ich werde aber versuchen mit Powerline das vorhanden Stromkabel (= 5 x 2,5mm²) zu nutzen. Dazu muss ich noch die passende Phase rausfinden und entsprechend umklemmen.

Lese ich sowohl den Screenshot als auch den Text falsch?
Der Repeater selbst ist das zweite Gerät. MAC: 32:91:ab:6b.68:98.
00:1e:7b..99 wird dann der HA sein.

Richtig, der Repeater ist das zweite Gerät und hat MAC 32:91:ab:6b.68:98.
01:1e:06:42:7b:99 ist der HomeAssistant.
Die ARP Response schickt also der Repeater raus (siehe Sender MAC address).

 

[Advocat]

Nein, der Repeater ist im Mesh eingebunden und hat seine Konfiguration daher von der FritzBox (=Mesh Master) bekommen. Ich verstehe es so, dass es im Mesh genau einen DHCP Server auf dem Master gibt.

Dann nimm andere IPs für beide Repeater. DHCP und Fix, aber nicht im Pool Bereich (192.168.178.20÷254) Z.bsp. 192.168.178.3 und 192.168.178.4.

 

[martina]

Aus solchen Gründen betreibe ich keines der von mir betreuten "Fritzbox-Netzes" mit dem Default-Adressbereich.

 

[darthvader]

Mir ist noch aufgefallen, dass der Repeater anscheinend unterschiedliche MAC Adressen hat.
Screenshot aus Heimnetz | Netzwerk der FB 6660:

Hier sieht man als MAC genau die Adresse, von der die "falsche" ARP Response kam.

Und hier ein Screenshot des Repeaters selbst:

Auffällig ist, dass die MAC bis auf das erste Byte (32 vs 4e) identisch sind.

 

[cuco]

Aus solchen Gründen betreibe ich keines der von mir betreuten "Fritzbox-Netzes" mit dem Default-Adressbereich.

Auch wenn ich das ähnlich mache, ist das für Otto-Normalverbraucher ziemlich irrelevant und wohl auch nicht ursächlich für das Problem. Das könnte in jedem IP-Bereich auftreten.

Mir ist noch aufgefallen, dass der Repeater anscheinend unterschiedliche MAC Adressen hat.
[...]
Auffällig ist, dass die MAC bis auf das erste Byte (32 vs 4e) identisch sind.

Er hat vermutlich 3 MACs. Einmal die Client-MAC, mit der er sich mit der 6660 verbindet, einmal der 2,4GHz-AP und einmal der 5GHz-AP.

 

[Lufo]

Der FritzRepeater wird auch noch eine MAC für die RJ45-Schnittstelle haben

 

[Corvus]

Im MESH wird zu den Repeatern immer eine WPA2/3 Verbindung mit PMF aufgebaut. Lässt sich zwar im Router umstellen, stellt sich aber wieder zurück.
Bei PMF wird die Verbindung alle 6 oder 12 Stunden neu hergestellt.
Bei den Clients steht das im Log, bei den Repeatern passiert es entweder still oder gar nicht, Letzteres glaub ich nicht recht.
Reines WPA2 ohne PMF zu verwenden war bei mir nicht bloß nötig, um gewisse Clients anmelden zu können, es sorgte auch für stabilere Verbindungen mit durchgehend Maximalbandbreite(866mbit/s ist zZ der kleinste gemeinsame Nenner, mit und ohne doppelte Kanalbandbreite, das kann man nicht beeinflussen).
Die Verbindung zwischen Router und MESH Repeatern ist aber immer WPA2/3. Außerdem kann es jederzeit zu DFS Radarerkennung kommen mit Unterbrechung oder Totalausfall auf 5ghz. Die Kanäle 36 bis 48 ausgenommen, es sei denn sie ragen wegen doppelter Bandbreite in den geschützten Bereich. Das kann man aber nicht kontrollieren. Vorübergehend gab es ne Einstellung dafür im FritzOS, aber schon Jahre nimmer.
Das steht dann auch im Log.

Da könnte es nen Zusammenhang mit dem Wetter geben. Wenn bei schlechter Sicht Flugzeuge ihr Wetterradar aktivieren. Und wenn das vom Router empfangen wird bei normaler Flughöhe, dann dürfte es keinen sicheren Ort geben, außer in Sibirien oder Alaska. Ich hab immer mit nem Flughafen in 10 bis 15km Luftlinie entfernt gewohnt, aber nicht in ner Flugschneise, einmal am Grund eines engen Tals. Und Pech gehabt.

 

[Corvus]

Noch was. Auch bei Einstellungsübernahme vom Router muss man beim Repeater die Routerverbindung anhand von MAC Adressen auswählen, während die SSID ja überall gleich ist. Und zwar getrennt für 2,5 und 5ghz.

Bei der Fritzbox 7490 musste man sich bis FritzOS 7.5 auf ein Band festlegen und während Phasen von Radarterror war der Repeater auf 5ghz überwiegend ganz offline, weil bei wiederholtem Auftreten ein immer längeres Timeout zur Neuverbindung kommt, bis zu zwei Stunden Auszeit glaub, aber mind. 30min.
Diesen Monat ist im Log noch gar nichts verzeichnet und im Juni war ne Phase am Ende der Trockenzeit mit Unwettern, was für die Theorie mit dem Rumpfradar der Maschinen spricht, die das gerade nötig hatten.

Dann noch Roaming bei WLAN Clients deaktivieren oder auf konservativ stellen, wo es so etwas gibt wie in Windows-Treibern.
Und für maximale Unterbrechungsfreiheit müsste man noch Band Steering im Router ausschalten, dann wird die Verbindung gehalten bis sie ganz zusammengebrochen ist und nicht vorher Band oder Repeater gewechselt. Bei beweglichen Clients nicht so gut.

 

[Pommbaer]

Die Wege des AVM Mesh sind unergründlich.

Ich habe die Erfahrung gemacht, dass die Repeater von AVM bei reinem WIreless durchaus mal komische Dinge tun.
Habe auch so einen Kandidaten (1200AX) den ich gelegentlich ausstecken muss, da das 5 Ghz Wlan von Zeit zu Zeit wie ein Sack Nüsse läuft.
Danach ist wieder tage- bis wochenlang alles fein.

Alle Repeater die ich über Lan angebunden habe funken seit Installation ohne jegliche Unterbrechung oder Störung. Auch der o.g. Kandidat als er noch am Lan hing (aktuell leider nicht möglich)

 

[Korfox]

Ich starte sowohl die FrritzBox als auch die beiden Repeater im Mesh automatisiert über den Home Assistant alle 7 Tage neu. Das sorgt für Ruhe.
Allerdings bin ich der Meinung, dass man die Frequenz in 5GHz-Band so wählen kann, dass sie nicht dem Flugradar in die Quere kommt (bzw. vice versa). Ich musste/konnte im Repeater aber auch nichts einstellen für das Mesh. Knopf drücken, Knopf drücken, fertig. Jetzt ist in den Repeatern alles ausgegraut.
Sind allerdings 2400er. Vielleicht sind die anders.

 

[Mornsgrans]

Ich tippe auf "Automatische WLAN-Kanal-Wahl". Bei Kanalwechsel geht die Verbindung verloren und je nach Verbindungsqualität funktioniert das wiederverbinden des Repeaters nicht.
Festen WLAN-Kanal wählen und/oder kleiner Standortwechsel des Repeaters oder Routers, um noch 1-2 dB Signalstärke herauszuholen, kann da vielleicht helfen.

 

[darthvader]

Bin bis So unterwegs, daher kann ich Änderungen erst dann ausprobieren.
Der 1200 in der Garage hat nur 5GHz abgeschalten, weil die Wallbox (em2go Home) damit nicht zurecht kommt. Ich bekäme auch die Strecke zur FB 6660 im 5GHz Band nicht abgedeckt.

Übrigens hatte ich seit dem Tag, an dem ich den Thread aufgemacht habe, das Problem nicht mehr beobachten können. Vielleicht hat der 1200 einfach vor dem Thinkpad Forum Angst

@Korfox Den wöchentlichen Reboot werde ich auch einrichten.

@Mornsgrans Ich denke, dass ich schon den optimalen Standort habe. Die (Fertig-)Garage aus Beton hat oben links und rechts ca. 10cm große Löcher zur Belüftung, genau dort ist der 1200 platziert.