Если вам просто нужен ответ на вопрос в заголовке, то просто нажмите на TLDR и можете закрыть страницу. Но если вам любопытны подробности, то пристегнитесь, мы займёмся отладкой; этот пост в основном посвящён моему мыслительному процессу и методикам, которые я использовал, чтобы прийти к ответу.

TLDR: просто скажи мне, почему CDC Ethernet не работает в Android

Сервер EthernetTracker Android признаёт только интерфейсы с именем ethX; драйверы Linux CDC Ethernet создают интерфейсы с именем usbX. Эту проблему никак не решить, кроме как получением рута в телефоне и изменением значения config_ethernet_iface_regex.

В Android есть поддержка USB-адаптеров Ethernet. Для них даже есть меню!

Это значит, что если вы очень внимательно выберете USB-адаптер Ethernet, чипсет которого совместим с вашим устройством на Android, то вы можете подключить его, после будут действовать эти настройки. Как же узнать, какие чипсеты совместимы с вашим телефоном?

Только благодаря слухам!

Я даже и не совсем шучу. Если компания, изготовившая ваш телефон, продаёт и USB-адаптер Ethernet в качестве аксессуара для него, то вероятность его работы достаточно высока. В противном случае это лотерея: производители телефонов редко, а то и никогда не публикуют списки поддерживаемых Ethernet-адаптеров. Лучшее, что вы можете добиться — это найти на форуме пост человека, у которого есть точно такой же телефон и который купил конкретный адаптер, проверив его работоспособность; после этого вам остаётся лишь надеяться, что вы сможете отыскать точно такое же устройство.

Но так ли это?

Как вы, может быть, знаете, глубоко внутри гугловским панцирем Android скрывается ядро Linux. Для сборки ядра Linux нужно сначала его сконфигурировать. Эта конфигурация определяет, какие функции и оборудование будет поддерживать получившееся ядро. Следовательно, список поддерживаемых вашим телефоном Ethernet-адаптеров будет более-менее соответствовать устройствам, выбранным в конфигурации ядра телефона; конечно, возможно (хоть и маловероятно), что производитель телефона не поставил все собранные драйверы или что он отдельно собрал дополнительные сторонние драйверы.

Итак, чтобы разобраться, какие Ethernet-адаптеры поддерживает ваш телефон, нужно найти конфигурацию ядра телефона. Как же это сделать?

Для начала нужно включить отладку по USB и установить ADB

Если вы хотите повторять действия, описанные в этом посте, вам придётся включить отладку по USB и установить ADB (Android Debug Bridge) — это инструмент командной строки, используемый разработчиками для взаимодействия с устройствами на Android. В посте мы будем использовать его для выполнения на телефоне команд оболочки.

По всему этому есть хорошая документация, так что я не буду тратить время на её некачественное переписывание. Вместо этого приведу пару ссылок:

1. Сначала включите отладку по USB в телефоне

2. Установите ADB на компьютер

3. Выполните команду adb shell, которая даст вам доступ к оболочке в телефоне.

Поздравляю, теперь вы можете выполнять команды в телефоне. Введите exit и нажмите на Enter, когда будете готовы выйти из оболочки ADB.

Далее нам нужно настроить всё так, чтобы ADB подключался к телефону по сети, а не через USB. Это необходимо, потому что мы собираемся подключать сетевые адаптеры к USB-порту телефона, поэтому не можем использовать его для отладки.

Пока телефон подключен к компьютеру через USB:

1. Подключите телефон к той же сети, к которой подключен компьютер через WiFi

2. Настройте IP-адрес телефона — это можно сделать, зайдя в приложение Settings, или попробовать выполнить adb shell ifconfig wlan0

3. Не отключая телефон от USB, выполните adb tcpip 5555

4. Отключите USB-кабель от телефона

5. Подключите телефон заново, выполнив adb connect YOUR_PHONE_IP:5555 (заменив YOUR_PHONE_IP на IP-адрес телефона)

