Seit einiger Zeit plage ich mich bei meinem Raspberry Pi mit Netzwerkproblemen im Zusammenhang mit USB-WLAN-Adaptern rum. Um rauszubekommen, ob es sich um ein plattformspezifisches Problem handelt, habe ich die USB-Adpater ein Lenovo ThinkPad mit BunsenLabs Linux gesteckt. Auch hier traten – wenn auch ganz andere – Probleme auf.

Das Problem

Während ich unter Raspbian genau eine WLAN-Verbindung g aufbauen konnte und danach aus Interface im Zustand unavailable versank und nur noch mit einem Neustart zu wieder genau einer Kooperation zu überreden war, bekam ich am Laptop gar keine Verbindung aufgebaut. Mit nmcli device monitor <ifname> konnte ich verfolgen, wie immer wieder der Verbindungsaufbau begonnen wurde, dann aber ohne aussagekräftigen Fehlertext abbrach.

Nach einiger Suche fand ich in /var/log/messages die folgenden beiden Zeilen:

Feb 10 10:15:36 Thinka kernel: [115379.120208] wlxe4beed0d150b: authenticated  
Feb 10 10:15:41 Thinka kernel: [115384.123033] wlxe4beed0d150b: aborting authentication with XX:XX:XX:XX:XX:XX by local choice (Reason: 3=DEAUTH_LEAVING)

Die Authentifizierung scheint erfolgreich zu sein (erste Zeile) und dann sag irgendwas lokal im System “Nö, doch lieber nicht…” (zweite Zeile)?

Das muss man nicht verstehen, aber nun hatte ich einen markanten String, den ich an Google verfüttern konnte.

Eine Lösung

Der erste Suchtreffer versprach eine einfache Lösung:

ln -s /dev/null /etc/systemd/network/99-default.link

Nun, was hier vordergründig passiert, verstand ich sofort: In die Konfiguration des systemd wird Link auf /dev/null gesetzt. Was dies genau bewirkt, entzog sich zunächt meiner Kenntnis. Auch ohne zu wissen, was konkret passiert, erschien mir das Risiko überschaubar und ich probierte es aus.

Nachdem ich den USB-Adapter abgezogen und wieder angesteckt hatte, funktionierte es.

Die Änderung führte dazu, dass das Netzwerkinterface nicht mehr den Namen wlxe4beed0d150b, sondern wlan0 zugewiesen bekommt. Das freut scheinbar nicht nur mich als Menschen, sondern auch den NetworkManager, der auf den Notebooks die Netzwerkverbindungen verwaltet. 😉

Es blieb immer noch die Frage nach dem Wie.

Wie es funktioniert

Einen ersten Hinweis bekam ich, als ich den Link auch auf meinen Raspberry Pie anlegen wollte. Die Datei existierte schon. Nicht als Link, sondern als reguläre Textdatei:

# This machine is most likely a virtualized guest, where the old persistent
# network interface mechanism (75-persistent-net-generator.rules) did not work.
# This file disables /lib/systemd/network/99-default.link to avoid
# changing network interface names on upgrade. Please read
# /usr/share/doc/udev/README.Debian.gz about how to migrate to the currently
# supported mechanism.                                                                                                                                        

Die Datei /lib/systemd/network/99-default.linkhat den folgenden Inhalt:

[Link]
NamePolicy=kernel database onboard slot path
MACAddressPolicy=persistent

Mit dieser Vorgabe wird die Namensvergabe durch den systemd für die Netzwerk-Interfaces gesteuert (siehe Dokumentation bei freedesktop.org). Entsprechend der üblichen Vorgehensweise liegt unterhalb von /lib/systemd/network/ die Referenzkonfiguration, die durch die Konfiguration unterhalb von /etc/systemd/network/für die jeweilige Installation angepasst wird.

Die bessere Lösung

Blieb noch die Frage, weshalb ein Link nach /dev/nullangelegt wurde. IMHO ist dies ein kruder Hack, der aus Bequemlichkeit (oder empfundener Cleverness) gewählt wurde: Durch den Link spart man sich das Anlegen einer regulären Datei (und natürlich auch den Plattenplatz).

Für mich ist das Vorgehen überclever: Falls ich jemals wieder an die Stelle vorbeikommen würde, würde ich mich fragen, was zum Teufel da los ist: Eine Datei, die nach /dev/nullverlinkt ist?!??!

Der Lösungsansatz, den ich auf dem Raspberry Pi vorgefunden hat, überzeugt mich mehr:

• Er tut, was er soll
• Er dokumentiert das Vorgehen und macht es damit nachvollziehbar.

Ich habe den Link auf /dev/null durch eine Datei mit entsprechenden Kommentarzeilen ersetzt.

Was bleibt

Mein ursprüngliches Problem mit dem Raspberry Pi unter Raspbian lässt sich auf dem Weg leider nicht lösen. Dort hießen die WLAN-Interfaces schon immer ganz ordentlich wlan0, wlan1,…

Update 23.02.2019

Überschriften eingezogen und Text ab der Überschrift Wie es funktioniert überarbeitet und ergänzt.