IPv6 call failed with uqmi on built-in ZTE modems

For Developers
1

After recently porting a ZTE MF286[,A,R] family support to OpenWrt, i decided to play around with IPv6 support - however I stumbled upon a strange issue. The modem would connect to IPv4 APNs just fine, even using just the last configured settings, with nothing more, than this in /etc/config/network:

config interface 'wan'
        option proto 'qmi'
        option device '/dev/cdc-wdm0'

However, when attempting connection over IPv6, call to uqmi -s -d /dev/cdc-wdm0 --set-client-id wds,19 --start-network --apn internetipv6 would return a correct PDH, but afterwards, call to uqmi -s -d /dev/cdc-wdm0 --get-data-status afterwards still returns "disconnected". I haven't dug into why that might be in uqmi source code yet, but I discovered one quirk. If I call uqmi manually like this:

uqmi -s -d /dev/cdc-wdm0 --start-network --apn internetipv6 --ip-family ipv6

omitting the CID, the subsequent ifup wan connects the interface properly and everything works as it should.
My configuration at this time is:

config interface 'wan'
        option proto 'qmi'
        option device '/dev/cdc-wdm0'
        option pdptype 'ipv6'
        option apn 'internetipv6'

What's curious, is this happens on all Qualcomm-based modems used in the series (in MF283+, MF286, MF286A and even MF286D), and ModemManager can successfully connect over IPv6 with them. Any suggestions, on where to look further? Behaviour is the same on current master as well as on ancient 19.07 release.
Here is a full trace from QMI protocol handler:

