Warum CDC-Ethernet unter Android nicht verwendet werden kann (2023)

• Der EthernetTracker-Dienst von Android erkennt nur Netzwerk-Interfaces mit dem Namen ethX
• Der CDC-Ethernet-Treiber von Linux erstellt Interface-Namen als usbX
• Dadurch werden standardkonforme CDC-Ethernet-Geräte unter Android nicht automatisch aktiviert
• Um das zu beheben, muss der Nutzer das Smartphone selbst rooten und den Wert config_ethernet_iface_regex ändern
• Praktisch realistisch ist es, nicht standardkonforme USB-Ethernet-Adapter zu verwenden, sondern nur Produkte mit bestimmten Chipsätzen mit vendorspezifischen Treibern

---

Einleitung und Problemüberblick

• Der zentrale Grund, warum CDC Ethernet auf Android-Geräten nicht funktioniert, ist die Benennungsregel für Interfaces
• Systemseitig wird USB-Ethernet zwar unterstützt, aber die Bedingungen für die Aktivierung des Ethernet-Menüs sind eingeschränkt
• Informationen zu kompatiblen Chipsätzen sind schwer zu bekommen, und praktisch ist man auf "Mundpropaganda" unter Nutzern angewiesen
• Auch Android basiert auf dem Linux-Kernel, aber nicht alles wird allein durch die Kernel-Konfiguration entschieden

USB-Debugging und ADB-Einrichtung

• Auf dem Android-Gerät müssen USB-Debugging aktiviert und ADB installiert werden
• Um einen Netzwerkadapter zu testen, muss ADB in den Netzwerkmodus über Wi-Fi umgeschaltet werden
• Per Kommando lassen sich die aktuelle Kernel-Version und Architektur prüfen

So prüft man Kernel-Version und Konfiguration

• Neuere Smartphones (Android 11 und höher) verwenden die GKI(Generic Kernel Image)-Kernel-Struktur
  • Google baut den Basiskernel, und der Hersteller fügt nur Module hinzu
  • In der zugehörigen Kernel-Konfigurationsdatei (gki_defconfig) lassen sich unterstützte Funktionen erkennen
• Bei älteren Smartphones muss man in den jeweils vom Hersteller bereitgestellten Kernel-Quellen nach der Datei defconfig suchen
• Mit etwas Glück kann man die aktuelle Kernel-Konfiguration auch direkt unter /proc/config.gz prüfen

So erkennt man unterstützte USB-Ethernet-Adapter

• Die meisten relevanten Kernel-Konfigurationswerte haben die Form CONFIG_USB_NET_XXX
  • y bedeutet eingebaut, m bedeutet als Modul gebaut (wahrscheinlich nutzbar), is not set bedeutet keine Unterstützung
• In der Datei drivers/net/usb/Kconfig kann man die Beschreibung der einzelnen Konfigurationswerte nachlesen
• Informationen zum Adapter-Chipsatz werden dennoch nur selten klar ausgewiesen

CDC Ethernet (Communications Device Class) und seine Anwendung unter Android

• CDC ist ein USB-Networking-Standard und bietet verschiedene Protokolle wie EEM/ECM/NCM
• Unter Linux, Windows und macOS werden standardkonforme CDC-Ethernet-Geräte ohne separaten Treiber automatisch erkannt
• Auch unter Android sind die zugehörigen Treiber auf Kernel-Ebene gebaut
  • Beispiel: Samsung-Geräte, bei denen CONFIG_USB_NET_CDCETHER, EEM und NCM alle auf y gesetzt sind
• Trotzdem bleibt das Ethernet-Menü weiterhin deaktiviert

Die Logik zur Verfolgung von Netzwerk-Interfaces in Android

• Android verwendet zur Erkennung von Netzwerk-Interfaces die Klasse EthernetTracker.java
• EthernetTracker führt beim Auftauchen eines neuen Interfaces ein Matching anhand eines Namensmusters (regulärer Ausdruck) durch
• Das Matching-Kriterium wird aus der Ressource config_ethernet_iface_regex übernommen
  • Der Standardwert ist eth\\d (nur Netzwerk-Interfaces, die mit eth beginnen und auf die eine Zahl folgt, sind gültig)
• Der vom Kernel erzeugte Name (usb0) passt nicht zu diesem Muster und wird deshalb bei Verfolgung und Aktivierung ignoriert

Einschränkungen der Lösung und Fazit

• Diesen Benennungs-RegEx kann der Nutzer nicht direkt ändern (ohne Root nicht möglich)
• Dadurch können standardkonforme CDC-Ethernet-Produkte zwar verbunden werden, sind aber im Netzwerk-Menü nicht nutzbar
• Umgekehrt funktionieren nur einige Adapter, die direkt über Vendor- oder Chipsatz-Treiber registriert werden
• Selbst wenn Google standardmäßigen Support-Code wie das EEM-Modul in den Kernel aufnimmt, ist der praktische Betrieb nicht möglich
• Es wäre ein einfaches Problem zu lösen, wenn der reguläre Ausdruck zumindest auf (eth|usb)\\d geändert würde, aber derzeit bleibt es unverändert

