IOS14 USB tethering not working

[luochongjun]

I used Tethering on Openwrt and it worked fine with IOS13.
Recently, my device has been upgraded to IOS14, and it doesn't work properly.
I can successfully obtain the IP address 172.20.10.2 and ping 172.20.10.1, but I can't access the Internet, nor can I ping other IP addresses.
I checked openwrt's firewall and routing settings, and I can make sure they work.
At the same time, I was testing on Ubuntu 16.04.12 and had the same problem.
I also tried to compile the latest libimobiledevice and usbbmuxd source code, did not solve the problem.
I wrote a post on the openwrt forum, and others had the same problem
https://forum.openwrt.org/t/has-the-ios14-tethering-issue-been-resolved/74949

[nikias]

Can you test this on macOS by any chance? Maybe it needs some permission or similar. Something must have changed, but also before this was not related to code in libimobiledevice. The code is implemented in the kernel here: https://github.com/torvalds/linux/blob/master/drivers/net/usb/ipheth.c
The fact that you get an IP address and can ping the phone shows that the kernel driver works though...

[luochongjun]

Thanks,
Doesn't the usbmuxd have any relevant code?
Maybe it's permission related, but the kernel just does the driver work, not have related code.

[phrichuk]

I am having this same problem, and it is being mentioned now in more and more forums. I have not seen a message from anyone who has iOS14 iPhone USB tethering working on Linux/OpenWRT, so I believe it is currently broken.
I can see from page https://libimobiledevice.org/status/ "This list is based on known services until iOS 13.5." - so iOS14 has not yet been formally checked against. I wonder if it would be worth updating, to confirm this is currently broken for iOS14 - it might save time for people hunting round for a solution that does not appear to exist yet. Fingers crossed it is a 'quick fix' to mend this, and Apple have not done anything nasty in iOS14 to sabotage the great work that is libimobiledevice!

[kkota1]

Note that this doesn't fix the issue, but I found that since updating to iOS 14, I now have to manually run idevicepair pair in order to get the "Trust this device?" dialog on the phone. IIRC, it used to automatically do this after the physical connection was detected.

Additionally, I can ping the iPhone gateway directly

traceroute to 172.20.10.1 (172.20.10.1), 30 hops max, 60 byte packets
 1  _gateway (172.20.10.1)  0.895 ms  0.842 ms  0.813 ms

but pinging google hangs.

PING google.com(lax31s11-in-x0e.1e100.net (2607:f8b0:4007:811::200e)) 56 data bytes

This suggests to me that there's an issue with iOS reading the packet and deciding not to forward it to the carrier. Note that DNS works.

I've tried this networkd config with and without masquerading to no avail

[Match]
Name=enp55s0u1c4i2

[Network]
DHCP=yes
IPMasquerade=yes

USB tethering still works on Windows 10, so I am going to attempt to compare the outgoing packets and spoof a W10 device.

[nikias]

If you have to run idevicepair pair then something is wrong with the usbmuxd setup. usbmuxd is handling the pairing as soon as a device is detected, and this has the dialog pop up on the device. Regarding tethering, the only thing that usbmuxd does is that it selects a different USB config for the device. There is nothing done in particular regarding the tethering, the code to expose the USB ethernet device is handled by the ipheth kernel module. Maybe the setup sequence changed. Currently it sends a setup packet here:
https://github.com/torvalds/linux/blob/master/drivers/net/usb/ipheth.c#L250
We probably need a USB packet analyzer on a supported platform (macOS/Windows) to figure out what has changed or what we are missing.

[phrichuk]

Thanks for this. I am getting a bit old now, my era was ZX Spectrum and BBC Micro... I would have had a go myself at solving equivalent problems back in the day... glad to see the younger generation (I assume!) getting stuck into this problem!
In terms of symptoms, I had not noticed any recent change in the 'trust device' dialogue behaviour myself. I can ping the gateway as above, and agree DNS seems to work. I upgraded to iOS 14.0.1 earlier today, and the issue remains as per iOS14. And it works fine for me too on W10. Something must have changed within iOS since v13.x- there are several traceroute steps within the iPhone between 172.20.10.1 and the outside world when this is working (why???), so something must have changed in there somewhere! This must be solvable - because it still works on W10! Therefore best of luck to kkota1 and others trying to spot the significant difference between W10 behaviour and Linux/WRT behaviour here, then hopefully emulating the 'new' required behaviour via Linux/OpenWRT as per W10!

[kkota1]

Packet comparison for usb tethering, google.com ping request, seq = 1. Linux above (no ping response), Windows below (success).

[lwhsu]

@kkota1 thanks for the analysis and experiments. I got totally the same issue here. The packets you captured look like the ethernet packets on the network interface. I think as @nikias suggested, we may need to compare the USB packets used to setup tethering. Maybe this helps https://gitlab.com/wireshark/wireshark/-/wikis/CaptureSetup/USB .

[kkota1]

@lwhsu ok I will try to do that

[nikias]

@kkota1 nice, could you expand the ipv6 entries or maybe even upload the pcap files?

[kkota1]

@nikias attached
packet-compare.zip

[kkota1]

@nikias I attached the raw usb packets from successful windows pings. See time 4.9 to 8.5s

I won't have time to try the linux usb packets today but hopefully someone else here is able to

windows-ping-usbpcap.zip

[nikias]

@kkota1 thanks for the pcap files. I was looking on mobile before, so I didn't see it's just the ICMP packets. I think the problem here will be the actual "handshake" that occurs when the device is attached to the host. This is assuming that the actual network device works fine (and it seems to do, since ping to the phone works, and apparently DNS also). Something is preventing the traffic from leaving the phone, so it feels like there's a new "pairing" sequence or similar that needs to be done for this to work.