Tue Mar  8 23:39:30 2022 daemon.notice netifd: Interface 'wan' is setting up now
Tue Mar  8 23:39:30 2022 daemon.notice netifd: wan (21208): + '['  '='  ]
Tue Mar  8 23:39:30 2022 daemon.notice netifd: wan (21208): + timeout=10
Tue Mar  8 23:39:30 2022 daemon.notice netifd: wan (21208): + '['  '='  ]
Tue Mar  8 23:39:30 2022 daemon.notice netifd: wan (21208): + metric=0
Tue Mar  8 23:39:30 2022 daemon.notice netifd: wan (21208): + '[' -n  ]
Tue Mar  8 23:39:30 2022 daemon.notice netifd: wan (21208): + '[' -n /dev/cdc-wdm0 ]
Tue Mar  8 23:39:30 2022 daemon.notice netifd: wan (21208): + '[' -n  ]
Tue Mar  8 23:39:30 2022 daemon.notice netifd: wan (21208): + readlink -f /dev/cdc-wdm0
Tue Mar  8 23:39:30 2022 daemon.notice netifd: wan (21208): + device=/dev/cdc-wdm0
Tue Mar  8 23:39:30 2022 daemon.notice netifd: wan (21208): + '[' -c /dev/cdc-wdm0 ]
Tue Mar  8 23:39:30 2022 daemon.notice netifd: wan (21208): + basename /dev/cdc-wdm0
Tue Mar  8 23:39:30 2022 daemon.notice netifd: wan (21208): + devname=cdc-wdm0
Tue Mar  8 23:39:30 2022 daemon.notice netifd: wan (21208): + readlink -f /sys/class/usbmisc/cdc-wdm0/device/
Tue Mar  8 23:39:30 2022 daemon.notice netifd: wan (21208): + devpath=/sys/devices/platform/soc/8af8800.usb3/8a00000.dwc3/xhci-hcd.0.auto/usb2/2-1/2-1:1.5
Tue Mar  8 23:39:30 2022 daemon.notice netifd: wan (21208): + ls /sys/devices/platform/soc/8af8800.usb3/8a00000.dwc3/xhci-hcd.0.auto/usb2/2-1/2-1:1.5/net
Tue Mar  8 23:39:30 2022 daemon.notice netifd: wan (21208): + ifname=wwan0
Tue Mar  8 23:39:30 2022 daemon.notice netifd: wan (21208): + '[' -n wwan0 ]
Tue Mar  8 23:39:30 2022 daemon.notice netifd: wan (21208): + '[' -n  ]
Tue Mar  8 23:39:30 2022 daemon.notice netifd: wan (21208): + echo 'Waiting for SIM initialization'
Tue Mar  8 23:39:30 2022 daemon.notice netifd: wan (21208): Waiting for SIM initialization
Tue Mar  8 23:39:30 2022 daemon.notice netifd: wan (21208): + local 'uninitialized_timeout=0'
Tue Mar  8 23:39:30 2022 daemon.notice netifd: wan (21208): + uqmi -s -d /dev/cdc-wdm0 --get-pin-status
Tue Mar  8 23:39:30 2022 daemon.notice netifd: wan (21208): + grep '"UIM uninitialized"'
Tue Mar  8 23:39:30 2022 daemon.notice netifd: wan (21208): + uqmi -s -d /dev/cdc-wdm0+ grep '"Not supported"\|"Invalid QMI command"'
Tue Mar  8 23:39:30 2022 daemon.notice netifd: wan (21208):  --get-pin-status
Tue Mar  8 23:39:30 2022 daemon.notice netifd: wan (21208): + '[' -n  ]
Tue Mar  8 23:39:30 2022 daemon.notice netifd: wan (21208): + '[' -n  ]
Tue Mar  8 23:39:30 2022 daemon.notice netifd: wan (21208): + uqmi -s -d /dev/cdc-wdm0 --stop-network 0xffffffff --autoconnect
Tue Mar  8 23:39:30 2022 daemon.notice netifd: wan (21208): + uqmi -s -d /dev/cdc-wdm0 --set-data-format 802.3
Tue Mar  8 23:39:30 2022 daemon.notice netifd: wan (21208): + uqmi -s -d /dev/cdc-wdm0 --wda-set-data-format 802.3
Tue Mar  8 23:39:30 2022 daemon.notice netifd: wan (21208): + uqmi -s -d /dev/cdc-wdm0 --wda-get-data-format
Tue Mar  8 23:39:31 2022 daemon.notice netifd: wan (21208): + dataformat='"raw-ip"'
Tue Mar  8 23:39:31 2022 daemon.notice netifd: wan (21208): + '[' '"raw-ip"' '=' '"raw-ip"' ]
Tue Mar  8 23:39:31 2022 daemon.notice netifd: wan (21208): + '[' -f /sys/class/net/wwan0/qmi/raw_ip ]
Tue Mar  8 23:39:31 2022 daemon.notice netifd: wan (21208): + echo 'Device does not support 802.3 mode. Informing driver of raw-ip only for wwan0 ..'
Tue Mar  8 23:39:31 2022 daemon.notice netifd: wan (21208): Device does not support 802.3 mode. Informing driver of raw-ip only for wwan0 ..
Tue Mar  8 23:39:31 2022 daemon.notice netifd: wan (21208): + echo Y
Tue Mar  8 23:39:31 2022 daemon.notice netifd: wan (21208): + uqmi -s -d /dev/cdc-wdm0 --sync
Tue Mar  8 23:39:31 2022 daemon.notice netifd: wan (21208): + echo 'Waiting for network registration'
Tue Mar  8 23:39:31 2022 daemon.notice netifd: wan (21208): Waiting for network registration
Tue Mar  8 23:39:31 2022 daemon.notice netifd: wan (21208): + local 'registration_timeout=0'
Tue Mar  8 23:39:31 2022 daemon.notice netifd: wan (21208): + uqmi -s -d /dev/cdc-wdm0 --get-serving-system
Tue Mar  8 23:39:31 2022 daemon.notice netifd: wan (21208): + grep '"searching"'
Tue Mar  8 23:39:31 2022 daemon.notice netifd: wan (21208): + '[' -n  ]
Tue Mar  8 23:39:31 2022 daemon.notice netifd: wan (21208): + echo 'Starting network wan'
Tue Mar  8 23:39:31 2022 daemon.notice netifd: wan (21208): Starting network wan
Tue Mar  8 23:39:31 2022 daemon.notice netifd: wan (21208): + echo ipv6
Tue Mar  8 23:39:31 2022 daemon.notice netifd: wan (21208): + awk '{print tolower($0)}'
Tue Mar  8 23:39:31 2022 daemon.notice netifd: wan (21208): + pdptype=ipv6
Tue Mar  8 23:39:31 2022 daemon.notice netifd: wan (21208): + '[' ipv6 '=' ip -o ipv6 '=' ipv6 -o ipv6 '=' ipv4v6 ]
Tue Mar  8 23:39:31 2022 daemon.notice netifd: wan (21208): + '[' ipv6 '=' ip ]
Tue Mar  8 23:39:31 2022 daemon.notice netifd: wan (21208): + '['  '=' 1 ]
Tue Mar  8 23:39:31 2022 daemon.notice netifd: wan (21208): + autoconnect=
Tue Mar  8 23:39:31 2022 daemon.notice netifd: wan (21208): + '[' ipv6 '=' ip -o ipv6 '=' ipv4v6 ]
Tue Mar  8 23:39:31 2022 daemon.notice netifd: wan (21208): + '[' ipv6 '=' ipv6 -o ipv6 '=' ipv4v6 ]
Tue Mar  8 23:39:31 2022 daemon.notice netifd: wan (21208): + uqmi -s -d /dev/cdc-wdm0 --get-client-id wds
Tue Mar  8 23:39:31 2022 daemon.notice netifd: wan (21208): + cid_6=19
Tue Mar  8 23:39:31 2022 daemon.notice netifd: wan (21208): + '[' 19 -eq 19 ]
Tue Mar  8 23:39:31 2022 daemon.notice netifd: wan (21208): + uqmi -s -d /dev/cdc-wdm0 --set-client-id wds,19 --set-ip-family ipv6
Tue Mar  8 23:39:31 2022 daemon.notice netifd: wan (21208): + uqmi -s -d /dev/cdc-wdm0 --set-client-id wds,19 --start-network --apn internetipv6
Tue Mar  8 23:39:31 2022 daemon.notice netifd: wan (21208): + pdh_6=685554480
Tue Mar  8 23:39:31 2022 daemon.notice netifd: wan (21208): + '[' 685554480 -eq 685554480 ]
Tue Mar  8 23:39:31 2022 daemon.notice netifd: wan (21208): + uqmi -s -d /dev/cdc-wdm0 --get-data-status
Tue Mar  8 23:39:31 2022 daemon.notice netifd: wan (21208): + connstat='"disconnected"'
Tue Mar  8 23:39:31 2022 daemon.notice netifd: wan (21208): + '[' '"disconnected"' '==' '"connected"' ]
Tue Mar  8 23:39:31 2022 daemon.notice netifd: wan (21208): + echo 'No data link!'
Tue Mar  8 23:39:31 2022 daemon.notice netifd: wan (21208): No data link!
Tue Mar  8 23:39:31 2022 daemon.notice netifd: wan (21208): + uqmi -s -d /dev/cdc-wdm0 --set-client-id wds,19 --release-client-id wds
Tue Mar  8 23:39:31 2022 daemon.notice netifd: wan (21208): + proto_notify_error wan CALL_FAILED
2

