Issues with Netgear 340U latest firmware

Dan Williams dcbw at redhat.com
Thu Aug 14 12:04:28 PDT 2014


On Thu, 2014-08-14 at 11:24 -0700, Gopakumar Choorakkot Edakkunni wrote:
> Thanks Aleksander, Bjorn, Markus ! The qmicli to change from raw-ip to
> 802-3 did work afterall - what I was missing yesterday is that I did not do
> an rmmod and modprobe of cdc_qdm and qmi_wwan. Today I reissued those
> commands and did rmmod and modprobe again and with that it worked.. Couple
> of qns below
> 
> 1. I see that the qmi_wwan.c already has a "hack" in place to detect raw-ip
> Vs 802-3 and switch modes appropriately as explained here (
> http://www.mail-archive.com/linux-usb@vger.kernel.org/msg19918.html) - so
> is that not sufficient to workaround this issue ? Why would we need this
> qmicli forced setting on top of it ? Just for my understanding ..

Not quite... it doesn't actually switch the mode in the modem firmware
at all.  It simply fixes up a firmware bug where the modem firmware
*sends* some packets in Raw IP mode mistakenly, but the modem is
actually still in 802.3 mode and expects incoming 802.3 packets.

> 2. The qmicli force 802-3 at times takes multiple attempts (multiple times
> the cli has to be issued) before it finally reports that its operating in
> 802-3 mode. I am assuming its something related to how fast/slow the
> firmware processes these commands ? Any ideas ?

It might be, yes.  Is there any other process running (like
ModemManager) that's using QMI already and has reserved some client IDs?
My thought here is that if the modem is already in-use, even if it's not
sending data yet, that the firmware waits for some reason before
actually switching.  Usually the *first* thing you should do, when doing
anything with the modem, is switch it to 802.3 mode.  The proceed as
normal.  Maybe even put that in a udev helper script or something.

Dan

> Once again, thanks a lot to all of your for helping with this .. I was
> calling up AT&T with this problem report and was not getting anywhere with
> that :)
> 
> Rgds,
> Gopa.
> 
> 
> On Thu, Aug 14, 2014 at 7:41 AM, Markus Gothe <nietzsche at lysator.liu.se>
> wrote:
> 
> > I can confirm that this made the new firmware work for me.
> >
> > Seems like the device ended up in raw-ip mode after upgrade.
> >
> > //Markus - The panama-hat hacker
> > Den 14 aug 2014 01:04 skrev Aleksander Morgado <aleksander at aleksander.es>:
> > >
> > > On Wed, Aug 13, 2014 at 9:19 PM, Dan Williams <dcbw at redhat.com> wrote:
> > > > b) On "9x15" devices, the Netgear GobiNet driver uses the WDA service's
> > > > Set Data Format call instead of the CTL service.  Not sure if that
> > makes
> > > > a difference here or not, but maybe new devices expect the WDA
> > mechanism
> > > > instead, and so the data format is not getting switched to Ethernet?
> > >
> > > My tests with newer Sierra devices and this issue (CTL vs WDA) yielded
> > > more or less the same results. This is, wwan data format can be
> > > changed with both ways successfully, with the difference being that
> > > the WDA service is just much better documented. Recent libqmi/qmicli
> > > has support for WDA, btw:
> > >   --wda-set-data-format=[raw-ip|802-3]
> > >   --wda-get-data-format
> > >
> > > The problem for the reporter may just be that by default raw-ip is
> > > configured in the WWAN interface; or if it has 2 interfaces, one may
> > > be raw-ip and the other 802-3. qmicli doesn't change the data format
> > > by default (as ModemManager does), so the issue may just be that 802-3
> > > needs to be explicitly requested via qmicli...
> > >
> > > Gopakumar, can you try to run:
> > > $ qmicli --wds-noop --device-open-net="net-802-3|net-no-qos-header"
> > > and then your normal WDS connection setup?
> > >
> > > Or, with a newer libqmi:
> > > $ qmicli --wda-set-data-format="802-3"
> > >
> > > --
> > > Aleksander
> > > https://aleksander.es
> > > _______________________________________________
> > > libqmi-devel mailing list
> > > libqmi-devel at lists.freedesktop.org
> > > http://lists.freedesktop.org/mailman/listinfo/libqmi-devel
> >




More information about the libqmi-devel mailing list