/net/usb/ipheth.c incompatibility with Apple iOS 14

/net/usb/ipheth.c incompatibility with Apple iOS 14

[Kiran]

Effect on end user: when a linux machine is connected via USB to an
iPhone that has been updated to iOS 14 and has personal hotspot mode
turned on, the user cannot connect to the internet.

Troubleshooting: DNS works, the linux machine can ping the iPhone
gateway, pinging google.com hangs. It appears that there is a change
to the USB packets that iOS expects.

Here is a link to what I think is the most relevant part of a Github
issue discussion with more specific details:

https://github.com/libimobiledevice/libimobiledevice/issues/1038#issuecomment-699630379

This is my first linux bug report and I'm not familiar with kernel
development. The other people in the Github post will be better to
talk to regarding a fix. But if I can provide more info, just let me
know.

Thanks,

Kiran

Re: /net/usb/ipheth.c incompatibility with Apple iOS 14

[Greg KH]

On Sun, Sep 27, 2020 at 07:14:39AM -0700, Kiran wrote:
> Effect on end user: when a linux machine is connected via USB to an
> iPhone that has been updated to iOS 14 and has personal hotspot mode
> turned on, the user cannot connect to the internet.
> 
> Troubleshooting: DNS works, the linux machine can ping the iPhone
> gateway, pinging google.com hangs. It appears that there is a change
> to the USB packets that iOS expects.
> 
> Here is a link to what I think is the most relevant part of a Github
> issue discussion with more specific details:
> 
> https://github.com/libimobiledevice/libimobiledevice/issues/1038#issuecomment-699630379
> 
> This is my first linux bug report and I'm not familiar with kernel
> development. The other people in the Github post will be better to
> talk to regarding a fix. But if I can provide more info, just let me
> know.

Not much we can do about this, but if you come up with a patch that
works, please let us know and we will be glad to review it.

good luck!

greg k-h

Re: /net/usb/ipheth.c incompatibility with Apple iOS 14

[Yves-Alexis Perez]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Mon, 2020-09-28 at 19:50 +0200, Greg KH wrote:
> On Sun, Sep 27, 2020 at 07:14:39AM -0700, Kiran wrote:
> > Effect on end user: when a linux machine is connected via USB to an
> > iPhone that has been updated to iOS 14 and has personal hotspot mode
> > turned on, the user cannot connect to the internet.
> > 
> > Troubleshooting: DNS works, the linux machine can ping the iPhone
> > gateway, pinging google.com hangs. It appears that there is a change
> > to the USB packets that iOS expects.
> > 
> > Here is a link to what I think is the most relevant part of a Github
> > issue discussion with more specific details:
> > 
> > https://github.com/libimobiledevice/libimobiledevice/issues/1038#issuecomment-699630379
> > 
> > This is my first linux bug report and I'm not familiar with kernel
> > development. The other people in the Github post will be better to
> > talk to regarding a fix. But if I can provide more info, just let me
> > know.
> 
> Not much we can do about this, but if you come up with a patch that
> works, please let us know and we will be glad to review it.

Hi Greg,

I'm experiencing the issue myself so I should be able to test a patch and
submit it properly once we have one.

Unfortunately it seems that we don't really have a clue how the driver is
really supposed to behave and negotiate with the device. I'm adding Diego
Giagio to CC because his address is in the file header and in case he could
jump in and help, but I'm not holding my breath since the copyright date is
from 2009.

It'd be nice if we had some documentation and/or contact at Apple, but other
than that I guess we'll have to poke around and see how the itunes driver do
their job in MacOS or Windows.

