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