Por que não é possível usar Ethernet CDC no Android (2023)

• O serviço EthernetTracker do Android reconhece apenas interfaces de rede com nome ethX
• O driver Linux de Ethernet CDC cria os nomes de interface como usbX
• Por causa disso, dispositivos Ethernet CDC padrão não são ativados automaticamente no Android
• Para resolver isso, o usuário precisa fazer root no celular e alterar o valor de config_ethernet_iface_regex
• Na prática, a forma mais realista é usar apenas produtos com chipsets específicos que tenham drivers específicos do fornecedor, em vez de adaptadores USB Ethernet padrão compatíveis com a norma

---

Introdução e visão geral do problema

• O motivo central de o Ethernet CDC não funcionar em dispositivos Android é a regra de nomenclatura das interfaces
• Em nível de sistema, há suporte a adaptadores USB Ethernet, mas há restrições nas condições para que o menu Ethernet seja ativado
• É difícil obter informações sobre chipsets compatíveis e, na prática, a estrutura depende de “rumores” entre usuários
• Embora o Android também seja baseado no kernel Linux, nem tudo é definido apenas pela configuração do kernel

Depuração USB e configuração do ADB

• É necessário ativar a depuração USB e instalar o ADB no dispositivo Android
• Para testar o adaptador de rede, é preciso mudar o ADB para o modo de rede via Wi‑Fi
• Por meio de comandos, é possível verificar a versão do kernel e a arquitetura atuais

Como verificar a versão e a configuração do kernel

• Telefones mais recentes (Android 11 ou superior) usam a estrutura de kernel GKI (Generic Kernel Image)
  • O Google compila o kernel base, e o fabricante adiciona apenas módulos
  • É possível identificar os recursos suportados no arquivo de configuração desse kernel (gki_defconfig)
• Em telefones antigos, é preciso procurar o arquivo defconfig no código-fonte do kernel fornecido separadamente por cada fabricante
• Com sorte, também é possível verificar diretamente a configuração atual do kernel em /proc/config.gz

Como verificar adaptadores USB Ethernet compatíveis

• A maioria dos valores de configuração relevantes do kernel tem o formato CONFIG_USB_NET_XXX
  • y significa embutido, m significa compilado como módulo (provavelmente utilizável), e is not set significa sem suporte
• É possível consultar a explicação de cada valor no arquivo drivers/net/usb/Kconfig
• Mesmo assim, ainda é raro que as informações sobre o chipset do adaptador apareçam de forma clara

Ethernet CDC (Communications Device Class) e casos de aplicação no Android

• CDC é um padrão de rede USB que oferece vários protocolos como EEM/ECM/NCM
• Em Linux, Windows e macOS, dispositivos Ethernet CDC padrão são reconhecidos automaticamente sem driver adicional
• O Android também já tem, no nível do kernel, os drivers relacionados compilados
  • Exemplo: em dispositivos Samsung, CONFIG_USB_NET_CDCETHER, EEM e NCM estão todos definidos como y
• No entanto, o menu Ethernet continua desativado

Lógica de rastreamento de interfaces de rede no Android

• O Android usa a classe EthernetTracker.java para detectar interfaces de rede
• O EthernetTracker faz correspondência por padrão de nome (expressão regular) quando uma nova interface aparece
• O critério de correspondência é obtido do recurso config_ethernet_iface_regex
  • O valor padrão é eth\\d (apenas interfaces de rede que começam com eth e são seguidas por um número são consideradas válidas)
• O nome gerado pelo kernel (usb0) não corresponde a esse padrão e, por isso, é ignorado no rastreamento e na ativação

Limitações da solução e conclusão

• Essa expressão regular de nomenclatura não pode ser alterada diretamente pelo usuário (sem root, é impossível)
• Como resultado, produtos Ethernet CDC padrão não podem ser usados no menu de rede mesmo quando conectados
• Em contrapartida, apenas alguns adaptadores registrados diretamente por drivers do fornecedor ou do chipset podem ser usados
• Mesmo que o Google inclua no kernel código de suporte padrão, como o módulo EEM, isso ainda não permite o funcionamento real
• É um problema simples que seria resolvido se a expressão regular fosse alterada ao menos para (eth|usb)\\d, mas isso continua como está

