<div dir="ltr"><div><div>Thanks Dan. Making this the "first thing" is doable but a lil tricky since everything is so asynchronous .. as soon as wwan0 interface is created, then brings signals dhcp to start sending packets etc.. Let me think of how I can get this done, or to be absolutely reliable, I am thinking add this into the qmi_wwan.c driver itself as some module option ? Let the driver do it as the first thing so that we are 100% sure that nothing else (dhcp etc..) went through before doing this. I will spend some time over the weekend to see what this qmicli 802-3 option does and if I can patch it into the qmi_wwan.c </div>Rgds, </div>Gopa. </div><div class="gmail_extra"> <div class="gmail_quote">On Thu, Aug 14, 2014 at 12:04 PM, Dan Williams <<a href="mailto:dcbw@redhat.com" target="_blank">dcbw@redhat.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">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 ( > <a href="http://www.mail-archive.com/linux-usb@vger.kernel.org/msg19918.html" target="_blank">http://www.mail-archive.com/linux-usb@vger.kernel.org/msg19918.html</a>) - 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 .. </div>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. <div class=""> > 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 ? </div>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 <div class="HOEnZb"><div class="h5"> > 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 <<a href="mailto:nietzsche@lysator.liu.se">nietzsche@lysator.liu.se</a>> > 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 <<a href="mailto:aleksander@aleksander.es">aleksander@aleksander.es</a>>: > > > > > > On Wed, Aug 13, 2014 at 9:19 PM, Dan Williams <<a href="mailto:dcbw@redhat.com">dcbw@redhat.com</a>> 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 > > > <a href="https://aleksander.es" target="_blank">https://aleksander.es</a> > > > _______________________________________________ > > > libqmi-devel mailing list > > > <a href="mailto:libqmi-devel@lists.freedesktop.org">libqmi-devel@lists.freedesktop.org</a> > > > <a href="http://lists.freedesktop.org/mailman/listinfo/libqmi-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/libqmi-devel</a> > > </div></div></blockquote></div> </div>