Wow, this brings back memories. I hacked on this and other iPhone support on Linux back in the day, including on getting music sync support working, back when I myself used an iPhone.
At the time I wrote usbmuxd, which implements the sync (not tethering) part of the protocol. I can now say that I had a bit of behind the scenes help from an Apple engineer; his tips helped work out some corner cases that would've been quite hard to track down otherwise. This friend sadly passed away a few years ago.
Unfortunately, Apple has always been (publicly) hostile to third party support for their devices. For example, they insist on "signing" music databases with algorithms based on their FairPlay DRM implementation, to stop non-iTunes software from syncing music to them. I reverse engineered one variant of this (which was based on a white-box AES implementation and a lot of obfuscated junk) but they kept changing the algorithm. This went into libgpod and libimobiledevice.
I suspect you meant https://bugreport.apple.com/, which is also accessible via rdar:// on consumer iOS devices. Sadly, the redirect service that has been running their ever since it was replaced by Feedback Assistant seems to not be working at the moment :(
After that CVE was disclosed in 2014, I decided to ditch all Apple hardware forever. There is absolutely no security on any Apple device. The bug meant that there was not a single working SSL encryption from Apple's first OS up until (and including) OSX 10.9.2 and iOS 7.0.6 ... which kinda speaks volumes on Q&A or security audits.
Yes, all previous OSX version up until 2014 were affected, too. The doubled `goto fail;` line was included since the first public revision of libsecurity_ssl, and the (c) of that file is 1999-2001,2005-2012 Apple Inc. [1]
Nowadays, due to Apple never using any git or any other version control software for opensourced codes, I could trace it down to Mac OSX 10.4 which was released in 2005. [2]
With 10.1, there's no libsecurity open sourced, I don't know why, but I'm pretty damn sure that at least 10.2 included the library back then. I don't have my old Powerbook G4 anymore, but I swear I could verify this bug on 10.2 (Jaguar) that was running on it at the time.
Other versions of (maybe patched?) versions of libsecurity-ssl are located on the same server, with a global directory for everything so it's not actually versioned!? [3]
At least the version of the file that has copyright 2000-2001 still has the same bug in it, so that is very likely the one that was used in the 10.1 public release [4]
USB tether is one less wireless signal to worry about. If you're tethering for a long time you're probably plugging your phone into your laptop anyway, to charge it.
I always disliked wired tether and USB cellular modems because Linux thinks it knows about the link state and will close all your sockets if you briefly lost the carrier, whereas with WiFi tethering Linux is never aware of whether the phone has a carrier or not. The ergonomics are much nicer, imho.
I admit I never tried the wired mode on iOS. Maybe it doesn't propagate the link state?
Unlike cellular modems, the iPhone acts as a router and the link state it propagates is the link state of a (virtual) interface connected to that router, independent of the state of the upstream cellular interface.
This is a silly solution, but can you solve this by creating a bridge device and putting the cellular modem (and nothing else) on the bridge? Then the link state of the bridge should remain up.
I wonder why my experience is so different. I primarily use it while taking the train to my parents and for the second part of the journey the signal is bouncing between 2g/3g/no signal but I've not encountered this.
* It disconnects more than once per day, requiring me to enable the wifi hotspot again on the phone
* The phone gets very hot
* It is slower than usb tethering: In my measurements, I get about 4MByte/s over USB and around 2MByte/s with wifi, though I'm not too confident in the results. According to the mobile provider, I should get 10.
EDIT: A fourth one is that the wifi hotspot leaks my first name and phone brand to everyone in the vicinity.
For the fourth point, the network uses the phone’s name set in General->About->Name, which can be anything you want. But your phone brand would probably still be leaked to those who might care by looking at the BSSID of the network (does iOS 14’s MAC address randomization affect those as well?).
> Why do people use the USB tether? The WiFi hotspot always works perfectly, it's an open protocol etc.
My mobile is an Android device, but I believe these reasons all still apply:
* lower power consumption for both devices with wifi off
* significantly lower & more stable ping. i drop from ~44ms with a lot of jitter (a significant number of 120ms pings) to mostly stable <35ms, with a very occasional high ping.
* better-re-sharing. if i am hosting a bunch on a phone, with USB i can bring a mobile travel router with me that has much better range & works with many more users. (it's possible that wifi extender mode may emulate some of this advantage, but it would almost certainly double the jitter problem)
You can use your mobile as a Wifi-to-USB dongle and dont have to care about wireless credentials which is very nice. This is not possible with a wifi hotspot because in Hotspot mode you cannot use your wifi in parallel.
I do use that with a mobile router that supports Android's usb-cdc-ethernet adapter to forward hotel wifis when i only have one code for a single device (mac address). Or when the wifi gadget you want to use doesnt work with the captive portal. Fast and hassle free.
Personally the wifi version of wireless hotspot was always finicky for me on Linux, requiring a few restarts of the hotspot and the computer wifi to get synced up.
Wired tethering always worked instantly. Well, until now sadly :(. I tried to do this the other day and I just figured something was bugged, but I didn’t realise it is an iOS14 issue. Guess I am stuck with the wifi hotspot for now when I am out and about.
I use a desktop. USB tether works well (I have android phone, not apple) for me. Why bother setting up wifi and buy additional device to make it work with my desktop?
Bummer, I just picked up a nice little cheap GL.iNet travel router ("Mango" and "Slate" are popular models) that works (worked?) with USB tethering on iOS (presumably pre-iOS 14).
I'm sure WiFi tethering will still work with it, but it's nice to remove one potentially flaky connection from the equation.
Apple is probably not going to help for this, sadly. I am fairly sure the details of tethering are considered to be private API and when something like that breaks (having likely been created by reverse engineering originally) they just don’t care. That being said, perhaps you’ll get some support from some skills do reverse engineers to help update that code!
I'm surprised they don't use FreeBSD or some sort of in-house headless build of macOS, since their entire product line has been built around FreeBSD/POSIX base for macOS.
I went to summer house to work and got my old Linux with me. For 10 days, I was out of internet bc wifi driver (obscure brand) was also broken. It was very frustrating, now I know why!
If you manage to get anyone from Apple to speak with you send them my way also. I am the author of IOS support for DeviceFarmer ( previously OpenSTF ). Part of that support involves getting video of the screen over the USB connection which uses the same undocumented pathways that libimobiledevice uses. I've been attempting to find someone at Apple to support the open source efforts for nearly a year to no avail.
What I would like Apple to support is fetching the raw h264 stream in a documented fashion, rather than forcing one to use AVFoundation and get pre-processed frames/data. Only allowing decoded video makes it impossible to scale. ( having many devices connected to a single mac all streaming video )
It would also be awesome if they would open up and document all the protocols and operations that the lockdown protocol supports. I doubt that will ever happen though.
I'm not an Apple user. The reason I've spent the last year and a half developing an open source solution to support Apple devices is because it is a challenge and is profitable. I view myself as a sort of technological mercenary. I go where my skills are needed.
I don't own a personal mac laptop, nor do I use an iPhone. If Apple gave me a macbook pro and an iPhone I wouldn't use either. ( other than to develop software that requires those )
I do though believe in making required technical things easier for others. It is a good feeling making something possible with IOS devices that hasn't been done as open source previously.
Creating and testing IOS apps isn't something that will cease to be just because hardcore developers dislike the closed Apple ecosystem. The people who fund Apple, in my opinion, aren't hardcore geeks. They are the normal folk in the world.
My only request to Apple is to please listen to what the developers want and provide some of the information I need so that I can in turn improve the development experience for the developers that are already paying into their ecosystem.
Sitting on your high horse saying "I don't like the way big companies function" doesn't pay the bills or convince anyone you are a good engineer who will stay professional regardless of your personal feelings.
1. If the work is ultimately for a company you are working for fulltime and getting paid from the start. This is the case with IOS support for DeviceFarmer. I work fulltime for T-Mobile. I am thankful to them for allowing the majority of the resulting software to be open sourced. The reason they allowed it to be that way, and wanted it from the start, is so that we can benefit from users using the software, finding bugs, and reporting them. There have been contributions from the open source community to it as well that have been very helpful.
2. By providing paid support for an open source project. There is a great need right now for someone ( and/or many someones ) to work with companies to get DeviceFarmer setup and working well for their needs. I do this a little bit on the side myself, but it is tricky because I don't have much time remaining after my day job to do so, and I have to be careful not to let it become a conflict of interest.
DeviceFarmer as a entity is a collection of key personnel who have been maintaining OpenSTF. I believe all of them are fulltime employees of various companies that use it internally and contribute to it to address their own needs. I joined the core team as a result of writing IOS support for it ( I say "writing", despite also porting in a large chunk of IOS support from other open source contributors; mrx in specific )
Right now DeviceFarmer isn't a legal entity. There is no company or non-profit currently. It is just a bunch of developers cooperating. We have considered creating a non-profit company for it, but it has not been done yet. The members of the group are spread out internationally.
The original main author(s) of OpenSTF formed the company HeadSpin out of it, and offered it as a commercial project. Very recently the company collapsed as a result of internal corruption, but the project itself lives on. Really they had abandoned OpenSTF 2-years ago anyway. The rebranding to DeviceFarmer instead of OpenSTF is to move the project to being open and no longer restricted by HeadSpin.
HeadSpin themselves refused to ever accept contribution of IOS support into the OpenSTF project, because IOS support was one of the main differences in their commercial offering. They refused to ever open source that portion of OpenSTF. Forking the project was necessary to allow this. Essentially the entire community has moved to the fork and abandoned OpenSTF. The crumbling of HeadSpin sealed the deal and OpenSTF is essentially no more.
Another option than creating your own legal entity is to join a fiscal sponsor of open source projects, like Software Freedom Conservancy, Software in the Public Interest or one of the other open source foundations:
At the time I wrote usbmuxd, which implements the sync (not tethering) part of the protocol. I can now say that I had a bit of behind the scenes help from an Apple engineer; his tips helped work out some corner cases that would've been quite hard to track down otherwise. This friend sadly passed away a few years ago.
Unfortunately, Apple has always been (publicly) hostile to third party support for their devices. For example, they insist on "signing" music databases with algorithms based on their FairPlay DRM implementation, to stop non-iTunes software from syncing music to them. I reverse engineered one variant of this (which was based on a white-box AES implementation and a lot of obfuscated junk) but they kept changing the algorithm. This went into libgpod and libimobiledevice.