Hi
I have a modified version of uqmi. I configure APN profiles in the modem and use this profiles when the modem registers to the network. https://github.com/mrhaav/openwrt-packages

What target version do you use?

3

As I stated, behaviour is the same on current master as well on 19.07.9.
I've seen your fork, but haven't looked into details yet - this doesn't look like the need for explicit profile configuration. I think the next step would be to use qmicli and compare QMI exchange using USB capture.

4

I can start both IPv6 or dual-stack sessions with my uqmi version.
Your issue could be related to what default APN profile is configured in your modem.

You can check your default APN with my version uqmi or qmicli.

qmicli -d /dev/cdc-wdm0 --wds-get-profile-list=3gpp
qmicli -d /dev/cdc-wdm0 --wds-get-default-profile-num=3gpp
5

Yeah, I ensured the default bearer APN is correct, by using AT+CGDCONT command as mentioned previously. This was in fact required step for both IPv4 and IPv6 to work, and it's common knowledge, that uqmi cannot change this on its own, unfortunately.

6

Yes, I know. That is what I have added in my uqmi. So now you can change APN and pdptype from Luci without any AT-commands.
I have added some information, printed to syslog, during the setup, as well.
Maybe it will help you in to find a solution.

7

For a proper reference, I'll go with qmi-utils/libqmi combo, which is well-proven in the field and doesn't require me to fiddle with build system. My intention is to fix the bug in upstream, not to switch to downstream fork of uqmi. Already got some usbmon captures - will post them shortly.

Edit: and I think I found it. After call to uqmi --start-network was made, with selected CID, the subsequent call to uqmi --get-data-status was missing that CID, thus modem would report wrong state as "disconnected". When I added the CID, the correct state was reported. I will post a RFC/RFT patch shortly, as I believe, that this is broken for IPv4 as well, and was working by accident.
The fix is here: https://github.com/Leo-PL/openwrt/commits/uqmi-query-data-status-cid
And opened PR as well: https://github.com/openwrt/openwrt/pull/9452
This got merged today as well, so marking as solved.

Also implemented IPv4/IPv6 dual-APN multiplexing, because why not: https://github.com/Leo-PL/openwrt/tree/uqmi-split-apn-dualstack
@bmork what do you thing about this implementation? Is it upstream-worthy?

1 Like
8

Can't harm. But I'm not sure how useful it is. Looks like a very specialized use case. At least not something I have ever wanted or needed....

When I mentioned muxing I was thinking more like e.g this: https://techship.com/faq/example-on-how-to-establish-a-data-connection-with-telit-fn980-series-in-linux-using-qmi-rmnet-and-usb-interface/

Then you can connect to more than 2 APNs and mix and match with IP, IPV6 and IPV4V6 as you like.

But that requires a lot more out of uqmi. And the usage is pretty complicated (as demonstrated in that link) so who knows how we can get it to play with uci. Probably not worth the job. You can always switch to qmicli if necessary. And ModemManager will help you set up the muxed sessions and links. And MBIM is a better option for muxed links anyway

9

I might submit it as RFC then. For me, it's a workaround for crappy (ex-national) ISP which offers only IPv4 or IPv6+CLAT APNs, no IPv4v6.

10

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.