Why Android can't use CDC Ethernet (2023)(jordemort.dev)
jordemort.dev
Why Android can't use CDC Ethernet (2023)
https://jordemort.dev/blog/why-android-cant-use-cdc-ethernet/
142 comments
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 )
(Ah, I think I found it: https://lkml.iu.edu/hypermail/linux/kernel/1103.2/03250.html )
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...
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...
[deleted]
yes to this post!
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)
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)
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/...
[1]: https://android-review.googlesource.com/c/platform/packages/...
[2]: https://android-review.googlesource.com/c/platform/packages/...
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?
What are Android T+, U+ and V+?
T = Android 13
U = Android 14
V = Android 15
U = Android 14
V = Android 15
I wonder what was the need for this obfuscation
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
It's not deliberate obfuscation. But the end result is still obfuscated.
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.
I have the same thought every time marketing at a major OEM changes a systematic naming scheme.
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...
[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...
As Lineage is concerned I found that a while ago and made https://review.lineageos.org/c/LineageOS/android_packages_mo...
But no one bothered to test, and I had no way to verify so it's in a limbo for now :)
It's always a mix of things people report to us, things someone randomly pick up, but then we need real users testing them out lol
It's always a mix of things people report to us, things someone randomly pick up, but then we need real users testing them out lol
> 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".
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".
I wonder if it would make sense to use NetworkManager on Android (with the Android Wireless Settings UI acting as the NetworkManager GUI)
It's because some usbX devices must be used by other modules, and managing the list is something they didn't want to do. So ethX it is.
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?
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.
Another reason why having root is important on a device that you own.
"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.
https://www.reddit.com/r/GrapheneOS/comments/13264di/is_root...
https://www.reddit.com/r/GrapheneOS/comments/13264di/is_root...
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.
I'm not an android dev, but the author of that reddit comment (Daniel Micay) is definitely an Android Security expert, so I trust his advice there.
He is an "expert", also known as a "corporate mouthpiece".
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.
Do you believe the same thing about desktop PCs?
Yes? I don't use a single computer I own as root.
Few people do; "don't use root as your primary login" has been standard advice for decades. Do you ever use sudo or equivalent?
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.
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.
Oh wow, you got on the Windows 12 Preview somehow?
...you're clearly being sarcastic but I don't get the joke.
I read it as commentary on PCs being turned into these types of things: https://www.amazon.com/Fisher-Price-Classic-Farmer-Says/dp/B...
Ah, the vCenter Server Appliance web gui!
Every person I know who uses a Windows computer uses an account with Administrator privileges on their own computer.
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.
UAC is not a security boundary, it is instead considered a defense-in-depth feature (aka best effort but bypassable). This is officially documented by Microsoft in multiple places.
[0] https://www.microsoft.com/en-us/msrc/windows-security-servic...
[1] https://learn.microsoft.com/en-us/troubleshoot/windows-serve...
Administrator on windows has been severely restricted since at least the debut of windows 7 if not earlier.
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.
I mean, ok, but why?
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.
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).
"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.
> 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
This is exactly why Qubes OS was created: https://qubes-os.org. My daily driver, can't recommend it enough.
This is exactly why Qubes OS was created: https://qubes-os.org. My daily driver, can't recommend it enough.
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.
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".
The difference is that you can take off your seatbelt for a moment if you need to reach into glove compartment.
Also, you're statistically much more likely to die from a car crash than a malware attack.
Also, you're statistically much more likely to die from a car crash than a malware attack.
> you're statistically much more likely to die from a car crash than a malware attack
That's true now, but I honestly don't think it'll be the case in twenty years.
That's true now, but I honestly don't think it'll be the case in twenty years.
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.
No but you can elevate to it when you need it. You can't on android.
That wasn't the question.
God forbid system developers allow for personal agency.
System developers develop systems. If you want to enforce personal agency, go to the polls and vote for it.
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.
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.
There's plenty of actually granular permissions; they're just not used by anyone.
How many people on Windows create separate user accounts, run programs as those accounts (hello runas), & set ACLs?
How many people on Windows create separate user accounts, run programs as those accounts (hello runas), & set ACLs?
Not many, but I have found Sandboxie to be quite useful for this purpose.
It’s not user friendly
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.
That really should not surprise people when their smartphone has been telling them it is the wrong design pattern for over a decade.
Point the finger at whoever you want. If you need to find who broke the bicycle for the mind, I think most of us know who's responsible.
Point the finger at whoever you want. If you need to find who broke the bicycle for the mind, I think most of us know who's responsible.
I'm not sure what you mean, I find smartphones' "do you want to allow this application access to X?" a pretty understandable and secure pattern.
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.
agreed.
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.
Having the _option_ is a must.
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.
Having the _option_ is a must.
Agree, but how it is enabled is important.
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!”
And then their whole machine is compromised.
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!”
And then their whole machine is compromised.
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.
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.
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.
often times we’re lucky if a user reads those popups at all. :)
Do you also live in a padded room because hardwood floors are potentially slippery and unsafe?
Jesus Christ.
Jesus Christ.
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.
And even though I wanted to stay connected, iOS decides it knows better and reconnects to my Carplay network.
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.
I’m guessing your dash cam app is not implemented correctly.
As far as I remember this have a solution for both Android and iPhone. Probably your dashcam just doesn't implemented them right.
https://developer.apple.com/forums/thread/13164
https://developer.apple.com/forums/thread/13164
[deleted]
Only if you have an app. It could well be the only reason you would want to make a custom app, because of this irritating behaviour by the OS.
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.
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.
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
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
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:
The Android revert message is also interesting:
there are devices in the field using usbX interfaces for tethering
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.
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.
Unfortunately, test interfaces have to match `testtap\d+`
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
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
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.
What’s old is new again; Windows Phone devices did USB charging + ethernet (+ display) a decade ago.
I was really shocked when they stopped making android phones with USB micro hdmi support, which basically allowed playing games on TV
That's because a lot of new phones (and tablets) support video via USB-C just like laptops.
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
https://en.wikipedia.org/wiki/Thunderbolt_(interface)
https://en.wikipedia.org/wiki/Thunderbolt_(interface)
My HDMI Philips monitor supported MHL. And DVI-D, incidentally.
However, I was never able to use MHL display. None of my devices seemed to support it. Android Kitkat/Lollipop, Samsung Galaxy Tab.
I’ve no idea what sort of cable would’ve been needed. There was no USB connector on the monitor.
However, I was never able to use MHL display. None of my devices seemed to support it. Android Kitkat/Lollipop, Samsung Galaxy Tab.
I’ve no idea what sort of cable would’ve been needed. There was no USB connector on the monitor.
I had a micro-usb to MHL adapter added to my nexus tablet (forgot already which version)
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.
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.
Instead of looking it up you could have read the article:
So what’s this about CDC Ethernet and why should I care?
CDC stands for Communications Device Class.
So what’s this about CDC Ethernet and why should I care?
CDC stands for Communications Device Class.
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.
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.
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?
Does iOS communicate with them using some other standard?
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
I found this out when using CAN bus to ethernet on iPhone
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?
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.
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?
Why is this buried almost at the end of the article? Why even mention it at that point?
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 assumed that the article must be about a frustrated CDC employee just trying to get internet access at work.
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.
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.
It's been fixed since, the article is 2 years old.
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.
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.
[deleted]
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.
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.
There's still plenty of phones out there still running the older kernels. My S21 is probably one of them unfortunately.
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)