Habe gleich die Radikalkur gemacht. Bensheim 002, 006 und 014 sind komplett neu aufgesetzt. Einzige Änderungen zur Defaultinstallation: SSH-Passwort gesetzt und Koordinaten eingetragen. Keine Änderungen an LAN oder WLAN (musste dafür einen alten Switch reanimieren).
Bensheim-015 hängt auf dem Dachboden und hat privates WLAN, da komme ich gerade schlecht dran. Mal sehen, was heute so passiert.
So, ich melde Vollzug: Ich habe alle meine 4 Knoten sauber neu geflashed, und kurz bevor ich nach Hause gekommen bin, ist einer einfach so neu gestartet. Dann habe ich mein altes Experiment wiederholt (mit 2 Android-Geräten einmal zwischen den 4 Knoten geroamed) und dabei ist schon der nächste neu gestartet (Bensheim-006). Auf dem Rückweg dann Bensheim-015. Das ganze ist also halbwegs reproduzierbar.
Einer der Knoten hat eine serielle Schnittstelle dran, soll ich mal versuchen, die zu loggen und den Fehler zu reproduzieren? Oder warten wir einfach getrost auf 2016.2?
Zu meinem Test: Eben habe ich ein Nexus 6 benutzt (das hat praktisch auf zweidrittel der Strecke zum nächsten Knoten alleine geroamed) und ein Telekom Puls Tablet (das musste ich meist direkt am Knoten zum roamen forcieren, indem ich WLAN kurz aus- und wiedereingeschaltet habe. Kann das aber gerne mal mit anderer Hardware wiederholen, hätte so ziemlich alle Betriebssysteme im Angebot.
War wieder innerhalb von Minuten reproduzierbar, der zweite Reboot war dann schon der Knoten mit der Seriellen Schnittstelle dran. Viel Glück bei der Analyse…
Edit: Obwohl ich nur zwischen 3 Knoten geroamed bin (Kind schläft schon im Dachgeschoss, der 4. Knoten hängt auf dem Dachboden), sind interessanterweise alle 4 sogar neu gestartet, wie ich gerade im Grafana sehe.
Das ist diesmal sogar sehr hilfreich. Es sieht tatsächlich so aus als gäbe es einen Bug im ath9k WLAN Treiber. Gucken wir mal ob sich das mit Gluon 2016.2 und der deutlich neueren Version der Treiber verbessert.