commit 662dc80a5e86 breaks rmnet over usb

commit 662dc80a5e86 breaks rmnet over usb

[Koen Vandeputte]

Hi Laurent,

I'm testing the latest openwrt state and found an issue probably
caused by your usb mtu limit patch :-)

I'm talking about this one:
662dc80a5e86 ("usbnet: limit max_mtu based on device's hard_mtu")

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v6.12.74&id=662dc80a5e86b35bbf339e0b87b7cc3f07c09de1


When using wwan0 iface normally, this makes sense, but the problem is
when using QMI modems combined with the rmnet driver and aggregated
frames.

- The modem is configured to frame sizes of 16383 or 32767 using QMI
- wwan0 (using qmi_wwan) is configured to match this frame size by
setting it's MTU to the same value
- Frames of this size are sent over to qmi_wwan driver (containing
multiple data packets)
- Frames are then forwarded to the rmnet driver
- Frames get de-aggregated here and sent to the network stack for processing.

The reason here is to reduce USB transfers heavily.


As you see, it's perfectly possible here to use very large MTU sizes
as the aggregation feature by rmnet relies on this.
Also the modem can be perfectly configured to send very large aggregated frames.

After your patch, wwan0 is limited to 1500 bytes it seems, effectively
breaking aggregation.

On my tests, download speeds are reduced from >300Mbps to ~.8Mbps

I also made a build reverting this patch and all works well again.


Is there any other solution to fix this?
I guess it should be reverted otherwise :-)

Thanks a lot!

Koen

Re: commit 662dc80a5e86 breaks rmnet over usb

[Laurent Vivier]

On 2/23/26 13:04, Koen Vandeputte wrote:
> Hi Laurent,

Hi Koen,

> I'm testing the latest openwrt state and found an issue probably
> caused by your usb mtu limit patch :-)
> 
> I'm talking about this one:
> 662dc80a5e86 ("usbnet: limit max_mtu based on device's hard_mtu")
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v6.12.74&id=662dc80a5e86b35bbf339e0b87b7cc3f07c09de1
> 
> 
> When using wwan0 iface normally, this makes sense, but the problem is
> when using QMI modems combined with the rmnet driver and aggregated
> frames.
> 
> - The modem is configured to frame sizes of 16383 or 32767 using QMI
> - wwan0 (using qmi_wwan) is configured to match this frame size by
> setting it's MTU to the same value
> - Frames of this size are sent over to qmi_wwan driver (containing
> multiple data packets)
> - Frames are then forwarded to the rmnet driver
> - Frames get de-aggregated here and sent to the network stack for processing.
> 
> The reason here is to reduce USB transfers heavily.
> 
> 
> As you see, it's perfectly possible here to use very large MTU sizes
> as the aggregation feature by rmnet relies on this.
> Also the modem can be perfectly configured to send very large aggregated frames.
> 
> After your patch, wwan0 is limited to 1500 bytes it seems, effectively
> breaking aggregation.
> 
> On my tests, download speeds are reduced from >300Mbps to ~.8Mbps
> 
> I also made a build reverting this patch and all works well again.
> 
> 
> Is there any other solution to fix this?
> I guess it should be reverted otherwise :-)

It's weird to be able to set an MTU that is not supported by the hardware.