Resumo

• Causa principal: o Android não ignora o padrão Ethernet CDC em si; a estrutura simplesmente não ativa a interface porque o nome da interface de rede não corresponde à expressão regular (eth\\d)
• Forma de contornar: é necessário fazer root no celular e alterar o valor de config_ethernet_iface_regex para algo como (eth|usb)\\d
• Escolha prática: em vez de adaptadores com suporte padrão a USB CDC, a alternativa mais realista é escolher produtos com integração de driver claramente definida para cada chipset
• Problema estrutural: este é um caso em que a política de nomenclatura da camada superior de software atua como limitação sistêmica em termos de visibilidade para o usuário e compatibilidade com padrões

[GN⁺]

Comentários do Hacker News

• Relato de quem escreveu este texto depois de sofrer tentando conectar um dispositivo Android a um adaptador CDC Ethernet no trabalho anterior; depois, algumas pessoas disseram que, se certos bits do endereço MAC forem alterados, o kernel passa a atribuir um nome ethX; a pessoa não testou isso diretamente nem atualizou a postagem com essa informação, e hoje em dia quase não usa mais dispositivos Android; acrescenta ainda que esse método só serve quando é possível controlar o endereço MAC
  • Reação dizendo que essa informação pode ser útil; encontrou qual é o bit e compartilhou um link relacionado
  • Manifestação positiva sobre o post em questão
• Avaliação de que é um artigo de análise aprofundada interessante; ao conferir o código-fonte, parece que em outubro de 2023 a expressão regular problemática mudou de eth\\d para *, o que provavelmente resolveu o problema; também foi apresentado um link para a mudança no código; explicação de que, a partir do Android U+ (provavelmente versão 14), usb\\d+ e eth%d passaram a ser incluídos por padrão
  • Explicação de que essa mudança depois foi revertida porque “existem dispositivos que fazem tethering pela interface usbX” e, em seguida, reaplicada para oferecer suporte apenas ao Android V+ (versão nova); também foram anexados um link sobre o rollback e um link para a aplicação final
• Crítica forte ao fato de o serviço EthernetTracker do Android só aceitar interfaces nomeadas como ethX; explicação de que distribuições Linux já resolveram esse problema nos anos 2000; lembrança de que antes era incômodo ter de inspecionar o sistema inteiro porque muitos drivers usavam seus próprios prefixos de nome; hoje, distribuições Linux renomeiam automaticamente interfaces de rede com ferramentas como udev, e esse processo funciona por meio da chamada SIOCSIFNAME via ioctl no kernel; acrescenta que kernels modernos ainda oferecem a conveniência de numerar automaticamente nomes como wlan* ou wlan%d
• Análise de que, olhando o histórico de commits do LineageOS, o problema foi corrigido, depois revertido por causa de problemas de compatibilidade, e voltou a ser aplicado nas versões mais recentes do Android; opinião de que, pelo conteúdo dos commits, parece haver participação de pessoas do Google, então é possível que isso também tenha sido adotado em builds oficiais do Google
• Concordância com a frase do texto: "<i>não há como mudar o valor de config_ethernet_iface_regex sem fazer root no celular</i>", argumentando que esse é mais um motivo para a importância de ter root em dispositivos que a pessoa possui
  • Opinião de que a possibilidade de desviar tráfego de rede arbitrariamente é a principal razão para não se conceder privilégios de superusuário ao espaço de usuário; concorda em pressionar OEMs a permitir desbloqueio do bootloader, mas diz não conseguir pensar em usos de root no Android que justifiquem a enorme superfície de ameaça que isso abre para atacantes
