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)
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]
a few months ago I was given a unihiker board that uses cdc and didn’t work with my android devices, now that I read this I tried again since I got them upgraded to android 15 in between but still doesn’t work and I’m afraid this is due to samsung implementation of android 15! Works on ipad though which was a surprise to me!
So the meta question is: Why does the device API require the system to play these name games instead of giving enough information to discover whether the thing is an honest-to-God Ethernet device?
It’s not really obfuscation. It goes back to when Android OS’s used to be named after desserts. While in development they would be referred to just by the letter as the dessert name wasn’t usually finalized
Numbers are exactly as obfuscatory as letters. "Android 14" doesn't tell me anything other than it comes after 13 and before 15, and "V" tells me the same relative to U and W.
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.
> 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?
"Rooting" removes a lot of Android security features, though. Instead of Apps only having the necessary permissions, apps can have ALL permissions with root and thus are a huge security vulnerability.
If you give that app root, sure. That linked post is silly; your UI layer does not need root to grant privileges. e.g. `kdesu` asks for your password and hands it to `su`. The UI portion doesn't itself need setuid/root. A keyboard could of course keylog you. Don't install random keyboards.
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.
I've used sudo before, but I find that it is really difficult to type with the safety gloves on because I keep fatfingering the password and locking myself out.
My family recently got me a new computer setup that won't require sudo and other practices considered harmful. It even does shapes, colors, and animal sounds, which is good enough for my use case.
I think that's just legacy holdover largely mitigated by some of the user account access control stuff introduced with Vista. Also, administrator isn't the same as root. That would be more like system level access which is not the default level for Windows accounts.
It feels ontologically wrong to me to constantly beg my own computer for permissions to do things. I always use root on Linux, and my Gentoo machines don't even have a non-root account. (I get great satisfaction from compiling VLC to let me run it as root as well as patching Dolphin and other apps to not complain about it.) On Windows I always use an admin account and disable all UAC prompts. I've managed to have no incidents since I started this policy a decade ago by simply not downloading malware or using 123 as my password on an open SSH port. Go figure.
The point of lowering application permission is not to prevent you from doing things. It’s to prevent the application to do things you don’t want.
That’s why people try to give apps as little permission as possible and only grant them when they are required.
Technically you are one vulnerability away from irremediably losing everything after opening a seemingly innocent file. I am actually convinced the sole reason it doesn’t happen is because it doesn’t make sense to target people doing that because they virtually don’t exist.
So you don't understand why seatbelts were invented and your evidence that they're unnecessary is that you personally haven't gotten into a car accident.
"Not downloading malware" is everyone's default stance, but no one can identify all of it.
And that's only a single vector out of many. Security flaws exist in even the best operating systems that make you vulnerable even when doing everything "right" (which you emphatically are not).
My problem with this argument is that my user data is by far the most valuable thing on my computer. Almost nothing that gets protected by “root” really matters much. What I really want is a way to protect all my user data from rogue programs, but I have no way to do that on modern computers. Any program I run with my regular user account can steal or delete all of my data already. When my data is so trivially at risk, who cares if a bad program can also wipe my OS or something? I can reinstall Linux. I can’t get my data back if someone steals it.
Check Fedora Silveblue, or Kinoite (or the Budgie edition) if you don't like neither KDE nor Gnome. Inmutable OS, it can be set to a rolling channel to get daily updates, you can rollback it from GRUB in case of disasters and, even better, everything non-desktop environment based it's installed from Flatpak and containerized.
That's why you run programs as different users. Background services like nginx or jellyfin get their own users. Have a separate `games` user if you play video games. If you're going to mess with untrustworthy code, make another user first. Don't give world permissions to your home directory.
That might help if nginx has a security vulnerability. But what about all the programs I run as a user? Nobody runs their IDE or “npm install” under separate user accounts. Nor should we have to in order to prevent a package from interacting with my filesystem outside of the project directory.
macOS does ask you if you want to allow a program to access your files in $HOME. Not sure if it's a perfect solution, but still, it's something.
As a more additive approach than just giving up and running everything as root, I think in Linux you could do the same with (a fair amount of effort and) SELinux or AppArmor.
There's a difference between choosing to wear a seatbelt and being chained to the seat by the car manufacturer, who then refuses to release you "for your own safety".
I wear seatbelts (but I'm proud of my state for being the only one not to force adults to) because a car crash is much more likely than being victim to a zero-day vulnerability.
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".
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.
While I agree with you, without using a more granular permission paradigm I get more than a little antsy giving third-party software arbitrary access to even my standard user's privileges on Windows.
I've been using a dedicated computer for banking / finance work for a few years now. I also run some software that I consider less trustworthy on my "daily driver" Windows PC as a dedicated user, separate from my "daily driver" account.
I really need to make the jump to Qubes. I've been meaning to for years. The learning curve for their contrivances seems steep and I'm lazy.
Oh yeah, definitely, but mobile OSes do this fairly well. Windows just asks if you want to give access to everything or not, of course you're always going to click yes, especially if the program doesn't work without it.
It sure isn't. Although its competition is stuff like chmod (way less granular), and SELinux, and SELinux isn't winning any usability competitions either.
Five minutes after this popup exists, you won't be able to run any of the big "can't participate in your social life without these" apps anymore without granting them those elevated privileges.
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.
for the vast majority of consumers and employees this is like using a bazooka to kill a mosquito. Unnecessary and dangerous. But for some EXPERTS (IT/Tech professionals) and hobbyists, it’s crucial to their workflow.
The same popup that asks for microphone access but now says the word root in its place, and a consumer is like “not sure what root is, maybe they meant toot!”
Ever since I remember if you wanted root on Android, you had to go out your way by flashing SuperSU, then Magisk or KernelSU; most users don't ever use that. Even more so, with few recent solutions like KernelSU or some Magisk forks you have to go out of your way again to whitelist the app before it can even ask for root - mostly for avoiding detection, but that does act as an extra layer of security.
I'm not too worried about security for normal users if we kept it that way. I just want not to have any extra roadblocks for the powerusers from the banks, Authy or McDonald's.
The problem is that the bar needs to be moved higher and higher, to a level nowadays which would be annoying to most of us who know what they are doing.
20 years ago if I started to list ip addresses to my ISP on the phone I got somebody technical immediately. This doesn’t work anymore, because people know more about this. This caused that for example I could only turn WiFi on or off on my ISP’s router and nothing else without a specific request to them, a manual restart to my router days later, and I need to use a terrible buggy software.
These kind of things unfortunately also restrict beginners, or people who without such barriers would start to tinker, and eventually learn to do these safely. Even I waited for weeks with the call, who have been configuring routers for 25 years.
I’m installing now a self hosted OwnTracks on docker. A lot of beginner started to do the same. They make rookie mistakes all the time. Let them make those mistakes.
I would have never learned what I know without the freedom of making mistakes.
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.
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.
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.
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.
Windows also cant do it, right ?, If i have 2 Wireless adapter on Windows, i can not connect to 2 seperate Wifi networks(at least with using the GUI, did not try using terminal)
Yeah, you can! If both if them advertise a default route via DHCP, it can get confused (it's basically random which one it will try to connect to the internet with), but it will otherwise work. It also needs the local IP ranges to not overlap. And if the wifi network without internet doesn't advertise a default route, it'll work just fine by default.
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.
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
From what I can tell, the code that the patch covered is responsible for configuring the network interface as a client.
If another system on the phone brings up the interface as a host device to tether internet to a second device, you end up with the phone trying to configure the interface both as a router and as a client.
This. In general interface names are arbitrary and not a good way to determine anything about what it's connected to, but the usb vs eth distinction is particularly bad, because linux will use either for either 'end' of a link.
Another fun reason for wireless charging -- sometimes it's just easier to sneak power into the device by a side-channel than to try to find the right chain of adapters.
On older devices wireless charging usually doesn't provide enough power to sustain the battery level while working though. Because very few of them have Qi quick charge.
Pedantic nitpick to say: USB is a serial protocol, but video is not serial? It's a Displayport or Thunderbolt connection, using a USB-C-shaped connector and cable
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.
Right. Beyond half way through the article. I saw it, but was so baffled through the top half, I had already searched for it before I continued. I figured someone else would want to know. There's even another comment saying the exact same thing.
Regardless, my comment was mostly about how I had never run into the issue.
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.
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.
> 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.
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.
Thank you, I decided to say "fuck it" and read the entire article mentally expanding it into "center for disease control devices", and I have no regrets.
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.
Non-generic adapters are fixed in custom ROMs/LOS, on stock Android 16 my ZTE modem is still reporting as usb0 due to MAC address local bit, while Huawei dongle works just fine.
Android phone to android tablet USB tethering is also local MAC and non-functional.
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.
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)
reply