<html><head></head><body lang="en-US" style="background-color: rgb(255, 255, 255); line-height: initial;">                                                                                      <div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);">Which firmware version are you using on the modem???</div><div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);"><br></div><div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);">I think you should be able to set the default behaviour by AT commands Or at least make a hard nvram reset.</div><div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);"><br></div><div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);">//M</div>                                                                                                                                     <div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);"><br></div>                                                                                                                                                                                                   <div style="font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);">Sent from my BlackBerry 10 smartphone.</div>                                                                                                                                                                                  <table width="100%" style="background-color:white;border-spacing:0px;"> <tbody><tr><td colspan="2" style="font-size: initial; text-align: initial; background-color: rgb(255, 255, 255);">                           <div style="border-style: solid none none; border-top-color: rgb(181, 196, 223); border-top-width: 1pt; padding: 3pt 0in 0in; font-family: Tahoma, 'BB Alpha Sans', 'Slate Pro'; font-size: 10pt;">  <div><b>From: </b>Evade Flow</div><div><b>Sent: </b>tisdagen den 16:e augusti 2016 21:29</div><div><b>To: </b>Aleksander Morgado</div><div><b>Cc: </b>libqmi (development); Bjørn Mork</div><div><b>Subject: </b>Re: Problem with AirCard 340U on embedded Linux</div></div></td></tr></tbody></table><div style="border-style: solid none none; border-top-color: rgb(186, 188, 209); border-top-width: 1pt; font-size: initial; text-align: initial; background-color: rgb(255, 255, 255);"></div><br><div id="_originalContent" style=""><div dir="ltr">> Which takes me to the next question, which is, why did qmi-network not                                   <br>> work for you before you cherry-picked those patches?<br><br>Doh--sorry for the confusion. `qmi-network` *does*, in fact, work fine,<br>regardless of whether those 11 patches are applied. I'm inexperienced with<br>broadband modems on Linux, and I did not, at first, recognize that I needed to<br>run `dhclient` myself. I naively hoped that `qmi-network` would 'magically' get<br>me an IP address, and when it didn't, I started writing my own little script<br>(posted previously in this thread) to experiment with different options,<br>including a version that manually configured an IP address and routing. Nothing<br>seemed to work.<br><br>Some time later, I found several posts in this mailing list that mentioned the<br>need to call `dhclient <iface>` after starting the network with `qmi-network`.<br>So I added that to my little script. And it *still* didn't work. (Boo!) Later,<br>I discovered that adding a call to `qmicli` with `--wda-set-data-format=802-3`<br>fixed my script. (Yay!) It never occurred to me that `qmi-network` might<br>already be doing that, but I can confirm now that it *does*.<br><br>Here's the output from running `qmi-network`, followed by `dhclient`, on the<br>kernel 4.1.13 target board, with no patches applied:<br><br>```<br>root@embedded-dev $ qmi-network /dev/cdc-wdm0 start<br>Loading profile at /etc/qmi-network.conf...<br>    APN: <a href="http://fast.t-mobile.com">fast.t-mobile.com</a><br>    APN user: unset<br>    APN password: unset<br>    qmi-proxy: no<br>Checking data format with 'qmicli -d /dev/cdc-wdm0 --wda-get-data-format '...<br>Device link layer protocol retrieved: raw-ip<br>Getting expected data format with 'qmicli -d /dev/cdc-wdm0 --get-expected-data-format'...<br>error: cannot get expected data format: Expected data format not retrieved properly: Failed to open file '/sys/class/net/wwp0s21f0u3u4i8/qmi/raw_ip': No such file or directory <br>Expected link layer protocol not retrieved: kernel unsupported<br>Updating device link layer protocol with 'qmicli -d /dev/cdc-wdm0 --wda-set-data-format=802-3 '... <br>New device link layer protocol retrieved: 802-3<br>Starting network with 'qmicli -d /dev/cdc-wdm0 --wds-start-network=apn='<a href="http://fast.t-mobile.com">fast.t-mobile.com</a>'  --client-no-release-cid '...<br>Saving state at /tmp/qmi-network-state-cdc-wdm0... (CID: 1)<br>Saving state at /tmp/qmi-network-state-cdc-wdm0... (PDH: 1143419264)<br>Network started successfully<br>root@embedded-dev $ dhclient -v wwp0s21f0u3u4i8 <br>Internet Systems Consortium DHCP Client 4.3.2<br>Copyright 2004-2015 Internet Systems Consortium.<br>All rights reserved.<br>For info, please visit <a href="https://www.isc.org/software/dhcp/">https://www.isc.org/software/dhcp/</a><br><br>Listening on LPF/wwp0s21f0u3u4i8/f2:b7:e0:79:43:35<br>Sending on   LPF/wwp0s21f0u3u4i8/f2:b7:e0:79:43:35<br>Sending on   Socket/fallback<br>DHCPREQUEST on wwp0s21f0u3u4i8 to 255.255.255.255 port 67<br>DHCPNAK from 26.175.235.110<br>DHCPDISCOVER on wwp0s21f0u3u4i8 to 255.255.255.255 port 67 interval 7<br>DHCPREQUEST on wwp0s21f0u3u4i8 to 255.255.255.255 port 67<br>DHCPOFFER from 26.175.235.110<br>DHCPACK from 26.175.235.110<br>bound to 26.175.235.109 -- renewal in 3471 seconds.<br>root@embedded-dev $ ping -c 1 <a href="http://google.com">google.com</a><br>PING <a href="http://google.com">google.com</a> (216.58.192.174): 56 data bytes<br>64 bytes from <a href="http://216.58.192.174">216.58.192.174</a>: seq=0 ttl=54 time=46.611 ms<br><br>--- <a href="http://google.com">google.com</a> ping statistics ---<br>1 packets transmitted, 1 packets received, 0% packet loss<br>round-trip min/avg/max = 46.611/46.611/46.611 ms<br>```<br><br>So, if I gave the impression that `qmi-network` needed to be patched, I do<br>apologize. Only my brain needed patching. `:-] Other than the `No such file or<br>directory error message` (which appears harmless), `qmi-network` works fine.<br><br>Thanks, guys, for educating/humoring me, and sorry for the confusion!<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 16, 2016 at 2:47 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"><span class="">On Tue, Aug 16, 2016 at 8:14 PM, Bjørn Mork <<a href="mailto:bjorn@mork.no">bjorn@mork.no</a>> wrote:<br>
>> If you're going to stick to forcing 802-3 LLP in your device using the<br>
>> --wda-set-data-format, I think you can ignore all those patches.<br>
>><br>
>> The "--get-expected-data-format" command will only work if your kernel<br>
>> has raw-ip support (32f7adf, which you had cherry-picked already).<br>
>> Which takes me to the next question, which is, why did qmi-network not<br>
>> work for you before you cherry-picked those patches? If qmi-network<br>
>> detects an error in "--get-expected-data-format", it should default to<br>
>> the old behavior of defaulting to 802-3 with WDA...<br>
><br>
> I really don't think "--get-expected-data-format" can come into the<br>
> picture here?  The ISC dhclient won't handle that.  So the reason it<br>
> worked for the desktop must have been the fallback to<br>
> --wda-set-data-format.<br>
<br>
</span>Sure, that is likely what happened in the desktop, which didn't have<br>
the raw-ip support patches I assume; but why didn't the same thing<br>
work in the embedded platform running Linux 4.1? i.e. why didn't it<br>
fallback to --wda-set-data-format=802-3 when<br>
"--get-expected-data-format" failed?<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Aleksander<br>
<a href="https://aleksander.es" rel="noreferrer" target="_blank">https://aleksander.es</a><br>
</font></span></blockquote></div><br></div>
<br><!--end of _originalContent --></div></body></html>