Date:   Wed, 2 Feb 2022 12:35:31 +0200
From:   Georgi Valkov <gvalkov@....bg>
To:     Yves-Alexis Perez <corsac@...sac.net>
Cc:     Jan Kiszka <jan.kiszka@...mens.com>,
        Jakub Kicinski <kuba@...nel.org>,
        "David S . Miller" <davem@...emloft.net>,
        linux-usb <linux-usb@...r.kernel.org>,
        Linux Netdev List <netdev@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "stable @ vger . kernel . org" <stable@...r.kernel.org>
Subject: Re: [PATCH v2 0/1] ipheth URB overflow fix



> On 2022-02-02, at 10:09 AM, Yves-Alexis Perez <corsac@...sac.net> 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

Powered by blists - more mailing lists