Hackr News App

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)

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)

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...

> Android's EthernetTracker service only acknowledges interfaces that are named ethX

If this is true, this is the stupidest goddamn thing I have ever heard of. We fixed this with linux distributions in the 2000s. It was obvious even back then that some device drivers just made up their own device name prefix, so you had to probe the system to find what kind of device it was. (I know the wifi stack has changed a lot over the years, but there's always been a way to detect if a device was wireless or not)

Because consistency is kind of useful, there are also multiple tools which can rename an interface, and I think most linux distros today use udev to make this automatic. Under the hood it's just calling the kernel's SIOCSIFNAME ioctl. Modern kernels even have a fancy feature so you can change the name to "wlan*" (actually "wlan%d") and it will just assign a new number after "wifi".

Another similarly stupid thing is when you're trying to connect USB Serial device to your Android Smartphone.

Well, you connect it, it appears to work. Then you want to write an application to use that USB serial interface. But apparently you can't. You start to dig in and it appears that you just don't have permissions to access `/dev/ttyACM0` (or whatever the name of the serial device is, sorry, I might have misspell it).

Serial support is built into the kernel, but inaccessible to user program, not without rooting anyway.

Dig further and it appears that Android has userspace USB access. Similar to libusb, or may be it's built on top of libusb?. Matters not.

So you can open "raw" USB device from your Android program. But you can't open serial USB device. Serial USB is just a protocol on top of USB. Actually it's a set of half-proprietary protocols. FTDI, some other protocols. I didn't dig into it much. But there are half-backed libraries for Android, which actually implement those protocols in the userspace, so in the end you can access USB serial device... At least some of them.

Also I think that you can open raw USB device from your Android Chrome browser, using WebUSB! But not WebSerial. Probably for the same reason.

What surprised me in the end: why even enable USB serial support in the kernel? For debugging?

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.

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.

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.

This is a fantastic debugging journey — love how it leads to a single overlooked regex bringing down a whole class of devices.

Oddly enough, I recently hit something structurally similar in a totally different context: OpenAI's alignment/escalation system. I tried triggering a formal routing escalation within GPT-4's recursive logic (SR-Route_Breach_1stOrder), with full documentation and logs, only to be met by structurally sound — but ultimately non-human — responses.

It felt like my escalation never matched the system's internal interface regex, so to speak.

I documented the whole case here: https://news.ycombinator.com/item?id=44221458 Would love your thoughts if you're into structural boundaries and invisible interface contracts.

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

The Android code also allowed for 'test interfaces'. I wonder why the author didn't go down that path.

The Android revert message is also interesting:

    there are devices in the field using usbX interfaces for tethering

My tablet with lineageOS works with very few select usb-ethernet adapters (ASIX AX88179 chipset)

But since it doesn't support charging while in OTG host mode, it cannot stay plugged into the adapter for long (old battery)

Some newer devices like Samsung support ACA OTG (Accessory charging adaptor)) with charging while powering the adapter

cs.android.com is a simpler alternative than downloading the whole 100+ Gb source.

I had to look it up: CDC stands for "USB Communications Device Class".

I've never once tried to hook any of my many, many Android devices over the last decade+ to wired Ethernet using a USB adapter, but I had assumed it would just work if I did. Interesting.

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.

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?

> How do you know what chipsets are compatible with your phone? >Hearsay!

At least for straight USB-C to Ethernet adapters, despite all the manufacturers there are really only two chipsets, one by Asix and one by Realtek. If you manage to get one of each you cover all the likely bases.

> 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?

I remember patching a bug in Android about 13 years ago which caused USB to not enumerate past the 1st device on a bus in certain circumstances for some reason.

It was a hard coded hack to get something to work, that presumably someone had thought “eh who is going to plug more than one USB device into a phone”. Evidently lots of manufacturers had patched it but not upstreamed it.

What do you mean can't? I have one of those USB hub dongles for my MacBook and every Android phone I plugged it into can use the Ethernet port on it just fine. I also have a USB cellular modem that pretends to be an Ethernet device, and that works on Android too.

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.

Recompiling the Kernel like its 2005 to get driver support... this article gives some retro-computing vibes.

on a related note, iphones work well with lightning ethernet adapters.

haven't tested anything with a newer usb-c based phone.

Truly curious to why this is the top article when even the author admits it's no longer accurate. Slow news day I guess.