Fryboyter

WLAN Stick und Predictable Network Interface Names

Predictable Network Interface Names sind im Grunde eine gute Sache, da der zugeteilte Name des Interfaces immer gleich bleibt. Bei einem USB-WLAN-Stick kann es aber auch nerven.

Wie heute schon geschrieben, habe ich mir den Fritz!WLAN Stick AC 860 zugelegt. Diesen habe ich bei ersten Tests in den USB-Port auf der rechten Seite des Notebooks gesteckt. Der Befehl “ip addr” hat dann zum Beispiel “wlp0s26u1u2” als Interface-Name ausgspuckt, welchen ich in die Konfigurationsdatei von netctl eingetragen habe. Nachdem alles funktioniert hat, habe ich noch etwas herumgespielt und hierbei den Stick auch in den USB-Port auf der linken Seite gesteckt. Und schon konnte ich die Netzwerkverbindung nicht aufbauen. Ein erneutes Ausführen von “ip addr” hat mir nun den Interface-Namen “wlp0s20u2” angezeigt.

Im Grunde genommen ist das auch logisch, da es sich um einen anderen Steckplatz handelt und daher auch ein anderer Name fest zugeteilt wird. Aber in der Praxis ist das ungünstig, da in der Konfiguration von netctl der Interface-Name fix eingetragen wird. Muss ich also zukünftig darauf achten, den Stick immer in den gleichen Port zu stecken? Entweder das oder man erstellt sich eine udev-Regel.

Hierzu schließt man erst einmal den Stick an und führt danach “lsusb” aus. Hiermit erhält man beispielsweise folgende Ausgabe.

Bus 001 Device 004: ID 057c:8503 AVM GmbH

Nun prüft man, wie udev den Stick sieht. Hierzu führt man folgenden Befehl aus.

udevadm info -a -p $(udevadm info -q path -n \_/dev/bus/usb/001/004) | grep ATTR{configuration} 

Hier muss man den Teil mit /dev/bus/usb entsprechend der Ausgabe von lsub anpassen. Im Falle des von mir verwendeten Sticks wird “ATTR{configuration}==“FRITZ!WLAN AC 860”” ausgegeben.

Nun hat man alles, was man für eine udev-Regel braucht. Unter /etc/udev/rules.d/ erstellt man daher die Datei 10-network-devices.rules mit folgendem Inhalt und speichert diese ab. Nutzt man einen anderen Stick, muss man logischerweise bei ATTRS{product} etwas anderes eintragen.

SUBSYSTEM=="net", ACTION=="add", ATTRS{product}=="FRITZ!WLAN AC 860", NAME="wlan"

Schließt man zukünftig einen Netzwerkadapter über USB an, wird geprüft ob dieser das Produkt-Attribut “FRITZ!WLAN AC 860” hat. Wenn ja, wird diesem der Interface-Name “wlan” zugeteilt. Und zwar egal an welchem USB-Anschluss der Stick angeschlossen wurde.

Vielleicht ist es dem einen oder anderen aufgefallen, dass bei dem Befehl mit udevadm ATTR{product} angezeigt wird, in der Regel aber ATTRS{product} steht. Das ist kein Fehler, sondern muss in diesem Fall so sein.

Linux | OSBN

Fritz!WLAN Stick AC 860 unter Linux

In meinem Notebook ist eine Centrino Advanced-N 6205 WLAN-Karte verbaut. Diese verbindet, egal was ich mache, mit maximal 54 MB/s (genutzt wird noch weniger). Laut Google bin ich wohl nicht der einzige mit dem Problem. Also muss etwas her das mehr Bandbreite bietet.

Normalerweise würde ich einfach die Karte wechseln. Was bei Geräten von Lenovo (zumindest bei älteren Modellen) nicht ganz so einfach ist. Denn im Bios / UEFI ist eine Whitelist vorhanden. Somit funktionieren nur bestimmte Karten. Eine offizielle Aufstellung funktionierender Karten gibt es natürlich nicht. Weihnachtsgeld sei dank habe ich mir spontan den WLAN-USB-Stick AC 860 von AVM gekauft.

Im Lieferumfang findet man neben dem USB-Stick auch einen USB-Standfuß sowie eine Anleitung.