[kkota1]

If I am reading this correctly, when I replayed the windows traffic from linux, it worked. So this is indeed a packet issue? This is my first time using tcpreplay

[kiran@kiran-linux packet-compare]$ sudo tcpreplay -i enp55s0u1c4i2 -K hotspot-windows.pcapng 
[sudo] password for kiran: 
File Cache is enabled
Actual: 329 packets (158214 bytes) sent in 21.73 seconds
Rated: 7277.9 Bps, 0.058 Mbps, 15.13 pps
Flows: 15 flows, 0.69 fps, 115 flow packets, 214 non-flow
Statistics for network device: enp55s0u1c4i2
	Successful packets:        329
	Failed packets:            0
	Truncated packets:         0
	Retried packets (ENOBUFS): 0
	Retried packets (EAGAIN):  0

[nikias]

Hmm does the ICMP ping get a reply back when replaying? Maybe it is something completely different, like some ipv6 issue

[kkota1]

I am seeing successful ping responses but I'm not sure if it's just replaying both request AND responses on my local machine, or if it's actually sending the requests out and waiting for real responses from the internet.

I am currently trying tcpliveplay instead

[luochongjun]

I compared the USB packets of WIN10 and Linux, and found that feature configuration packets will be sent to iPhone in WIN10, but Linux does not. I am trying to set it in Linux.

[luochongjun]

If I am reading this correctly, when I replayed the windows traffic from linux, it worked. So this is indeed a packet issue? This is my first time using tcpreplay

[kiran@kiran-linux packet-compare]$ sudo tcpreplay -i enp55s0u1c4i2 -K hotspot-windows.pcapng 
[sudo] password for kiran: 
File Cache is enabled
Actual: 329 packets (158214 bytes) sent in 21.73 seconds
Rated: 7277.9 Bps, 0.058 Mbps, 15.13 pps
Flows: 15 flows, 0.69 fps, 115 flow packets, 214 non-flow
Statistics for network device: enp55s0u1c4i2
	Successful packets:        329
	Failed packets:            0
	Truncated packets:         0
	Retried packets (ENOBUFS): 0
	Retried packets (EAGAIN):  0

Very cool, I will try

[luochongjun]

For the SET Feature USB data packets captured on Win10, the same type of data packets do not appear on Linux

[luochongjun]

Attach the usb package
usb package.zip

[luochongjun]

I found that every time I got the MAC address in Win10, the following packets would be sent out. From the description, they should be specific to iPhone.

I try to simulate this packet in Linux, but I don't know how to do it. I can simulate setup data, but I can't simulate URB Function. Who can give me some advice?

[nikias]

Good find. The dump shows the "CARRIER" packet

{bmRequestType: 0xc0, bRequest: 69, wValue: 0x0000, wIndex: 0, wLength: 1}

which returnes 04 in the buffer.

Then the above packet:

{bmRequestType: 0xc1, bRequest: 3, wValue: 0x0000, wIndex: 2, wLength: 4}

Returns 02 00 00 00 in the buffer. Directly after there's also another one:

{bmRequestType: 0xc1, bRequest: 3, wValue: 0x0000, wIndex: 2, wLength: 4}

Returns 00 00 00 00 in the buffer.

Finally it shows a "get mac address" request

{bmRequestType: 0xc0, bRequest: 0, wValue: 0x0000, wIndex: 2, wLength: 6}

The "CARRIER" and "get mac address" packets are handled by ipheth; so it seems we are missing the two new ones there.

[nikias]

Right... there's also that OUT URB

{bmRequestType: 0x40, bRequest: 64, wValue: 0x0064, wIndex: 0, wLength: 0}

[luochongjun]

Both CHECK_CARRIER and GET_MAC get the correct return values in Linux, but it's hard to determine if the packet is of request type bmRequestType: 0x40. I didn't find a set URB Function in the driver.

[nikias]

This would send the OUT URB after getting the mac address. Maybe that solves it?

--- a/ipheth.c	2020-09-27 14:51:03.000000000 +0200
+++ b/ipheth.c	2020-09-27 14:55:27.000000000 +0200
@@ -284,6 +284,7 @@
 	struct usb_device *udev = dev->udev;
 	struct net_device *net = dev->net;
 	int retval;
+	int retval2;

 	retval = usb_control_msg(udev,
 				 usb_rcvctrlpipe(udev, IPHETH_CTRL_ENDP),
@@ -307,6 +308,20 @@
 		retval = 0;
 	}

+	retval2 = usb_control_msg(udev,
+			usb_sndctrlpipe(udev, IPHETH_CTRL_ENDP),
+			0x40, /* request */
+			0x40, /* request type */
+			0x64, /* value */
+			0x00, /* index */
+			NULL,
+			0,
+			IPHETH_CTRL_TIMEOUT);
+	if (retval2 < 0) {
+		dev_err(&dev->intf->dev, "%s: usb_control_msg: %d\n",
+			__func__, retval2);
+	}
+
 	return retval;
 }

[nikias]

One thing I also noticed is that ipheth is sending the CARRIER packet every second. Maybe the device doesn't like that either.

[kkota1]

I submitted the bug info and this thread to the /net/usb maintainers' email

I don't have the expertise to help with the bug fix but if anyone wants more pcap files or me to do QA work, just let me know. Thanks all

[luochongjun]

I've added all the different packets to Linux, but the problem remains.
I had to try to find official support for IOS.

[nikias]

Well I am quite confident this can be made operational. Maybe we are just looking at the wrong place...

[kkota1]

win-handshake.zip

Here's another pcap from windows. Pairing starts at 26 seconds