Problem with AirCard 340U on embedded Linux

Tue Aug 16 17:26:55 UTC 2016

> You were able to make the setup work with dhclient because you
changed
> the expected data format of the device to 802-3 before qmi-network did
> its own check.

Makes sense, thanks for the detailed explanation! I really wish I could
use ModemManager, and perhaps I will, eventually. Unfortunately, the
embedded stack I'm working with is using connman + ofono, which I don't
have any experience with, and haven't been able to find much
documentation for. This, frankly, wasn't very helpful in getting the AC
340U to work:

  - https://01.org/connman/documentation

I may have the freedom on this project to replace connman/ofono with
NetworkManager/ModemManager (or perhaps *just* ModemManager). If quality
of documentation were the only consideration, ModemManager would win
hands-down:

  - https://www.freedesktop.org/software/ModemManager/api/latest/
  - http://ofono.sourcearchive.com/documentation/0.36-1/main.html

But that's a battle for another day. Right now I just need to get a
4G/LTE pipe connected! `:-o

On a slightly different subject, I wonder if I could trouble you to
comment on which of the patches you mention in this post:

  -
https://lists.freedesktop.org/archives/libqmi-devel/2015-December/001477.html

would be beneficial to include on an embedded device running kernel
version 4.1.13 with a Sierra Wireless AC 340U?

> 34a55d5 net: qmi_wwan: ignore bogus CDC Union descriptors
> 6c73008 net: qmi_wwan: should hold RTNL while changing netdev type
> 32f7adf net: qmi_wwan: support "raw IP" mode
> 81e0ce7 usbnet: allow mini-drivers to consume L2 headers
> 544c8f6 net: qmi_wwan: remove 1199:9070 device id
> 9372514 net: qmi_wwan: MDM9x30 specific power management
> 68242a5 net: qmi_wwan: add XS Stick W100-2 from 4G Systems
> b3d8cf0 USB: qmi_wwan: Add quirk for Quectel EC20 Mini PCIe module
> 7091079 qmi_wwan: fix entry for HP lt4112 LTE/HSPA+ Gobi 4G Module
> 0db65fc qmi_wwan: add Sierra Wireless MC74xx/EM74xx
> e704059 net: qmi_wwan: Sierra Wireless MC73xx -> Sierra Wireless
MC7304/MC7354

I applied all of them (in desperation, to be honest) to see if they
might fix my problem. Since it turns out to have been something
unrelated, I reverted them all. And I *am* still able to connect; but I
noticed at least one difference. This command no longer works:

root at embedded-dev $ qmicli -d /dev/cdc-wdm0 --get-expected-data-format
error: couldn't create QmiDevice: Couldn't query file info: Error when
getting information for file '/dev/cdc-wdm0': No such file or directory

Since I can still connect, anyway, I'm wondering whether I should bother
with any patches. It's easy enough to include them, I'm just worried I
don't have the expertise to vet them properly. If you have a minute, and
can say off the top of your head, I'd be very interested to know your
opinion.

On Tue, Aug 16, 2016 at 10:55 AM, Aleksander Morgado <
aleksander at aleksander.es> wrote:

> On Tue, Aug 16, 2016 at 4:45 PM, Evade Flow <evadeflow at gmail.com> wrote:
> >> What about this just after plugging the device, without having run
> >> qmi-network?
> >>
> >> $ qmicli -d /dev/cdc-wdm0 --wda-get-data-format
> >>
> >> If it says "raw-ip"; then it may make sense what happened to you.
> >
> > Thanks, Aleksander. It does, indeed, show 'raw-ip':
> >
> > root at mel-automotive-gr-mrb $ qmicli -d /dev/cdc-wdm0
> --wda-get-data-format
> > [/dev/cdc-wdm0] Successfully got data format
> >                    QoS flow header: no
> >                Link layer protocol: 'raw-ip'
> >   Uplink data aggregation protocol: 'disabled'
> > Downlink data aggregation protocol: 'disabled'
> >                      NDP signature: '0'
> >   Uplink data aggregation max size: '0'
> > Downlink data aggregation max size: '0'
> >
> > For my own education, can you elaborate as to how it makes sense?
>
> So. qmi-network now checks 2 things:
>
>  * The kernel expected data format (by default 802-3)
>  * The device expected data format (by default raw-ip in your case).
>
> If the kernel allows updating the data format, as it is the case in
> your setup, qmi-network will run --set-expected-data-format=raw-ip so
> that both device and kernel match the data format; raw-ip in this
> case. Given that not all devices support all data formats (newer
> devices only do raw-ip) we always prefer the DEVICE data format.
>
> The problem is that dhclient doesn't work with an interface in raw-ip
> format; so you need to configure the interface "manually" with e.g.
> iproute2 commands. This is what we do in ModemManager nowadays; if the
> device is by default in raw-ip, we just request static ip addressing
> instead of DHCP.
>
> You were able to make the setup work with dhclient because you changed
> the expected data format of the device to 802-3 before qmi-network did
> its own check.
>
> --
> Aleksander
> https://aleksander.es
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libqmi-devel/attachments/20160816/f1eec958/attachment-0001.html>