To restore performance I think the rx_usb_size should be decoupled from MTU max in qmi_wwan.

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;
+
         /* claim data interface and set it up */
         if (info->control != info->data) {
                 status = usb_driver_claim_interface(driver, info->data, dev);

Thanks,
Laurent

Re: commit 662dc80a5e86 breaks rmnet over usb

[David Laight]

On Mon, 23 Feb 2026 15:08:41 +0100
Laurent Vivier <lvivier@redhat.com> wrote:

...
> It's weird to be able to set an MTU that is not supported by the hardware.
> 
> To restore performance I think the rx_usb_size should be decoupled from MTU max in qmi_wwan.

A lot of 'usbnet' drivers support usb packets that contain multiple ethernet frames.
IIRC (I looked at this code quite a few years ago) some (all?) lie very badly
about the skb 'true_size' of receive packets - putting in the frame size
even though it is sat in 16kb+ of kernel memory.

In reality the driver want to receive the 'stream' of usb packets and
debatch it directly into ethernet frames without going though the 'urb'
buffers at all.
ISTR that would be possible with the xhci/usb3 hardware, but would be a
massive re-write of parts of the stack.
I was only trying (and I mean failing) to get 100M working reliably.
Project got canned for other reasons.

	David

Re: commit 662dc80a5e86 breaks rmnet over usb

[Daniele Palmas]

Hello,

Il giorno lun 23 feb 2026 alle ore 15:08 Laurent Vivier
<lvivier@redhat.com> ha scritto:
>
> On 2/23/26 13:04, Koen Vandeputte wrote:
> > Hi Laurent,
>
> Hi Koen,
>
> > I'm testing the latest openwrt state and found an issue probably
> > caused by your usb mtu limit patch :-)
> >
> > I'm talking about this one:
> > 662dc80a5e86 ("usbnet: limit max_mtu based on device's hard_mtu")
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v6.12.74&id=662dc80a5e86b35bbf339e0b87b7cc3f07c09de1
> >
> >
> > When using wwan0 iface normally, this makes sense, but the problem is
> > when using QMI modems combined with the rmnet driver and aggregated
> > frames.
> >
> > - The modem is configured to frame sizes of 16383 or 32767 using QMI
> > - wwan0 (using qmi_wwan) is configured to match this frame size by
> > setting it's MTU to the same value
> > - Frames of this size are sent over to qmi_wwan driver (containing
> > multiple data packets)
> > - Frames are then forwarded to the rmnet driver
> > - Frames get de-aggregated here and sent to the network stack for processing.
> >
> > The reason here is to reduce USB transfers heavily.
> >
> >
> > As you see, it's perfectly possible here to use very large MTU sizes
> > as the aggregation feature by rmnet relies on this.
> > Also the modem can be perfectly configured to send very large aggregated frames.
> >
> > After your patch, wwan0 is limited to 1500 bytes it seems, effectively
> > breaking aggregation.
> >
> > On my tests, download speeds are reduced from >300Mbps to ~.8Mbps
> >
> > I also made a build reverting this patch and all works well again.
> >
> >
> > Is there any other solution to fix this?
> > I guess it should be reverted otherwise :-)
>
> It's weird to be able to set an MTU that is not supported by the hardware.
>
> To restore performance I think the rx_usb_size should be decoupled from MTU max in qmi_wwan.
>
> 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.

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.

Regards,
Daniele

>          /* claim data interface and set it up */
>          if (info->control != info->data) {
>                  status = usb_driver_claim_interface(driver, info->data, dev);
>
> Thanks,
> Laurent
>
>

Re: commit 662dc80a5e86 breaks rmnet over usb

[Laurent Vivier]

On 2/25/26 08:19, Daniele Palmas wrote:
> Hello,

Hello Daniele,

> 
> Il giorno lun 23 feb 2026 alle ore 15:08 Laurent Vivier
> <lvivier@redhat.com> ha scritto:
>>
>> On 2/23/26 13:04, Koen Vandeputte wrote:
>>> Hi Laurent,
>>
>> Hi Koen,
>>
>>> I'm testing the latest openwrt state and found an issue probably
>>> caused by your usb mtu limit patch :-)
>>>
>>> I'm talking about this one:
>>> 662dc80a5e86 ("usbnet: limit max_mtu based on device's hard_mtu")
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v6.12.74&id=662dc80a5e86b35bbf339e0b87b7cc3f07c09de1
>>>
>>>
>>> When using wwan0 iface normally, this makes sense, but the problem is
>>> when using QMI modems combined with the rmnet driver and aggregated
>>> frames.
>>>
>>> - The modem is configured to frame sizes of 16383 or 32767 using QMI
>>> - wwan0 (using qmi_wwan) is configured to match this frame size by
>>> setting it's MTU to the same value
>>> - Frames of this size are sent over to qmi_wwan driver (containing
>>> multiple data packets)
>>> - Frames are then forwarded to the rmnet driver
>>> - Frames get de-aggregated here and sent to the network stack for processing.
>>>
>>> The reason here is to reduce USB transfers heavily.
>>>
>>>
>>> As you see, it's perfectly possible here to use very large MTU sizes
>>> as the aggregation feature by rmnet relies on this.
>>> Also the modem can be perfectly configured to send very large aggregated frames.
>>>
>>> After your patch, wwan0 is limited to 1500 bytes it seems, effectively
>>> breaking aggregation.
>>>
>>> On my tests, download speeds are reduced from >300Mbps to ~.8Mbps
>>>
>>> I also made a build reverting this patch and all works well again.
>>>
>>>
>>> Is there any other solution to fix this?
>>> I guess it should be reverted otherwise :-)
>>
>> It's weird to be able to set an MTU that is not supported by the hardware.
>>
>> To restore performance I think the rx_usb_size should be decoupled from MTU max in qmi_wwan.
>>
>> 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.
> 
> 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.