6. Попробуйте выполнить adb shell, чтобы убедиться, что всё по-прежнему работает

После того, как ADB начнёт работать по сети, можно начинать разбираться, какая версия ядра работает в устройстве с Android.

Если у вас новый телефон…

Сегодня Google публикует Android Common Kernel, на основе которого должны создавать свои ядра производители телефонов. Исходники этого ядра опубликованы в репозитории Git на googlesource.com.

Если в вашем телефоне установлен Android 11 или выше, то в нём используется ядро GKI — в этом случае Google собирает ядро, а производители телефонов записывают все свои тайные ингредиенты в модули ядра. В этом случае используемую Google конфигурацию можно найти, перейдя в соответствующую ветвь репозитория ядра и просмотрев файл arch/$ARCH/configs/gki_defconfig, где $ARCH — это архитектура процессора телефона. Например, если в телефоне установлен 64-битный процессор ARM (а это почти наверняка так), то его конфигурацию можно найти по адресу arch/arm64/configs/gki_defconfig.

Как точно определить, какие версия ядра и архитектура процессора в моём телефоне?

Теперь, когда вы можете выполнять команды оболочки в телефоне, можно воспользоваться старым добрым uname, чтобы определить версию ядра и архитектуру.

1. Вернитесь к инструкции выше, включите отладку по USB и установите ADB, если ещё этого не сделали

2. Выполните в телефоне uname -a, или выполнив adb shell, а затем uname -a, или одновременно, выполнив adb shell uname -a.

Вывод будет примерно таким:

Linux localhost 4.19.113-26203352 #1 SMP PREEMPT Tue Apr 18 16:05:51 KST 2023 aarch64 Toybox

Версия ядра будет указана в третьем поле, а архитектура — в предпоследнем; вам придётся самим разбираться, какая ветвь или тэг в репозитории ядра Google соответствует тому, что используется в вашем телефоне.

А что, если у меня старый телефон?

Если у вас старый телефон, то вы в той же ситуации, что и я: обычно я пользуюсь iPhone, но для тестирования на Android держу под рукой Samsung Galaxy s20. К сожалению, в s20 установлен Android 10, а эта версия была выпущена до того, как стал обязательным весь этот стандартизированный процесс с ядром Google. Хоть с тех пор s20 был обновлён до Android 13, Google не требует у производителей телефонов обновлять ядро вместе с версией Android, поэтому Samsung этого не сделала; в телефоне по-прежнему установлено ядро на основе Linux 4.19.

В этом случае вам нужно получить конфигурацию ядра у производителя телефона, поэтому остаётся надеяться, что он регулярно выпускает исходники. Samsung так поступает; исходники её телефонов можно найти на opensource.samsung.com.

Получив исходники для своего устройства, вам придётся покопаться, чтобы определить конфигурацию ядра. В исходниках Samsung для моего телефона содержался Kernel.tar.gz; внутри этого архива находилось дерево исходников ядра Linux с некоторыми дополнениями. Одним из таких дополнений оказался скрипт оболочки build_kernel.sh, выглядящий примерно так:

#!/bin/bash

export ARCH=arm64
mkdir out

BUILD_CROSS_COMPILE=$(pwd)/toolchain/gcc/linux-x86/aarch64/aarch64-linux-android-4.9/bin/aarch64-linux-android-
KERNEL_LLVM_BIN=$(pwd)/toolchain/llvm-arm-toolchain-ship/10.0/bin/clang
CLANG_TRIPLE=aarch64-linux-gnu-
KERNEL_MAKE_ENV="DTC_EXT=$(pwd)/tools/dtc CONFIG_BUILD_ARM64_DT_OVERLAY=y"

