Age | Commit message (Collapse) | Author | Files | Lines |
|
* Mode 4
USB Ethernet + CDC-NCM
iOS >= 16.0
* Mode 5
CDC-NCM Direct only (no usbmux, no USB Ethernet, no PTP)
iOS >= 17.0
|
|
iPhone 15 Pro/Pro Max support up to 10 Gbps USB 3.x. Add the necessary
case to display the correct link speed.
Requires libusb 1.0.22 (2018-03-25) or newer,
introduced in libusb/libusb@7a91d7cdccaa7dfc3db0828a5230d6260e9338d7
|
|
[1] changes to mode 3 CDC NCM by default. Revert back to mode 1:
Originally mode 1 was used, where a tethered iPhone appears as an
Ethernet interface, handled by the ipheth driver. This has been the
default for many years and is known to work on iPhone 3G, 4S, 7 Plus,
11 and newer. Since [2-3] ipheth supports CDC NCM in mode 1, and
configures the iPhone to use it.
In mode 3, the Ethernet interface is handled by kmod-usb-net-cdc-ncm.
This driver has better performance, but now the iPhone does not
provide DHCP or Internet connectivity, so we should revert to mode 1.
Analysing the network traffic, shows that both the iPhone and OpenWRT
are DHCP clients. The iPhone does not act as a DHCP server. I can set
a static IP on OpenWRT and lease 172.20.10.1 to the iPhone. Then I can
ping the iPhone and I have IPv4 connectivity. However the iPhone does
not provide Internet connectivity to OpenWRT. Maybe in mode 3, the
iPhone is a client meant to receive Internet over USB and therefore
it is not a gateway?
Attempts to switch old iPhones, such as 3G and 4S to mode 3 fail.
They remain in mode 1 and work correctly using the ipheth driver.
Comparison, tested on iPhone 7 Plus and 11
- mode 1 eth0 kmod-usb-net-ipheth 264 Mbit/s DHCP server, Internet
- mode 3 usb0 kmod-usb-net-cdc-ncm 304 Mbit/s DHCP client, no Internet
[1] https://github.com/libimobiledevice/usbmuxd/commit/c7a0dd9b82633ea347497626282e3051a469ef50
[2] https://github.com/torvalds/linux/commit/a2d274c62e44b1995c170595db3865c6fe701226
[3] https://github.com/openwrt/openwrt/commit/680f8738d02a1876ae4cd11aacf9cd56e520fadf
Signed-off-by: Georgi Valkov <gvalkov@gmail.com>
|
|
|
|
|
|
|
|
Fixes regression introduced in 84801d8 that removed the default value.
|
|
|
|
Switch mode only if guess is different than desired mode.
|
|
|
|
to a separate function.
This function can later be used to determine active mode.
|
|
ignore unexpected responses and complete initializations.
|
|
- Find and use it when completing initialization
- Mark device as not alive instead of directly closing it
- Debug and plug memory leaks
|
|
Handle some memory issues.
|
|
|
|
Use USBMUXD_DEFAULT_DEVICE_MODE env. var. to let the user control desired mode.
|
|
1904 is the M1 iMac; presumably this is now a range
Signed-off-by: Hector Martin <marcan@marcan.st>
|
|
|
|
|
|
|
|
|
|
VMware on macOS somehow exposes a bad configuration 5 for iDevices. Trying
to use it breaks things and can end up in a kernel panic on the device. The
code change introduced with this commit tries its best to make sure the USB
configuration 5 is not 'bad' before switching to it, and otherwise falling
back to configuration 4.
|
|
|
|
|
|
This makes it easier to recognize the related libusb error code
in the logs rather than numeric error codes which needed to be
looked up in the documentation
|
|
|
|
|
|
|
|
- this fixes setting configuration for iOS 11 devices inside virtual machines which caused timeout and subsequent reboot of the device when unplugged from USB
|
|
string length
|
|
|
|
|
|
|
|
Since this buffer is only used during device initialization we don't want
the usb_device struct to be unecessary big.
|
|
usb_device_add may now be called from libusb main loop via the hotplug
callbacks.
No blocking call must occur there and libusb 1.0.21 now returns an error
when trying to perform blocking I/O in this callback.
Should fix the error when hotpluging a device reported in #81
|
|
|
|
|
|
|