Tinkerboard S verliert alle paar Tage Netzwerkverbindung

[riggert]

Hallo,

ich habe ein seltsames Phänomen:
- raspberrymatic 3.47.18.20190918 auf Tinkerboard 2
- RedMatic 5.2
- ccu historian 2.2.3
- LAN Verbindung direkt an der Fritzbox, habe auch einen switch dazwischen probiert

Alles läuft einwandfrei, nach ein paar Tagen fängt die blaue LED an schnell zu blinken.
Die CCU ist dann nicht mehr erreichbar, kein WebUI, kein ssh, kein ping.
Allerdings scheint mir das Tinkerboard NICHT neu zu booten, die CCU Programme, die z.b. bei einer Aktor-Änderung auslösen funktionieren noch einwandfrei. Von daher gehe ich nicht von einem Absturz und einer reboot-Schleife aus.
Netzwerkkabel trennen und wieder verbinden hilft nicht.
Nach reboot, funktioniert sofort wieder alles einwandfrei.
Leider deshalb keine logfiles, die evtl. ermöglichen würden, das Problem einzukreisen.

Ich sehe jedoch folgendes auf meiner Fritzbox nachdem ich mal die Änderungsnotiz für Anmeldung von Geräten eingeschaltet habe:

Code: Alles auswählen

Die folgenden Netzwerkgeräte haben sich erstmalig mit Ihrer FRITZ!Box verbunden.
Datum                      Name                    IP-Adresse       MAC-Adresse             Verbindungsart
06.11.2019 20:08:31	PC-MEINE_IP	    MEINE_IP         XX:XX:56:41:XX:XX    <leer>

Diese Meldung taucht alle 3 Minuten auf.
Das seltsame dabei ist:
1. die MAC Adresse ändert sich jedes Mal: hier byte 2 und 3
2. die Verbindungsart ist leer/nicht angegeben

Die zufällige MAC-Adresse riecht doch nach WLAN MAC Address randomization?
So weit ich es sehe, ist per default jedoch der WLAN adapter per SW disabled.

Nach einem Neustart meldet mir die Fritzbox

Code: Alles auswählen

Die folgenden Netzwerkgeräte haben sich erstmalig mit Ihrer FRITZ!Box verbunden.
Datum	                Name	                 IP-Adresse       MAC-Adresse	       Verbindungsart
06.11.2019 20:30:05	MEIN_HOSTNAME        MEINE_IP        XX:XX:AA:BB:XX:XX    LAN1

Hier entspricht die MAC-Adresse auch der eth0 MAC Adresse des LAN Adapters.
Darüberhinaus sehe ich keinen weiteren oder parallelen Versuch eine Verbindung mit einer randomized MAC zu versuchen.

Kann sich das jemand erklären?
Tipps wie ich es Debuggen könnte?
Bin mir nicht sicher ob das /var/log/messages file aus den USB stick zu verschieben etwas helfen würde. Ich würde vermuten ich würde einfach nur Netzwerkfehler NACH Ausfall des links sehen.

[hoedlmoser]

nach ein paar Tagen fängt die blaue LED an schnell zu blinken.

wie hoch ist die lease time für dhcp auf deiner fritte eingestellt? korreliert das eventuell?

[riggert]

sehr interessanter Gedanke.
Ich verwende allerdings eine feste IP.
Lease time is 10 Tage. Tatsächlich ist das delta nah dran - 11 Tage dachte schon bingo.
Davor jedoch war es mal 5, mal 2 Tage - korreliert also nicht wirklich.

Ich könnte mal mit der lease testen, ob ich es provozieren kann (warum auch immer, wenn ich feste IPs verwende, Kollision?) oder mal testweise wieder auf dhcp umstellen.
Kann man auf der Fritte evtl. den link layer testen, wenn ich das Tinkerboard direkt dran habe? Dann könnte ich evtl. auf HW vs. SW stack schliessen.

[dondaik]

für mich wäre die frage wer da anfängt MAC adressen zu würfeln .
die fritte behält eigentlich ( hier ) eine fest zugewiesen IP für eine MAC - Adr ewig,

