Re: commit 662dc80a5e86 breaks rmnet over usb

[Jakub Kicinski]

On Wed, 25 Feb 2026 08:19:46 +0100 Daniele Palmas wrote:
> > Could you try something like:
> >
> > diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
> > index 3a4985b582cb..6b4796fac692 100644
> > --- a/drivers/net/usb/qmi_wwan.c
> > +++ b/drivers/net/usb/qmi_wwan.c
> > @@ -788,6 +788,8 @@ static int qmi_wwan_bind(struct usbnet *dev, struct usb_interface *intf)
> >                  usbnet_get_ethernet_addr(dev, cdc_ether->iMACAddress);
> >          }
> >
> > +       dev->rx_urb_size = 32768;
> > +  
> 
> So far userspace tools (e.g. also the most important one which is
> ModemManager) rely on changing the rx_urb_size by changing the MTU: I
> know this is ugly, but it is a behavior that has been there since a
> lot of time, not sure how many tools based on this assumption could
> break.

What's the policy in ModemManager to change the rx_urb_size?
Increase it to make sure it can hold some specific cmd / packet?

I wonder if having rx_urb_size max of (mtu, 32k) would break anything.

Since we're talking about rx buffer config the right API to configure
it is likely ethtool -G rx-buf-len :(

> There's also the chance that there are modems which require a higher
> rx_urb_size, so having this fixed could not work well.
> 
> Unfortunately usbnet serves many drivers, I agree with Koen that a
> revert is the safest option.

Then again the usbnet driver is brittle enough as is, if it's just qmi
that needs this workaround we would be making common code less robust
for a benefit of a single "hack" (for lack of a better term)