Por qué no se puede usar Ethernet CDC en Android (2023)

• El servicio EthernetTracker de Android solo reconoce interfaces de red con nombres ethX
• El controlador de Ethernet CDC de Linux crea los nombres de interfaz como usbX
• Por esto, los dispositivos Ethernet CDC estándar no se activan automáticamente en Android
• Para resolverlo, el usuario debe rootear el teléfono y cambiar el valor de config_ethernet_iface_regex
• En la práctica, la opción realista es usar solo productos con chipsets específicos que tengan controladores específicos del proveedor, en lugar de adaptadores USB Ethernet estándar compatibles con la norma

---

Introducción y resumen del problema

• La causa principal de que CDC Ethernet no funcione en dispositivos Android es la regla de nombres de las interfaces
• A nivel de sistema sí existe soporte para adaptadores USB Ethernet, pero las condiciones para que se active el menú de Ethernet tienen restricciones
• Es difícil obtener información sobre chipsets compatibles y, en la práctica, la situación depende de los "rumores" entre usuarios
• Android también está basado en el kernel de Linux, pero no todo se decide solo con la configuración del kernel

Depuración USB y configuración de ADB

• En un dispositivo Android es necesario activar la depuración USB e instalar ADB
• Para probar un adaptador de red, hay que cambiar ADB a modo de red por Wi‑Fi
• Mediante comandos se puede verificar la versión del kernel y la arquitectura actuales

Cómo verificar la versión y la configuración del kernel

• Los teléfonos recientes (Android 11 o superior) usan una estructura de kernel GKI (Generic Kernel Image)
  • Google compila el kernel base y el fabricante solo agrega módulos
  • En ese archivo de configuración del kernel (gki_defconfig) se pueden revisar las funciones compatibles
• En teléfonos antiguos, hay que buscar el archivo defconfig en el código fuente del kernel que publica cada fabricante
• Si hay suerte, también se puede revisar directamente la configuración actual del kernel en /proc/config.gz

Cómo comprobar qué adaptadores USB Ethernet están soportados

• La mayoría de las opciones relevantes del kernel tienen la forma CONFIG_USB_NET_XXX
  • Si es y, está integrado; si es m, está compilado como módulo (probablemente usable); si aparece como is not set, no hay soporte
• En el archivo drivers/net/usb/Kconfig se puede consultar la descripción de cada opción
• Aun así, rara vez se muestra con claridad la información del chipset del adaptador

Ethernet CDC (Communications Device Class) y su uso en Android

• CDC es un estándar de red por USB que ofrece varios protocolos como EEM/ECM/NCM
• En Linux, Windows y macOS, los dispositivos Ethernet CDC estándar se reconocen automáticamente sin controladores adicionales
• Android también tiene esos controladores compilados a nivel de kernel
  • Ejemplo: dispositivos Samsung con CONFIG_USB_NET_CDCETHER, EEM y NCM configurados como y
• Sin embargo, el menú de Ethernet sigue desactivado

Lógica de seguimiento de interfaces de red en Android

• Android usa la clase EthernetTracker.java para detectar interfaces de red
• EthernetTracker, cuando aparece una nueva interfaz, comprueba si su nombre coincide con un patrón (expresión regular)
• El criterio de coincidencia se toma del recurso config_ethernet_iface_regex
  • El valor predeterminado es eth\\d (solo son válidas las interfaces de red que empiezan con eth y terminan en un número)
• El nombre que genera el kernel (usb0) no coincide con ese patrón, así que se ignora al rastrearlo y activarlo

Limitaciones de la solución y conclusión

• El usuario no puede cambiar directamente esta expresión regular de nombres (sin root es imposible)
• Como resultado, aunque se conecten productos Ethernet CDC estándar, no pueden usarse desde el menú de red
• En cambio, sí pueden funcionar algunos adaptadores que se registran directamente mediante controladores del proveedor o del chipset
• Aunque Google incluya en el kernel código de soporte estándar como el módulo EEM, en la práctica no funciona
• Es un problema simple que se resolvería, al menos, cambiando la expresión regular a (eth|usb)\\d, pero por ahora sigue igual

