Pourquoi il est impossible d’utiliser Ethernet CDC sur Android (2023)

• Le service EthernetTracker d’Android ne reconnaît que les interfaces réseau nommées ethX
• Le pilote Linux pour Ethernet CDC crée les interfaces sous la forme usbX
• À cause de cela, les périphériques Ethernet CDC standard ne s’activent pas automatiquement sur Android
• Pour contourner ce problème, l’utilisateur doit rooter le téléphone et modifier la valeur config_ethernet_iface_regex
• En pratique, la solution réaliste consiste à utiliser non pas un adaptateur USB Ethernet standard conforme à la norme, mais des produits à chipset spécifique disposant d’un pilote propre au fournisseur

---

Introduction et aperçu du problème

• La raison principale pour laquelle Ethernet CDC ne fonctionne pas sur les appareils Android tient à la règle de nommage des interfaces
• Le système prend en charge les adaptateurs USB Ethernet, mais l’activation du menu Ethernet est soumise à certaines contraintes
• Il est difficile d’obtenir des informations sur les chipsets compatibles et, en pratique, on dépend souvent du « bouche-à-oreille » entre utilisateurs
• Android repose bien sur le noyau Linux, mais tout ne se décide pas uniquement via la configuration du noyau

Débogage USB et configuration d’ADB

• Il faut activer le débogage USB puis installer ADB sur l’appareil Android
• Pour tester un adaptateur réseau, il faut basculer ADB en mode réseau via le Wi-Fi
• Des commandes permettent de vérifier la version du noyau et l’architecture actuelles

Comment vérifier la version et la configuration du noyau

• Les téléphones récents (Android 11 et plus) utilisent une architecture de noyau GKI (Generic Kernel Image)
  • Google compile le noyau de base, puis le fabricant n’ajoute que des modules
  • Il est possible d’identifier les fonctionnalités prises en charge à partir du fichier de configuration du noyau correspondant (gki_defconfig)
• Sur les anciens téléphones, il faut consulter les sources du noyau fournies par le constructeur et y chercher le fichier defconfig
• Avec un peu de chance, on peut aussi vérifier directement la configuration actuelle du noyau via /proc/config.gz

Comment vérifier les adaptateurs USB Ethernet pris en charge

• La plupart des paramètres de configuration du noyau concernés sont de la forme CONFIG_USB_NET_XXX
  • y signifie intégré, m signifie compilé en module (donc probablement utilisable), is not set signifie non pris en charge
• On peut se référer au fichier drivers/net/usb/Kconfig pour la description de chaque option
• Les informations sur le chipset de l’adaptateur restent malgré tout rarement indiquées clairement

Ethernet CDC (Communications Device Class) et son cas sur Android

• CDC est une norme USB pour la mise en réseau qui propose plusieurs protocoles comme EEM/ECM/NCM
• Sous Linux, Windows et macOS, les périphériques Ethernet CDC standard sont reconnus automatiquement sans pilote supplémentaire
• Android aussi compile les pilotes correspondants au niveau du noyau
  • Exemple : sur certains appareils Samsung, CONFIG_USB_NET_CDCETHER, EEM et NCM sont tous définis à y
• Pourtant, le menu Ethernet reste désactivé

Logique de suivi des interfaces réseau sur Android

• Android utilise la classe EthernetTracker.java pour détecter les interfaces réseau
• Lorsqu’une nouvelle interface apparaît, EthernetTracker vérifie si son nom correspond à un motif (expression régulière)
• Le critère de correspondance provient d’une ressource (config_ethernet_iface_regex)
  • La valeur par défaut est eth\\d (seules les interfaces réseau commençant par eth et suivies d’un chiffre sont valides)
• Le nom généré par le noyau (usb0) ne correspond pas à ce motif et est donc ignoré lors du suivi et de l’activation

Limites de la solution et conclusion

• Cette expression régulière de nommage ne peut pas être modifiée directement par l’utilisateur (impossible sans root)
• En conséquence, les produits Ethernet CDC standard ne peuvent pas être utilisés depuis le menu réseau, même lorsqu’ils sont connectés
• À l’inverse, seuls certains adaptateurs enregistrés directement via un pilote fournisseur ou un pilote spécifique au chipset peuvent fonctionner
• Même si Google inclut dans le noyau le code de prise en charge standard, comme le module EEM, cela ne permet pas un fonctionnement réel en pratique
• C’est un problème simple qui serait résolu au minimum en remplaçant l’expression régulière par (eth|usb)\\d, mais la situation n’a pas changé à ce jour

