USB-Ethernet-Adapter scheitern am Plug-and-Play unter Linux

Der USB-zu-Ethernet-Adapter mit Plug-and-Play-Versprechen verbindet sich nicht unter Linux

Den Kauf eines USB-3.0-auf-Gigabit-Ethernet-Adapters für einen Laptop ohne RJ45-Anschluss sollte die einfachste Sache der Welt sein: einstecken, kurz warten und surfen. Bei bestimmten Linux-Kernels bleibt das „Plug-and-Play“-Versprechen genau das: ein Versprechen. Das Gerät erscheint, das System zählt es auf, der Treiber scheint geladen, doch die Netzwerkverbindung kommt nie zustande. Der Ärger bricht aus, wenn der Nutzer genau das braucht: ein Kabel dort, wo WLAN schlecht funktioniert.

Warum verbindet sich ein USB-Ethernet-Adapter unter Linux nicht?

Die Schuld liegt fast nie am Gerät, sondern an der Softwarekette, die es erkennen muss. Der Rechner läuft mit Linux Mint und Kernel 5.4.0-42-generic, und der Adapter ist ein TP-Link UE300/UE330 basierend auf dem Realtek-Chipsatz, der vom Modul r8152 verwaltet wird. Bevor irgendetwas kompiliert wird, ist es sinnvoll, drei Dinge zu prüfen: ob das Gerät in „lsusb“ auftaucht, ob das Modul geladen ist — über „lsmod“ — und ob eine zugehörige Netzwerkschnittstelle existiert, via „ip link“ oder „ifconfig“.

Das Bemerkenswerte an diesem Fall ist, dass der Hersteller Kompatibilität mit Linux und Plug-and-Play-Funktionalität bewirbt. Die Realität ist ein Gerät, das manuelles Kompilieren eines Treibers verlangen kann, wenn die im Kernel integrierte Version Probleme macht. Die Hardware ist mehr als ausreichend; der Support ist knapp bemessen.

Das Treiber-Labyrinth: von Version 2.08.0 bis 2.14.0

Der Versuch der Behebung führt über ein Treiber-Repository für den Realtek-Chipsatz, mit Anweisungen, die buchstabengetreu befolgt werden müssen: in den richtigen Ordner wechseln und „make && make install“ gefolgt von „depmod -a“ ausführen. Das Detail, das verwirrt, ist der Pfad: Es ist nicht dasselbe, von r8152-2.08.0 zu kompilieren wie von r8152-2.14.0, und dies im falschen Verzeichnis zu tun, lässt das Modul uninstalliert, ohne dass ein offensichtlicher Fehler auftritt.

Ab hier vermehren sich die Rezepte. Einige zielen darauf ab, die Kernel-Header zu installieren, „make clean“ auszuführen und das Modul manuell in den Netzwerkordner zu kopieren, wobei „depmod -a“, „modprobe“ und „insmod“ verkettet werden. Andere erinnern daran, dass dieses sehr Gerät seit viel älteren Kernels unterstützt wird — 4.14 wird genannt — und dass das Problem möglicherweise nicht beim Treiber liegt, sondern bei der Netzwerkkonfiguration. Manche schlagen sogar vor, von einem 4.15.0-43-Kernel zu booten.

lsusb, ip link und ping: die Diagnose, die nie eintrifft

Bei einer kabelgebundenen Verbindung entscheidet der Router über die Adressvergabe: Wenn der Adapter seine IP per DHCP erhält, zeigt das typische Gateway auf 192.168.1.1, und es empfiehlt sich, einen bekannten DNS festzulegen, wie Googles 8.8.8.8. Eine ernsthafte Diagnose erfordert das Trennen des WLANs — sonst mischen sich zwei Schnittstellen und die Tests sagen nichts — und das Starten von drei Pings: zum Router, zu einer öffentlichen IP und zu einer Domain.

Das verwirrende Symptom ist, dass das Gerät in den Daten, die der Kernel liefert, zwar erkannt erscheint, aber keine Link-Etablierung sichtbar ist, als wäre kein Kabel verbunden. Die Überprüfung der Interfaces-Konfigurationsdatei hilft wenig, wenn die Schnittstelle gar nicht erst hochkommt. Und in /var/log findet sich keine Spur eines Nachrichtenprotokolls, wo der Fehler gelesen werden könnte.

Lohnt sich der Kampf mit dem Treiber oder ein Adapterwechsel?

Hier spalten sich die Meinungen. Eine Strömung besteht darauf, die Diagnose zu ordnen, bevor zehn Dinge gleichzeitig angefasst werden: „lsusb“, „lsmod“ und die Schnittstellenkonfiguration prüfen, und erst dann kompilieren. Eine andere befürwortet das Booten einer anderen Live-Distribution — oder sogar eines Rescue-Windows — um auszuschließen, dass der Fehler von der Modultversion der Distribution stammt.

Und es gibt den pragmatischen Ausweg: das Gerät verkaufen und einen kaufen, der out-of-the-box funktioniert. Sein Argument ist gesunder Menschenverstand: Wenn der Adapter wenig kostet und sich Stunden häufen, ist ein kompatibles Teil billiger als der Streit. Dagegen spricht, dass der Hersteller es als fabrikseitig kompatibel verkauft und es nach dieser Logik ohne Drama funktionieren sollte. Dazwischen tauchen Hausmittel auf, wie das Testen des Geräts an einem USB-2.0-Port statt an einem 3.0er.

Was noch ungelöst bleibt

Mit dem, was auf dem Tisch liegt, ist die wahrscheinlichste Lösung die Neuinstallation des Treibers aus dem richtigen Ordner oder das Testen eines anderen Kernels. Aber solange keine Ausgaben von „lsusb“, „ip link“ und keine Ping-Ergebnisse vorliegen, ist jede Diagnose ein Glücksspiel. Und so geht es weiter: ein Adapter, der als universelle Lösung verkauft wird, und ein Betriebssystem, das ihm nicht ganz die Hand reicht.