Ok, thanks. On Wed, Dec 14, 2022 at 10:25 AM Daniele Palmas <dnlplm@xxxxxxxxx> wrote: > > Hello Seija, > > Il giorno mar 13 dic 2022 alle ore 20:55 Seija K. > <doremylover123@xxxxxxxxx> ha scritto: > > On Tue, Dec 13, 2022 at 1:23 PM Daniele Palmas <dnlplm@xxxxxxxxx> wrote: > > > > > > 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 > > > > Yes, I did. > > > > I've applied your change and verified that the rx_urb_size can't be > changed anymore by modifying the mtu of the wwan netdevice and stays > fixed to 1504. > > Just a heads-up, that this change is not working fine with qmap setup > procedure, since the URB size can't be changed anymore to the value of > the maximum dl aggregated block set through wda_set_data_format. > > I know that linking MTU with the rx_urb_size is odd, but this is how > it's done currently. > > Regards, > Daniele > > > On Tue, Dec 13, 2022 at 1:23 PM Daniele Palmas <dnlplm@xxxxxxxxx> wrote: > > > > > > Hello Seija, > > > > > > Il giorno mar 13 dic 2022 alle ore 18:44 Seija K. > > > <doremylover123@xxxxxxxxx> 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@xxxxxxxxx> > > > > > > > > Co-Authored-By: TarAldarion <gildeap@xxxxxx> > > > > --- > > > > 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