Regards,
- -- 
Yves-Alexis
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl+CzJsACgkQ3rYcyPpX
RFt2Rgf/VzM6ym/SL+90osHG6Z92xGnPKoR1j3RJcJtVSAuZwXADnzeKB0dd8Bvx
TSiFYkTItY0KzFmDvuZ4jFqhnhuG2Qd8q8kJlLNh7lQKXa79547a2vBNA9oRF25a
5hnAsK0KEJTtDYmCptUUpH8V18U5zlIqFfF+/eWyzyBdWyh4bnv5U22kQeXtyY1o
iGEhGQ4+U/lJTfjdb/t5ZS47EJIbKRN8ExrdKszp6ob7Sd6TOn5tJwfbJ0juu+50
f9o4mFXTs1um8PHNMY/cmVuLY31SSZEO6cjh6RMvg6D+LQY/tNYM33D0Pio5/zcM
+L5UuP9vyA2Hnh6g/BAIId+WiBUaNQ==
=i4w2
-----END PGP SIGNATURE-----

[PATCH] usbnet: ipheth: fix connectivity with iOS 14

[Yves-Alexis Perez]

Starting with iOS 14 released in September 2020, connectivity using the
personal hotspot USB tethering function of iOS devices is broken.

Communication between the host and the device (for example ICMP traffic
or DNS resolution using the DNS service running in the device itself)
works fine, but communication to endpoints further away doesn't work.

Investigation on the matter shows that UDP and ICMP traffic from the
tethered host is reaching the Internet at all. For TCP traffic there are
exchanges between tethered host and server but packets are modified in
transit leading to impossible communication.

After some trials Matti Vuorela discovered that reducing the URB buffer
size by two bytes restored the previous behavior. While a better
solution might exist to fix the issue, since the protocol is not
publicly documented and considering the small size of the fix, let's do
that.

Tested-by: Matti Vuorela <matti.vuorela@bitfactor.fi>
Signed-off-by: Yves-Alexis Perez <corsac@corsac.net>
Link: https://lore.kernel.org/linux-usb/CAAn0qaXmysJ9vx3ZEMkViv_B19ju-_ExN8Yn_uSefxpjS6g4Lw@mail.gmail.com/
Link: https://github.com/libimobiledevice/libimobiledevice/issues/1038
Cc: stable@vger.kernel.org
---
 drivers/net/usb/ipheth.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/usb/ipheth.c b/drivers/net/usb/ipheth.c
index b09b45382faf..207e59e74935 100644
--- a/drivers/net/usb/ipheth.c
+++ b/drivers/net/usb/ipheth.c
@@ -59,7 +59,7 @@
 #define IPHETH_USBINTF_SUBCLASS 253
 #define IPHETH_USBINTF_PROTO    1
 
-#define IPHETH_BUF_SIZE         1516
+#define IPHETH_BUF_SIZE         1514
 #define IPHETH_IP_ALIGN		2	/* padding at front of URB */
 #define IPHETH_TX_TIMEOUT       (5 * HZ)
 
-- 
2.29.2

Re: [PATCH] usbnet: ipheth: fix connectivity with iOS 14

[Sergei Shtylyov]

Hello!

On 19.11.2020 20:24, Yves-Alexis Perez wrote:

> Starting with iOS 14 released in September 2020, connectivity using the
> personal hotspot USB tethering function of iOS devices is broken.
> 
> Communication between the host and the device (for example ICMP traffic
> or DNS resolution using the DNS service running in the device itself)
> works fine, but communication to endpoints further away doesn't work.
> 
> Investigation on the matter shows that UDP and ICMP traffic from the
                                         ^ "no" missing?

> tethered host is reaching the Internet at all. For TCP traffic there are
> exchanges between tethered host and server but packets are modified in
> transit leading to impossible communication.
> 
> After some trials Matti Vuorela discovered that reducing the URB buffer
> size by two bytes restored the previous behavior. While a better
> solution might exist to fix the issue, since the protocol is not
> publicly documented and considering the small size of the fix, let's do
> that.
> 
> Tested-by: Matti Vuorela <matti.vuorela@bitfactor.fi>
> Signed-off-by: Yves-Alexis Perez <corsac@corsac.net>
> Link: https://lore.kernel.org/linux-usb/CAAn0qaXmysJ9vx3ZEMkViv_B19ju-_ExN8Yn_uSefxpjS6g4Lw@mail.gmail.com/
> Link: https://github.com/libimobiledevice/libimobiledevice/issues/1038
> Cc: stable@vger.kernel.org
[...]

