Issues with Netgear 340U latest firmware

Gopakumar Choorakkot Edakkunni gopakumar.c.e at gmail.com
Wed Aug 13 20:16:33 PDT 2014


Well, I spoke too soon. I checked the exact patched version of 3.12.13
kernel I run and that already has the 1199:9051 added to the list. So back
to square one -

1. 1199:9051 is present in the list with 3.12.13 kernel (patched to add
that in)
2. was working fine before the latest firmware upgrade
3. upgraded to latest and stopped working
4. Tried the suggestions here about using the 802-3 option in qmicli, no
luck there either

So if anyone else volunteers to upgrade to the latest firmware to see if
that fails too ;), that would be welcome :)

Rgds,
Gopa.



On Wed, Aug 13, 2014 at 8:00 PM, Gopakumar Choorakkot Edakkunni <
gopakumar.c.e at gmail.com> wrote:

> 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/f78a5388/attachment-0001.html>


More information about the libqmi-devel mailing list