Issues with Netgear 340U latest firmware

Wed Aug 13 20:00:19 PDT 2014

Apologies .. I meant "1199:9051"  - that is the modem I use. And the kernel
I use is 3.12.13.

If you are adventurous ;), would you mind upgrading the firmware to the
latest and see if that still works :) ? Also whats the kernel version you
use ?

Rgds,
Gopa.

On Wed, Aug 13, 2014 at 7:52 PM, David McCullough <
david.mccullough at accelecon.com> wrote:

>
> Gopakumar Choorakkot Edakkunni wrote the following:
> > Going back to the VID/PID, I was looking up the qmi_wwan.c in the kernel
> > sources and I find that the 1109:9051 is not in the QMI_FIXED_INTF table
> in
> > the kernel version I am running (3.12.13) !! And in the kernel version
> > 3.12.16 for example, I see the 1109:9051 in the table (correctly as
> Aircard
> > 340U). But I promise it was just working perfectly fine till the firmware
> > upgrade :) - which means it was either working purely by "chance" (is
> that
> > possible!!) or that the PID changed after a firmware upgrade (highly
> > unlikely ?).
> >
> > At any rate, I will try out the 3.12.16 kernel tomorrow or just add
> > 1109:9051 to the list in 3.12.13 and see how it goes. Will update
> tomorrow.
>
> Mine runs at 1199:9051,  id the 1109 a typo ?
> ATI shows revision:
>
>         SWI9X15C_01.05.11.23 r13063 carmd-fwbuild1 2013/03/30 23:11:32
>
> Which is almost certinaly the older rev,
>
> Cheers,
> Davidm
>
>
> > On Wed, Aug 13, 2014 at 5:26 PM, Gopakumar Choorakkot Edakkunni <
> > gopakumar.c.e at gmail.com> wrote:
> >
> > > Hi Aleksander,
> > >
> > > Thanks a lot for the suggestions. I tried them out, but that did not
> solve
> > > the problem. I upgraded to libqmi 1.10.2 to get the latest clis .. I
> cross
> > > checked with a couple of other people with Sierra/Netgear 340U modems
> > > running linux and they are facing the same issue too. The  firmware
> version
> > > just before this latest one was all hunky dory and great,
> unfortunately the
> > > upgrade to the latest has caused this issue.
> > >
> > > Before issuing the command you suggested:
> > >
> > > wwan0     Link encap:Ethernet  HWaddr C2:4A:EB:3B:51:7C
> > >           inet6 addr: fe80::c04a:ebff:fe3b:517c/64 Scope:Link
> > >           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
> > >           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> > >           TX packets:139 errors:0 dropped:0 overruns:0
> > > carrier:0                         <<<<========== These are DHCP packets
> > > going out
> > >           collisions:0 txqueuelen:1000
> > >           RX bytes:0 (0.0 B)  TX bytes:48174 (47.0
> > > KiB)                                       <<<<========== No response
> > >
> > >
> > > Now I issue the command:
> > >
> > > root:~# qmicli -d /dev/cdc-wdm0
> > > --wda-set-data-format="802-3"
> > > [/dev/cdc-wdm0] Successfully set data format
> > >                         QoS flow header: no
> > >                     Link layer protocol: '802-3'
> > >        Uplink data aggregation protocol: 'disabled'
> > >      Downlink data aggregation protocol: 'disabled'
> > >                           NDP signature: '0'
> > > Downlink data aggregation max datagrams: '0'
> > >      Downlink data aggregation max size: '0'
> > >
> > > As seen in ifconfig below, it has no change (DHCP requests have been
> going
> > > on continuosly in the meantime via udhcpc) :
> > >
> > > root:~# ifconfig wwan0
> > > wwan0     Link encap:Ethernet  HWaddr C2:4A:EB:3B:51:7C
> > >           inet6 addr: fe80::c04a:ebff:fe3b:517c/64 Scope:Link
> > >           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
> > >           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> > >           TX packets:306 errors:0 dropped:0 overruns:0 carrier:0
> > >           collisions:0 txqueuelen:1000
> > >           RX bytes:0 (0.0 B)  TX bytes:115308 (112.6
> > > KiB)                               <<<<<=========== Still no response
> > >
> > > Rgds,
> > > Gopa.
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Wed, Aug 13, 2014 at 4:13 PM, Aleksander Morgado <
> > > aleksander at aleksander.es> wrote:
> > >
> > >> On Wed, Aug 13, 2014 at 9:19 PM, Dan Williams <dcbw at redhat.com>
> wrote:
> > >> > Bjorn: I see that the Sierra drivers expect the following layout
> > >> >
> > >> > Serial:
> > >> > 1199:68A2 - blacklisted: 8, 10, 11, 19, 20
> > >> > 1199:68C0 - blacklisted: 8, 10, 11
> > >> > 1199:9057 - blacklisted: 0, 1, 5, 8, 10, 11 ("Netgear AC341U IPT2
> mode")
> > >> >
> > >> > Net:
> > >> > 1199:68A2 - 8, 10, 19 ("MDM9x15 PDNs")
> > >> > 1199:68C0 - 8, 10, 19
> > >> > 1199:9057 - 8, 10, 11
> > >> >
> > >> > Which means that qmi_wwan is missing:
> > >> >
> > >> > 1199:68a2: 10
> > >> > 1199:68c0: 19
> > >> > 1199:9057: 10, 11
> > >> >
> > >> > No idea whether adding these to qmi_wwan would be useful or not,
> you've
> > >> > done more work than I with these devices, and I'm not sure where we
> > >> > landed on whether or not to expose the non-functional QMI interfaces
> > >> > through qmi_wwan.
> > >>
> > >> It was decided not to expose the non-functional ones.
> > >>
> > >> E.g. the MC7304 (0x1199, 0x68c0) exposed interfaces 8, 10 and 11. 8
> > >> and 10 were both QMI (one with raw-ip by default, the other one with
> > >> 802-3 by default), and 11 was the non-functional one, so it was
> > >> removed from the driver.
> > >>
> > >> --
> > >> Aleksander
> > >> https://aleksander.es
> > >>
> > >
> > >
>
> > _______________________________________________
> > libqmi-devel mailing list
> > libqmi-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/libqmi-devel
>
>
> --
> David McCullough,  davidm at spottygum.com,   Ph: 0410 560 763
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/libqmi-devel/attachments/20140813/586ead69/attachment.html>