make -j8 -C $(pwd) O=$(pwd)/out $KERNEL_MAKE_ENV ARCH=arm64 CROSS_COMPILE=$BUILD_CROSS_COMPILE REAL_CC=$KERNEL_LLVM_BIN CLANG_TRIPLE=$CLANG_TRIPLE vendor/x1q_usa_singlex_defconfig

make -j8 -C $(pwd) O=$(pwd)/out $KERNEL_MAKE_ENV ARCH=arm64 CROSS_COMPILE=$BUILD_CROSS_COMPILE REAL_CC=$KERNEL_LLVM_BIN CLANG_TRIPLE=$CLANG_TRIPLE

cp out/arch/arm64/boot/Image $(pwd)/arch/arm64/boot/Image

Если внимательно присмотреться, можно увидеть ссылку на нечто, напоминающее конфигурацию ядра: vendor/x1q_usa_singlex_defconfig. В корне архива есть подпапка vendor, поэтому я при помощи find нашёл, где конкретно находится файл:

$ find . -name x1q_usa_singlex_defconfig
./arch/arm64/configs/vendor/x1q_usa_singlex_defconfig

Ага, вот он, вложен глубоко в подпапку.

Искать конфигурацию ядра сложновато. Возможно, есть способ попроще?

Если повезёт, то да! Попробуйте сделать так:

$ adb shell zcat /proc/config.gz

Если вам повезло, то производитель телефона включил соответствующую опцию ядра и сжатая копия конфигурации, с которой компилировалось ядро, находится в /proc/config.gz. Если это так, то в терминал будет выведен большой объём текста. Вероятно, стоит перенаправить его куда-то, чтобы можно было удобно его исследовать:

$ adb shell zcat /proc/config.gz > my_kernel_config

Если вам не повезло, то вы увидите нечто подобное:

zcat: /proc/config.gz: No such file or directory

В этом случае лёгкий путь вам недоступен; вам придётся разбираться в исходниках, из которых собрано ядро.

Как выглядит конфигурация ядра?

Если вам любопытно, можете изучить конфигурацию ядра моего Galaxy s20: x1q_usa_singlex_defconfig

Ваша конфигурация ядра будет выглядеть очень похоже, но не идентично.

Итак, теперь у меня есть конфигурация ядра телефона. Что дальше?

Чтобы определить, какие USB-адаптеры Ethernet поддерживает ядро, в основном нужны переменные конфигурации, начинающиеся с USB_NET, поэтому просто поищем эту строку в конфигурации ядра при помощи grep:

$ grep USB_NET my_kernel_config
CONFIG_USB_NET_DRIVERS=y
CONFIG_USB_NET_AX8817X=y
CONFIG_USB_NET_AX88179_178A=y
CONFIG_USB_NET_CDCETHER=y
CONFIG_USB_NET_CDC_EEM=y
CONFIG_USB_NET_CDC_NCM=y
# CONFIG_USB_NET_HUAWEI_CDC_NCM is not set
... и так далее ...

Ищите строки вида CONFIG_USB_NET_something, которые могут относиться к чипсету выбранного адаптера. Здорово, если они имеют значение y; это значит, что драйвер встроен в ядро и что ядро телефона точно поддерживает этот чипсет. Если значение равно m, то это тоже может быть неплохо; это значит, что в процессе сборки ядра драйвер был скомпилирован как модуль, и что этот модуль, вероятно, можно загружать в телефон, если только производитель телефона специально не исключил его. Хуже всего, если вы видите is not set; драйвер не встроен в ядро и не скомпилирован как модуль, так что, скорее всего, недоступен для использования.

Если вам сложно понять, какие строки конфигурации относятся к нужным чипсетам, то посмотрите drivers/net/usb/Kconfig в дереве ядра. Этот файл будет содержать расширенные описания каждого пункта конфигурации.

К сожалению, чтобы понять, какой чип используется в конкретном адаптере, скорее всего, придётся снова прибегнуть к слухам; лишь немногие производители USB-адаптеров Ethernet сообщают об используемых чипсетах.

