<div dir="ltr"><div>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 ?). <br>
<br></div>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.<br><br>Rgds,<br>Gopa.<br> <br></div><div class="gmail_extra"><br><br>
<div class="gmail_quote">On Wed, Aug 13, 2014 at 5:26 PM, Gopakumar Choorakkot Edakkunni <span dir="ltr"><<a href="mailto:gopakumar.c.e@gmail.com" target="_blank">gopakumar.c.e@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div><div>Hi Aleksander,<br><br></div>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.<br>

<br>Before issuing the command you suggested:<br><br>wwan0     Link encap:Ethernet  HWaddr C2:4A:EB:3B:51:7C  <br>          inet6 addr: fe80::c04a:ebff:fe3b:517c/64 Scope:Link<br>          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1<br>

          RX packets:0 errors:0 dropped:0 overruns:0 frame:0<br>          TX packets:139 errors:0 dropped:0 overruns:0 carrier:0                         <<<<========== These are DHCP packets going out<br>          collisions:0 txqueuelen:1000 <br>

          RX bytes:0 (0.0 B)  TX bytes:48174 (47.0 KiB)                                       <<<<========== No response<br><br><br></div>Now I issue the command:<br><div><br>root:~# qmicli -d /dev/cdc-wdm0 --wda-set-data-format="802-3"                                        <br>

[/dev/cdc-wdm0] Successfully set data format<br>                        QoS flow header: no<br>                    Link layer protocol: '802-3'<br>       Uplink data aggregation protocol: 'disabled'<br>     Downlink data aggregation protocol: 'disabled'<br>

                          NDP signature: '0'<br>Downlink data aggregation max datagrams: '0'<br>     Downlink data aggregation max size: '0'<br><br></div><div>As seen in ifconfig below, it has no change (DHCP requests have been going on continuosly in the meantime via udhcpc) :<br>

<br>root:~# ifconfig wwan0<br>wwan0     Link encap:Ethernet  HWaddr C2:4A:EB:3B:51:7C  <br>          inet6 addr: fe80::c04a:ebff:fe3b:517c/64 Scope:Link<br>          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1<br>
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0<br>
          TX packets:306 errors:0 dropped:0 overruns:0 carrier:0<br>          collisions:0 txqueuelen:1000 <br>          RX bytes:0 (0.0 B)  TX bytes:115308 (112.6 KiB)                               <<<<<=========== Still no response<br>

<br></div><div>Rgds,<br>Gopa.<br></div><div><br><br></div><div><br><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Aug 13, 2014 at 4:13 PM, Aleksander Morgado <span dir="ltr"><<a href="mailto:aleksander@aleksander.es" target="_blank">aleksander@aleksander.es</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On Wed, Aug 13, 2014 at 9:19 PM, Dan Williams <<a href="mailto:dcbw@redhat.com" target="_blank">dcbw@redhat.com</a>> wrote:<br>


</div><div>> Bjorn: I see that the Sierra drivers expect the following layout<br>
><br>
> Serial:<br>
> 1199:68A2 - blacklisted: 8, 10, 11, 19, 20<br>
> 1199:68C0 - blacklisted: 8, 10, 11<br>
> 1199:9057 - blacklisted: 0, 1, 5, 8, 10, 11 ("Netgear AC341U IPT2 mode")<br>
><br>
> Net:<br>
> 1199:68A2 - 8, 10, 19 ("MDM9x15 PDNs")<br>
> 1199:68C0 - 8, 10, 19<br>
> 1199:9057 - 8, 10, 11<br>
><br>
> Which means that qmi_wwan is missing:<br>
><br>
> 1199:68a2: 10<br>
> 1199:68c0: 19<br>
> 1199:9057: 10, 11<br>
><br>
> No idea whether adding these to qmi_wwan would be useful or not, you've<br>
> done more work than I with these devices, and I'm not sure where we<br>
> landed on whether or not to expose the non-functional QMI interfaces<br>
> through qmi_wwan.<br>
<br>
</div>It was decided not to expose the non-functional ones.<br>
<br>
E.g. the MC7304 (0x1199, 0x68c0) exposed interfaces 8, 10 and 11. 8<br>
and 10 were both QMI (one with raw-ip by default, the other one with<br>
802-3 by default), and 11 was the non-functional one, so it was<br>
removed from the driver.<br>
<span><font color="#888888"><br>
--<br>
Aleksander<br>
<a href="https://aleksander.es" target="_blank">https://aleksander.es</a><br>
</font></span></blockquote></div><br></div>
</div></div></blockquote></div><br></div>