Issues with Netgear 340U latest firmware

Bjørn Mork bjorn at mork.no
Thu Aug 14 01:42:23 PDT 2014


Gopakumar Choorakkot Edakkunni <gopakumar.c.e at gmail.com> writes:

>     Interface Descriptor:
>       bLength                 9
>       bDescriptorType         4
>       bInterfaceNumber       12
>       bAlternateSetting       0
>       bNumEndpoints           1
>       bInterfaceClass         2 Communications
>       bInterfaceSubClass     14
>       bInterfaceProtocol      0
>       iInterface              0
>       CDC Header:
>         bcdCDC               1.10
>       CDC MBIM:
>         bcdMBIMVersion       1.00

Hey, I just got an idea: Maybe this second MBIM configuration was added
in your new firmware?  Did you verify that you are using the qmi_wwan
driver, or is the device now driven by the cdc_mbim driver?  That would
explain your problems because the network data framing is completely
different.

You may all now think "What the heck is he talking about? We got
positive confirmation that the device still speaks QMI".  But this is
the really fun part of the Sierra firmwares: The firmware chooses
protocol based on probing.  So if you start talking QMI to an MBIM
function then it becomes a QMI function!  But the descriptors will of
course stay the same so the drivers won't notice, and the cdc_mbim
driver will still think that it should add MBIM framing to your DHCP
packets.

If this is the problem, then you could try an udev rule like this to
force the device to cfg #1 as a workaround (if you prefer to use QMI):

 ATTR{idVendor}=="1199",ATTR{idProduct}=="9051",ATTR{bConfigurationValue}=="2" ATTR{bConfigurationValue}="1"

Or just go for MBIM.  But then you have to be careful *not* to talk QMI
to the device before you start talking MBIM to it.


Bjørn


More information about the libqmi-devel mailing list