<div dir="ltr">> 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: - <a href="https://01.org/connman/documentation">https://01.org/connman/documentation</a> 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: - <a href="https://www.freedesktop.org/software/ModemManager/api/latest/">https://www.freedesktop.org/software/ModemManager/api/latest/</a> - <a href="http://ofono.sourcearchive.com/documentation/0.36-1/main.html">http://ofono.sourcearchive.com/documentation/0.36-1/main.html</a> 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: - <a href="https://lists.freedesktop.org/archives/libqmi-devel/2015-December/001477.html">https://lists.freedesktop.org/archives/libqmi-devel/2015-December/001477.html</a> 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@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. </div><div class="gmail_extra"> <div class="gmail_quote">On Tue, Aug 16, 2016 at 10:55 AM, Aleksander Morgado <<a href="mailto:aleksander@aleksander.es" target="_blank">aleksander@aleksander.es</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, Aug 16, 2016 at 4:45 PM, Evade Flow <<a href="mailto:evadeflow@gmail.com">evadeflow@gmail.com</a>> 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@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 <a href="https://aleksander.es" rel="noreferrer" target="_blank">https://aleksander.es</a> </blockquote></div> </div>