Why Android can't use CDC Ethernet (2023)
81 comments
·June 8, 2025jordemort
rcxdude
This might actually help me out! Did you find what bit it is?
(Ah, I think I found it: https://lkml.iu.edu/hypermail/linux/kernel/1103.2/03250.html )
goodburb
Thanks, setting the MAC address to global bit works on my Moto Android 15, Honor Android 9, and GSI 16 from a Raspberry Pi [1].
It now appears as eth0 and routes created only after turning off the Wi-Fi, DHCP is obtained regardless.
ECM scores 270Mbit, RNDIS 150Mbit.
Mobile hotspots/dongles with MAC address modification should work. (currently detected as usb0)
[1]: https://gist.github.com/TalalMash/c20e6aa237e1f123ddf9686a07...
chews
yes to this post!
progbits
Fun deep dive article!
Looked up the source and it appears the regex was changed from `eth\\d` to just `*` in October 2023, presumably fixing this issue:
https://android-review.googlesource.com/c/platform/packages/...
The description says "The default will include both usb\d+ and eth%d named interfaces on Android U+", "U+" being version 14 I think (https://en.wikipedia.org/wiki/Android_version_history)
mshockwave
It was later reverted[1] because "there are devices in the field using usbX interfaces for tethering". Shortly after that, it got re-landed but only supported Android V+[2]
[1]: https://android-review.googlesource.com/c/platform/packages/...
[2]: https://android-review.googlesource.com/c/platform/packages/...
franga2000
Looking at the LineageOS commit history, it seems seems this has been fixed [0], reverted [1] due to compatibility issues, then unreverted again [2] but only for the latest Android versions. If I'm reading the commits right, someone at Google was involved, so this might be in the official Google build now.
[0] https://github.com/LineageOS/android_packages_modules_Connec... [1] https://github.com/LineageOS/android_packages_modules_Connec... [2] https://github.com/LineageOS/android_packages_modules_Connec...
userbinator
There is no way to work around this, short of rooting the phone to change the value of config_ethernet_iface_regex.
Another reason why having root is important on a device that you own.
bigyabai
Being able to arbitrarily redirect networking traffic is perhaps the single greatest reason to not have superuser privs in userland. I support anybody that wants to pressure OEMs into allowing bootloader unlocks, but I also can't name a use for root that justifies the insanely expanded surface area for attackers, at least on Android.
Zak
Do you believe the same thing about desktop PCs?
bigyabai
Yes? I don't use a single computer I own as root.
userbinator
The corporate FUD has gotten strong enough that people are getting scared of freedom. That should disturb you more than any perceived paranoia about "attackers".
stavros
Seriously, people are acting like the "do you want to give this application elevated privileges" popup is some arcane magick that we as a race can never hope to possess.
lucasban
Most users have no interest in developing the skills to handle that level of freedom responsibly. I think it should be an option, but it is unfair to say this is only corporate FUD.
rcxdude
It also, very annoyingly, can't connect to multiple networks at once. e.g. connecting to a wifi network which doesn't have internet access (and doesn't even advertise a default route) and a cell phone network at the same time. Linux can do it, Windows can do it, Android stubbornly refuses (and indeed many variants will refuse to stay connected to a wifi network without internet, if not just make you jump through confusing hoops). There are some APIs which mean that if you write an app, you can do it just in the app, but there's no way as a user to get it to do so.
spaqin
It's even more annoying when you go to mainland China with your western Android phone. They determine internet connection by trying to connect to Google services. If you connect to a local WiFi, of course it won't go through the Great Firewall, and every single time will prompt you asking if you want to keep the internet-less connection.
roygbiv2
This is incredibly annoying. If my internet goes down I'm unable to diagnose it from my phone because it won't stay connected to the WiFi that doesn't have internet. DNS is also messed up on Android, it refuses to use the Dhcp supplied dns without having to set multiple options and even then some internal dns refuses to resolve.
OptionOfT
Same with iOS. When I connect to my dashcam to download some videos I get a pop-up after a while that is like: "No internet detected, switch to cellular?" I tap remain connected. No option to disable that.
And even though I wanted to stay connected, iOS decides it knows better and reconnects to my Carplay network.
raron
As far as I remember this have a solution for both Android and iPhone. Probably your dashcam just doesn't implemented them right.
null
Aurornis
This actually works fine on iOS when the app is implemented properly. I have multiple devices where I do this without issue.
I’m guessing your dash cam app is not implemented correctly.
kimixa
Also check for firmware requirements - some devices enumerate but fail on ifup without firmware available. The android UI naturally can't cope with this, only dmesg tells you what's going on. Though not sure if CDC devices require this? Though a lot of adapters are (were?) based on Realtek or Kawasaki chips that did.
I guess this android change is relatively recent though, as we regularly used USB network dongles on our debug devices (that used 100% "Vanilla" AOSP). Or perhaps a kernel change, or a quirk of the CDC driver to name the device usb*? You just had to be careful which chipset the dongle used and ensure it didn't need any firmware.
hypercube33
Thats super weird. I have like 15 USB ethernet adapters and all of them work just fine. I'm pretty sure they are a few different chipsets from Realtek and AXIS or something like that, too. If you get ones that dont need drivers on linux you're good to go with pretty much any OS and BIOS
Grazester
Yeah I came to say ethernet adapter on my thunderbolt/usb dock works just fine on my on my pixel 5 and pixel 9 phones
Zak
A related thing that used to annoy me is that vanilla Android wouldn't connect to ad-hoc WiFi networks. Third-party ROMs usually would, so it wasn't due to a hard problem.
The bug report had a two-digit number and Google steadfastly refused to fix it for years. I haven't seen an ad-hoc network in a long time, but they were common when Android was young.
tripdout
cs.android.com is a simpler alternative than downloading the whole 100+ Gb source.
ahepp
I'm working on an embedded system right now that has two CDC ethernet devices. One shows up as ethX and the other shows up as usbX. Maybe it's because one is CDC EEM and the other is CDC ECM? But I don't think this is generally true for all CDC ethernet.
MBCook
The article says that iOS doesn’t support CDC Ethernet adapters. But I’ve plugged just standard USB ethernet adapters into my phone and had them work.
Does iOS communicate with them using some other standard?
robingchan
yes - ASIX / realtek chipsets are whats in your generic dongle, the drivers for which are bundled in iOS. CDC ECM is not supported.
I found this out when using CAN bus to ethernet on iPhone
brigade
macOS definitely does not ship drivers for Realtek’s vendor protocol, and only supports them via ECM/NCM. Are you claiming iOS is the exact opposite?
kccqzy
Well macOS ships with something called AppleUSBRealtek8153Patcher (aka com.apple.driver.usb.realtek8153patcher). I'm not sure if this uses proprietary Realtek protocols, but it's pretty well known that this patcher does not work reliably on macOS. These days I only use Realtek 8156 on macOS (which uses NCM). And I just tested the 8156 on iOS; in fact this comment is transmitted by iOS to HN via a 8156 dongle.
hansjorg
> CDC stands for Communications Device Class https://en.m.wikipedia.org/wiki/USB_communications_device_cl...
Why is this buried almost at the end of the article? Why even mention it at that point?
andix
Rule of thumb: Explain every abbreviation the first time it is used in an article or a meeting. Only really obvious things like USB or HTTP can be skipped.
I wrote this after a bad week at a previous job trying to get an Android device to work with a CDC Ethernet adapter.
Since writing this, a couple people have let me know that there is a particular bit in the MAC address, that if flipped, will cause the kernel to assign an `ethX` name instead of `usbX` name. I haven't tried it myself or updated the post with that information because I moved on to a different job, and Android devices are no longer a large part of my life.
Of course, that only helps if you have a CDC device where you're in control of the MAC address (i.e. maybe another Linux device pretending to be a CDC adapter)