Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <CAA42iKxeinZ4gKfttg_K8PdRt+p-p=KjqgcbGjtxzOqn_C0F9g@mail.gmail.com>
 <CAGRyCJGCrR_FVjCmsnbYhs76bDc0rD83n-=2ros2p9W_GeVq-w@mail.gmail.com>
In-Reply-To: <CAGRyCJGCrR_FVjCmsnbYhs76bDc0rD83n-=2ros2p9W_GeVq-w@mail.gmail.com>
From:   "Seija K." <doremylover123@gmail.com>
Date:   Tue, 13 Dec 2022 14:54:57 -0500
Message-ID: <CAA42iKzssPn2DAheYW3dczgj__pAJm1utR7NP1hushLPmrFSTA@mail.gmail.com>
Subject: Re: [PATCH] net: Fix for packets being rejected in the xHCI
 controller's ring buffer
To:     Daniele Palmas <dnlplm@gmail.com>
Cc:     =?UTF-8?Q?Bj=C3=B8rn_Mork?= <bjorn@mork.no>,
        "David S. Miller" <davem@davemloft.net>,
        Eric Dumazet <edumazet@google.com>,
        Jakub Kicinski <kuba@kernel.org>,
        Paolo Abeni <pabeni@redhat.com>, netdev@vger.kernel.org,
        linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Yes, I did.

On Tue, Dec 13, 2022 at 1:23 PM Daniele Palmas <dnlplm@gmail.com> wrote:
>
> Hello Seija,
>
> Il giorno mar 13 dic 2022 alle ore 18:44 Seija K.
> <doremylover123@gmail.com> ha scritto:
> >
> > When a packet larger than MTU arrives in Linux from the modem, it is
> > discarded with -EOVERFLOW error (Babble error).
> >
> > This is seen on USB3.0 and USB2.0 buses.
> >
> > This is because the MRU (Max Receive Size) is not a separate entity
> > from the MTU (Max Transmit Size), and the received packets can be
> > larger than those transmitted.
> >
> > Following the babble error, there was an endless supply of zero-length
> > URBs that were rejected with -EPROTO (increasing the rx input error
> > counter each time).
> >
> > This is only seen on USB3.0. These continue to come ad infinitum until
> > the modem is shut down.
> >
> > There appears to be a bug in the core USB handling code in Linux that
> > doesn't deal with network MTUs smaller than 1500 bytes well.
> >
> > By default, the dev->hard_mtu (the real MTU) is in lockstep with
> > dev->rx_urb_size (essentially an MRU), and the latter is causing
> > trouble.
> >
> > This has nothing to do with the modems; the issue can be reproduced by
> > getting a USB-Ethernet dongle, setting the MTU to 1430, and pinging
> > with size greater than 1406.
> >
> > Signed-off-by: Seija Kijin <doremylover123@gmail.com>
> >
> > Co-Authored-By: TarAldarion <gildeap@tcd.ie>
> > ---
> > drivers/net/usb/qmi_wwan.c | 7 +++++++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
> > index 554d4e2a84a4..39db53a74b5a 100644
> > --- a/drivers/net/usb/qmi_wwan.c
> > +++ b/drivers/net/usb/qmi_wwan.c
> > @@ -842,6 +842,13 @@ static int qmi_wwan_bind(struct usbnet *dev,
> > struct usb_interface *intf)
> > }
> > dev->net->netdev_ops = &qmi_wwan_netdev_ops;
> > dev->net->sysfs_groups[0] = &qmi_wwan_sysfs_attr_group;
> > + /* LTE Networks don't always respect their own MTU on the receiving side;
> > + * e.g. AT&T pushes 1430 MTU but still allows 1500 byte packets from
> > + * far-end networks. Make the receive buffer large enough to accommodate
> > + * them, and add four bytes so MTU does not equal MRU on network
> > + * with 1500 MTU. Otherwise, usbnet_change_mtu() will change both.
> > + */
> > + dev->rx_urb_size = ETH_DATA_LEN + 4;
>
> Did you test this change with QMAP?
>
> To support qmap dl aggregated blocks qmi_wwan relies on the
> usbnet_change_mtu behavior of changing the rx_urb_size.
>
> Thanks,
> Daniele
>
> > err:
> > return status;
> > }
> > --
> > 2.38.2