Does iOS communicate with them using some other standard?
I found this out when using CAN bus to ethernet on iPhone
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
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.
[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...
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
Another reason why having root is important on a device that you own.
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'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.
How many people on Windows create separate user accounts, run programs as those accounts (hello runas), & set ACLs?
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.
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.
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.
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.
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.
"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).
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.
This is exactly why Qubes OS was created: https://qubes-os.org. My daily driver, can't recommend it enough.
Also, 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.
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.
Jesus Christ.
https://www.reddit.com/r/GrapheneOS/comments/13264di/is_root...
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.
So what’s this about CDC Ethernet and why should I care?
CDC stands for Communications Device Class.
Regardless, my comment was mostly about how I had never run into the issue.
Why is this buried almost at the end of the article? Why even mention it at that point?
The Android revert message is also interesting:
there are devices in the field using usbX interfaces for tethering
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.
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.
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)
(Ah, I think I found it: https://lkml.iu.edu/hypermail/linux/kernel/1103.2/03250.html )
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...
And even though I wanted to stay connected, iOS decides it knows better and reconnects to my Carplay network.
I’m guessing your dash cam app is not implemented correctly.
It relying on a specific optional part of the spec to be implemented on a different device seems to be a huge flaw.
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.
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".
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.
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.
Android phone to android tablet USB tethering is also local MAC and non-functional.
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?
haven't tested anything with a newer usb-c based phone.
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.
progbits•8mo ago
Looked up the source and it appears the regex was changed from `eth\\d` to just `*` in October 2023, presumably fixing this issue:
https://android-review.googlesource.com/c/platform/packages/...
The description says "The default will include both usb\d+ and eth%d named interfaces on Android U+", "U+" being version 14 I think (https://en.wikipedia.org/wiki/Android_version_history)
mshockwave•8mo ago
[1]: https://android-review.googlesource.com/c/platform/packages/...
[2]: https://android-review.googlesource.com/c/platform/packages/...
dfc•8mo ago
charcircuit•8mo ago
U = Android 14
V = Android 15
NooneAtAll3•8mo ago
isiahl•8mo ago
throwaway314155•8mo ago
IshKebab•8mo ago
tough•8mo ago
KeplerBoy•8mo ago
shadowgovt•8mo ago
fc417fc802•8mo ago
gbil•8mo ago
shadowgovt•8mo ago