Resumen

• Causa principal: Android no está ignorando el estándar CDC Ethernet como tal; el problema es que el nombre de la interfaz de red no coincide con la expresión regular (eth\\d), por lo que no se activa
• Forma de evitarlo: hay que rootear el teléfono y cambiar el valor de config_ethernet_iface_regex a algo como (eth|usb)\\d
• Elección realista: más que usar adaptadores con soporte estándar USB CDC, la alternativa práctica es elegir productos cuyo controlador esté claramente vinculado a un chipset específico
• Problema estructural: este caso muestra cómo una política deficiente de nombres en la capa superior del software se convierte en una limitación del sistema en términos de visibilidad para el usuario y compatibilidad con estándares

[GN⁺]

Comentarios de Hacker News

• Comparte que escribió este artículo después de batallar en un trabajo anterior al intentar conectar un dispositivo Android con un adaptador CDC Ethernet; luego algunas personas le comentaron que, si se cambia cierto bit de la dirección MAC, el kernel asigna un nombre ethX; aclara que no lo probó personalmente ni actualizó la publicación con ese dato, que hoy casi no usa dispositivos Android, y agrega que este método solo sirve si puedes controlar la dirección MAC
  • Reacción de que esta información podría serle útil; dice que encontró qué bit es y comparte un enlace relacionado
  • Expresa una reacción positiva al post
• Lo califican como un artículo de análisis profundo interesante; al revisar el código fuente, parece que en octubre de 2023 la expresión regular en cuestión cambió de eth\d a *, por lo que se supone que el problema quedó resuelto; comparte un enlace al cambio de código relacionado y explica que, desde Android U+ (probablemente la versión 14), por defecto ya incluye tanto usb\d+ como eth%d
  • Explica que ese cambio después fue revertido porque "hay dispositivos que hacen tethering con una interfaz usbX", y que poco después volvió a aplicarse, pero solo para Android V+ (una versión nueva); también adjunta un enlace sobre la reversión y un enlace a la aplicación final
• Fuerte crítica a la parte donde el servicio EthernetTracker de Android solo reconoce interfaces nombradas como ethX; explica que las distribuciones Linux ya habían resuelto este problema desde los años 2000, recuerda lo incómodo que era tener que revisar todo el sistema porque muchos drivers usaban su propio prefijo de nombre, y comenta que hoy las distribuciones Linux renombran automáticamente las interfaces de red con herramientas como udev, proceso que funciona mediante la llamada ioctl SIOCSIFNAME del kernel; además, añade que los kernels modernos incluso ofrecen la comodidad de asignar números automáticamente a nombres como wlan* o wlan%d
• Al ver el historial de commits de LineageOS, analiza que el problema se corrigió, luego se revirtió por problemas de compatibilidad, y en las versiones más recientes de Android volvió a aplicarse; opina que, por el contenido de los commits, parece que también participó gente de Google, así que es posible que se haya aplicado en builds oficiales de Google
• Coincide con la frase del artículo: "<i>no hay otra forma de cambiar el valor de config_ethernet_iface_regex más que rootear el teléfono</i>", y sostiene que esa es otra razón por la que el acceso root es importante en dispositivos que posee
  • Opina que la posibilidad de desviar arbitrariamente el tráfico de red es precisamente la razón principal por la que no se debería otorgar privilegios de superusuario al espacio de usuario; dice estar a favor de presionar a los OEM para que permitan desbloquear el bootloader, pero que no se le ocurren usos que justifiquen el enorme alcance de amenaza que el root le da a un atacante en Android
