Problem with AirCard 340U on embedded Linux

[Evade Flow]

> Which takes me to the next question, which is, why did qmi-network
not
> work for you before you cherry-picked those patches?

Doh--sorry for the confusion. `qmi-network` *does*, in fact, work fine,
regardless of whether those 11 patches are applied. I'm inexperienced with
broadband modems on Linux, and I did not, at first, recognize that I needed
to
run `dhclient` myself. I naively hoped that `qmi-network` would 'magically'
get
me an IP address, and when it didn't, I started writing my own little script
(posted previously in this thread) to experiment with different options,
including a version that manually configured an IP address and routing.
Nothing
seemed to work.

Some time later, I found several posts in this mailing list that mentioned
the
need to call `dhclient <iface>` after starting the network with
`qmi-network`.
So I added that to my little script. And it *still* didn't work. (Boo!)
Later,
I discovered that adding a call to `qmicli` with
`--wda-set-data-format=802-3`
fixed my script. (Yay!) It never occurred to me that `qmi-network` might
already be doing that, but I can confirm now that it *does*.

Here's the output from running `qmi-network`, followed by `dhclient`, on the
kernel 4.1.13 target board, with no patches applied:

```
root at embedded-dev $ qmi-network /dev/cdc-wdm0 start
Loading profile at /etc/qmi-network.conf...
    APN: fast.t-mobile.com
    APN user: unset
    APN password: unset
    qmi-proxy: no
Checking data format with 'qmicli -d /dev/cdc-wdm0 --wda-get-data-format
'...
Device link layer protocol retrieved: raw-ip
Getting expected data format with 'qmicli -d /dev/cdc-wdm0
--get-expected-data-format'...
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
Expected link layer protocol not retrieved: kernel unsupported
Updating device link layer protocol with 'qmicli -d /dev/cdc-wdm0
--wda-set-data-format=802-3 '...
New device link layer protocol retrieved: 802-3
Starting network with 'qmicli -d /dev/cdc-wdm0 --wds-start-network=apn='
fast.t-mobile.com'  --client-no-release-cid '...
Saving state at /tmp/qmi-network-state-cdc-wdm0... (CID: 1)
Saving state at /tmp/qmi-network-state-cdc-wdm0... (PDH: 1143419264)
Network started successfully
root at embedded-dev $ dhclient -v wwp0s21f0u3u4i8
Internet Systems Consortium DHCP Client 4.3.2
Copyright 2004-2015 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/wwp0s21f0u3u4i8/f2:b7:e0:79:43:35
Sending on   LPF/wwp0s21f0u3u4i8/f2:b7:e0:79:43:35
Sending on   Socket/fallback
DHCPREQUEST on wwp0s21f0u3u4i8 to 255.255.255.255 port 67
DHCPNAK from 26.175.235.110
DHCPDISCOVER on wwp0s21f0u3u4i8 to 255.255.255.255 port 67 interval 7
DHCPREQUEST on wwp0s21f0u3u4i8 to 255.255.255.255 port 67
DHCPOFFER from 26.175.235.110
DHCPACK from 26.175.235.110
bound to 26.175.235.109 -- renewal in 3471 seconds.
root at embedded-dev $ ping -c 1 google.com
PING google.com (216.58.192.174): 56 data bytes
64 bytes from 216.58.192.174: seq=0 ttl=54 time=46.611 ms

--- google.com ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 46.611/46.611/46.611 ms
```

So, if I gave the impression that `qmi-network` needed to be patched, I do
apologize. Only my brain needed patching. `:-] Other than the `No such file
or
directory error message` (which appears harmless), `qmi-network` works fine.

Thanks, guys, for educating/humoring me, and sorry for the confusion!

On Tue, Aug 16, 2016 at 2:47 PM, Aleksander Morgado <
aleksander at aleksander.es> wrote:

> On Tue, Aug 16, 2016 at 8:14 PM, Bjørn Mork <bjorn at mork.no> wrote:
> >> If you're going to stick to forcing 802-3 LLP in your device using the
> >> --wda-set-data-format, I think you can ignore all those patches.
> >>
> >> The "--get-expected-data-format" command will only work if your kernel
> >> has raw-ip support (32f7adf, which you had cherry-picked already).
> >> Which takes me to the next question, which is, why did qmi-network not
> >> work for you before you cherry-picked those patches? If qmi-network
> >> detects an error in "--get-expected-data-format", it should default to
> >> the old behavior of defaulting to 802-3 with WDA...
> >
> > I really don't think "--get-expected-data-format" can come into the
> > picture here?  The ISC dhclient won't handle that.  So the reason it
> > worked for the desktop must have been the fallback to
> > --wda-set-data-format.
>
> Sure, that is likely what happened in the desktop, which didn't have
> the raw-ip support patches I assume; but why didn't the same thing
> work in the embedded platform running Linux 4.1? i.e. why didn't it
> fallback to --wda-set-data-format=802-3 when
> "--get-expected-data-format" failed?
>
> --
> Aleksander
> https://aleksander.es
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libqmi-devel/attachments/20160816/9f177089/attachment-0001.html>