Introduction
Introduction Statistics Contact Development Disclaimer Help
_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
Visit Hacker News on the Web
COMMENT PAGE FOR:
Why Android can't use CDC Ethernet (2023)
m463 wrote 1 hour 43 min ago:
on a related note, iphones work well with lightning ethernet adapters.
haven't tested anything with a newer usb-c based phone.
vbezhenar wrote 9 hours 31 min ago:
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?
grishka wrote 12 hours 38 min ago:
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.
gambiting wrote 12 hours 36 min ago:
It's been fixed since, the article is 2 years old.
goodburb wrote 12 hours 24 min ago:
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.
grishka wrote 12 hours 31 min ago:
The USB modem worked on a Nexus 5 in 2016.
gambiting wrote 11 hours 15 min ago:
It probably identified itself as an Eth device then.
404Escalation wrote 14 hours 4 min ago:
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: [1] Would love your thoughts if
you're into structural boundaries and invisible interface contracts.
[1]: https://news.ycombinator.com/item?id=44221458
sollewitt wrote 14 hours 5 min ago:
> 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.
0xbadcafebee wrote 14 hours 17 min ago:
> 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".
preisschild wrote 6 hours 4 min ago:
I wonder if it would make sense to use NetworkManager on Android
(with the Android Wireless Settings UI acting as the NetworkManager
GUI)
throwaway314155 wrote 16 hours 41 min ago:
Truly curious to why this is the top article when even the author
admits it's no longer accurate. Slow news day I guess.
kiwijamo wrote 47 min ago:
There's still plenty of phones out there still running the older
kernels. My S21 is probably one of them unfortunately.
ahepp wrote 17 hours 1 min ago:
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.
kimixa wrote 18 hours 39 min ago:
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.
rcxdude wrote 20 hours 1 min ago:
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.
mrheosuper wrote 14 hours 33 min ago:
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)
rcxdude wrote 10 hours 55 min ago:
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.
spaqin wrote 16 hours 13 min ago:
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 wrote 17 hours 37 min ago:
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 wrote 19 hours 56 min ago:
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.
Aurornis wrote 17 hours 47 min ago:
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.
rcxdude wrote 11 hours 0 min ago:
The point is it shouldn't need a damn app, much less one to
implement it "correctly".
shakna wrote 11 hours 3 min ago:
The phone is the network manager, though.
It relying on a specific optional part of the spec to be
implemented on a different device seems to be a huge flaw.
raron wrote 18 hours 21 min ago:
As far as I remember this have a solution for both Android and
iPhone. Probably your dashcam just doesn't implemented them right.
[1]: https://developer.apple.com/forums/thread/13164
rcxdude wrote 10 hours 52 min ago:
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.
jordemort wrote 20 hours 11 min ago:
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)
chews wrote 18 hours 41 min ago:
yes to this post!
rcxdude wrote 19 hours 59 min ago:
This might actually help me out! Did you find what bit it is?
(Ah, I think I found it: [1] )
[1]: https://lkml.iu.edu/hypermail/linux/kernel/1103.2/03250.html
goodburb wrote 19 hours 6 min ago:
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]
[1]: https://gist.github.com/TalalMash/c20e6aa237e1f123ddf9686a...
Zak wrote 20 hours 39 min ago:
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.
secondcoming wrote 20 hours 54 min ago:
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
What's the problem with this?
yeth0099 wrote 12 hours 20 min ago:
Unfortunately, test interfaces have to match `testtap\d+`
jeroenhd wrote 19 hours 53 min ago:
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.
rcxdude wrote 19 hours 51 min ago:
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.
hansjorg wrote 21 hours 5 min ago:
> CDC stands for Communications Device Class [1] Why is this buried
almost at the end of the article? Why even mention it at that point?
[1]: https://en.m.wikipedia.org/wiki/USB_communications_device_clas...
bede wrote 13 hours 7 min ago:
I assumed that the article must be about a frustrated CDC employee
just trying to get internet access at work.
stavros wrote 20 hours 12 min ago:
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.
p0w3n3d wrote 8 hours 24 min ago:
Colonial Defence Committee
kps wrote 19 hours 16 min ago:
I doesn't surprise me that Android doesn't support any Ethernet
hardware made by Control Data Corporation.
MBCook wrote 14 hours 59 min ago:
This was the name I had been reading until the post explained it
as well.
andix wrote 20 hours 23 min ago:
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.
russellbeattie wrote 21 hours 8 min ago:
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.
dfc wrote 19 hours 53 min ago:
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.
russellbeattie wrote 19 hours 19 min ago:
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.
userbinator wrote 21 hours 23 min ago:
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.
preisschild wrote 6 hours 3 min ago:
"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.
[1]: https://www.reddit.com/r/GrapheneOS/comments/13264di/is_root...
ndriscoll wrote 5 hours 5 min ago:
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.
bigyabai wrote 21 hours 13 min ago:
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.
greenavocado wrote 5 hours 9 min ago:
God forbid system developers allow for personal agency.
bigyabai wrote 50 min ago:
System developers develop systems. If you want to enforce
personal agency, go to the polls and vote for it.
msgodel wrote 9 hours 55 min ago:
Do you also live in a padded room because hardwood floors are
potentially slippery and unsafe?
Jesus Christ.
Zak wrote 20 hours 52 min ago:
Do you believe the same thing about desktop PCs?
bigyabai wrote 20 hours 47 min ago:
Yes? I don't use a single computer I own as root.
gsich wrote 17 hours 48 min ago:
That wasn't the question.
Zak wrote 20 hours 38 min ago:
Few people do; "don't use root as your primary login" has been
standard advice for decades. Do you ever use sudo or
equivalent?
jimmaswell wrote 16 hours 55 min ago:
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.
StopDisinfo910 wrote 6 hours 47 min ago:
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.
smt88 wrote 16 hours 48 min ago:
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).
Wowfunhappy wrote 7 hours 59 min ago:
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.
Y_Y wrote 6 hours 40 min ago:
> 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.
diogocp wrote 15 hours 10 min ago:
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".
josephg wrote 15 hours 50 min ago:
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.
fsflover wrote 49 min ago:
> 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: [1] . My
daily driver, can't recommend it enough.
[1]: https://qubes-os.org
ndriscoll wrote 4 hours 50 min ago:
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.
anthk wrote 9 hours 16 min ago:
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.
j0057 wrote 14 hours 32 min ago:
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.
jimmaswell wrote 16 hours 5 min ago:
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.
1231232131231 wrote 18 hours 32 min ago:
Every person I know who uses a Windows computer uses an
account with Administrator privileges on their own computer.
fc417fc802 wrote 16 hours 42 min ago:
Administrator on windows has been severely restricted since
at least the debut of windows 7 if not earlier.
baby_souffle wrote 17 hours 51 min ago:
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.
zorgmonkey wrote 2 hours 35 min ago:
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] [1]
[1]: https://www.microsoft.com/en-us/msrc/windows-sec...
[2]: https://learn.microsoft.com/en-us/troubleshoot/w...
beeflet wrote 20 hours 17 min ago:
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.
Wowfunhappy wrote 19 hours 27 min ago:
...you're clearly being sarcastic but I don't get the joke.
EvanAnderson wrote 19 hours 4 min ago:
I read it as commentary on PCs being turned into these
types of things:
[1]: https://www.amazon.com/Fisher-Price-Classic-Farm...
SSLy wrote 8 hours 44 min ago:
Ah, the vCenter Server Appliance web gui!
zoky wrote 20 hours 3 min ago:
Oh wow, you got on the Windows 12 Preview somehow?
userbinator wrote 21 hours 3 min ago:
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".
lucasban wrote 19 hours 30 min ago:
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.
lurking_swe wrote 19 hours 8 min ago:
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.
sroussey wrote 18 hours 39 min ago:
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.
ruszki wrote 15 hours 6 min ago:
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.
spaqin wrote 16 hours 15 min ago:
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.
lurking_swe wrote 18 hours 35 min ago:
often times we’re lucky if a user reads those popups at
all. :)
stavros wrote 20 hours 19 min ago:
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.
ben0x539 wrote 17 hours 35 min ago:
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.
Gigachad wrote 12 hours 16 min ago:
This is half the reason I pick Apple stuff. Having a huge
company fight the bullshit from Meta and Google for you.
stavros wrote 17 hours 22 min ago:
I'm in the EU, that doesn't fly here.
EvanAnderson wrote 18 hours 58 min ago:
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.
stavros wrote 18 hours 18 min ago:
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.
dwattttt wrote 15 hours 52 min ago:
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?
ClumsyPilot wrote 11 hours 35 min ago:
It’s not user friendly
ranger_danger wrote 13 hours 42 min ago:
Not many, but I have found Sandboxie to be quite useful
for this purpose.
bigyabai wrote 20 hours 11 min ago:
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.
stavros wrote 20 hours 8 min ago:
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.
hypercube33 wrote 21 hours 34 min ago:
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 wrote 20 hours 40 min ago:
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
Retric wrote 21 hours 32 min ago:
Fixed in 2023:
[1]: https://news.ycombinator.com/item?id=44219502
franga2000 wrote 21 hours 36 min ago:
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] [1] [2]
[1]: https://github.com/LineageOS/android_packages_modules_Connecti...
[2]: https://github.com/LineageOS/android_packages_modules_Connecti...
[3]: https://github.com/LineageOS/android_packages_modules_Connecti...
luca020400 wrote 6 hours 15 min ago:
As Lineage is concerned I found that a while ago and made [1] 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
[1]: https://review.lineageos.org/c/LineageOS/android_packages_mo...
ck2 wrote 21 hours 36 min ago:
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
Marsymars wrote 19 hours 56 min ago:
What’s old is new again; Windows Phone devices did USB charging +
ethernet (+ display) a decade ago.
p0w3n3d wrote 8 hours 22 min ago:
I was really shocked when they stopped making android phones with
USB micro hdmi support, which basically allowed playing games on TV
izacus wrote 17 min ago:
That's because a lot of new phones (and tablets) support video
via USB-C just like laptops.
AStonesThrow wrote 16 min ago:
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
[1]: https://en.wikipedia.org/wiki/Thunderbolt_(interface)
AStonesThrow wrote 8 hours 18 min ago:
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.
p0w3n3d wrote 6 hours 40 min ago:
I had a micro-usb to MHL adapter added to my nexus tablet
(forgot already which version)
myself248 wrote 20 hours 35 min ago:
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.
tripdout wrote 21 hours 42 min ago:
cs.android.com is a simpler alternative than downloading the whole 100+
Gb source.
MBCook wrote 21 hours 47 min ago:
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 wrote 21 hours 37 min ago:
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 wrote 20 hours 2 min ago:
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 wrote 18 hours 24 min ago:
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.
progbits wrote 21 hours 51 min ago:
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: [1] The
description says "The default will include both usb\d+
and eth%d named interfaces on Android U+", "U+" being version 14 I
think ( [2] )
[1]: https://android-review.googlesource.com/c/platform/packages/mo...
[2]: https://en.wikipedia.org/wiki/Android_version_history
mshockwave wrote 21 hours 2 min ago:
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] [2]:
[1]: https://android-review.googlesource.com/c/platform/packages/...
[2]: https://android-review.googlesource.com/c/platform/packages/...
shadowgovt wrote 3 hours 1 min ago:
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?
gbil wrote 11 hours 21 min ago:
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!
dfc wrote 19 hours 57 min ago:
What are Android T+, U+ and V+?
charcircuit wrote 19 hours 56 min ago:
T = Android 13
U = Android 14
V = Android 15
NooneAtAll3 wrote 17 hours 14 min ago:
I wonder what was the need for this obfuscation
fc417fc802 wrote 16 hours 45 min ago:
I have the same thought every time marketing at a major OEM
changes a systematic naming scheme.
isiahl wrote 16 hours 50 min ago:
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
throwaway314155 wrote 16 hours 36 min ago:
It's not deliberate obfuscation. But the end result is
still obfuscated.
shadowgovt wrote 3 hours 1 min ago:
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.
IshKebab wrote 12 hours 20 min ago:
Not as bad as Ubuntu/Debian code names at least.
tough wrote 8 hours 52 min ago:
at least follows alphabetic order!
KeplerBoy wrote 8 hours 47 min ago:
As does android.
<- back to front page
You are viewing proxied material from codevoid.de. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.