MBR, Sergei

Re: [PATCH] usbnet: ipheth: fix connectivity with iOS 14

[Yves-Alexis Perez]

On Fri, 2020-11-20 at 12:15 +0300, Sergei Shtylyov wrote:
> > Investigation on the matter shows that UDP and ICMP traffic from the
>                                          ^ "no" missing?
Yes indeed. Thanks and sorry for the typo.

Regards,
-- 
Yves-Alexis

Re: [PATCH] usbnet: ipheth: fix connectivity with iOS 14

[Jakub Kicinski]

On Thu, 19 Nov 2020 18:24:39 +0100 Yves-Alexis Perez wrote:
> Starting with iOS 14 released in September 2020, connectivity using the
> personal hotspot USB tethering function of iOS devices is broken.
> 
> Communication between the host and the device (for example ICMP traffic
> or DNS resolution using the DNS service running in the device itself)
> works fine, but communication to endpoints further away doesn't work.
> 
> Investigation on the matter shows that UDP and ICMP traffic from the
> tethered host is reaching the Internet at all. For TCP traffic there are
> exchanges between tethered host and server but packets are modified in
> transit leading to impossible communication.
> 
> After some trials Matti Vuorela discovered that reducing the URB buffer
> size by two bytes restored the previous behavior. While a better
> solution might exist to fix the issue, since the protocol is not
> publicly documented and considering the small size of the fix, let's do
> that.
> 
> Tested-by: Matti Vuorela <matti.vuorela@bitfactor.fi>
> Signed-off-by: Yves-Alexis Perez <corsac@corsac.net>
> Link: https://lore.kernel.org/linux-usb/CAAn0qaXmysJ9vx3ZEMkViv_B19ju-_ExN8Yn_uSefxpjS6g4Lw@mail.gmail.com/
> Link: https://github.com/libimobiledevice/libimobiledevice/issues/1038

Applied to net with the typo fixed, thanks!

Re: [PATCH] usbnet: ipheth: fix connectivity with iOS 14

[Yves-Alexis Perez]

On Sat, 2020-11-21 at 14:03 -0800, Jakub Kicinski wrote:
> Applied to net with the typo fixed, thanks!

Thanks!

Is there any chance it'll be in 5.10 or will it have to wait for the 5.11
merge window?

Also it should be applied to all supported/stable kernels. I guess that'll
have to wait until it's in Linus tree according [1] to but I'm unsure if I
need to trigger the action myself or if Greg (or Dave, according to [2]) will
do it.

I looked at [3] and it seems that adding the CC: stable in my commit message
maybe was an error because it's marked as a Failure, so if there's anything
needed from me here, don't hesitate to ask.

[1] https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
[2]
https://www.kernel.org/doc/html/latest/networking/netdev-FAQ.html#q-how-can-i-tell-what-patches-are-queued-up-for-backporting-to-the-various-stable-releases
[3] https://patchwork.kernel.org/bundle/netdev/stable/?state=*

Regards,
-- 
Yves-Alexis

Re: [PATCH] usbnet: ipheth: fix connectivity with iOS 14

[Jakub Kicinski]

On Tue, 24 Nov 2020 11:41:40 +0100 Yves-Alexis Perez wrote:
> On Sat, 2020-11-21 at 14:03 -0800, Jakub Kicinski wrote:
> > Applied to net with the typo fixed, thanks!  
> 
> Thanks!
> 
> Is there any chance it'll be in 5.10 or will it have to wait for the 5.11
> merge window?

It'll be in 5.10-rc6.

> Also it should be applied to all supported/stable kernels. I guess that'll
> have to wait until it's in Linus tree according [1] to but I'm unsure if I
> need to trigger the action myself or if Greg (or Dave, according to [2]) will
> do it.