Так что за история с CDC Ethernet и почему это должно быть важно?

CDC расшифровывается как Communications Device Class. Это набор взаимосвязанных стандартов, которые должны соблюдать производители USB-устройств. Среди прочего, в них есть трио стандартов EEM (Ethernet Emulation Model), ECM (Ethernet Control Model) и NCM (Network Control Model), которые можно использовать для создания USB-адаптеров Ethernet. Основные различия между этими тремя стандартами заключаются в сложности: EEM проще всего в реализации и поддержке на маломощных устройствах, но он может не обеспечивать наилучшей производительности. ECM более сложен в реализации и для USB-хоста, и для устройства, но обеспечивает повышенную производительность по сравнению с EEM; NCM — потомок ECM, обещающий ещё более высокие скорости. Во многих устройствах реализован не один, а несколько протоколов, и они позволяют операционной системе хоста самой выбирать предпочитаемый способ общения с устройством.

Смысл этих стандартов заключается в том, что если производители их соблюдают, то операционные системы могут иметь единый общий драйвер, работающий со множеством различных драйверов. Обычно нам не требуются особые драйверы для USB-клавиатур и мышей благодаря стандарту USB HID; стандарт USB CDC предназначен для решения этой же задачи в случае сетевых USB-устройств.

Особенно забавно здесь то, что Linux реализует стороны и хоста, и устройства стандартов CDC Ethernet. Это значит, что если у вас есть оборудование с портом USB OTG, которые часто используются в Raspberry Pi и других компактных устройствах на ARM, то можно приказать ядру использовать этот порт, притворившись, что это Ethernet-адаптер. Это создаёт на хосте сетевой USB-интерфейс, непосредственно подключенный к интерфейсу на гостевом устройстве, что позволяет создавать такие замечательные устройства, как встроенные маршрутизаторы, файрволы и VPN-шлюзы, которые для хоста выглядят, как обычные Ethernet-адаптеры.

Linux, а также Windows и macOS (но не iOS) содержит драйверы для устройств CDC Ethernet. К сожалению, ни один из них не работает в устройствах Android, несмотря на то, что в основе их лежит Linux. Почему так?

Судя по конфигурации ядра, Android должен поддерживать CDC

Давайте посмотрим ещё раз на нашу конфигурацию ядра и поищем при помощи grep строки USB_NET_CDC:

$ grep USB_NET_CDC my_kernel_config
CONFIG_USB_NET_CDCETHER=y
CONFIG_USB_NET_CDC_EEM=y
CONFIG_USB_NET_CDC_NCM=y
... и так далее ...

Здесь мы видим, что в ядре Samsung есть встроенная поддержка всех трёх стандартов CDC Ethernet (CONFIG_USB_NET_CDCETHER соответствует ECM). Ядра GKI Google чуть менее щедрые, в них отсутствуют ECM и NCM, но всё равно есть поддержка EEM в виде модуля.

У меня есть устройство с портом OTG, сконфигурированное как Ethernet-устройство. Оно работает, когда я подключаю его к Mac. Оно работает, когда я подключаю его к своему десктопному компьютеру с Ubuntu. Оно даже работает, когда я подключаю его к моей игровой машине под Windows (на самом деле, это тот же компьютер, что и десктопный с Ubuntu, загружающийся с другого накопителя). Оно не работает, когда я подключаю его к Galaxy s20. Настройки Ethernet остаются неактивными:

Давайте запустим оболочку в телефоне и немного изучим вопрос.

Ядро Linux раскрывает информацию о себе в псевдо-файловой системе sysfs — она выглядит, как дерево папок с файлами, однако при чтении файлов мы на самом деле получаем информацию о текущем состоянии ядра.

Среди прочего, sysfs содержит папку /sys/class/net, в которой есть по одной записи для каждого сетевого интерфейса, опознанного ядром. Давайте подключим наше Ethernet-устройство к телефону и посмотрим, отображается ли здесь что-нибудь:

