AndroidでCDC Ethernetを使えない理由（2023）

• AndroidのEthernetTrackerサービスは、名前が ethX のネットワークインターフェースしか認識しない
• LinuxのCDC Ethernetドライバーは、インターフェース名を usbX として生成する
• このため、標準的なCDC EthernetデバイスはAndroidで自動的に有効化されない
• これを解決するには、ユーザーが自分で端末をroot化し、config_ethernet_iface_regex の値を変更する必要がある
• 標準準拠のUSB Ethernetアダプターではなく、ベンダー固有ドライバーがある特定チップセット製品だけを使うのが現実的な方法である

---

序論と問題の概要

• AndroidデバイスでCDC Ethernetが動作しない主因は、インターフェースの命名規則にある
• システムとしてはUSB Ethernetアダプターをサポートしているが、Ethernetメニューが有効化される条件には制約がある
• 互換性のあるチップセット情報を得るのは難しく、実際にはユーザー間の「口コミ」に依存する構造になっている
• AndroidもLinuxカーネルベースではあるが、カーネル設定だけですべてが決まるわけではない

USBデバッグとADB設定

• Androidデバイスでは、USBデバッグを有効化したうえでADBをインストールする必要がある
• ネットワークアダプターをテストするには、ADBをWi-Fi経由のネットワークモードに切り替える必要がある
• コマンドによって現在のカーネルバージョンとアーキテクチャを確認できる

カーネルバージョンと設定の確認方法

• 新しいスマートフォン（Android 11以降）は、GKI（Generic Kernel Image）カーネル構造を持つ
  • Googleが基本カーネルをビルドし、メーカーがモジュールだけを追加する方式
  • そのカーネル設定ファイル（gki_defconfig）からサポート機能を把握できる
• 古いスマートフォンでは、メーカーごとに提供されるカーネルソースから**defconfig**ファイルを探して確認する必要がある
• 運がよければ、/proc/config.gz から現在のカーネル設定を直接確認できることもある

対応しているUSB Ethernetアダプターの確認方法

• 関連するカーネル設定値の多くは CONFIG_USB_NET_XXX という形式である
  • y なら内蔵、m ならモジュールとしてビルド（おそらく使用可能）、is not set なら未サポート
• drivers/net/usb/Kconfig ファイルで各設定値の説明を参照できる
• それでも、アダプターのチップセット情報が明確に表示されるケースはまれである

CDC Ethernet（Communications Device Class）とAndroidでの適用事例

• CDCはUSBネットワーキング標準であり、EEM/ECM/NCMの各種プロトコルを提供する
• Linux、Windows、macOSでは、標準的なCDC Ethernetデバイスは追加ドライバーなしで自動認識される
• Androidでもカーネルレベルでは関連ドライバーがビルドされている
  • 例: CONFIG_USB_NET_CDCETHER、EEM、NCM がいずれも y に設定されたSamsung端末
• しかし、Ethernetメニューは依然として無効のままである

Androidのネットワークインターフェース追跡ロジック

• Androidは、ネットワークインターフェースの検出に EthernetTracker.java クラスを使用する
• EthernetTracker は新しいインターフェースが現れると、名前パターン（正規表現）のマッチングを行う
• マッチ条件はリソース（config_ethernet_iface_regex）から取得される
  • デフォルト値は eth\\d（eth で始まり、その後に数字が続くネットワークインターフェースだけが有効）
• カーネルが生成する名前（usb0）はこのパターンに一致しないため、追跡および有効化の対象から外れる

解決上の制約と結論

• この命名正規表現は、ユーザーが直接変更できない（root化なしでは不可能）
• 結果として、標準的なCDC Ethernet製品は接続してもネットワークメニューでは使用できない
• 逆に、ベンダーやチップセットのドライバーによって直接登録される一部のアダプターだけが利用可能である
• GoogleがEEMモジュールなど標準サポートコードをカーネルに含めていても、実際には動作しない
• 少なくとも正規表現を (eth|usb)\\d に変えれば解決するシンプルな問題だが、現状ではそのまま放置されている

要約

• 主な原因: AndroidがCDC Ethernet標準を無視しているのではなく、ネットワークインターフェース名が正規表現（eth\\d）に一致しないため有効化されない構造である
• 回避策: 端末をroot化したうえで config_ethernet_iface_regex の値を (eth|usb)\\d などに変更する必要がある
• 現実的な選択: 標準USB CDC対応アダプターよりも、チップセットごとにドライバー連携が明確な製品を選ぶのが現実的な代替策である
• 構造的な問題: ユーザーから見える挙動や標準互換性の観点で、ソフトウェア上位スタックの命名ポリシー不備がシステム上の制約として作用している事例である

[GN⁺]

Hacker Newsのコメント

• 以前の職場でAndroidデバイスとCDC Ethernetアダプターを接続しようとして苦労した後にこの記事を書いた経験の共有。その後、何人かからMACアドレスの特定のビットを変えるとカーネルが ethX という名前を割り当てると聞いたとのこと。本人は直接テストしたり、その内容を投稿に反映したりはしておらず、最近はAndroidデバイスをほとんど使っていないとの説明。この方法はMACアドレスを制御できる場合にしか使えないという前提も追加
  • この情報は自分の役に立ちそうだという反応。どのビットか見つけたとして、関連リンクを共有
  • その投稿に好意的な反応を示すコメント