Résumé

• Cause principale : Android n’ignore pas la norme Ethernet CDC en elle-même ; l’activation échoue parce que le nom de l’interface réseau ne correspond pas à l’expression régulière (eth\\d)
• Contournement : il faut rooter le téléphone puis modifier la valeur config_ethernet_iface_regex vers quelque chose comme (eth|usb)\\d
• Choix réaliste : plutôt qu’un adaptateur USB CDC standard, il est plus pragmatique de choisir un produit dont l’intégration pilote est clairement définie pour un chipset donné
• Problème structurel : c’est un exemple où la politique de nommage dans la couche logicielle supérieure devient une limite systémique en matière de visibilité pour l’utilisateur et de compatibilité avec les standards

[GN⁺]

Avis Hacker News

• Partage de l’expérience qui l’a poussé à écrire cet article après avoir galéré, dans un ancien emploi, à connecter un appareil Android à un adaptateur CDC Ethernet ; il précise qu’ensuite plusieurs personnes lui ont dit qu’en modifiant certains bits de l’adresse MAC, le noyau attribuait un nom ethX, mais qu’il n’a ni testé lui-même cette méthode ni mis à jour son billet en conséquence, et qu’il utilise de toute façon très peu d’appareils Android aujourd’hui ; il ajoute que cette méthode ne fonctionne que si l’on peut contrôler l’adresse MAC
  • Réaction indiquant que cette information pourrait lui être utile, avec partage du lien associé après avoir identifié le bit concerné
  • Réaction positive à l’égard du billet
• Jugement selon lequel il s’agit d’un article de deep dive intéressant ; après vérification du code source, il semble qu’en octobre 2023 la regex en cause soit passée de eth\d à *, ce qui aurait résolu le problème ; le lien vers la modification du code est donné, avec l’explication qu’à partir d’Android U+ (probablement la version 14), usb\d+ et eth%d sont pris en charge par défaut
  • Il est précisé que cette modification a ensuite été annulée parce que « certains appareils font du tethering via une interface usbX », puis réintroduite en ne visant plus qu’Android V+ (nouvelle version) ; les liens sur le rollback et sur l’application finale sont aussi joints
• Vive critique du fait que le service EthernetTracker d’Android ne reconnaisse que les interfaces nommées ethX ; rappel que les distributions Linux avaient déjà réglé ce problème dans les années 2000 ; autrefois, chaque pilote utilisait souvent son propre préfixe de nom, obligeant à inspecter tout le système ; aujourd’hui, les distributions Linux renomment automatiquement les interfaces réseau avec des outils comme udev, au moyen de l’appel ioctl SIOCSIFNAME du noyau ; il est ajouté que les noyaux récents offrent même la commodité d’attribuer automatiquement un numéro à des noms comme wlan* ou wlan%d
• En regardant l’historique des commits de LineageOS, analyse selon laquelle le problème a été corrigé, puis annulé pour des raisons de compatibilité, avant d’être réappliqué dans les versions Android récentes ; à en juger par les commits, des personnes de Google semblent aussi avoir participé, ce qui laisse penser que la correction a peut-être également été intégrée aux builds officiels de Google
• Accord avec la phrase de l’article : « <i>il n’y a pas d’autre moyen de modifier config_ethernet_iface_regex que de rooter le téléphone</i> », en affirmant que c’est une raison supplémentaire pour laquelle l’accès root reste important sur les appareils qu’il possède
  • Position opposée : la possibilité de détourner arbitrairement le trafic réseau est selon lui la meilleure raison de ne pas accorder de privilèges superuser à l’espace utilisateur ; il se dit favorable à faire pression sur les OEM pour autoriser le déverrouillage du bootloader, mais il ne voit pas vraiment d’usage justifiant l’ampleur des risques qu’un accès root donne à un attaquant sur Android