And there is no intermediate driver (qmi_wwan or rmnet) that can define a max_mtu higher 
than that defined by usbnet?

Thanks,
Laurent

Re: commit 662dc80a5e86 breaks rmnet over usb

[Laurent Vivier]

On 2/25/26 08:48, Laurent Vivier wrote:
> On 2/25/26 08:19, Daniele Palmas wrote:
>> Hello,
> 
> Hello Daniele,
> 
>>
>> Il giorno lun 23 feb 2026 alle ore 15:08 Laurent Vivier
>> <lvivier@redhat.com> ha scritto:
>>>
>>> On 2/23/26 13:04, Koen Vandeputte wrote:
>>>> Hi Laurent,
>>>
>>> Hi Koen,
>>>
>>>> I'm testing the latest openwrt state and found an issue probably
>>>> caused by your usb mtu limit patch :-)
>>>>
>>>> I'm talking about this one:
>>>> 662dc80a5e86 ("usbnet: limit max_mtu based on device's hard_mtu")
>>>>
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/? 
>>>> h=v6.12.74&id=662dc80a5e86b35bbf339e0b87b7cc3f07c09de1
>>>>
>>>>
>>>> When using wwan0 iface normally, this makes sense, but the problem is
>>>> when using QMI modems combined with the rmnet driver and aggregated
>>>> frames.
>>>>
>>>> - The modem is configured to frame sizes of 16383 or 32767 using QMI
>>>> - wwan0 (using qmi_wwan) is configured to match this frame size by
>>>> setting it's MTU to the same value
>>>> - Frames of this size are sent over to qmi_wwan driver (containing
>>>> multiple data packets)
>>>> - Frames are then forwarded to the rmnet driver
>>>> - Frames get de-aggregated here and sent to the network stack for processing.
>>>>
>>>> The reason here is to reduce USB transfers heavily.
>>>>
>>>>
>>>> As you see, it's perfectly possible here to use very large MTU sizes
>>>> as the aggregation feature by rmnet relies on this.
>>>> Also the modem can be perfectly configured to send very large aggregated frames.
>>>>
>>>> After your patch, wwan0 is limited to 1500 bytes it seems, effectively
>>>> breaking aggregation.
>>>>
>>>> On my tests, download speeds are reduced from >300Mbps to ~.8Mbps
>>>>
>>>> I also made a build reverting this patch and all works well again.
>>>>
>>>>
>>>> Is there any other solution to fix this?
>>>> I guess it should be reverted otherwise :-)
>>>
>>> It's weird to be able to set an MTU that is not supported by the hardware.
>>>
>>> To restore performance I think the rx_usb_size should be decoupled from MTU max in 
>>> qmi_wwan.
>>>
>>> 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.
>>
>> 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.
> 
> And there is no intermediate driver (qmi_wwan or rmnet) that can define a max_mtu higher 
> than that defined by usbnet?

Perhaps we can remove the change from usbnet and move it to the device bind function?

diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
index a032c1ded406..836915e4abad 100644
--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -235,6 +235,8 @@ int usbnet_generic_cdc_bind(struct usbnet *dev, struct usb_interface 
*intf)

  	if (header.usb_cdc_ether_desc && info->ether->wMaxSegmentSize) {
  		dev->hard_mtu = le16_to_cpu(info->ether->wMaxSegmentSize);
+		if (dev->net->max_mtu > (dev->hard_mtu - dev->net->hard_header_len))
+			dev->net->max_mtu = dev->hard_mtu - dev->net->hard_header_len;
  		/* because of Zaurus, we may be ignoring the host
  		 * side link address we were given.
  		 */
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index ed86ba87ca4e..295c3614878b 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -1829,11 +1829,9 @@ usbnet_probe(struct usb_interface *udev, const struct usb_device_id 
*prod)
  		if ((dev->driver_info->flags & FLAG_NOARP) != 0)
  			net->flags |= IFF_NOARP;

-		if (net->max_mtu > (dev->hard_mtu - net->hard_header_len))
-			net->max_mtu = dev->hard_mtu - net->hard_header_len;
-
-		if (net->mtu > net->max_mtu)
-			net->mtu = net->max_mtu;
+		/* maybe the remote can't receive an Ethernet MTU */
+		if (net->mtu > (dev->hard_mtu - net->hard_header_len))
+			net->mtu = dev->hard_mtu - net->hard_header_len;

  	} else if (!info->in || !info->out)
  		status = usbnet_get_endpoints(dev, udev);