[hoedlmoser]

feste IPs verwende, Kollision?)

Deine fixe IP liegt aber eh nicht im DHCP range?!

kann man auf so einer fritte eigentlich die ARP table abfragen? also welche IP aktuell welche MAC hat?

[dondaik]

kann man sehen....

[riggert]

feste IP liegt nicht im DHCP IP range.
Habe jetzt mal spasseshalber auf DHCP umgestellt (gleiche IP, Fritzbox: immer gleiche IP zuweisen) - die Fritte kann ja DHCP Adressen auch ausserhalb der DHCP range vergeben.
Btw. MAC is korrekt in der Fritzbox und entspricht der eth0 MAC - alles gut.

Theorie:
Die gewürfelten MAC Adressen kommen vom WLAN interface das evtl. neu gestartet wird und erst von /etc/network/if-up.d/eQ3StartNetwork per SW disabled wird (MAC randomization WLAN clients?).
Das würde bedeuten, da es alle ca. 2min passiert im Fehlerfall, dass die interfaces permanent runterfallen und wieder hochfahren.
Dann aber müsste ich zumindest zeitweise einen erfolgreichen ping durchführen können - hier muss ich wohl warten bis es wieder passiert. Ich habe zwar gepingt ohne Erfolg, aber vielleicht einfach nicht lange genug um das if-up Fenster zu erwischen - wenn es eines gibt.

Dann würde sich die Frage stellen, warum die interfaces runterkrachen.

[riggert]

kleines update, heute ist es schon wieder passiert.
korreliert definitiv nicht mit DHCP lease times.

Beobachtungen:
- ping sporadisch möglich, mal up/mal down -> sieht also so aus als würde das eth0 device bzw. ifup/ifdown durchlaufen werden, permanent
--> monit?
- watchdog Variable "WatchDog-Alarm" variable allerdings scheinbar nicht gesetzt -> monit würde sie ja bei Auslösen setzen. Ich sehe im CCU historian allerdings keine Auslösung. Leider wird die Variable bei Neustart geresetet, kann man den Zustand beibehalten?
- schreibe inzwischen logs auf einen rsyslog server -> keinerlei Einträge vor dem Fehler (evtl. schon zu spät um UDP Nachricht zu schicken)
- sehr seltsam und kann eigentlich kein Zufall sein:
Das ganze passierte ungefähr zu der Zeit als wir nach Hause kamen.
Ich benutze hm_pdetect um WLAN logins in Systemvariablen zu schreiben. Kann mir zwar nicht erklären wie das zusammenhängen soll, aber ist schon sehr merkwürdig. Mein geofence (pocket control) meldete mir um Ankunft um 14:29 (ca. 500m Entfernung vom Haus), dann Auto ausladen und ins Haus.
Ab 14:34 bekomme ich die o.g. logs von der Fritte.
Das kann doch kein Zufall sein....

Werde jetzt mal hm_pdetect ausschalten und schauen wie's hier weitergeht. Könnte natürlich auch node-red sein, dass die Zustände hier auswertet und Variablen ändert - ist ja aber ein Standardfall...

[riggert]

Update: seit ich hm_pdetect deinstalliert habe, bisher keinerlei Probleme.
Habe die Anwesenheit-Erkennung im ähnlichen Umfang mit Red Matic implementiert- alles gut.

[AitschPi]

Hm, schon länger her. Aber bei mir passiert das nun auch beim TinkerBoard S. In noch unbestimmbaren Abständen kommt die Mitteilung der FritzBox über neues Netzwerkgerät. Da aber ein anderer DHCP-Server (Raspberry mit dnsmasq) die fest zuteilt, sind IP und Mac gleich.

CCU (raspberrymatic) ist nicht erreichbar, blaue LED blinkt schnell. Und nach Neustart steht im Logfile nichts drin (ist ja das Boot-Protokoll).

Hat das jemand noch?

(Raspberrymatic aktuell. Das trat aber schon vorher in den letzten beiden Monaten auf. Das oben besprochene detect-addone hatte ich nie drauf.)