Auf dem Notebook ist Arch (Kernel 4.19.9) installiert. Gleich nach dem anschließen des Sticks wird dieser erkannt und startet im sogenannten CD-ROM-Modus. Auf diesem “CD-ROM” sind die Treiber gespeichert. Natürlich für Windows. Das ist zum einen für Linux überflüssig und zum anderen bleibt der Stick in diesem Modus hängen. Super.

Die Lösung ist allerdings ziemlich einfach. Man muss einfach usb_modeswitch installieren. Bei Arch liegt das Paket in den community Paketquellen. Stöpselt man dann den Stick an, startet er im richtigen Modus durch.

Für die Netzwerkverbindungen auf meinem Notebook verwende ich netctl. Hier musste ich nur die Bezeichnung des alten Interface gegen die des neuen in der Konfigurationsdatei austauschen. Und schon steht die Verbindung. Theoretisch sind laut Router 866 / 866 Mbit/s möglich. In der Praxis ist der Stick mit 650 / 780 Mbit/s verbunden und läuft stabil. Mal schauen ob man hier noch etwas an der einen oder anderen Schraube drehen kann. Alles in allem bin ich zufrieden. Endlich kann ich die komplette Bandbreite meines Internetanschlusses auch mit dem Notebook ausreizen. Einen Datentransfer im LAN konnte ich noch nicht testen. Ich gehe aber davon aus, dass das auch keine Probleme macht.

Noch ein Hinweis zum Schluss. Der Stick wird erst ab Kernel 4.19 unterstützt.

Linux | OSBN

WLAN-Verbindung nach Suspend tot

Mein Netbook ist, wie hier schon geschrieben, mit einem WLAN-USB-Stick von Edimax ausgerüstet. An sich läuft dieser auch sehr zufriedenstellend. Wäre da nur nicht ein Problem wenn ich den Rechner per Suspend schlafen schicke.

In der Datei /etc/systemd/logind.conf habe ich eingestellt, dass sobald der Deckel des Netbooks geschlossen wird der Rechner per Suspend to Ram schlafen geschickt wird. Das funktioniert auch soweit. Wecke ich den Rechner wieder auf funktioniert alles nur die WLAN-Verbindung mag nicht mehr. Hierbei ist mir aufgefallen, dass jedes mal wenn ich den Rechner ins Bett schicke die Anzeige am Stick ausgeht aber nach dem Aufwecken nicht wieder an.

Da ich systemd und für die Netzwerkverbindungen netctl nutze habe ich mir kurzerhand eine Service-Datei gebastelt mit der nach dem Aufwecken auch die WLAN-Verbindung automatisch wieder in einen funktionsfähigen Zustand versetzt wird.

[Unit]
Description=Verbindung mit netctl sichern und wiederherstellen
Before=sleep.target
StopWhenUnneeded=yes


[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/bin/netctl store ; /usr/bin/netctl stop-all
ExecStop=/usr/bin/netctl restore 


[Install]
WantedBy=sleep.target

Im Grunde genommen ist das Ganze schnell erklärt. Bevor sleep.target (in dem Fall also Suspend) ausgeführt wird, werden die Befehle abgesetzt, die in der Zeile welche mit ExecStart beginnt stehen. Wenn der Rechner wieder aufgeweckt wird, wird dann noch das ausgeführt, was in der Zeile mit ExecStop eingetragen ist.

Mit netctl store wird abgespeichert, welche Profil gerade aktiv ist. Netctl stop-all stoppt alle Profile. Und netctl restore läd alle Profile wieder, die mit store als aktiv gespreichert wurden. Den Service habe ich dann unter /etc/systemd/system/netctl-restore.service abgespeichert und mittels systemctl enable netctl-restore.service scharf geschaltet. Versetze ich den Rechner nun in Tiefschlaf und wecke ich ihn wieder auf, steht innerhalb weniger Sekunden die WLAN-Verbindung wieder. Einen kleine Schönheitsfehler gibt es aber noch. Ich nutze aus diversen Gründen (wie z. B. wegen der Gema-Blockade bei Youtube) einen VPN-Dienst. Dieser spielt hierbei irgendwie nicht mit. Von daher habe ich die Service-Datei noch einmal bearbeitet und Zeile 10 wie folgt erweitert.

ExecStop=/usr/bin/netctl restore ; /usr/bin/systemctl restart openvpn@vpn.service

Somit wird erst das Profil mit netctl wieder aktviert und danach die OpenVPN-Verbindung neu gestartet.

Linux | OSBN