An other solution would be to add a FLAG_NOMAXMTU in qmi_wwan driver_info->flags to 
disable the setting of max_mtu in usbnet_probe() to keep the change generic and qmi_wwan 
the exception.

Thanks,
Laurent

Re: commit 662dc80a5e86 breaks rmnet over usb

[Daniele Palmas]

Hello Laurent,

Il giorno mer 25 feb 2026 alle ore 12:04 Laurent Vivier
<lvivier@redhat.com> ha scritto:
>
> On 2/25/26 08:48, Laurent Vivier wrote:
> > On 2/25/26 08:19, Daniele Palmas wrote:
> >> Hello,
> >
> > Hello Daniele,
> >
> >>
> >> Il giorno lun 23 feb 2026 alle ore 15:08 Laurent Vivier
> >> <lvivier@redhat.com> ha scritto:
> >>>
> >>> On 2/23/26 13:04, Koen Vandeputte wrote:
> >>>> Hi Laurent,
> >>>
> >>> Hi Koen,
> >>>
> >>>> I'm testing the latest openwrt state and found an issue probably
> >>>> caused by your usb mtu limit patch :-)
> >>>>
> >>>> I'm talking about this one:
> >>>> 662dc80a5e86 ("usbnet: limit max_mtu based on device's hard_mtu")
> >>>>
> >>>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?
> >>>> h=v6.12.74&id=662dc80a5e86b35bbf339e0b87b7cc3f07c09de1
> >>>>
> >>>>
> >>>> When using wwan0 iface normally, this makes sense, but the problem is
> >>>> when using QMI modems combined with the rmnet driver and aggregated
> >>>> frames.
> >>>>
> >>>> - The modem is configured to frame sizes of 16383 or 32767 using QMI
> >>>> - wwan0 (using qmi_wwan) is configured to match this frame size by
> >>>> setting it's MTU to the same value
> >>>> - Frames of this size are sent over to qmi_wwan driver (containing
> >>>> multiple data packets)
> >>>> - Frames are then forwarded to the rmnet driver
> >>>> - Frames get de-aggregated here and sent to the network stack for processing.
> >>>>
> >>>> The reason here is to reduce USB transfers heavily.
> >>>>
> >>>>
> >>>> As you see, it's perfectly possible here to use very large MTU sizes
> >>>> as the aggregation feature by rmnet relies on this.
> >>>> Also the modem can be perfectly configured to send very large aggregated frames.
> >>>>
> >>>> After your patch, wwan0 is limited to 1500 bytes it seems, effectively
> >>>> breaking aggregation.
> >>>>
> >>>> On my tests, download speeds are reduced from >300Mbps to ~.8Mbps
> >>>>
> >>>> I also made a build reverting this patch and all works well again.
> >>>>
> >>>>
> >>>> Is there any other solution to fix this?
> >>>> I guess it should be reverted otherwise :-)
> >>>
> >>> It's weird to be able to set an MTU that is not supported by the hardware.
> >>>
> >>> To restore performance I think the rx_usb_size should be decoupled from MTU max in
> >>> qmi_wwan.
> >>>
> >>> 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.
> >>
> >> 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.
> >
> > And there is no intermediate driver (qmi_wwan or rmnet) that can define a max_mtu higher
> > than that defined by usbnet?
>
> Perhaps we can remove the change from usbnet and move it to the device bind function?
>
> diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
> index a032c1ded406..836915e4abad 100644
> --- a/drivers/net/usb/cdc_ether.c
> +++ b/drivers/net/usb/cdc_ether.c
> @@ -235,6 +235,8 @@ int usbnet_generic_cdc_bind(struct usbnet *dev, struct usb_interface
> *intf)
>
>         if (header.usb_cdc_ether_desc && info->ether->wMaxSegmentSize) {
>                 dev->hard_mtu = le16_to_cpu(info->ether->wMaxSegmentSize);
> +               if (dev->net->max_mtu > (dev->hard_mtu - dev->net->hard_header_len))
> +                       dev->net->max_mtu = dev->hard_mtu - dev->net->hard_header_len;
>                 /* because of Zaurus, we may be ignoring the host
>                  * side link address we were given.
>                  */
> diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
> index ed86ba87ca4e..295c3614878b 100644
> --- a/drivers/net/usb/usbnet.c
> +++ b/drivers/net/usb/usbnet.c
> @@ -1829,11 +1829,9 @@ usbnet_probe(struct usb_interface *udev, const struct usb_device_id
> *prod)
>                 if ((dev->driver_info->flags & FLAG_NOARP) != 0)
>                         net->flags |= IFF_NOARP;
>
> -               if (net->max_mtu > (dev->hard_mtu - net->hard_header_len))
> -                       net->max_mtu = dev->hard_mtu - net->hard_header_len;
> -
> -               if (net->mtu > net->max_mtu)
> -                       net->mtu = net->max_mtu;
> +               /* maybe the remote can't receive an Ethernet MTU */
> +               if (net->mtu > (dev->hard_mtu - net->hard_header_len))
> +                       net->mtu = dev->hard_mtu - net->hard_header_len;
>
>         } else if (!info->in || !info->out)
>                 status = usbnet_get_endpoints(dev, udev);
>
> An other solution would be to add a FLAG_NOMAXMTU in qmi_wwan driver_info->flags to
> disable the setting of max_mtu in usbnet_probe() to keep the change generic and qmi_wwan
> the exception.
>