$ adb shell ls /sys/class/net
... куча вывода ...
usb0
wlan0

Возможно, usb0 — это наше устройство? Давайте проверим это при помощи ifconfig:

$ adb shell ifconfig usb0
usb0      Link encap:UNSPEC    Driver cdc_eem
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 TX bytes:0

Оно определённо похоже на наше устройство. К сожалению, интерфейс отключен, а настройки Ethernet в телефоне по-прежнему недоступны:

Давайте отключим устройство и убедимся, что usb0 действительно при этом пропадает:

$ adb shell ls /sys/class/net | grep usb
$ # вывода нет

Да, пропало.

Похоже, мы используем режим EEM. Наряду с модулем g_ether в Linux также есть configfs, которую можно использовать для создания собственных устройств. Давайте попробуем устройство, поддерживающее только ECM, и проверим, работает ли оно:

$ adb shell ls /sys/class/net | grep usb
usb0
$ adb shell ifconfig usb0
usb0      Link encap:UNSPEC    Driver cdc_ether
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 TX bytes:0

Оно по-прежнему определяется, но по-прежнему отключено. Может, нам больше повезёт с NCM?

$ adb shell ls /sys/class/net | grep usb
usb0
$ adb shell ifconfig usb0
usb0      Link encap:UNSPEC    Driver cdc_ncm
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 TX bytes:0

Нет, не повезло.

Так почему же CDC не работает в Android?

Мы более-менее выяснили, что на уровне ядра всё в порядке. Я практически уверен, что при желании можно было бы получить рут телефона, вручную сконфигурировать интерфейс при помощи ifconfig, и устройство без проблем передавало бы трафик. Это значит, что проблема находится где-то выше по стеку ПО над ядром.

Если бы это была обычная система Linux, на этом этапе я бы начал исследовать systemd-networkd, или NetworkManager, или ifupdown, в зависимости от конкретных условий. Однако это необычная система Linux; это устройство на Android и ничего из этого здесь не существует. Что я знаю о том, как Android конфигурирует сетевые интерфейсы?

НИЧЕГО. Я ничего не знаю о том, как Android конфигурирует сетевые интерфейсы. Как нам в этом разобраться?

Ну, Android как минимум частично опенсорсна: многие важные её части сокрыты под вуалью, называющейся Google Play Services, но, возможно, в выпущенных исходниках достаточно информации, чтобы в этом разобраться.

Чтобы приступить к исследованию, надо скачать исходники Android. Это сам по себе непростой процесс, поэтому изучите документацию Google самостоятельно. Единственное, что могу отметить — вам понадобится специальный инструмент repo. Похоже, он предназначен для упрощения скачивания исходников из нескольких репозиториев Git одновременно; иногда кажется, что я единственный человек, которому нравятся подмодули Git. Скачивать придётся много исходников, так что начните процесс и пока поиграйте в Zelda.

Думаю, неплохо будет начать с поиска строки Ethernet. Так как исходников очень много, я на этот раз откажусь от ванильного grep и воспользуюсь помощью ripgrep. В исходниках Android много файлов конфигураций и другого бардака, а также большая часть дистрибутива Linux, но я знаю, что важный для меня код, вероятно, будет написан на Java, поэтому я ограничусь rg, чтобы искать только в файлах Java:

$ rg -t java Ethernet
... ОЧЕНЬ МНОГО ВЫВОДА ...

На этом этапе у нас нет особого выбора, придётся изучать найденные файлы и пытаться разобраться, какую часть кода винить в нашей проблеме. К счастью, я спасу вас от этих заморочек. Прочитав кучу кода Android, я определил, что виновником оказался EthernetTracker.java. Похоже, это сервис, прослушивающий сокет Netlink и получающий от ядра уведомления о новых сетевых интерфейсах. В EthernetTracker есть метод, определяющий валидность Ethernet-интерфейса; если он валиден, то EthernetTracker сообщает остальной части системы, что интерфейс доступен, а приложение Settings позволяет его настроить. Если интерфейс невалидный, то EthernetTracker просто игнорирует его.