• Pergunta sobre o significado de “não funciona”; ao conectar um dongle hub USB de MacBook a um telefone Android, a porta Ethernet funcionou sem problema, e também houve experiência em que um modem celular foi reconhecido como dispositivo Ethernet e funcionou bem no Android
  • Aviso de que esse problema já foi corrigido e de que o artigo original é de dois anos atrás
• Reclamação de que o Android, de forma muito inconveniente, não permite múltiplas conexões de rede simultâneas; por exemplo, mesmo querendo conectar ao mesmo tempo um Wi‑Fi sem internet (e sem roteador padrão) e a rede celular, isso não é permitido; em Linux ou Windows isso seria algo normal, mas o Android bloqueia isso à força; além disso, em muitas variantes o sistema desconecta de forma confusa quando o usuário insiste em um Wi‑Fi sem internet, e no máximo existem APIs que funcionam mais ou menos apenas para apps, sem permitir esse controle ao próprio usuário
  • iOS é parecido; ao conectar ao Wi‑Fi para baixar vídeos de uma dashcam, aparece um pop-up dizendo “sem internet, mudar para celular?” e, mesmo escolhendo permanecer no Wi‑Fi, o iOS acaba trocando sozinho para a rede do CarPlay; acrescenta que nem sequer existe uma forma manual de desativar isso
  • Também menciona que o Windows, na prática, não consegue se conectar simultaneamente a duas redes Wi‑Fi com dois adaptadores sem fio; pelo menos não pela GUI, e a pessoa não tentou pelo terminal
  • Opinião de que essa limitação é realmente irritante; ao tentar diagnosticar uma falha de internet pelo telefone, é difícil porque ele não permanece no Wi‑Fi; reclama também de problemas complicados nas configurações de DNS do Android, como não receber isso via DHCP
  • Relato de que foi ainda mais incômodo entrar na China continental com um telefone Android ocidental; como o Android verifica a conectividade com serviços do Google, o Wi‑Fi local sempre era marcado como sem internet, e o usuário precisava responder manualmente repetidas vezes se queria manter a conexão
• Conselho para sempre verificar também os requisitos de firmware; alguns dispositivos até são reconhecidos corretamente, mas, se o firmware não estiver disponível, falham no ifup, e a interface do Android não mostra nada disso — só dá para ver o problema nos logs do dmesg; não há certeza se isso também se aplica a dispositivos CDC, mas muitas dongles USB Ethernet usavam chipsets Realtek ou Kawasaki e havia casos que exigiam firmware; essa mudança no Android parece ser recente, mas em um dispositivo de depuração com AOSP vanilla a pessoa conseguiu usar bem dongles de rede USB, então suspeita que seja uma questão de convenção de nomenclatura no kernel ou no driver CDC; no fim, recomenda prestar atenção ao chipset da dongle e à necessidade de firmware
• Relato de quem possui mais de 15 adaptadores USB Ethernet, com chipsets variados como Realtek e AXIS, e diz que todos funcionaram muito bem; confiança de que, se você obtiver modelos que não exigem driver no Linux, eles basicamente funcionarão sem problema em qualquer sistema operacional e BIOS
  • Informação de que o problema foi corrigido em 2023, com um link relacionado no Hacker News
  • Relato adicional de que o adaptador Ethernet de um dock Thunderbolt/USB funcionou bem tanto no Pixel 5 quanto no Pixel 9
• Comentário de que foi uma jornada de depuração perfeita e de que foi interessante ver como uma única expressão regular tornou toda uma família de dispositivos inutilizável; recordação de ter esbarrado recentemente em uma limitação estrutural parecida no sistema de alignment/escalation do GPT-4 e da OpenAI; relata que tentou acionar a lógica interna com documentação oficial e até logs, mas no fim tudo pareceu barrado por algo que fazia sentido para humanos, porém não correspondia à expressão regular de uma interface interna; compartilhou o registro relacionado em um link separado e propôs ouvir opiniões de quem se interessa por arquitetura de sistemas ou por limites de interfaces invisíveis