• 興味深いディープダイブ記事だという評価。ソースを確認したところ、2023年10月に問題の正規表現が eth\d から * に変更されたようで、その結果この問題は解決したと推測。関連コード変更リンクを提示。Android U+（おそらくバージョン14）からはデフォルトで usb\d+ と eth%d の両方を含むようになったとの説明
  • その変更は後に「usbX インターフェースでテザリングするデバイスがあるため」ロールバックされたが、その後すぐにAndroid V+バージョン（新バージョン）のみを対象として再度反映されたとの説明。ロールバック関連リンク、最終適用リンクも添付
• Androidの EthernetTracker サービスが ethX と命名されたインターフェースしか認識しない点への強い批判。Linuxディストリビューションではこうした問題はすでに2000年代に解決されていたとの説明。ドライバーごとに独自の名前プレフィックスを使うことが多く、システム全体を調査しなければならない不便さがあったという回想。今日のLinuxディストリビューションでは udev のようなツールでネットワークインターフェース名を自動変更し、この処理はカーネルの SIOCSIFNAME ioctl 呼び出しで動作するとの説明。最新のカーネルでは "wlan*" や "wlan%d" のような名前に自動で番号が付与される便利さまで提供されている点も補足
• LineageOSのコミット履歴を見ると、この問題は修正された後、互換性の問題で差し戻され、最新のAndroidバージョンでは再び適用されているという分析。コミット内容を見る限りGoogle所属の人も関与しているようで、Google公式ビルドにも適用された可能性があるという意見
• 「config_ethernet_iface_regex の値を変えるには、スマホをroot化する以外に方法がない」という記事の一文に共感し、自分の所有するデバイスでroot権限が重要であるもう一つの理由だと主張
  • ネットワークトラフィックを任意に迂回できてしまう点こそ、ユーザー空間にsuperuser権限を与えるべきでない最大の理由だと考える、という意見。OEMにブートローダーアンロックを許可するよう圧力をかけることには賛成だが、Androidでroot権限が攻撃者に与える大きな脅威範囲に見合うほど正当化できる用途は思い浮かばないという立場
• 「使えない」とはどういう意味かを問うコメント。MacBook用のUSBハブドングルをAndroidスマホに挿したところ、Ethernetポートは問題なく動作し、セルラーモデムもEthernetデバイスとして認識されてAndroidで正常に使えた経験を共有
  • この問題はすでに修正されており、元の記事は2年前のものだという案内
• Androidは非常に不便なことに複数ネットワークの同時接続ができないという不満。たとえばインターネットのないWi‑Fi（デフォルトルーターもなし）とセルラーネットワークを同時に接続したくても不可能で、LinuxやWindowsでは当然できるのにAndroidはそれを無理やり禁止している、との指摘。しかも多くの派生版では、インターネットのないWi‑Fiにこだわると混乱を招く形で切断されたり、追加でアプリ内でだけ多少使えるAPIが提供されるだけで、ユーザー自身にはこうした制御をさせないようにしているという批判
  • iOSも似たようなもので、ドライブレコーダーから映像を受け取るためにWi‑Fiへ接続すると「インターネットなし、セルラーに切り替えますか？」というポップアップが出る。Wi‑Fiに留まると選んでも、結局iOSが勝手にCarPlayネットワークへ強制的に切り替えてしまうという体験の共有。手動で無効化する方法すらない点も付記
  • Windowsでも実際には、2つの無線アダプターで2つのWi‑Fiネットワークへ同時接続することはできない。少なくともGUIでは無理で、ターミナルでは試していないという言及
  • この制限は本当に腹立たしいという意見。インターネット障害時にスマホで診断しようとするとWi‑Fiに留まってくれず困る状況の共有。AndroidのDNS設定もDHCPから取得しないなど複雑な問題があるという不満
  • 欧米向けAndroidスマホを持って中国本土に入るとさらに不便だったという体験談。Androidはインターネット接続をGoogleサービスで確認するため、ローカルWi‑Fiに毎回インターネットなし警告を出す。そのたびにユーザーが手動で接続を維持するか答えなければならない煩わしさの説明
• ファームウェア要件も必ず確認すべきだという助言。ある種のデバイスは正常に認識されても、ファームウェアが用意されていないと ifup で失敗し、Android UIではこの状況をまったく表示できず、dmesg ログを確認して初めて問題が見えるとのこと。これがCDCデバイスにも当てはまるかは不明だが、多くのUSB EthernetドングルはRealtekやKawasakiチップセット中心で、ファームウェアが必要なケースがあったという経験談。このAndroidの変更は最近のもののようだが、素のAOSPデバッグ機ではUSBネットワークドングルを問題なく使えていたため、カーネル側あるいはCDCドライバー側の命名慣行ではないかと推測。結局のところ、ドングルのチップセットとファームウェア要否には注意すべきだという助言
• 15個以上のUSB Ethernetアダプターを所有しており、Realtek、AXISなど異なるチップセットでもどれも非常によく動作したという経験。Linuxでドライバー不要のモデルだけを揃えれば、実質的にあらゆるOSやBIOSで問題なく使えるという確信
  • 2023年にこの問題は修正されたという情報と、関連Hacker Newsリンクを提示
  • Thunderbolt/USBドックに付属するEthernetアダプターが、Pixel 5とPixel 9の両方で問題なく動作したという追加の経験
• 完璧なデバッグの旅であり、正規表現ひとつのせいでデバイス群全体が動かなくなった事例が興味深かったという感想。少し前にGPT-4とOpenAIのalignment/escalationシステムで似たような構造的制約にぶつかった経験も回想。公式ドキュメントやログまで揃えて内部ロジックをトリガーしようとしたが、結局は人間には合理的に見えても内部インターフェースの正規表現に一致せず弾かれたように思えたとの説明。関連記録を別リンクとして共有し、システム構造や見えないインターフェース境界に関心があるなら意見を聞きたいと提案