Как EthernetTracker определяет валидность интерфейса?

private boolean isValidEthernetInterface(String iface) {
    return iface.matches(mIfaceMatch) || isValidTestInterface(iface);
}

Разумеется, при помощи регулярного выражения.

Откуда берётся это регулярное выражение?

// Regex сопоставления интерфейса.
mIfaceMatch = mDeps.getInterfaceRegexFromResource(mContext);

Оно берётся из метода getInterfaceRegexFromResource. Откуда его берёт этот метод?

public String getInterfaceRegexFromResource(Context context) {
    final ConnectivityResources resources = new ConnectivityResources(context);
    return resources.get().getString(
        com.android.connectivity.resources.R.string.config_ethernet_iface_regex);
}

На самом деле, в начале файла есть понятный комментарий, объясняющий это:

/**
 * Отслеживает Ethernet-интерфейсы и управляет конфигурациями интерфейсов.
 *
 * <p>Интерфейсы могут иметь разные {@link android.net.NetworkCapabilities}. Это отображение определяется
 * в {@code config_ethernet_interfaces}. Примечательно, что некоторые интерфейсы могут быть помечены как ограниченные
 * отсутствием флага {@link android.net.NetworkCapabilities.NET_CAPABILITY_NOT_RESTRICTED}.
 * С интерфейсами могут быть связаны {@link android.net.IpConfiguration}.
 * Ethernet-интерфейсы могут быть представлены на этапе загрузки или появляться после загрузки (например, в случае Ethernet-адаптеров,
 * подключенных по USB). Этот класс поддерживает различные интерфейсы. Когда интерфейс появляется
 * в системе (или присутствует на момент загрузки), этот класс начинает отслеживать его и отображать его.
 * Отслеживаются только те интерфейсы, имена которых соответствуют регулярному выражению
 * {@code config_ethernet_iface_regex}.
 *
 * <p>Все публичные или приватные для пакетов методы должны быть потокобезопасными, если не указано иное.
 */

Вернёмся к ripgrep, чтобы проверить, сможем ли мы выяснить, что же такое config_ethernet_iface_regex:

$ rg config_ethernet_iface_regex
...

frameworks/base/core/res/res/values/config.xml
410:    <string translatable="false" name="config_ethernet_iface_regex">eth\\d</string>

...

packages/modules/Connectivity/service/ServiceConnectivityResources/res/values/config.xml
170:    <string translatable="false" name="config_ethernet_iface_regex">eth\\d</string>

...

А вот и оно. По умолчанию config_ethernet_iface_regex имеет значение eth\d; на языке регулярных выражений это означает литеральную строку eth, за которой следует число.

Ядро телефона называет устройство CDC Ethernet usb0. Это имя не начинается с eth, поэтому EthernetTracker игнорирует его. К сожалению, этот параметр не может настраивать пользователь, хоть его и можно хакнуть при помощи рута телефона.

Проблема действительно заключается в такой ерунде; весь класс USB-устройств оказывается недоступным из-за неудачного regex.

Это баг?

Я не знаю, сделано ли это намеренно; похоже, это недосмотр со стороны Google: самые новые ядра GKI, очевидно, делают всё возможное для включения поддержки адаптеров, но поскольку имя интерфейса не соответствует регулярному выражению, поддержку адаптеров EEM ядром невозможно использовать. Из-за этого при покупке USB-адаптеров Ethernet вы попадаете в парадоксальную ситуацию: вместо того, чтобы искать устройства, реализующие стандарт CDC, вам нужно ИЗБЕГАТЬ устройств на основе стандартов и искать те, которые поддерживаются драйвером поставщика/чипсета.