Zusammenfassung

• Kernursache: Android ignoriert den CDC-Ethernet-Standard nicht, sondern aktiviert ihn nicht, weil der Netzwerk-Interface-Name nicht zum regulären Ausdruck (eth\\d) passt
• Workaround: Das Smartphone muss gerootet und der Wert config_ethernet_iface_regex auf etwas wie (eth|usb)\\d geändert werden
• Praktische Wahl: Statt eines standardkonformen USB-CDC-Adapters ist es realistischer, ein Produkt zu wählen, bei dem die Treiberanbindung pro Chipsatz klar ist
• Strukturelles Problem: Dieses Beispiel zeigt, wie eine unzureichende Benennungspolitik im höheren Software-Stack im Hinblick auf Nutzersichtbarkeit und Standardkompatibilität zu einer systemischen Einschränkung wird

[GN⁺]

Hacker-News-Kommentare

• Jemand berichtet, dass er diesen Beitrag schrieb, nachdem er bei einem früheren Arbeitgeber große Mühe hatte, ein Android-Gerät mit einem CDC-Ethernet-Adapter zu verbinden; später hätten ihm einige Leute gesagt, dass der Kernel ein ethX-Namensschema vergibt, wenn man ein bestimmtes Bit der MAC-Adresse ändert. Er selbst habe das weder direkt getestet noch in den Beitrag übernommen und nutze Android-Geräte heute kaum noch. Zusätzlich der Hinweis, dass diese Methode nur funktioniert, wenn man die MAC-Adresse kontrollieren kann.
  • Reaktion, dass diese Information hilfreich sein könnte; das betreffende Bit sei gefunden worden, dazu ein passender Link.
  • Positive Reaktion auf den Beitrag.
• Einschätzung als interessanter Deep-Dive-Artikel; beim Blick in den Source-Code scheine die problematische Regex im Oktober 2023 von eth\\d auf * geändert worden zu sein, wodurch das Problem vermutlich behoben wurde. Dazu ein Link zur Code-Änderung. Ab Android U+ (vermutlich Version 14) seien damit standardmäßig sowohl usb\\d+ als auch eth%d eingeschlossen.
  • Erklärung, dass diese Änderung später zurückgerollt wurde, weil es „Geräte gibt, die Tethering über usbX-Interfaces machen“; kurz darauf sei sie erneut eingepflegt worden, diesmal nur für Android V+ (eine neuere Version). Ergänzt um einen Link zum Rollback und einen Link zur finalen Übernahme.
• Deutliche Kritik daran, dass der EthernetTracker-Dienst von Android nur Interfaces akzeptiert, die als ethX benannt sind; Linux-Distributionen hätten dieses Problem bereits in den 2000er Jahren gelöst. Rückblick darauf, dass es mühsam war, das ganze System zu durchsuchen, weil viele Treiber ihr eigenes Namenspräfix verwendeten. Heutige Linux-Distributionen benennen Netzwerkschnittstellen mit Tools wie udev automatisch um; das funktioniere über den SIOCSIFNAME-ioctl-Aufruf des Kernels. Ergänzend der Hinweis, dass moderne Kernel sogar die bequeme automatische Nummerierung für Namen wie wlan* oder wlan%d bieten.
• Analyse anhand der LineageOS-Commit-Historie, dass das Problem behoben wurde, dann wegen Kompatibilitätsproblemen wieder zurückgenommen wurde und in aktuellen Android-Versionen nun wieder enthalten ist. Aus den Commits wirke es so, als seien auch Leute von Google beteiligt gewesen, daher sei es möglich, dass die Änderung auch in offiziellen Google-Builds enthalten ist.
• Zustimmung zu dem Satz im Artikel: „<i>Um den Wert von config_ethernet_iface_regex zu ändern, bleibt außer Rooten des Telefons keine andere Möglichkeit</i>“, verbunden mit der Aussage, dass dies ein weiterer Grund sei, warum Root-Zugriff auf eigenen Geräten wichtig ist.
  • Gegenposition: Die Möglichkeit, Netzwerkverkehr beliebig umzuleiten, sei gerade einer der wichtigsten Gründe, Nutzerprozessen keine Superuser-Rechte zu geben. Druck auf OEMs, Bootloader-Entsperrung zu erlauben, sei sinnvoll, aber angesichts der großen Angriffsfläche, die Root auf Android einem Angreifer eröffnet, fielen einem keine wirklich überzeugenden legitimen Anwendungsfälle ein.
• Nachfrage, was genau mit „geht nicht“ gemeint sei: Wenn ein USB-Hub-Dongle für ein MacBook an ein Android-Telefon angeschlossen werde, funktioniere der Ethernet-Port problemlos; auch ein Mobilfunkmodem, das als Ethernet-Gerät erkannt wurde, habe unter Android gut funktioniert.
  • Hinweis, dass dieses Problem inzwischen behoben sei und der Originalartikel bereits zwei Jahre alt ist.