• Preguntan qué significa exactamente "no funciona"; comparten que al conectar a un teléfono Android un dongle USB hub para MacBook, el puerto Ethernet funcionó sin problemas, y que también tuvieron la experiencia de que un módem celular fuera reconocido como dispositivo Ethernet y operara bien en Android
  • Aclaran que este problema ya fue corregido y que el artículo original es de hace dos años
• Queja de que Android, de forma muy incómoda, no permite tener varias redes conectadas al mismo tiempo; por ejemplo, aunque se quiera usar simultáneamente una WiFi sin internet (incluso sin router por defecto) y la red celular, no se puede; señalan que en Linux o Windows eso es normal, pero Android lo bloquea a la fuerza, e incluso en muchas variantes termina desconectando de manera confusa si uno insiste en quedarse en una WiFi sin internet; además, critican que solo existan APIs que más o menos funcionan desde las apps, mientras que al usuario se le impide tener ese control
  • iOS es parecido: al conectarse por WiFi para descargar video de una dashcam, aparece un popup de "sin internet, ¿cambiar a datos móviles?"; y aunque elijas seguir en WiFi, iOS termina cambiándose por su cuenta a la red de CarPlay, sin ofrecer siquiera una forma de desactivarlo manualmente
  • En Windows tampoco se puede realmente conectar al mismo tiempo a dos redes Wi‑Fi con dos adaptadores inalámbricos, al menos no desde la GUI; menciona que no lo ha intentado desde la terminal
  • Opinan que esta limitación es realmente desesperante; comparten que cuando se cae internet e intentan diagnosticarlo con el teléfono, les cuesta porque no permanece en WiFi, y también se quejan de que la configuración DNS de Android ni siquiera se obtiene por DHCP, entre otros problemas complejos
  • Relatan que con un teléfono Android occidental en China continental era todavía más molesto: como Android verifica la conectividad a internet usando servicios de Google, la WiFi local mostraba constantemente advertencias de que no había internet, y cada vez el usuario tenía que responder manualmente que quería seguir conectado
• Aconsejan revisar también los requisitos de firmware: algunos dispositivos pueden ser reconocidos correctamente, pero si no tienen el firmware disponible, ifup falla; la UI de Android no muestra en absoluto esta situación y solo se ve el problema revisando los logs de dmesg; no están seguros de si esto también aplica a dispositivos CDC, pero cuentan que muchos dongles USB Ethernet usaban chipsets Realtek o Kawasaki y había casos que requerían firmware; suponen que este cambio en Android es reciente, pero como pudieron usar bien dongles de red USB en un dispositivo de depuración con AOSP vanilla, sospechan que podría ser una convención de nombres del lado del kernel o del driver CDC; en cualquier caso, recomiendan fijarse en el chipset del dongle y en si necesita firmware
• Comparten que poseen más de 15 adaptadores USB Ethernet y que, aunque usan chipsets distintos como Realtek y AXIS, todos funcionaron muy bien; están convencidos de que, si consigues modelos que no requieren drivers en Linux, en la práctica funcionan sin problemas en casi cualquier SO y BIOS
  • Comparten la información de que el problema se corrigió en 2023 y añaden un enlace relacionado de Hacker News
  • Experiencia adicional de que el adaptador Ethernet de un dock Thunderbolt/USB funcionó bien en ambos teléfonos, un Pixel 5 y un Pixel 9
• Consideran que fue una travesía de depuración perfecta, y les pareció fascinante que una sola expresión regular dejara inservible a toda una familia de dispositivos; recuerdan que hace poco se toparon con una limitación estructural parecida en el sistema de alignment/escalation de GPT-4 y OpenAI: intentaron activar la lógica interna con documentación oficial y logs, pero al final todo parecía bloquearse porque, aunque para una persona era razonable, no coincidía con la expresión regular de una interfaz interna; comparten un enlace aparte con el registro relacionado, y proponen que, si a alguien le interesan la estructura del sistema o los límites invisibles de sus interfaces, le gustaría conocer su opinión