Zugegeben, die Überschrift ist etwas reißerisch, aber ich habe mich ziemlich (auch über mich) geärgert und entsprechend viel Zeit in die Behebung investiert.
Mein Salon-Plotter (Raspi 5) ist eigentlich ein Server zum Zusammenführen der Bord-Daten und da der Rapberry-Pi aus historischen Gründen auch einen Bildschirm hat, gleichzeitig mein Reserver-Plotter. Der lief letzte Saison mit Debian 13 (Trixie) und mit einer Beta-Version von AvNav, während der eigentliche Cockpit-Plotter mit Debian 12 (Bookworm) und einer Release-Version von AvNav arbeitet. Das lief halbwegs während der (zu kurzen) Saison. Zurück im Winterlager habe ich dann versucht, ein Update beim Salon-Plotter einzuspielen, anschließend war die Benutzerführung geändert (das war aber im Segeln-Forum für die Beta angekündigt) und der WLAN-Client funktionierte nicht mehr. Letzteres war ziemlich unangenehm, da sich der Plotter damit im Winterlager in das heimische Netz verbindet und ich aus dem warmen Büro remote auf den Plotter mitsamt angeschlossener Peripherie zugreifen kann. Die Aussicht im ausgeräumten Boot bei zunehmend frischen Temperaturen den Plotter zu konfigurieren war wenig einladend, also muss der WLAN-Client als erstes wieder laufen. Da sich abzeichnete, dass das Problem mehr Zeit in Anspruch nimmt, habe ich mich für eine komplette Neuinstallation mit einer Release-Version von AvNav entschieden (also Bookworm statt Trixie), damit die Benutzerführung zwischen Cockpit und Salon gleich bleibt, außerdem befürchte ich, bei der Beta-Version u.U. mit weiteren Fehlern konfrontiert zu werden, die noch mehr Zeit kosten.
Also Image herunter geladen, SD-Karte geschrieben und die vorab gesicherten Einstellungen zurück gespielt. Dann das böse Erwachen – auch hier funktioniert der WLAN-Client nicht. Auffällig war, dass der USB-Pfad des Netzwerkadapters sich auch geändert hat. Der ist an einem externen Hub angeschlossen und es sah so aus, als ob es den Hub im System zwei mal gibt für einige Anschlüsse. Damit AvNav diesen Adapter als WLAN-Client konfiguriert, muss eine passende UDEV-Regel konfiguriert sein, die jetzt nicht mehr stimmte. Die Anpassung war schnell gemacht und damit wurde seitens AvNav der WLAN-Client wieder aktiv – aber leider immer nur für einige Sekunden oder manchmal auch Minuten. WLAN-Stick defekt? Nein, mit einem anderen WLAN-Stick trat das gleiche Verhalten auf. Zum Testen musste ich jedes mal ins Boot steigen, neu konfigurieren und im Büro dann feststellen, dass es wieder nur kurze Zeit funktionierte. Nach zweitägiger Suche fand ich dann den entscheidenden Hinweis bei Github. Die Ursache liegt in einer Änderung im Linux-Kernel, zwischen 6.11 und 6.12 scheint sich bzgl. USB3-Schnittstellen etwas geändert zu haben. Bisher war mein USB3-Hub auch an einem USB3-Port am Raspi 5 angeschlossen und der WLAN-Stick ist auch USB3-fähig (5.000 Mbit). Beim Kernel 6.11 wurden die angeschlossenen USB3-Geräte nur im USB2-Mode (480 Mbit) initialisiert und alles war bestens, jetzt existiert der USB3-Hub doppelt, einmal für USB2 und einmal für USB3 und die angeschlossenen Gerät werden entsprechend ihrer Kompatibilität zugewiesen. Deshalb die Änderung des USB-Pfads.
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/2p, 480M
USB3 ist eigentlich zu begrüßen, beim Raspi verursachen schnelle USB-Geräte aber WLAN- und Bluetooth-Störungen (bekannt von SSDs). Also müssen die USB3-Geräte auf den langsamen USB2-Modus gebracht werden. Beim aktuellen Kernel ist der Schnittstellen-Treiber „rtw_8822bu“ in der Version 27 integriert, auf Github ist aber die Version 30 verfügbar, die einen Schalter zum Beibehalten von USB2 enthält (switch_usb_mode). Eine Möglichkeit wäre, den Treiber per DKMS einzubinden und entsprechend zu konfigurieren (switch_usb_mode=n). Ich habe statt dessen den USB3-Hub beim Raspi 5 an einen USB2-Anschluss eingestöpselt. Danach musste ich zwar alle USB-Pfade in der Plottersoftware (AvNav, signal-k) neu konfigurieren, aber seit dem arbeitet der WLAN-Client wieder stabil.
Keine Kommentare:
Kommentar veröffentlichen