Issues with Netgear 340U latest firmware

Aleksander Morgado aleksander at aleksander.es
Thu Aug 14 02:11:17 PDT 2014


On Thu, Aug 14, 2014 at 10:42 AM, Bjørn Mork <bjorn at mork.no> wrote:
> 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.


Ah.... that could very well be it. ModemManager doesn't have this
problem, as we check the driver being used before probing, but
manually testing could trigger this issue.

Gopakumar; can you check (e.g. in dmesg output) which driver is
managing the modem? If it's mbim, then you can try to connect via
libmbim+mbimcli.

-- 
Aleksander
https://aleksander.es


More information about the libqmi-devel mailing list