Dave (or someone helping him, like myself) will do it, probably around
the time 5.10-rc6 is released.

> I looked at [3] and it seems that adding the CC: stable in my commit message
> maybe was an error because it's marked as a Failure, so if there's anything
> needed from me here, don't hesitate to ask.

No worries, I stripped the CC and put the patch in Dave's stable queue.

Re: [PATCH] usbnet: ipheth: fix connectivity with iOS 14

[Yves-Alexis Perez]

On Wed, 2021-09-22 at 20:11 +0000, Sam Bingner wrote:
> Sorry I didn't have time to research this further to prove it was a
> regression - but there is now somebody else who has done so and created a
> patch.  I thought it might be good to give a link to it to you guys.  It
> caused problems on all iOS versions AFAIK.  The patch and discussion is
> available at:
> 
> https://github.com/openwrt/openwrt/pull/4084

Hi Sam, sorry for the delay.

I've read the thread above and the patch. Unfortunately we don't have
documentation on how the driver is supposed to work and how the iPhone part
behave, everything was reverse engineered at the time and the people who did
it seem long gone.

As far as I understand it, when we experienced the “first” bug, it was noted
that reducing the (TX) buffer size by 2 helped, and thus the patch changing
IPHETH_BUF_SIZE to 1514 was committed, reducing both RX and TX buffer size.