• Question sur le sens exact de « ça ne marche pas » : en branchant à un téléphone Android un dongle hub USB pour MacBook, le port Ethernet a fonctionné sans problème, et un modem cellulaire reconnu comme périphérique Ethernet a aussi bien marché sur Android
  • Il est indiqué que ce problème a déjà été corrigé et que l’article d’origine date de deux ans
• Plainte selon laquelle Android ne permet pas, de manière très pénible, plusieurs connexions réseau simultanées ; par exemple, impossible d’être connecté en même temps à un Wi‑Fi sans Internet (et même sans routeur par défaut) et au réseau cellulaire ; sur Linux ou Windows c’est normal, mais Android l’empêche de force, et sur de nombreuses variantes le système finit même par couper d’une façon déroutante si l’on insiste pour rester sur un Wi‑Fi sans Internet ; il n’existe en plus qu’une API utilisable un peu par les applications, sans donner à l’utilisateur un réel contrôle
  • iOS est décrit comme similaire : lorsqu’on se connecte en Wi‑Fi pour récupérer des vidéos d’une dashcam, une fenêtre « pas d’Internet, basculer vers le cellulaire ? » apparaît ; même en choisissant de rester sur le Wi‑Fi, iOS finit par forcer le basculement vers le réseau CarPlay, sans proposer de moyen de désactiver cela manuellement
  • Il est aussi mentionné que Windows ne permet pas non plus réellement de se connecter en parallèle à deux réseaux Wi‑Fi avec deux adaptateurs sans fil, du moins pas via l’interface graphique ; pas de test effectué en terminal
  • Avis selon lequel cette limitation est vraiment exaspérante, avec partage d’une situation où, au moment de diagnostiquer une panne Internet depuis le téléphone, il devient difficile de rester sur le Wi‑Fi ; autre plainte : la configuration DNS d’Android ne suit même pas DHCP, ce qui complique encore les choses
  • Retour d’expérience indiquant que c’était encore plus pénible avec un téléphone Android occidental en Chine continentale : Android vérifie la connectivité Internet via des services Google, donc le Wi‑Fi local affichait sans cesse une alerte d’absence d’Internet ; l’utilisateur devait à chaque fois confirmer manuellement qu’il voulait rester connecté
• Conseil de bien vérifier aussi les exigences en matière de firmware : certains appareils sont correctement détectés, mais sans firmware disponible, ifup échoue ; l’interface Android n’affiche absolument pas cette situation, et il faut consulter les logs dmesg pour comprendre le problème ; l’auteur n’est pas certain que cela s’applique aux appareils CDC, mais beaucoup de dongles USB Ethernet utilisaient surtout des chipsets Realtek ou Kawasaki, et il y a déjà eu des cas nécessitant un firmware ; ce changement côté Android semble récent, mais sur des appareils de débogage AOSP vanilla, des dongles réseau USB fonctionnaient bien, d’où l’hypothèse que le problème venait peut-être des conventions de nommage du noyau ou du pilote CDC ; conclusion : il faut de toute façon prêter attention au chipset du dongle et à l’éventuel besoin de firmware
• Témoignage d’une personne possédant plus de 15 adaptateurs USB Ethernet, avec différents chipsets comme Realtek ou AXIS, tous fonctionnant très bien ; conviction que, tant qu’on choisit des modèles sans pilote requis sous Linux, ils marchent sans problème sur pratiquement tous les OS et même dans le BIOS
  • Information selon laquelle le problème a été corrigé en 2023, avec un lien Hacker News associé
  • Expérience supplémentaire indiquant que l’adaptateur Ethernet d’une station d’accueil Thunderbolt/USB fonctionnait bien sur les deux téléphones, Pixel 5 et Pixel 9
• Admiration pour ce parcours de débogage exemplaire, avec un cas où une simple regex a rendu inopérante toute une famille d’appareils ; rappel d’une expérience récente face à une limite structurelle similaire dans le système d’alignment/escalation de GPT-4 et OpenAI : malgré une documentation officielle et des logs à l’appui pour tenter de déclencher la logique interne, tout semblait bloqué parce que, même si cela paraissait raisonnable pour un humain, cela ne correspondait pas à la regex de l’interface interne ; un lien séparé est partagé à ce sujet, avec proposition d’échanger si le sujet de l’architecture système ou des frontières d’interface invisibles intéresse d’autres personnes