Uqmi fails to connect data in "IPV6 only" mode

For Developers
1

Hello

I have seen that qmi is failing to fetch IPV6 address in IPV6 only mode.
This logic in qmi.sh is failing

       # Check data connection state
		connstat=$(uqmi -s -d "$device" --set-client-id wds,"$cid_6" --get-data-status)
		[ "$connstat" == '"connected"' ] || {
			echo "No data link!"
			uqmi -s -d "$device" --set-client-id wds,"$cid_6" --release-client-id wds > /dev/null 2>&1
			proto_notify_error "$interface" CALL_FAILED
			return 1
		}

In IPV6 only mode, uqmi always returns "disconnected".

At the same time we already have received IPV6 ip addresses

uqmi -d /dev/cdc-wdm0  --set-client-id wds,2 --get-current-settings
{
	"pdp-type": "ipv6",
	"ip-family": "ipv6",
	"mtu": 1500,
	"ipv4": {
		
	},
	"ipv6": {
		"ip": "24:149:4e:488:1814:771a:94f1:3e04",
		"ip-prefix-length": 64,
		"gateway": "24:149:4e:488:1850:d5d8:12af:a2c6",
		"gw-prefix-length": 64,
		"dns1": "24:149:0:5000:900::2",
		"dns2": "2401:4900:50:9::75"
	},
	"domain-names": {
		
	}
}
2

I have ipv6 only working fine for the ZTE modem in the MF286D router without needing to modify qmi.sh.

I tried changing the ipv6 uqmi --get-data-status call in qmi.sh and it also worked:

connstat=$(uqmi -s -d "$device" --set-ip-family ipv6 --get-data-status)

3

I suppose that commit c8a88118af4602e9eb1b57434d9e2e2c57667e53 is included in your build - if you revert it, does the connection work? What is your router/modem model?
Without that commit, ZTE modems used in MF283+, MF286, MF286A and MF286D would fail that exact check, so maybe we need a different method to suit all the modems.
cc @daniel @bmork

@ai8 adding --set-ip-family ipv6 to get-data-status call also works on my 286D, instead of specifying CID, which is correct according to specification. Now I wonder, which modem of ones in the topic is the buggy one.

4

I don't know if this works for all newer modems and firmwares, but the procedure I documented here used to be the only working solution: https://www.spinics.net/lists/linux-usb/msg59572.html

I.e, use 2 separate CIDs, configure ip-family for each of them as a separate request, and connect separately.

The IP family TLV in the connect request was not sufficient/had no effect.

Now, I',m sure newer modems can be made to work with a simple procedure. But with the MDM9200 generation (and maybe older? not sure dual stack was supported at all before LTE) you had to do it that way. So if it works with newer modems, then it will be the most compatible solution.

10 years ago.... how time flies when you're having fun :slight_smile: And we still struggle with the IPv6 transition.

5

Not that fun, when your fix caused a regression for someone.
@ashish.kamble005 please check if fix by @ai8 works for you, if so - we need to revert my fix and probably apply this one.
Could you try connstat=$(uqmi -s -d "$device" --set-client-id wds,"$cid_6" --set-ip-family ipv6 --get-data-status)?
On MF286D, all three variants of the command work, by specifying CID, IP family or both.

I also tested on Sierra EM7455 - IPv6 works on both it and on MF286D in that variant, but I wasn't able to pull off the dual-APN-dual-stack trick on EM7455, that would probably require me to do that properly and set up rmnet muxing. I was only able to pull that of manually on EM7455 using MBIM multiplexing and mbimcli.

6

I suggested using --set-ip-family for the --get-data-status uqmi call because I suspected it would also return "disconnected" and for completeness @ashish.kamble005 should also try:

connstat=$(uqmi -s -d "$device" --get-data-status)

7

And this snippet is exactly what was used before, and failing on MF286D.

In the meantime I had a chance to test Telit LE910C4 with setting both CID and IP family, and it worked as well. Found another bug on it - it requires the connection state for IPv6 to be reset explicitly as well at the beginning of setup.
I'd like to submit the fix, but first I need a confirmation from @ashish.kamble005.

8

Yep and it also fails on MC7304 modem.

9

Yep that is still how qmi.sh does dual stack.and with the MC7304, EM7455 and ZTE MF286D modems I had to configure them with AT+CGDCONT=1,"IP","" and AT+CGDCONT=2,"IPV4V6","" then I added option profile '2' to the wwan interface in the network config file. The Sierra modems also needed option dhcpv6 '1'.

10

Yes, but that's for the case of half-assed ISP implementations, which do dual-stack using dual APNs. Just like I did that for Orange Poland, which doesn't offer true dual-stack, only either IPv4 or IPv6+CLAT..With proper IPv4v6, the procedure is the same, except for using the same APN and profile index in both address families.

11

I was thinking it was a quirk of the modems rather than an ISP issue.

I have looked into it more and the conclusive evidence is that profile 1 cannot be used for IPV4V6.

Configuring the modems to use profile 2 or higher for "IPV4V6" works fine whereas for profile 1 the uqmi ipv4 --start-network call fails.

Here is what I am using now:

at+cgdcont?
+CGDCONT: 3,"IPV4V6","","0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0",0,0,0,0

config interface 'wwan'
        option proto 'qmi'
        option device '/dev/cdc-wdm0'
        option apn 'everywhere'
        option auth 'none'
        option profile '3'
        option pdptype 'ipv4v6'

EDIT: During testing I hadn't rebooted the modem after removing +CGDCONT=1,"IP","" which resulted in it working when only profile 3 was configured on the modem. After I rebooted the router I had to readd +CGDCONT=1,"IP","" to get it to connect:

at+cgdcont?
+CGDCONT: 1,"IP","everywhere","0.0.0.0",0,0,0,0
+CGDCONT: 3,"IPV4V6","everywhere","0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0",0,0,0,0

It doesn't matter if I configure the APN on the modem to "everywhere" or leave them blank, both work fine on all three modems presumably because uqmi sets the APN in the --start-network call.

12

Hi

Will it not work if you add the APN in the CGDCONT?

AT+CGDCONT=1,"IPV4V6","everywhere"
13

Still doesn't work:

at+cgdcont?
+CGDCONT: 1,"IPV4V6","everywhere","0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0",0,0,0,0

config interface 'wwan'
        option proto 'qmi'
        option device '/dev/cdc-wdm0'
        option apn 'everywhere'
        option auth 'none'
        option profile '1'
        option pdptype 'ipv4v6'

Fri Mar 18 02:37:16 2022 daemon.notice netifd: Interface 'wwan' is setting up now
Fri Mar 18 02:37:16 2022 daemon.notice netifd: wwan (6799): Waiting for SIM initialization
Fri Mar 18 02:37:17 2022 daemon.notice netifd: wwan (6799): PIN verification is disabled
Fri Mar 18 02:37:18 2022 daemon.notice netifd: wwan (6799): Device does not support 802.3 mode. Informing driver of raw-ip only for wwan0 ..
Fri Mar 18 02:37:18 2022 daemon.notice netifd: wwan (6799): Waiting for network registration
Fri Mar 18 02:37:19 2022 daemon.notice netifd: wwan (6799): Starting network wwan
Fri Mar 18 02:37:20 2022 daemon.notice netifd: wwan (6799): Unable to connect IPv4
Fri Mar 18 02:37:20 2022 daemon.notice netifd: wwan (6897): Stopping network wwan
14

@ashish.kamble005 any updates on the testing? If I'm to fix that issue, I need the feedback.
I'd very much like to include in commit message of a fix, which modem was broken by that.