[v2,0/1] ipheth URB overflow fix

Message

Jan Kiszka Feb. 1, 2022, 7:16 a.m. UTC

Resent (v1 was mangled).

Note that the "Fixes:" tag is a strong assumption of mine. Speak up if
you think that is wrong.

Jan

Georgi Valkov (1):
  ipheth: fix EOVERFLOW in ipheth_rcvbulk_callback

 drivers/net/usb/ipheth.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

Comments

[e-mail] Feb. 2, 2022, 4:30 a.m. UTC | #1

Hello:

This patch was applied to netdev/net.git (master)
by Jakub Kicinski <[e-mail]>:

On Tue, 1 Feb 2022 08:16:17 +0100 you wrote:
> Resent (v1 was mangled).
> 
> Note that the "Fixes:" tag is a strong assumption of mine. Speak up if
> you think that is wrong.
> 
> Jan
> 
> [...]

Here is the summary with links:
  - [v2,1/1] ipheth: fix EOVERFLOW in ipheth_rcvbulk_callback
    https://git.kernel.org/netdev/net/c/63e4b45c82ed

You are awesome, thank you!

Yves-Alexis Perez Feb. 2, 2022, 8:09 a.m. UTC | #2

On Tue, 2022-02-01 at 08:16 +0100, Jan Kiszka wrote:
> Georgi Valkov (1):
>   ipheth: fix EOVERFLOW in ipheth_rcvbulk_callback
> 
>  drivers/net/usb/ipheth.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

Hi,

sorry for the extra-long delay. I finally tested the patch, and it seems to
work fine. I've tried it on my laptop for few hours without issue, but to be
fair it was working just fine before, I never experienced the EOVERFLOW
myself.

Regards,

Georgi Valkov Feb. 2, 2022, 10:35 a.m. UTC | #3

> On 2022-02-02, at 10:09 AM, Yves-Alexis Perez <[e-mail]> wrote:
> 
> On Tue, 2022-02-01 at 08:16 +0100, Jan Kiszka wrote:
>> Georgi Valkov (1):
>>   ipheth: fix EOVERFLOW in ipheth_rcvbulk_callback
>> 
>>  drivers/net/usb/ipheth.c | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> Hi,
> 
> sorry for the extra-long delay. I finally tested the patch, and it seems to
> work fine. I've tried it on my laptop for few hours without issue, but to be
> fair it was working just fine before, I never experienced the EOVERFLOW
> myself.

Thank you for testing and committing the patch!

Hi Yves!
In order to experience the EOVERFLOW, the iPhone has to receive a large packet
of size 1514 bytes. Note that it is common for ISPs to limit the MTU, which results
in dropping large packets before they arrive at the iPhone. For example if I run

mtr 8.8.8.8 -n

 1. 172.20.10.1
 2. (waiting for reply)
 3. 10.98.8.1
 4. 10.98.8.253
 5. 46.10.207.99
 6. 212.39.69.106
 7. 212.39.66.222
 8. 216.239.59.239
 9. 74.125.251.185
10. 8.8.8.8

Host 5 drops large packets, while 3 and 4 replay. Now run
ping 10.98.8.1 -D -s 1472

Without the patch I get EOVERFLOW and there is no further communication.
It would be nice if a failsafe mechanism is implemented to recover from faults
like that or in the event that no communication is detected over a certain period.
With the patch applied, everything works fine:
1480 bytes from 10.98.8.1: icmp_seq=0 ttl=253 time=50.234 ms

There is another issue with my iPhone 7 Plus, which is unrelated to this patch:
If an iPhone is tethered to a MacBook, the next time it gets connected to an
OpenWRT router the USB Ethernet interface appears, but there is no
communication. Hence I would assume this issue has to be fixed in another
patch. I can confirm that in this state macOS and Windows are able to use
USB tethering, only OpenWRT is affected. So far I found the following
workarounds:
* reboot the phone or run:
* usbreset 002/002 && /etc/init.d/usbmuxd restart
* or in macOS disable the USB Ethernet interface, before the iPhone is
unplugged: e.g. Settings, Network, iPhone USB: check Disable unless needed,
then connect over wifi. The USB interface gets disabled.
* the same effect can also be achieved using QuickTime, File,
New Movie Recording. Selecting the iPhone, causes the USB Ethernet interface
to disappear. If we unplug and tether to OpenWRT now, it works fine. This looks
like an incomplete initialisation, likely in usbmuxd or ipheth, which needs to switch
the iPhone to the proper mode.

The same happens if the phone is powered off, and then restarted while tethered,
or if it reboots due to extreme cold temperatures or low battery. Finally there is
also a bug or possible hardware/baseband fault in my phone where every few
days the modem reboots: the LTE icon disappears for a few seconds, and
tethering is turned off. In the last case Personal Hotspot disappears in Settings,
but can still be accessed under Mobile Data. This is likely another iOS bug.

Either way, running the commands mentioned above re-enable tethering and
restore the communication instantly. There is no need to unlock the iPhone with
a passcode after it restarts. It would be nice if a watchdog is integrated
in ipheth to trigger recovery automatically.

Any ideas how to implement a watchdog to fix this separate issue?
--
Georgi Valkov

Yves-Alexis Perez Feb. 2, 2022, 5:01 p.m. UTC | #4

On Wed, 2022-02-02 at 12:35 +0200, Georgi Valkov wrote:
> Without the patch I get EOVERFLOW and there is no further communication.
> It would be nice if a failsafe mechanism is implemented to recover from
> faults
> like that or in the event that no communication is detected over a certain
> period.
> With the patch applied, everything works fine:
> 1480 bytes from 10.98.8.1: icmp_seq=0 ttl=253 time=50.234 ms

Thanks for the steps. I can confirm that without the patch I get:

[  +4.516398] ipheth 1-3.3:4.2: ipheth_rcvbulk_callback: urb status: -75

and the interface doesn't work anymore.

With the patch applied, I get ping results and the network keeps going.

Regards,