Both solutions look good to me.

If you think that your change provides benefit to other usbnet users,
then keeping qmi_wwan the exception is probably better.

Thanks,
Daniele

> Thanks,
> Laurent
>

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)

Re: commit 662dc80a5e86 breaks rmnet over usb

[Daniele Palmas]

Hello Jakub,

Il giorno gio 26 feb 2026 alle ore 02:01 Jakub Kicinski
<kuba@kernel.org> ha scritto:
>
> 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.
>

Typically the host sends a QMI request to the modem for setting the
size of the maximum QMAP aggregated packets block. Then the modem
replies with the maximum size it supports and that one is then set by
the host through changing the MTU of the netdevice. Low-cat modems
usually support 4-8 KB, while 5G 16-32KB.

On ModemManager side this is currently fixed at 16KB, but one can use
other tools e.g. qmicli to set custom values as far as they are
supported by the modem.

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

Thanks for the hint, I'll try to have a look at that to improve qmi_wwan.

> > 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)

Makes sense, also Laurent proposed a solution to keep his fix in
usbnet and make qmi_wwan the exception.

Regards,
Daniele

Re: commit 662dc80a5e86 breaks rmnet over usb

[Laurent Vivier]

On 2/26/26 09:26, Daniele Palmas wrote:
> Hello Jakub,
> 
> Il giorno gio 26 feb 2026 alle ore 02:01 Jakub Kicinski
> <kuba@kernel.org> ha scritto:
>>
>> 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.
>>
> 
> Typically the host sends a QMI request to the modem for setting the
> size of the maximum QMAP aggregated packets block. Then the modem
> replies with the maximum size it supports and that one is then set by
> the host through changing the MTU of the netdevice. Low-cat modems
> usually support 4-8 KB, while 5G 16-32KB.
> 
> On ModemManager side this is currently fixed at 16KB, but one can use
> other tools e.g. qmicli to set custom values as far as they are
> supported by the modem.
> 
>> Since we're talking about rx buffer config the right API to configure
>> it is likely ethtool -G rx-buf-len :(
>>
> 
> Thanks for the hint, I'll try to have a look at that to improve qmi_wwan.
> 
>>> 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)
> 
> Makes sense, also Laurent proposed a solution to keep his fix in
> usbnet and make qmi_wwan the exception.

I was thinking to something like that (see below), but I'm not really able to test it. If 
everyone thinks it's the path to follow, I can send a patch.

Thanks,
Laurent

diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 3a4985b582cb..05acac10cd2b 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -928,7 +928,7 @@ static int qmi_wwan_resume(struct usb_interface *intf)

  static const struct driver_info	qmi_wwan_info = {
  	.description	= "WWAN/QMI device",
-	.flags		= FLAG_WWAN | FLAG_SEND_ZLP,
+	.flags		= FLAG_WWAN | FLAG_NOMAXMTU | FLAG_SEND_ZLP,
  	.bind		= qmi_wwan_bind,
  	.unbind		= qmi_wwan_unbind,
  	.manage_power	= qmi_wwan_manage_power,
@@ -937,7 +937,7 @@ static const struct driver_info	qmi_wwan_info = {

  static const struct driver_info	qmi_wwan_info_quirk_dtr = {
  	.description	= "WWAN/QMI device",
-	.flags		= FLAG_WWAN | FLAG_SEND_ZLP,
+	.flags		= FLAG_WWAN | FLAG_NOMAXMTU | FLAG_SEND_ZLP,
  	.bind		= qmi_wwan_bind,
  	.unbind		= qmi_wwan_unbind,
  	.manage_power	= qmi_wwan_manage_power,
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index ed86ba87ca4e..b72ba0803392 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -1829,11 +1829,12 @@ usbnet_probe(struct usb_interface *udev, const struct 
usb_device_id *prod)
  		if ((dev->driver_info->flags & FLAG_NOARP) != 0)
  			net->flags |= IFF_NOARP;

-		if (net->max_mtu > (dev->hard_mtu - net->hard_header_len))
+		if ((dev->driver_info->flags & FLAG_NOMAXMTU) == 0 &&
+		    net->max_mtu > (dev->hard_mtu - net->hard_header_len))
  			net->max_mtu = dev->hard_mtu - net->hard_header_len;

-		if (net->mtu > net->max_mtu)
-			net->mtu = net->max_mtu;
+		if (net->mtu > (dev->hard_mtu - net->hard_header_len))
+			net->mtu = dev->hard_mtu - net->hard_header_len;

  	} else if (!info->in || !info->out)
  		status = usbnet_get_endpoints(dev, udev);
diff --git a/include/linux/usb/usbnet.h b/include/linux/usb/usbnet.h
index b0e84896e6ac..bbf799ccf3b3 100644
--- a/include/linux/usb/usbnet.h
+++ b/include/linux/usb/usbnet.h
@@ -132,6 +132,7 @@ struct driver_info {
  #define FLAG_MULTI_PACKET	0x2000
  #define FLAG_RX_ASSEMBLE	0x4000	/* rx packets may span >1 frames */
  #define FLAG_NOARP		0x8000	/* device can't do ARP */
+#define FLAG_NOMAXMTU		0x10000	/* allow max_mtu above hard_mtu */

  	/* init device ... can sleep, or cause probe() failure */
  	int	(*bind)(struct usbnet *, struct usb_interface *);

Re: commit 662dc80a5e86 breaks rmnet over usb

[Daniele Palmas]

Il giorno gio 26 feb 2026 alle ore 10:09 Laurent Vivier
<lvivier@redhat.com> ha scritto:
>
> On 2/26/26 09:26, Daniele Palmas wrote:
> > Hello Jakub,
> >
> > Il giorno gio 26 feb 2026 alle ore 02:01 Jakub Kicinski
> > <kuba@kernel.org> ha scritto:
> >>
> >> 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.
> >>
> >
> > Typically the host sends a QMI request to the modem for setting the
> > size of the maximum QMAP aggregated packets block. Then the modem
> > replies with the maximum size it supports and that one is then set by
> > the host through changing the MTU of the netdevice. Low-cat modems
> > usually support 4-8 KB, while 5G 16-32KB.
> >
> > On ModemManager side this is currently fixed at 16KB, but one can use
> > other tools e.g. qmicli to set custom values as far as they are
> > supported by the modem.
> >
> >> Since we're talking about rx buffer config the right API to configure
> >> it is likely ethtool -G rx-buf-len :(
> >>
> >
> > Thanks for the hint, I'll try to have a look at that to improve qmi_wwan.
> >
> >>> 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)
> >
> > Makes sense, also Laurent proposed a solution to keep his fix in
> > usbnet and make qmi_wwan the exception.
>
> I was thinking to something like that (see below), but I'm not really able to test it. If
> everyone thinks it's the path to follow, I can send a patch.

I think I can test this by the end of the week and let you know.

Thanks,
Daniele

>
> Thanks,
> Laurent
>
> diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
> index 3a4985b582cb..05acac10cd2b 100644
> --- a/drivers/net/usb/qmi_wwan.c
> +++ b/drivers/net/usb/qmi_wwan.c
> @@ -928,7 +928,7 @@ static int qmi_wwan_resume(struct usb_interface *intf)
>
>   static const struct driver_info       qmi_wwan_info = {
>         .description    = "WWAN/QMI device",
> -       .flags          = FLAG_WWAN | FLAG_SEND_ZLP,
> +       .flags          = FLAG_WWAN | FLAG_NOMAXMTU | FLAG_SEND_ZLP,
>         .bind           = qmi_wwan_bind,
>         .unbind         = qmi_wwan_unbind,
>         .manage_power   = qmi_wwan_manage_power,
> @@ -937,7 +937,7 @@ static const struct driver_info     qmi_wwan_info = {
>
>   static const struct driver_info       qmi_wwan_info_quirk_dtr = {
>         .description    = "WWAN/QMI device",
> -       .flags          = FLAG_WWAN | FLAG_SEND_ZLP,
> +       .flags          = FLAG_WWAN | FLAG_NOMAXMTU | FLAG_SEND_ZLP,
>         .bind           = qmi_wwan_bind,
>         .unbind         = qmi_wwan_unbind,
>         .manage_power   = qmi_wwan_manage_power,
> diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
> index ed86ba87ca4e..b72ba0803392 100644
> --- a/drivers/net/usb/usbnet.c
> +++ b/drivers/net/usb/usbnet.c
> @@ -1829,11 +1829,12 @@ usbnet_probe(struct usb_interface *udev, const struct
> usb_device_id *prod)
>                 if ((dev->driver_info->flags & FLAG_NOARP) != 0)
>                         net->flags |= IFF_NOARP;
>
> -               if (net->max_mtu > (dev->hard_mtu - net->hard_header_len))
> +               if ((dev->driver_info->flags & FLAG_NOMAXMTU) == 0 &&
> +                   net->max_mtu > (dev->hard_mtu - net->hard_header_len))
>                         net->max_mtu = dev->hard_mtu - net->hard_header_len;
>
> -               if (net->mtu > net->max_mtu)
> -                       net->mtu = net->max_mtu;
> +               if (net->mtu > (dev->hard_mtu - net->hard_header_len))
> +                       net->mtu = dev->hard_mtu - net->hard_header_len;
>
>         } else if (!info->in || !info->out)
>                 status = usbnet_get_endpoints(dev, udev);
> diff --git a/include/linux/usb/usbnet.h b/include/linux/usb/usbnet.h
> index b0e84896e6ac..bbf799ccf3b3 100644
> --- a/include/linux/usb/usbnet.h
> +++ b/include/linux/usb/usbnet.h
> @@ -132,6 +132,7 @@ struct driver_info {
>   #define FLAG_MULTI_PACKET     0x2000
>   #define FLAG_RX_ASSEMBLE      0x4000  /* rx packets may span >1 frames */
>   #define FLAG_NOARP            0x8000  /* device can't do ARP */
> +#define FLAG_NOMAXMTU          0x10000 /* allow max_mtu above hard_mtu */
>
>         /* init device ... can sleep, or cause probe() failure */
>         int     (*bind)(struct usbnet *, struct usb_interface *);
>
>

Re: commit 662dc80a5e86 breaks rmnet over usb

[Daniele Palmas]

Hello,

Il giorno gio 26 feb 2026 alle ore 19:18 Daniele Palmas
<dnlplm@gmail.com> ha scritto:
>
> Il giorno gio 26 feb 2026 alle ore 10:09 Laurent Vivier
> <lvivier@redhat.com> ha scritto:
> >
> > On 2/26/26 09:26, Daniele Palmas wrote:
> > > Hello Jakub,
> > >
> > > Il giorno gio 26 feb 2026 alle ore 02:01 Jakub Kicinski
> > > <kuba@kernel.org> ha scritto:
> > >>
> > >> 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.
> > >>
> > >
> > > Typically the host sends a QMI request to the modem for setting the
> > > size of the maximum QMAP aggregated packets block. Then the modem
> > > replies with the maximum size it supports and that one is then set by
> > > the host through changing the MTU of the netdevice. Low-cat modems
> > > usually support 4-8 KB, while 5G 16-32KB.
> > >
> > > On ModemManager side this is currently fixed at 16KB, but one can use
> > > other tools e.g. qmicli to set custom values as far as they are
> > > supported by the modem.
> > >
> > >> Since we're talking about rx buffer config the right API to configure
> > >> it is likely ethtool -G rx-buf-len :(
> > >>
> > >
> > > Thanks for the hint, I'll try to have a look at that to improve qmi_wwan.
> > >
> > >>> 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)
> > >
> > > Makes sense, also Laurent proposed a solution to keep his fix in
> > > usbnet and make qmi_wwan the exception.
> >
> > I was thinking to something like that (see below), but I'm not really able to test it. If
> > everyone thinks it's the path to follow, I can send a patch.
>
> I think I can test this by the end of the week and let you know.
>

I've verified that without this patch I'm not able to set mtu > 1500
and ip -d link shows:

3: wwan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
DEFAULT group default qlen 1000
    link/ether 16:7f:28:3c:c4:3e brd ff:ff:ff:ff:ff:ff promiscuity 0
allmulti 0 minmtu 0 maxmtu 1500 addrgenmode eui64 numtxqueues 1
numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 tso_max_size 65536
tso_max_segs 65535 gro_max_size 65536 parentbus usb parentdev 3-8:1.0

while with the patch I'm able to set mtu > 1500 and ip -d link shows:

3: wwan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
DEFAULT group default qlen 1000
    link/ether 2e:56:3a:37:75:e2 brd ff:ff:ff:ff:ff:ff promiscuity 0
allmulti 0 minmtu 0 maxmtu 65535 addrgenmode eui64 numtxqueues 1
numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 tso_max_size 65536
tso_max_segs 65535 gro_max_size 65536 parentbus usb parentdev 3-8:1.0

Interesting enough, in the failing kernel ModemManager is still able
to change the MTU of wwan and properly create the QMAP data call with
the correct rx_urb size, resulting in a netdevice like:

3: wwan0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 16384 qdisc
fq_codel state UNKNOWN mode DEFAULT group default qlen 1000
    link/none  promiscuity 0  allmulti 0 minmtu 0 maxmtu 65535
addrgenmode random numtxqueues 1 numrxqueues 1 gso_max_size 65536
gso_max_segs 65535 tso_max_size 65536 tso_max_segs 65535 gro_max_size
65536 parentbus usb parentdev 3-8:1.0

Still need to check the reason for this, but it seems to me that your
fix is working properly.

Thanks,
Daniele

> Thanks,
> Daniele
>
> >
> > Thanks,
> > Laurent
> >
> > diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
> > index 3a4985b582cb..05acac10cd2b 100644
> > --- a/drivers/net/usb/qmi_wwan.c
> > +++ b/drivers/net/usb/qmi_wwan.c
> > @@ -928,7 +928,7 @@ static int qmi_wwan_resume(struct usb_interface *intf)
> >
> >   static const struct driver_info       qmi_wwan_info = {
> >         .description    = "WWAN/QMI device",
> > -       .flags          = FLAG_WWAN | FLAG_SEND_ZLP,
> > +       .flags          = FLAG_WWAN | FLAG_NOMAXMTU | FLAG_SEND_ZLP,
> >         .bind           = qmi_wwan_bind,
> >         .unbind         = qmi_wwan_unbind,
> >         .manage_power   = qmi_wwan_manage_power,
> > @@ -937,7 +937,7 @@ static const struct driver_info     qmi_wwan_info = {
> >
> >   static const struct driver_info       qmi_wwan_info_quirk_dtr = {
> >         .description    = "WWAN/QMI device",
> > -       .flags          = FLAG_WWAN | FLAG_SEND_ZLP,
> > +       .flags          = FLAG_WWAN | FLAG_NOMAXMTU | FLAG_SEND_ZLP,
> >         .bind           = qmi_wwan_bind,
> >         .unbind         = qmi_wwan_unbind,
> >         .manage_power   = qmi_wwan_manage_power,
> > diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
> > index ed86ba87ca4e..b72ba0803392 100644
> > --- a/drivers/net/usb/usbnet.c
> > +++ b/drivers/net/usb/usbnet.c
> > @@ -1829,11 +1829,12 @@ usbnet_probe(struct usb_interface *udev, const struct
> > usb_device_id *prod)
> >                 if ((dev->driver_info->flags & FLAG_NOARP) != 0)
> >                         net->flags |= IFF_NOARP;
> >
> > -               if (net->max_mtu > (dev->hard_mtu - net->hard_header_len))
> > +               if ((dev->driver_info->flags & FLAG_NOMAXMTU) == 0 &&
> > +                   net->max_mtu > (dev->hard_mtu - net->hard_header_len))
> >                         net->max_mtu = dev->hard_mtu - net->hard_header_len;
> >
> > -               if (net->mtu > net->max_mtu)
> > -                       net->mtu = net->max_mtu;
> > +               if (net->mtu > (dev->hard_mtu - net->hard_header_len))
> > +                       net->mtu = dev->hard_mtu - net->hard_header_len;
> >
> >         } else if (!info->in || !info->out)
> >                 status = usbnet_get_endpoints(dev, udev);
> > diff --git a/include/linux/usb/usbnet.h b/include/linux/usb/usbnet.h
> > index b0e84896e6ac..bbf799ccf3b3 100644
> > --- a/include/linux/usb/usbnet.h
> > +++ b/include/linux/usb/usbnet.h
> > @@ -132,6 +132,7 @@ struct driver_info {
> >   #define FLAG_MULTI_PACKET     0x2000
> >   #define FLAG_RX_ASSEMBLE      0x4000  /* rx packets may span >1 frames */
> >   #define FLAG_NOARP            0x8000  /* device can't do ARP */
> > +#define FLAG_NOMAXMTU          0x10000 /* allow max_mtu above hard_mtu */
> >
> >         /* init device ... can sleep, or cause probe() failure */
> >         int     (*bind)(struct usbnet *, struct usb_interface *);
> >
> >