• Beschwerde, dass Android sehr unpraktischerweise keine gleichzeitigen Mehrfach-Netzwerkverbindungen zulässt: Beispielsweise könne man nicht gleichzeitig mit einem WiFi ohne Internetzugang (auch ohne Standard-Router) und dem Mobilfunknetz verbunden sein. Unter Linux oder Windows sei das selbstverständlich möglich, Android verhindere es jedoch künstlich; in vielen Varianten werde man sogar auf verwirrende Weise getrennt, wenn man an einem WiFi ohne Internet festhalte, oder es gebe nur zusätzliche APIs, die ein wenig für Apps funktionieren, während normale Nutzer keinerlei Kontrolle darüber haben.
  • iOS sei ähnlich: Wenn man sich mit WiFi verbindet, um Videos von einer Dashcam herunterzuladen, erscheine ein Popup wie „Kein Internet, zu Mobilfunk wechseln?“; selbst wenn man angebe, im WiFi zu bleiben, wechsle iOS am Ende eigenmächtig ins CarPlay-Netzwerk. Nicht einmal eine manuelle Deaktivierung werde angeboten.
  • Auch unter Windows sei es praktisch nicht möglich, mit zwei WLAN-Adaptern gleichzeitig zwei verschiedene WiFi-Netze zu nutzen; zumindest nicht über die GUI, und im Terminal habe man es nicht ausprobiert.
  • Meinung, dass diese Einschränkung extrem nervig ist; wenn das Internet ausfällt und man es mit dem Telefon diagnostizieren will, bleibe das Gerät nicht im WiFi, was alles erschwert. Zusätzlich die Beschwerde, dass Android seine DNS-Einstellungen ebenfalls nicht per DHCP übernimmt und es noch weitere komplizierte Probleme gibt.
  • Erfahrungsbericht, dass es mit westlichen Android-Smartphones auf dem chinesischen Festland noch unangenehmer war: Android prüfe die Internetverbindung über Google-Dienste und markiere lokales WiFi daher ständig als „ohne Internet“. Jedes Mal müsse der Nutzer manuell bestätigen, dass die Verbindung dennoch bestehen bleiben soll.
• Rat, unbedingt auch die Firmware-Anforderungen zu prüfen: Manche Geräte würden zwar korrekt erkannt, scheiterten aber bei ifup, wenn die notwendige Firmware nicht vorhanden ist. Die Android-Oberfläche zeige diesen Zustand überhaupt nicht an; das Problem sei nur in dmesg sichtbar. Ob das auch für CDC-Geräte gilt, sei unklar, aber viele USB-Ethernet-Dongles hätten auf Realtek- oder Kawasaki-Chipsätzen basiert, bei denen es solche Firmware-Anforderungen gab. Die Android-Änderung scheine zwar jüngeren Datums zu sein, aber auf einem unveränderten AOSP-Debug-Gerät hätten USB-Netzwerk-Dongles gut funktioniert, daher liege die Vermutung eher bei den Namenskonventionen des Kernels oder des CDC-Treibers. Fazit: Auf Chipsatz und eventuellen Firmware-Bedarf des Dongles sollte man achten.
• Jemand besitzt mehr als 15 USB-Ethernet-Adapter mit unterschiedlichen Chipsätzen wie Realtek und AXIS, und alle hätten problemlos funktioniert. Wenn man unter Linux nur Modelle auswähle, die keine Treiber benötigen, könne man sie praktisch in jedem OS und sogar im BIOS ohne Probleme einsetzen.
  • Hinweis, dass das Problem 2023 behoben wurde, zusammen mit einem passenden Hacker-News-Link.
  • Zusätzliche Erfahrung, dass der Ethernet-Adapter an einem Thunderbolt-/USB-Dock sowohl mit einem Pixel 5 als auch mit einem Pixel 9 problemlos funktionierte.
• Begeisterung darüber, dass dies eine perfekte Debugging-Reise sei: Faszinierend, dass eine einzige Regex eine ganze Geräteklasse unbenutzbar machen konnte. Dazu die Rückschau auf eine ähnliche strukturelle Grenze, auf die man kürzlich bei GPT-4 und dem Alignment-/Escalation-System von OpenAI gestoßen sei. Trotz offizieller Dokumentation und Logs, mit denen man die interne Logik auslösen wollte, sei man am Ende offenbar daran gescheitert, dass etwas aus menschlicher Sicht vernünftig wirkte, intern aber nicht auf die Regex eines Interfaces passte. Die entsprechende Geschichte wird in einem separaten Link geteilt, verbunden mit der Einladung zu Meinungen von Leuten, die sich für Systemarchitektur oder unsichtbare Schnittstellengrenzen interessieren.