During my testings I never experienced the subsequent bug (the
ipheth_rcvbulk_callback: urb status: -75) but maybe I never received 1500b
packets (it's a bit strange but maybe).

Maybe the right fix would be to split IPHETH_BUF_SIZE to
IPHETH_{RX,TX}_BUF_SIZE? Something like:

diff --git a/drivers/net/usb/ipheth.c b/drivers/net/usb/ipheth.c
index 57d94b18ef33..005d2e31d97c 100644
--- a/drivers/net/usb/ipheth.c
+++ b/drivers/net/usb/ipheth.c
@@ -60,7 +60,9 @@
 #define IPHETH_USBINTF_PROTO    1
 
 #define IPHETH_BUF_SIZE         1514
-#define IPHETH_IP_ALIGN		2	/* padding at front of URB */
+#define IPHETH_IP_ALIGN		2	/* padding at front of URB on
RX path */
+#define IPHETH_TX_BUF_SIZE      IPHETH_BUF_SIZE
+#define IPHETH_RX_BUF_SIZE      IPHETH_BUF_SIZE + IPHETH_IP_ALIGN
 #define IPHETH_TX_TIMEOUT       (5 * HZ)
 
 #define IPHETH_INTFNUM          2
@@ -116,12 +118,12 @@ static int ipheth_alloc_urbs(struct ipheth_device
*iphone)
 	if (rx_urb == NULL)
 		goto free_tx_urb;
 
-	tx_buf = usb_alloc_coherent(iphone->udev, IPHETH_BUF_SIZE,
+	tx_buf = usb_alloc_coherent(iphone->udev, IPHETH_TX_BUF_SIZE,
 				    GFP_KERNEL, &tx_urb->transfer_dma);
 	if (tx_buf == NULL)
 		goto free_rx_urb;
 
-	rx_buf = usb_alloc_coherent(iphone->udev, IPHETH_BUF_SIZE,
+	rx_buf = usb_alloc_coherent(iphone->udev, IPHETH_RX_BUF_SIZE,
 				    GFP_KERNEL, &rx_urb->transfer_dma);
 	if (rx_buf == NULL)
 		goto free_tx_buf;
@@ -134,7 +136,7 @@ static int ipheth_alloc_urbs(struct ipheth_device *iphone)
 	return 0;
 
 free_tx_buf:
-	usb_free_coherent(iphone->udev, IPHETH_BUF_SIZE, tx_buf,
+	usb_free_coherent(iphone->udev, IPHETH_TX_BUF_SIZE, tx_buf,
 			  tx_urb->transfer_dma);
 free_rx_urb:
 	usb_free_urb(rx_urb);
@@ -146,9 +148,9 @@ static int ipheth_alloc_urbs(struct ipheth_device *iphone)
 
 static void ipheth_free_urbs(struct ipheth_device *iphone)
 {
-	usb_free_coherent(iphone->udev, IPHETH_BUF_SIZE, iphone->rx_buf,
+	usb_free_coherent(iphone->udev, IPHETH_RX_BUF_SIZE, iphone->rx_buf,
 			  iphone->rx_urb->transfer_dma);
-	usb_free_coherent(iphone->udev, IPHETH_BUF_SIZE, iphone->tx_buf,
+	usb_free_coherent(iphone->udev, IPHETH_TX_BUF_SIZE, iphone->tx_buf,
 			  iphone->tx_urb->transfer_dma);
 	usb_free_urb(iphone->rx_urb);
 	usb_free_urb(iphone->tx_urb);
@@ -317,7 +319,7 @@ static int ipheth_rx_submit(struct ipheth_device *dev,
gfp_t mem_flags)
 
 	usb_fill_bulk_urb(dev->rx_urb, udev,
 			  usb_rcvbulkpipe(udev, dev->bulk_in),
-			  dev->rx_buf, IPHETH_BUF_SIZE,
+			  dev->rx_buf, IPHETH_RX_BUF_SIZE,
 			  ipheth_rcvbulk_callback,
 			  dev);
 	dev->rx_urb->transfer_flags |= URB_NO_TRANSFER_DMA_MAP;
@@ -381,7 +383,7 @@ static netdev_tx_t ipheth_tx(struct sk_buff *skb, struct
net_device *net)
 	int retval;
 
 	/* Paranoid */
-	if (skb->len > IPHETH_BUF_SIZE) {
+	if (skb->len > IPHETH_TX_BUF_SIZE) {
 		WARN(1, "%s: skb too large: %d bytes\n", __func__, skb->len);
 		dev->net->stats.tx_dropped++;
 		dev_kfree_skb_any(skb);
@@ -389,12 +391,12 @@ static netdev_tx_t ipheth_tx(struct sk_buff *skb, struct
net_device *net)
 	}
 
 	memcpy(dev->tx_buf, skb->data, skb->len);
-	if (skb->len < IPHETH_BUF_SIZE)
-		memset(dev->tx_buf + skb->len, 0, IPHETH_BUF_SIZE - skb-
>len);
+	if (skb->len < IPHETH_TX_BUF_SIZE)
+		memset(dev->tx_buf + skb->len, 0, IPHETH_TX_BUF_SIZE - skb-
>len);
 
 	usb_fill_bulk_urb(dev->tx_urb, udev,
 			  usb_sndbulkpipe(udev, dev->bulk_out),
-			  dev->tx_buf, IPHETH_BUF_SIZE,
+			  dev->tx_buf, IPHETH_TX_BUF_SIZE,
 			  ipheth_sndbulk_callback,
 			  dev);
 	dev->tx_urb->transfer_flags |= URB_NO_TRANSFER_DMA_MAP;

-- 
Yves-Alexis

RE: [PATCH] usbnet: ipheth: fix connectivity with iOS 14

[Sam Bingner]

Sorry I didn't have time to research this further to prove it was a regression - but there is now somebody else who has done so and created a patch.  I thought it might be good to give a link to it to you guys.  It caused problems on all iOS versions AFAIK.  The patch and discussion is available at:

https://github.com/openwrt/openwrt/pull/4084

Sam

-----Original Message-----
From: Oliver Neukum <oneukum@suse.com> 
Sent: Monday, February 22, 2021 2:10 AM
To: Sam Bingner <sam@bingner.com>; linux-usb@vger.kernel.org
Cc: David S. Miller <davem@davemloft.net>; Martin Habets <mhabets@solarflare.com>; Luc Van Oostenryck <luc.vanoostenryck@gmail.com>; Shannon Nelson <snelson@pensando.io>; Michael S. Tsirkin <mst@redhat.com>; netdev@vger.kernel.org; linux-kernel@vger.kernel.org; Matti Vuorela <matti.vuorela@bitfactor.fi>; Jakub Kicinski <kuba@kernel.org>; Yves-Alexis Perez <corsac@corsac.net>
Subject: Re: [PATCH] usbnet: ipheth: fix connectivity with iOS 14

Am Sonntag, den 21.02.2021, 10:42 +0000 schrieb Sam Bingner:
> There seems to be a problem with this patch:
> 
> Whenever the iPhone sends a packet to the tethered device that is 1500 bytes long, it gets the error "ipheth 1-1:4.2: ipheth_rcvbulk_callback: urb status: -79" on the connected device and stops passing traffic.  I am able to bring it back up by shutting and unshutting the interface, but the same thing happens very quickly.   I noticed that this patch dropped the max USB packet size from 1516 to 1514 bytes, so I decided to try lowering the MTU to 1498; this made the connection reliable and no more errors occurred.
> 
> It appears to me that the iPhone is still sending out 1516 bytes over USB for a 1500 byte packet and this patch makes USB abort when that happens?  I could duplicate reliably by sending a ping from the iphone (ping -s 1472) to the connected device, or vice versa as the reply would then break it.
> 
> I apologize if this reply doesn't end up where it should - I tried to reply to the last message in this thread but I wasn't actually *on* the thread so I had to just build it as much as possible myself.

Is this a regression? Does it work after reverting the patch? Which version of iOS?

	Regards
		Oliver

Re: [PATCH] usbnet: ipheth: fix connectivity with iOS 14

[Oliver Neukum]

Am Sonntag, den 21.02.2021, 10:42 +0000 schrieb Sam Bingner:
> There seems to be a problem with this patch:
> 
> Whenever the iPhone sends a packet to the tethered device that is 1500 bytes long, it gets the error "ipheth 1-1:4.2: ipheth_rcvbulk_callback: urb status: -79" on the connected device and stops passing traffic.  I am able to bring it back up by shutting and unshutting the interface, but the same thing happens very quickly.   I noticed that this patch dropped the max USB packet size from 1516 to 1514 bytes, so I decided to try lowering the MTU to 1498; this made the connection reliable and no more errors occurred.
> 
> It appears to me that the iPhone is still sending out 1516 bytes over USB for a 1500 byte packet and this patch makes USB abort when that happens?  I could duplicate reliably by sending a ping from the iphone (ping -s 1472) to the connected device, or vice versa as the reply would then break it.
> 
> I apologize if this reply doesn't end up where it should - I tried to reply to the last message in this thread but I wasn't actually *on* the thread so I had to just build it as much as possible myself.

Is this a regression? Does it work after reverting the patch? Which
version of iOS?

	Regards
		Oliver

Re: [PATCH] usbnet: ipheth: fix connectivity with iOS 14

[Sam Bingner]

There seems to be a problem with this patch:

Whenever the iPhone sends a packet to the tethered device that is 1500 bytes long, it gets the error "ipheth 1-1:4.2: ipheth_rcvbulk_callback: urb status: -79" on the connected device and stops passing traffic.  I am able to bring it back up by shutting and unshutting the interface, but the same thing happens very quickly.   I noticed that this patch dropped the max USB packet size from 1516 to 1514 bytes, so I decided to try lowering the MTU to 1498; this made the connection reliable and no more errors occurred.

It appears to me that the iPhone is still sending out 1516 bytes over USB for a 1500 byte packet and this patch makes USB abort when that happens?  I could duplicate reliably by sending a ping from the iphone (ping -s 1472) to the connected device, or vice versa as the reply would then break it.

I apologize if this reply doesn't end up where it should - I tried to reply to the last message in this thread but I wasn't actually *on* the thread so I had to just build it as much as possible myself.

Sam