Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
|
|
PACKAGE_STRING, in some cases, might not include the version.
Use PACKAGE_NAME PACKAGE_VERSION instead.
Thanks to @httpstorm to point this out!
|
|
Thanks to @xunmod for reporting!
|
|
* 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>
|
|
|
|
|
|
|
|
|
|
|
|
Thanks to @intelfx for spotting this.
|
|
|
|
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.
|
|
Some older devices (e.g. iOS 2.x) wouldn't allow querying the iOS version
if the device is not paired. In this case we just assume an old version
instead of erroring out, and this way the device will be made available.
|
|
On older devices with iOS 5 and even before there is no "ProductName", only
"ProductType" or "DeviceClass" (which is still present).
usbmuxd fails to connect these devices, because it can't receive product name.
"DeviceClass", like "ProductVersion", can be retrieved even in locked state,
so this commit changes it to use that instead.
|
|
This is the PID used by the mac studio when in recovery mode.
|
|
1904 is the M1 iMac; presumably this is now a range
Signed-off-by: Hector Martin <marcan@marcan.st>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Thanks to @timgates32 for spotting this.
|
|
|
|
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.
|
|
called from device_abort_connect()
... which itself is only called from within client_close()
|
|
|
|
|
|
|
|
|
|
|
|
In environments with a larger number of devices, especially when these
are connected at the time usbmuxd starts, there will be a lot of simultaneous
connection attemps. With a backlog size of 5 these connection attempts will
easily get a ECONNREFUSED thus failing to perform the required preflight
operations. Increasing this to 256 will help to mitigate this.
|
|
|
|
|
|
|
|
|