Re: problems with QMI dual stack connections from MM - works with qmicli
> If this is a common X55 (or even wider Qualcomm?) problem, then maybe MM > should enforce the profile usage? Or is that baking too much policy > into MM? > It wouldn't be much to enforce internally using profiles when connecting using QMI, if that's the way forward. We really already do that with AT commands by default. Another point of view would be to say that if you want mutiple PDN connections, you should better connect using profiles. We're at the stage of deciding all this, so it's not too late to change whatever we need. -- Aleksander https://aleksander.es ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: problems with QMI dual stack connections from MM - works with qmicli
Aleksander Morgado writes: >> So maybe you'll have better luck using profiles. > > Oh, how convenient, if only we had the ability to connect using > specific existing profile ids with ModemManager... :D (it's already in > git master!) Yes, I will find some time to retest the modem with that auto-SIM stuff enabled, using the new MM profile stuff. But it looks like you should be able to verify it with any X55 modem. Thanks for sharing that, Daniele. The theory that this is somehow related to the modem profile management makes a lot of sense. I find it very likely that this conflicts with Quectel's automatic profile creation, so the everything adds up. If this is a common X55 (or even wider Qualcomm?) problem, then maybe MM should enforce the profile usage? Or is that baking too much policy into MM? Bjørn ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: problems with QMI dual stack connections from MM - works with qmicli
Hey! > > but if I create two profiles: > > $ sudo ./src/qmicli/qmicli -p -d /dev/cdc-wdm0 > --wds-create-profile=3gpp,apn=ibox.tim.it,pdp-type=IP > New profile created: > Profile type: '3gpp' > Profile index: '2' > > $ sudo ./src/qmicli/qmicli -p -d /dev/cdc-wdm0 > --wds-create-profile=3gpp,apn=wap.tim.it,pdp-type=IP > New profile created: > Profile type: '3gpp' > Profile index: '3' > > and make the connection using profiles: > > $ sudo ./src/qmicli/qmicli -p -d /dev/cdc-wdm0 --device-open-sync > --wda-set-data-format=ep-type=hsusb,ep-iface-number=2,link-layer-protocol=raw-ip,ul-protocol=qmapv5,dl-protocol=qmapv5,dl-max-datagrams=32,dl-datagram-max-size=31744 > [/dev/cdc-wdm0] Successfully set data format > QoS flow header: no > Link layer protocol: 'raw-ip' >Uplink data aggregation protocol: 'qmapv5' > Downlink data aggregation protocol: 'qmapv5' > NDP signature: '0' > Downlink data aggregation max datagrams: '32' > Downlink data aggregation max size: '16384' > > $ sudo ./src/qmicli/qmicli -p -d /dev/cdc-wdm0 --client-no-release-cid > --wds-bind-mux-data-port=mux-id=1,ep-type=hsusb,ep-iface-number=2 > [/dev/cdc-wdm0] Client ID not released: > Service: 'wds' > CID: '17' > > $ sudo ./src/qmicli/qmicli -p -d /dev/cdc-wdm0 --client-no-release-cid > --client-cid=17 --wds-set-ip-family=4 > [/dev/cdc-wdm0] Client ID not released: > Service: 'wds' > CID: '17' > > $ sudo ./src/qmicli/qmicli -p -d /dev/cdc-wdm0 --client-no-release-cid > --client-cid=17 --wds-start-network=3gpp-profile=2 > [/dev/cdc-wdm0] Network started > Packet data handle: '999450704' > [/dev/cdc-wdm0] Client ID not released: > Service: 'wds' > CID: '17' > > $ sudo ./src/qmicli/qmicli -p -d /dev/cdc-wdm0 --client-no-release-cid > --wds-bind-mux-data-port=mux-id=2,ep-type=hsusb,ep-iface-number=2 > [/dev/cdc-wdm0] Client ID not released: > Service: 'wds' > CID: '18' > > $ sudo ./src/qmicli/qmicli -p -d /dev/cdc-wdm0 --client-no-release-cid > --client-cid=18 --wds-set-ip-family=4 > [/dev/cdc-wdm0] Client ID not released: > Service: 'wds' > CID: '18' > > $ sudo ./src/qmicli/qmicli -p -d /dev/cdc-wdm0 --client-no-release-cid > --client-cid=18 --wds-start-network=3gpp-profile=3 > [/dev/cdc-wdm0] Network started > Packet data handle: '1012176704' > [/dev/cdc-wdm0] Client ID not released: > Service: 'wds' > CID: '18' > > things work! > > So maybe you'll have better luck using profiles. > Oh, how convenient, if only we had the ability to connect using specific existing profile ids with ModemManager... :D (it's already in git master!) -- Aleksander https://aleksander.es ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: problems with QMI dual stack connections from MM - works with qmicli
Hi Bjørn, Il giorno lun 26 apr 2021 alle ore 18:23 Bjørn Mork ha scritto: > > Bjørn Mork writes: > > > Sorry, i do not think these issues are related to ModemManager at all. > > This is a test from freshly booted modem, MM not running: > > root@finn:~# qmicli -p -d /dev/cdc-wdm0 --device-open-sync > --wda-set-data-format=ep-type=hsusb,ep-iface-number=4,link-layer-protocol=raw-ip,ul-protocol=qmapv5,dl-protocol=qmapv5,dl-max-datagrams=32,dl-datagram-max-size=31744 > [/dev/cdc-wdm0] Successfully set data format > QoS flow header: no > Link layer protocol: 'raw-ip' >Uplink data aggregation protocol: 'qmapv5' > Downlink data aggregation protocol: 'qmapv5' > NDP signature: '0' > Downlink data aggregation max datagrams: '32' > Downlink data aggregation max size: '31744' > root@finn:~# qmicli -p -d /dev/cdc-wdm0 --client-no-release-cid > --wds-bind-mux-data-port=mux-id=1,ep-type=hsusb,ep-iface-number=4 > [/dev/cdc-wdm0] Client ID not released: > Service: 'wds' > CID: '15' > root@finn:~# qmicli -p -d /dev/cdc-wdm0 --client-no-release-cid > --client-cid=15 --wds-set-ip-family=4 > [/dev/cdc-wdm0] Client ID not released: > Service: 'wds' > CID: '15' > root@finn:~# qmicli -p -d /dev/cdc-wdm0 --client-no-release-cid > --client-cid=15 --wds-start-network=apn=telenor.smart,ip-type=4 > [/dev/cdc-wdm0] Network started > Packet data handle: '3891631616' > [/dev/cdc-wdm0] Client ID not released: > Service: 'wds' > CID: '15' > root@finn:~# qmicli -p -d /dev/cdc-wdm0 --client-no-release-cid > --wds-bind-mux-data-port=mux-id=1,ep-type=hsusb,ep-iface-number=4 > [/dev/cdc-wdm0] Client ID not released: > Service: 'wds' > CID: '16' > root@finn:~# qmicli -p -d /dev/cdc-wdm0 --client-no-release-cid > --client-cid=16 --wds-set-ip-family=6 > [/dev/cdc-wdm0] Client ID not released: > Service: 'wds' > CID: '16' > root@finn:~# qmicli -p -d /dev/cdc-wdm0 --client-no-release-cid > --client-cid=16 --wds-start-network=apn=telenor.smart,ip-type=6 > [/dev/cdc-wdm0] Network started > Packet data handle: '3891309184' > [/dev/cdc-wdm0] Client ID not released: > Service: 'wds' > CID: '16' > root@finn:~# qmicli -p -d /dev/cdc-wdm0 --client-no-release-cid > --wds-bind-mux-data-port=mux-id=2,ep-type=hsusb,ep-iface-number=4 > [/dev/cdc-wdm0] Client ID not released: > Service: 'wds' > CID: '17' > root@finn:~# qmicli -p -d /dev/cdc-wdm0 --client-no-release-cid > --client-cid=17 --wds-set-ip-family=4 > [/dev/cdc-wdm0] Client ID not released: > Service: 'wds' > CID: '17' > root@finn:~# qmicli -p -d /dev/cdc-wdm0 --client-no-release-cid > --client-cid=17 --wds-start-network=apn=telenor,ip-type=4 > error: couldn't start network: QMI protocol error (14): 'CallFailed' > call end reason (1): generic-unspecified > verbose call end reason (2,236): [internal] call-already-present > [/dev/cdc-wdm0] Client ID not released: > Service: 'wds' > CID: '17' I guess the modem you are using is based on SDX55. Testing with a modem based on the same chipset, I can replicate your issue with just two ipv4 connections: $ sudo ./src/qmicli/qmicli -p -d /dev/cdc-wdm0 --device-open-sync --wda-set-data-format=ep-type=hsusb,ep-iface-number=2,link-layer-protocol=raw-ip,ul-protocol=qmapv5,dl-protocol=qmapv5,dl-max-datagrams=32,dl-datagram-max-size=31744 [/dev/cdc-wdm0] Successfully set data format QoS flow header: no Link layer protocol: 'raw-ip' Uplink data aggregation protocol: 'qmapv5' Downlink data aggregation protocol: 'qmapv5' NDP signature: '0' Downlink data aggregation max datagrams: '32' Downlink data aggregation max size: '16384' $ sudo ./src/qmicli/qmicli -p -d /dev/cdc-wdm0 --client-no-release-cid --wds-bind-mux-data-port=mux-id=1,ep-type=hsusb,ep-iface-number=2 [/dev/cdc-wdm0] Client ID not released: Service: 'wds' CID: '17' $ sudo ./src/qmicli/qmicli -p -d /dev/cdc-wdm0 --client-no-release-cid --client-cid=17 --wds-set-ip-family=4 [/dev/cdc-wdm0] Client ID not released: Service: 'wds' CID: '17' $ sudo ./src/qmicli/qmicli -p -d /dev/cdc-wdm0 --client-no-release-cid --client-cid=17 --wds-start-network=apn=ibox.tim.it,ip-type=4 [/dev/cdc-wdm0] Network started Packet data handle: '4120009568' [/dev/cdc-wdm0] Client ID not released: Service: 'wds' CID: '17' $ sudo ./src/qmicli/qmicli -p -d /dev/cdc-wdm0 --client-no-release-cid --wds-bind-mux-data-port=mux-id=2,ep-type=hsusb,ep-iface-number=2 [/dev/cdc-wdm0] Client ID not released: Service: 'wds' CID: '18' $ sudo ./src/qmicli/qmicli -p -d /dev/cdc-wdm0 --client-no-release-cid --client-cid=18 --wds-set-ip-family=4 [/dev/cdc-wdm0] Client ID not released:
Re: problems with QMI dual stack connections from MM - works with qmicli
Reinhard Speyerer writes: > from the observed behaviour AT+QMBNCFG="AutoSel",1 seems to have a similar > semantics as the Sierra Wireless PRI "AUTO-SIM" feature discussed recently > without the need for a device reboot. Depending on the IMSI and/or other > properties of your SIM AT+CGDCONT entries may be created/overwritten > and certain contexts e.g. for IMS may automatically be activated. > > Obtaining S1AP traces in the network or QCDM logs on the device and checking > the NAS EPS signalling might be a good way to validate your assumption about > the firmware vs APNs above. > > If that doesn't explain the effects observed at the QMI level you could try > AT+QCFG="volte_disable",1 (if it is set to 0) > AT+QMBNCFG="AutoSel",0 > AT+QMBNCFG="Deactivate" > power cycle the modem and check if anything changes. Thanks! That made all the difference! OK, I should have just taken the advice wrt these settings before. Why do they enable this by default? It looks pretty broken. "volte_disable" was set to 0. I guess that explains that "ims" thing? So I never got around to the MBIM testing. But given these results, I assume I would have had similar issues there. This appears to be a Quectel specific configuration problem. Well, back to testing MM without all the modem imposed confusion. Bjørn ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: problems with QMI dual stack connections from MM - works with qmicli
On Tue, Apr 27, 2021 at 02:10:12PM +0200, Bjørn Mork wrote: > Reinhard Speyerer writes: > > > On Mon, Apr 26, 2021 at 06:23:01PM +0200, Bjørn Mork wrote: > >> Bjørn Mork writes: > >> > >> > Sorry, i do not think these issues are related to ModemManager at all. > >> > >> This is a test from freshly booted modem, MM not running: > >> > >> [...] > >> root@finn:~# qmicli -p -d /dev/cdc-wdm0 --client-no-release-cid > >> --client-cid=17 --wds-start-network=apn=telenor,ip-type=4 > >> error: couldn't start network: QMI protocol error (14): 'CallFailed' > >> call end reason (1): generic-unspecified > >> verbose call end reason (2,236): [internal] call-already-present > >> [/dev/cdc-wdm0] Client ID not released: > >> Service: 'wds' > >> CID: '17' > >> root@finn:~# qmicli -p -d /dev/cdc-wdm0 --client-no-release-cid > >> --client-cid=17 --wds-start-network=apn=internet.public,ip-type=4 > >> error: couldn't start network: QMI protocol error (14): 'CallFailed' > >> call end reason (1): generic-unspecified > >> verbose call end reason (2,236): [internal] call-already-present > >> [/dev/cdc-wdm0] Client ID not released: > >> Service: 'wds' > >> CID: '17' > >> [...] > >> > >> I don't think there is much MM can do here. This modem firmware does > >> not work properly with QMAP muxing. Sorry about the confusion I've > >> caused by assuming this would work. > >> > >> Unless I am missing something in the sequence above? > >> > > > > Hi Bjørn, > > > > I'm not sure about the qmap5 vs. qmap part but assuming that none of > > the "problematic" APNs matches the APN assigned to the default bearer > > for EPS attach I would expect for this to be the correct QMI sequence > > to use. > > > > Can you crosscheck with AT+CGDCONT? and AT+CGACT? whether the corresponding > > contexts are really active on the UE as the QMI error suggests? If they are > > the next step would perhaps be to check AT+QMBNCFG="List" for a Telenor > > profile and the AT+QMBNCFG="AutoSel" setting in case you are still using the > > Quectel RM502Q for testing this. > > Thanks. Yes, same modem. I've seen the discussions wrt those Quectel > carrier config files, but sort of ignored it as "doesn't affect me". > But you're of course right that I should verify that assumtion. > > This is the AT command output after repeating the qmicli connections up > to and including the failed "internet.public" connection quoted above: > > > AT+CGDCONT? > +CGDCONT: 1,"IPV4V6","telenor.smart","0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0",0,0,0,0 > +CGDCONT: 2,"IPV4V6","ims","0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0",0,0,0,0 > +CGDCONT: 3,"IPV4V6","sos","0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0",0,0,0,1 > +CGDCONT: 4,"IP","internet.public","0.0.0.0",0,0,0,0 > > OK > AT+CGACT? > +CGACT: 1,1 > +CGACT: 2,1 > +CGACT: 3,0 > +CGACT: 4,0 > > OK > AT+QMBNCFG="List" > +QMBNCFG: "List",0,0,1,"ROW_Commercial",a010809,202001061 > +QMBNCFG: "List",1,0,0,"Telia_Sweden",a012400,201908071 > +QMBNCFG: "List",2,0,0,"TIM_Italy_Commercial",a012b00,201908071 > +QMBNCFG: "List",3,0,0,"France-Commercial-Orange",a010b21,201908071 > +QMBNCFG: "List",4,0,0,"Commercial-DT-VOLTE",a011f1f,201908071 > +QMBNCFG: "List",5,0,0,"UK-VoLTE-Vodafone",a010426,201908071 > +QMBNCFG: "List",6,0,0,"Commercial-EE",a01220b,201908071 > +QMBNCFG: "List",7,0,0,"Optus_Australia_Commercial",a014400,201908071 > +QMBNCFG: "List",8,0,0,"Telstra_Australia_Commercial",a010f00,202007081 > +QMBNCFG: "List",9,0,0,"Commercial-LGU",a012608,201908071 > +QMBNCFG: "List",10,0,0,"Commercial-KT",a01280b,201908071 > +QMBNCFG: "List",11,0,0,"Commercial-SKT",a01270a,201908071 > +QMBNCFG: "List",12,0,0,"Commercial-Reliance",a011b0c,202006011 > +QMBNCFG: "List",13,0,0,"Commercial-SBM",a011c0b,201908071 > +QMBNCFG: "List",14,0,0,"Commercial-KDDI",a010709,201908071 > +QMBNCFG: "List",15,0,0,"Commercial-DCM",a010d0d,201908071 > +QMBNCFG: "List",16,0,0,"VoLTE-CU",a011561,202001061 > +QMBNCFG: "List",17,0,0,"VoLTE_OPNMKT_CT",a0113e0,202001061 > +QMBNCFG: "List",18,0,0,"Volte_OpenMkt-Commercial-CMCC",a012010,202001061 > > OK > AT+QMBNCFG="AutoSel" > +QMBNCFG: "AutoSel",1 > > OK > > > So I think the carrier configuration is "generic" and therefore OK? > > Note that the "internet.public" profile (4) was added after the last > connection test, as a side effect of testing Aleksanders profile > management branch. It doesn't seem to affect the end result though. > > Other than that, I notice that the "ims" profile is connected. That's a > bit surprising to me, as I've never touched that. I guess it could be > an automatic thing from the "ROW_Commercial" config? How would we know? > Or it can be a leftover being configured by the OEM firmware on the > router this modem is stuck in. Although I don't find that very likely. > I like to believe I know which APNs that firmware connects to. > Hi Bjørn, from the observed behaviour AT+QMBNCFG="AutoSel",1 seems to have a similar semantics as the Sierra Wireless PRI "AUTO-SIM"
Re: problems with QMI dual stack connections from MM - works with qmicli
Reinhard Speyerer writes: > On Mon, Apr 26, 2021 at 06:23:01PM +0200, Bjørn Mork wrote: >> Bjørn Mork writes: >> >> > Sorry, i do not think these issues are related to ModemManager at all. >> >> This is a test from freshly booted modem, MM not running: >> >> [...] >> root@finn:~# qmicli -p -d /dev/cdc-wdm0 --client-no-release-cid >> --client-cid=17 --wds-start-network=apn=telenor,ip-type=4 >> error: couldn't start network: QMI protocol error (14): 'CallFailed' >> call end reason (1): generic-unspecified >> verbose call end reason (2,236): [internal] call-already-present >> [/dev/cdc-wdm0] Client ID not released: >> Service: 'wds' >> CID: '17' >> root@finn:~# qmicli -p -d /dev/cdc-wdm0 --client-no-release-cid >> --client-cid=17 --wds-start-network=apn=internet.public,ip-type=4 >> error: couldn't start network: QMI protocol error (14): 'CallFailed' >> call end reason (1): generic-unspecified >> verbose call end reason (2,236): [internal] call-already-present >> [/dev/cdc-wdm0] Client ID not released: >> Service: 'wds' >> CID: '17' >> [...] >> >> I don't think there is much MM can do here. This modem firmware does >> not work properly with QMAP muxing. Sorry about the confusion I've >> caused by assuming this would work. >> >> Unless I am missing something in the sequence above? >> > > Hi Bjørn, > > I'm not sure about the qmap5 vs. qmap part but assuming that none of > the "problematic" APNs matches the APN assigned to the default bearer > for EPS attach I would expect for this to be the correct QMI sequence > to use. > > Can you crosscheck with AT+CGDCONT? and AT+CGACT? whether the corresponding > contexts are really active on the UE as the QMI error suggests? If they are > the next step would perhaps be to check AT+QMBNCFG="List" for a Telenor > profile and the AT+QMBNCFG="AutoSel" setting in case you are still using the > Quectel RM502Q for testing this. Thanks. Yes, same modem. I've seen the discussions wrt those Quectel carrier config files, but sort of ignored it as "doesn't affect me". But you're of course right that I should verify that assumtion. This is the AT command output after repeating the qmicli connections up to and including the failed "internet.public" connection quoted above: AT+CGDCONT? +CGDCONT: 1,"IPV4V6","telenor.smart","0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0",0,0,0,0 +CGDCONT: 2,"IPV4V6","ims","0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0",0,0,0,0 +CGDCONT: 3,"IPV4V6","sos","0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0",0,0,0,1 +CGDCONT: 4,"IP","internet.public","0.0.0.0",0,0,0,0 OK AT+CGACT? +CGACT: 1,1 +CGACT: 2,1 +CGACT: 3,0 +CGACT: 4,0 OK AT+QMBNCFG="List" +QMBNCFG: "List",0,0,1,"ROW_Commercial",a010809,202001061 +QMBNCFG: "List",1,0,0,"Telia_Sweden",a012400,201908071 +QMBNCFG: "List",2,0,0,"TIM_Italy_Commercial",a012b00,201908071 +QMBNCFG: "List",3,0,0,"France-Commercial-Orange",a010b21,201908071 +QMBNCFG: "List",4,0,0,"Commercial-DT-VOLTE",a011f1f,201908071 +QMBNCFG: "List",5,0,0,"UK-VoLTE-Vodafone",a010426,201908071 +QMBNCFG: "List",6,0,0,"Commercial-EE",a01220b,201908071 +QMBNCFG: "List",7,0,0,"Optus_Australia_Commercial",a014400,201908071 +QMBNCFG: "List",8,0,0,"Telstra_Australia_Commercial",a010f00,202007081 +QMBNCFG: "List",9,0,0,"Commercial-LGU",a012608,201908071 +QMBNCFG: "List",10,0,0,"Commercial-KT",a01280b,201908071 +QMBNCFG: "List",11,0,0,"Commercial-SKT",a01270a,201908071 +QMBNCFG: "List",12,0,0,"Commercial-Reliance",a011b0c,202006011 +QMBNCFG: "List",13,0,0,"Commercial-SBM",a011c0b,201908071 +QMBNCFG: "List",14,0,0,"Commercial-KDDI",a010709,201908071 +QMBNCFG: "List",15,0,0,"Commercial-DCM",a010d0d,201908071 +QMBNCFG: "List",16,0,0,"VoLTE-CU",a011561,202001061 +QMBNCFG: "List",17,0,0,"VoLTE_OPNMKT_CT",a0113e0,202001061 +QMBNCFG: "List",18,0,0,"Volte_OpenMkt-Commercial-CMCC",a012010,202001061 OK AT+QMBNCFG="AutoSel" +QMBNCFG: "AutoSel",1 OK So I think the carrier configuration is "generic" and therefore OK? Note that the "internet.public" profile (4) was added after the last connection test, as a side effect of testing Aleksanders profile management branch. It doesn't seem to affect the end result though. Other than that, I notice that the "ims" profile is connected. That's a bit surprising to me, as I've never touched that. I guess it could be an automatic thing from the "ROW_Commercial" config? How would we know? Or it can be a leftover being configured by the OEM firmware on the router this modem is stuck in. Although I don't find that very likely. I like to believe I know which APNs that firmware connects to. Bjørn ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: problems with QMI dual stack connections from MM - works with qmicli
On Mon, Apr 26, 2021 at 06:23:01PM +0200, Bjørn Mork wrote: > Bjørn Mork writes: > > > Sorry, i do not think these issues are related to ModemManager at all. > > This is a test from freshly booted modem, MM not running: > > [...] > root@finn:~# qmicli -p -d /dev/cdc-wdm0 --client-no-release-cid > --client-cid=17 --wds-start-network=apn=telenor,ip-type=4 > error: couldn't start network: QMI protocol error (14): 'CallFailed' > call end reason (1): generic-unspecified > verbose call end reason (2,236): [internal] call-already-present > [/dev/cdc-wdm0] Client ID not released: > Service: 'wds' > CID: '17' > root@finn:~# qmicli -p -d /dev/cdc-wdm0 --client-no-release-cid > --client-cid=17 --wds-start-network=apn=internet.public,ip-type=4 > error: couldn't start network: QMI protocol error (14): 'CallFailed' > call end reason (1): generic-unspecified > verbose call end reason (2,236): [internal] call-already-present > [/dev/cdc-wdm0] Client ID not released: > Service: 'wds' > CID: '17' > [...] > > I don't think there is much MM can do here. This modem firmware does > not work properly with QMAP muxing. Sorry about the confusion I've > caused by assuming this would work. > > Unless I am missing something in the sequence above? > Hi Bjørn, I'm not sure about the qmap5 vs. qmap part but assuming that none of the "problematic" APNs matches the APN assigned to the default bearer for EPS attach I would expect for this to be the correct QMI sequence to use. Can you crosscheck with AT+CGDCONT? and AT+CGACT? whether the corresponding contexts are really active on the UE as the QMI error suggests? If they are the next step would perhaps be to check AT+QMBNCFG="List" for a Telenor profile and the AT+QMBNCFG="AutoSel" setting in case you are still using the Quectel RM502Q for testing this. Regards, Reinhard ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: problems with QMI dual stack connections from MM - works with qmicli
Bjørn Mork writes: > Sorry, i do not think these issues are related to ModemManager at all. This is a test from freshly booted modem, MM not running: root@finn:~# qmicli -p -d /dev/cdc-wdm0 --device-open-sync --wda-set-data-format=ep-type=hsusb,ep-iface-number=4,link-layer-protocol=raw-ip,ul-protocol=qmapv5,dl-protocol=qmapv5,dl-max-datagrams=32,dl-datagram-max-size=31744 [/dev/cdc-wdm0] Successfully set data format QoS flow header: no Link layer protocol: 'raw-ip' Uplink data aggregation protocol: 'qmapv5' Downlink data aggregation protocol: 'qmapv5' NDP signature: '0' Downlink data aggregation max datagrams: '32' Downlink data aggregation max size: '31744' root@finn:~# qmicli -p -d /dev/cdc-wdm0 --client-no-release-cid --wds-bind-mux-data-port=mux-id=1,ep-type=hsusb,ep-iface-number=4 [/dev/cdc-wdm0] Client ID not released: Service: 'wds' CID: '15' root@finn:~# qmicli -p -d /dev/cdc-wdm0 --client-no-release-cid --client-cid=15 --wds-set-ip-family=4 [/dev/cdc-wdm0] Client ID not released: Service: 'wds' CID: '15' root@finn:~# qmicli -p -d /dev/cdc-wdm0 --client-no-release-cid --client-cid=15 --wds-start-network=apn=telenor.smart,ip-type=4 [/dev/cdc-wdm0] Network started Packet data handle: '3891631616' [/dev/cdc-wdm0] Client ID not released: Service: 'wds' CID: '15' root@finn:~# qmicli -p -d /dev/cdc-wdm0 --client-no-release-cid --wds-bind-mux-data-port=mux-id=1,ep-type=hsusb,ep-iface-number=4 [/dev/cdc-wdm0] Client ID not released: Service: 'wds' CID: '16' root@finn:~# qmicli -p -d /dev/cdc-wdm0 --client-no-release-cid --client-cid=16 --wds-set-ip-family=6 [/dev/cdc-wdm0] Client ID not released: Service: 'wds' CID: '16' root@finn:~# qmicli -p -d /dev/cdc-wdm0 --client-no-release-cid --client-cid=16 --wds-start-network=apn=telenor.smart,ip-type=6 [/dev/cdc-wdm0] Network started Packet data handle: '3891309184' [/dev/cdc-wdm0] Client ID not released: Service: 'wds' CID: '16' root@finn:~# qmicli -p -d /dev/cdc-wdm0 --client-no-release-cid --wds-bind-mux-data-port=mux-id=2,ep-type=hsusb,ep-iface-number=4 [/dev/cdc-wdm0] Client ID not released: Service: 'wds' CID: '17' root@finn:~# qmicli -p -d /dev/cdc-wdm0 --client-no-release-cid --client-cid=17 --wds-set-ip-family=4 [/dev/cdc-wdm0] Client ID not released: Service: 'wds' CID: '17' root@finn:~# qmicli -p -d /dev/cdc-wdm0 --client-no-release-cid --client-cid=17 --wds-start-network=apn=telenor,ip-type=4 error: couldn't start network: QMI protocol error (14): 'CallFailed' call end reason (1): generic-unspecified verbose call end reason (2,236): [internal] call-already-present [/dev/cdc-wdm0] Client ID not released: Service: 'wds' CID: '17' root@finn:~# qmicli -p -d /dev/cdc-wdm0 --client-no-release-cid --client-cid=17 --wds-start-network=apn=internet.public,ip-type=4 error: couldn't start network: QMI protocol error (14): 'CallFailed' call end reason (1): generic-unspecified verbose call end reason (2,236): [internal] call-already-present [/dev/cdc-wdm0] Client ID not released: Service: 'wds' CID: '17' root@finn:~# qmicli -p -d /dev/cdc-wdm0 --client-no-release-cid --client-cid=17 --wds-bind-mux-data-port=mux-id=2,ep-type=hsusb,ep-iface-number=4 [/dev/cdc-wdm0] Client ID not released: Service: 'wds' CID: '17' root@finn:~# qmicli -p -d /dev/cdc-wdm0 --client-no-release-cid --client-cid=17 --wds-start-network=apn=internet.public,ip-type=4 error: couldn't start network: QMI protocol error (14): 'CallFailed' call end reason (1): generic-unspecified verbose call end reason (2,236): [internal] call-already-present [/dev/cdc-wdm0] Client ID not released: Service: 'wds' CID: '17' root@finn:~# qmicli -p -d /dev/cdc-wdm0 --client-no-release-cid --client-cid=17 --wds-set-ip-family=6 [/dev/cdc-wdm0] Client ID not released: Service: 'wds' CID: '17' root@finn:~# qmicli -p -d /dev/cdc-wdm0 --client-no-release-cid --client-cid=17 --wds-start-network=apn=tdt2.telenor.smart,ip-type=6 [/dev/cdc-wdm0] Network started Packet data handle: '3891374016' [/dev/cdc-wdm0] Client ID not released: Service: 'wds' CID: '17' I don't think there is much MM can do here. This modem firmware does not work properly with QMAP muxing. Sorry about the confusion I've caused by assuming this would work. Unless I am missing something in the sequence above? I'll switch the firmware to MBIM and see how that goes. I hear it's the future anyway :-) Bjørn ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: problems with QMI dual stack connections from MM - works with qmicli
Aleksander Morgado writes:
>> Some observations:
>>
>> - dual-stack fails if default bearer is connected as ipv4 only
>
> Oh, but this is expected, isn't it? or is it not expected? I have
> always assumed that to be the case.
Yes, I guess it is expected. It was mostly the APN change that
surprised me, complicating this further. But I do see how that makes
sense, and ideally the default APNs should all be dual-stack.
>> - default bearer APN changes when switching SIMs (to SIM defined APN?)
>
> Is the module switching carrier config as well when switching SIMs?
I tested with SIMs from the same carrier, but with quite different
profiles. One was a disabled "Fixed Wireless Access" SIM I got with
this used router (The SIM slots are hidden behind a cover, and the
seller probably didn't even know about it :-) This SIM is not accepted
by the network, so there is no default bearer connected. Our FWA thingy
does not currently support IPv6 (embarrassing). So any APN hints will
probably point to IPv4 only APNs.
The other SIM is an old "Mobile Broadband" SIM, predating our IPv6 setup
by years. If it has any APN hints, then those are alsp IPv4 only.
So it's not surprising to me that the SIM switch causes this issue. It
just wasn't something I thought about before it happened. Actually, it
took me a while to notice when dual-stack stopped working after a SIM
switch.
> Please note that ModemManager has 2 different sets of settings for the
> initial APN: the settings stored in the modem (either provided by
> carrier config or set by user manually) and also the real settings
> reported by the network once it's registered. E.g. the modem may ask
> for APN "internet" and the network may successfully register the
> device with APN ("data") instead. mmcli should show both these things
> separately; the real network status settings will be reported as a
> separate bearer object.
Yes, I believe this works perfectly. The modem profile is reset to
ipv4v6 and empty ("") APN when switching SIM. The connected bearer is
reported as ipv4 and APN "telenor.mbb". This is an IPv4 only APN that
could very well be a network default for that SIM.
If I manually configure the default bearer modem profile to use the dual
stack APN "telenor.smart", then it is used and the bearer is reported as
ipv4v6.
>> - connecting multiple ipv4 or dual-stack bearers fails
>
> Wait, it doesn't fail for me here, as long as I use ip-type=ipv4
> explicitly for example.
OK, I have to retry this in a clean enviroment.
> I haven't been able to test multiple dual-stack here yet; my network
> operator allows me to use multiple IPv4 APNs but no IPv6, and I still
> don't know how to configure more than one IPv4v6 APNs in my home LTE
>
I am lucky enough to know a few APNs that are meant to address specific
PGWs. Which multiplies the number of APNs by the totalt number of PGWs.
I have no home LTE network, though. Guess that should be part of the
Corona home office setup :-)
> There is one additional thing you didn't test, and I don't know if it
> would be useful for you or not. See this MR here:
> https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/merge_requests/477
> That branch allows querying/modifying/deleting connection profile
> settings in devices, and it also allows requesting a connection
> through a specific profile. The WDS Start Network, in this case, just
> references the profile id that should be connected.
Will test. So far I've just used AT commands to configure the default
bearer profile and left the rest untouched.
Bjørn
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: problems with QMI dual stack connections from MM - works with qmicli
Hey,
> >> > Well, the direct reason is clear from the log: We skip the
> >> > CONNECT_STEP_IP_FAMILY_IPV4 step for bearer2+. So we can connect
> >> > multiple IPv6 bearers after the first one. Just not any IPv4 or
> >> > dual-stack.
> >>
> >> OK, an extra debug line proves that this is because of the only possible
> >> reason: ctx->no_ip_family_preference is TRUE on the second bearer
> >>
> >> But how did that happen?
> >>
> >
> > I assume you're testing this by running mmcli --simple-connect without
> > using an explicit ip-type in the connection settings?
>
> Yes, this explains that part.
>
> > The no_ip_family_preference flag was originally implemented to allow
> > running WDS Start Network without the explicit IP Family Preference
> > TLV, to cover old devices that would not support that TLV yet. So, if
> > no explicit IP type is requested during connection, we would skip
> > adding that TLV.
> >
> > The logic was later updated to skip running the WDS Set IP Family
> > command following the same reason, i.e. if no IP type was requested as
> > input. This additional check could probably be skipped and we should
> > always always try to run this command, and just ignore the error if it
> > fails with an unsupported error or something.
> >
> > So, if you're attempting to connect the IPv4-only context by skipping
> > the ip-type connection setting, this issue would be triggered. I
> > cannot reproduce the issue if I consistently use ip-type=ipv4 when
> > wanting to connect to IPv4-only.
> >
> > I believe this should change though, but I'm not sure how. Maybe we
> > should remove altogether the no_ip_family_preference flag; I don't
> > recall when this was implemented (back in 2012) whether adding the TLV
> > to the Start Network command would break the connection attempt on
> > modems not supporting it, or just if it would silently ignore it. I'm
> > going to test with the oldest QMI devices I have around and see what
> > happens.
>
> The QMI connection logic has always been fragile and over-complicated.
> And it's not our fault. The firmware implemetation is fragile and
> over-complicated.
>
> I've been trying to come up with a procedure which is consistently
> working for me on this *one* modern modem over the weekend. And
> failed. I am starting to wonder if we can make this work..
>
> Some observations:
>
> - dual-stack fails if default bearer is connected as ipv4 only
Oh, but this is expected, isn't it? or is it not expected? I have
always assumed that to be the case.
> - default bearer APN changes when switching SIMs (to SIM defined APN?)
Is the module switching carrier config as well when switching SIMs?
Please note that ModemManager has 2 different sets of settings for the
initial APN: the settings stored in the modem (either provided by
carrier config or set by user manually) and also the real settings
reported by the network once it's registered. E.g. the modem may ask
for APN "internet" and the network may successfully register the
device with APN ("data") instead. mmcli should show both these things
separately; the real network status settings will be reported as a
separate bearer object.
> - connecting multiple ipv4 or dual-stack bearers fails
Wait, it doesn't fail for me here, as long as I use ip-type=ipv4
explicitly for example.
I haven't been able to test multiple dual-stack here yet; my network
operator allows me to use multiple IPv4 APNs but no IPv6, and I still
don't know how to configure more than one IPv4v6 APNs in my home LTE
network :D
> - connecting multiple ipv6 bearers works
>
> This is with commit 1fce03879e28 ("trying to move indication setup")
>
> Multiple ipv4 bearers works for me on commit f17095045187 ("port-qmi:
> fix WITH_QRTR check")
>
> I am unable to make any sense out of this, and am seriously considering
> just switching to MBIM and forgetting about this Qualcomm firmware mess
> ;-)
>
> Sorry, i do not think these issues are related to ModemManager at all.
>
The connection logic was really complex before adding the multiplexing
support already, it is much more complex now, and it's even more
complex for the setup in Qualcomm SoCs...
There is one additional thing you didn't test, and I don't know if it
would be useful for you or not. See this MR here:
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/merge_requests/477
That branch allows querying/modifying/deleting connection profile
settings in devices, and it also allows requesting a connection
through a specific profile. The WDS Start Network, in this case, just
references the profile id that should be connected.
--
Aleksander
https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: problems with QMI dual stack connections from MM - works with qmicli
Aleksander Morgado writes:
> Hey,
>
>> > Well, the direct reason is clear from the log: We skip the
>> > CONNECT_STEP_IP_FAMILY_IPV4 step for bearer2+. So we can connect
>> > multiple IPv6 bearers after the first one. Just not any IPv4 or
>> > dual-stack.
>>
>> OK, an extra debug line proves that this is because of the only possible
>> reason: ctx->no_ip_family_preference is TRUE on the second bearer
>>
>> But how did that happen?
>>
>
> I assume you're testing this by running mmcli --simple-connect without
> using an explicit ip-type in the connection settings?
Yes, this explains that part.
> The no_ip_family_preference flag was originally implemented to allow
> running WDS Start Network without the explicit IP Family Preference
> TLV, to cover old devices that would not support that TLV yet. So, if
> no explicit IP type is requested during connection, we would skip
> adding that TLV.
>
> The logic was later updated to skip running the WDS Set IP Family
> command following the same reason, i.e. if no IP type was requested as
> input. This additional check could probably be skipped and we should
> always always try to run this command, and just ignore the error if it
> fails with an unsupported error or something.
>
> So, if you're attempting to connect the IPv4-only context by skipping
> the ip-type connection setting, this issue would be triggered. I
> cannot reproduce the issue if I consistently use ip-type=ipv4 when
> wanting to connect to IPv4-only.
>
> I believe this should change though, but I'm not sure how. Maybe we
> should remove altogether the no_ip_family_preference flag; I don't
> recall when this was implemented (back in 2012) whether adding the TLV
> to the Start Network command would break the connection attempt on
> modems not supporting it, or just if it would silently ignore it. I'm
> going to test with the oldest QMI devices I have around and see what
> happens.
The QMI connection logic has always been fragile and over-complicated.
And it's not our fault. The firmware implemetation is fragile and
over-complicated.
I've been trying to come up with a procedure which is consistently
working for me on this *one* modern modem over the weekend. And
failed. I am starting to wonder if we can make this work..
Some observations:
- dual-stack fails if default bearer is connected as ipv4 only
- default bearer APN changes when switching SIMs (to SIM defined APN?)
- connecting multiple ipv4 or dual-stack bearers fails
- connecting multiple ipv6 bearers works
This is with commit 1fce03879e28 ("trying to move indication setup")
Multiple ipv4 bearers works for me on commit f17095045187 ("port-qmi:
fix WITH_QRTR check")
I am unable to make any sense out of this, and am seriously considering
just switching to MBIM and forgetting about this Qualcomm firmware mess
;-)
Sorry, i do not think these issues are related to ModemManager at all.
Bjørn
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: problems with QMI dual stack connections from MM - works with qmicli
Hey, > > Well, the direct reason is clear from the log: We skip the > > CONNECT_STEP_IP_FAMILY_IPV4 step for bearer2+. So we can connect > > multiple IPv6 bearers after the first one. Just not any IPv4 or > > dual-stack. > > OK, an extra debug line proves that this is because of the only possible > reason: ctx->no_ip_family_preference is TRUE on the second bearer > > But how did that happen? > I assume you're testing this by running mmcli --simple-connect without using an explicit ip-type in the connection settings? The no_ip_family_preference flag was originally implemented to allow running WDS Start Network without the explicit IP Family Preference TLV, to cover old devices that would not support that TLV yet. So, if no explicit IP type is requested during connection, we would skip adding that TLV. The logic was later updated to skip running the WDS Set IP Family command following the same reason, i.e. if no IP type was requested as input. This additional check could probably be skipped and we should always always try to run this command, and just ignore the error if it fails with an unsupported error or something. So, if you're attempting to connect the IPv4-only context by skipping the ip-type connection setting, this issue would be triggered. I cannot reproduce the issue if I consistently use ip-type=ipv4 when wanting to connect to IPv4-only. I believe this should change though, but I'm not sure how. Maybe we should remove altogether the no_ip_family_preference flag; I don't recall when this was implemented (back in 2012) whether adding the TLV to the Start Network command would break the connection attempt on modems not supporting it, or just if it would silently ignore it. I'm going to test with the oldest QMI devices I have around and see what happens. -- Aleksander https://aleksander.es ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: problems with QMI dual stack connections from MM - works with qmicli
Bjørn Mork writes: > Well, the direct reason is clear from the log: We skip the > CONNECT_STEP_IP_FAMILY_IPV4 step for bearer2+. So we can connect > multiple IPv6 bearers after the first one. Just not any IPv4 or > dual-stack. OK, an extra debug line proves that this is because of the only possible reason: ctx->no_ip_family_preference is TRUE on the second bearer But how did that happen? Bjørn ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: problems with QMI dual stack connections from MM - works with qmicli
Well, the direct reason is clear from the log: We skip the CONNECT_STEP_IP_FAMILY_IPV4 step for bearer2+. So we can connect multiple IPv6 bearers after the first one. Just not any IPv4 or dual-stack. Still clueless wrt the underlying problem. Bjørn ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: problems with QMI dual stack connections from MM - works with qmicli
Hey, > FYI, dual stack works after reordering the connection sequence a bit: > Nice! Thanks for fixing that. I've also updated your MR in gitlab with an additional fix to handle the proper WDS client allocation in the different muxed bearers; which was a huge oversight... I'll have to start testing the multi pdn setup with 2 IPv4 contexts instead of one IPv4 and the other IPv6 :D > > root@finn:/# mmcli -b 1 > > General| path: /org/freedesktop/ModemManager1/Bearer/1 > | type: default > > Status | connected: yes > | suspended: no > |multiplexed: yes > | interface: qmimux0 > | ip timeout: 20 > > Properties |apn: telenor.smart > |roaming: allowed > |ip type: ipv4v6 > > IPv4 configuration | method: static > |address: 10.205.79.109 > | prefix: 30 > |gateway: 10.205.79.110 > |dns: 193.213.112.4, 130.67.15.198 > |mtu: 1500 > > IPv6 configuration | method: static > |address: 2a02:2121:286:1ec2:19e4:7b6a:1fe2:de07 > | prefix: 64 > |gateway: 2a02:2121:286:1ec2:a550:56eb:e806:5a4e > |dns: 2001:4600:4:fff::52, > 2001:4600:4:1fff::52 > |mtu: 1540 > > Statistics | duration: 900 > | bytes rx: 9926 > | bytes tx: 11654 > | attempts: 1 > | total-duration: 900 > | total-bytes rx: 9926 > | total-bytes tx: 11654 > > > > Bjørn > ___ > ModemManager-devel mailing list > ModemManager-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel -- Aleksander https://aleksander.es ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: problems with QMI dual stack connections from MM - works with qmicli
FYI, dual stack works after reordering the connection sequence a bit: root@finn:/# mmcli -b 1 General| path: /org/freedesktop/ModemManager1/Bearer/1 | type: default Status | connected: yes | suspended: no |multiplexed: yes | interface: qmimux0 | ip timeout: 20 Properties |apn: telenor.smart |roaming: allowed |ip type: ipv4v6 IPv4 configuration | method: static |address: 10.205.79.109 | prefix: 30 |gateway: 10.205.79.110 |dns: 193.213.112.4, 130.67.15.198 |mtu: 1500 IPv6 configuration | method: static |address: 2a02:2121:286:1ec2:19e4:7b6a:1fe2:de07 | prefix: 64 |gateway: 2a02:2121:286:1ec2:a550:56eb:e806:5a4e |dns: 2001:4600:4:fff::52, 2001:4600:4:1fff::52 |mtu: 1540 Statistics | duration: 900 | bytes rx: 9926 | bytes tx: 11654 | attempts: 1 | total-duration: 900 | total-bytes rx: 9926 | total-bytes tx: 11654 Bjørn ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: problems with QMI dual stack connections from MM - works with qmicli
Bjørn Mork writes: > But this works: Except for the minor detail that qmapv5 won't work with the muxing in qmi_wwan. Which I believe is fine, as that muxing solution is deprecated anyway. But MM still needs to be aware, and change the protocol to qmap when using the qmi_wwan muxing. Verified dual-stack connection over qmi_wwan mux: root@finn:~# qmicli -p -d /dev/cdc-wdm0 --device-open-sync --wda-set-data-format=ep-type=hsusb,ep-iface-number=4,link-layer-protocol=raw-ip,ul-protocol=qmap,dl-protocol=qmap,dl-max-datagrams=32,dl-datagram-max-size=31744 [/dev/cdc-wdm0] Successfully set data format QoS flow header: no Link layer protocol: 'raw-ip' Uplink data aggregation protocol: 'qmap' Downlink data aggregation protocol: 'qmap' NDP signature: '0' Downlink data aggregation max datagrams: '32' Downlink data aggregation max size: '31744' root@finn:~# echo 1 >/sys/class/net/wwan0/qmi/add_mux root@finn:~# ifconfig wwan0 up root@finn:~# ifconfig wwan0 mtu 32333 root@finn:~# qmicli -p -d /dev/cdc-wdm0 --client-no-release-cid --wds-bind-mux-data-port=mux-id=1,ep-type=hsusb,ep-iface-number=4 [/dev/cdc-wdm0] Client ID not released: Service: 'wds' CID: '15' root@finn:~# qmicli -p -d /dev/cdc-wdm0 --client-no-release-cid --client-cid=15 --wds-set-ip-family=4 [/dev/cdc-wdm0] Client ID not released: Service: 'wds' CID: '15' root@finn:~# qmicli -p -d /dev/cdc-wdm0 --client-no-release-cid --client-cid=15 --wds-start-network=apn=telenor.smart,ip-type=4 [/dev/cdc-wdm0] Network started Packet data handle: '4275927056' [/dev/cdc-wdm0] Client ID not released: Service: 'wds' CID: '15' root@finn:~# qmicli -p -d /dev/cdc-wdm0 --client-no-release-cid --wds-bind-mux-data-port=mux-id=1,ep-type=hsusb,ep-iface-number=4 [/dev/cdc-wdm0] Client ID not released: Service: 'wds' CID: '16' root@finn:~# qmicli -p -d /dev/cdc-wdm0 --client-no-release-cid --client-cid=16 --wds-set-ip-family=6 [/dev/cdc-wdm0] Client ID not released: Service: 'wds' CID: '16' root@finn:~# qmicli -p -d /dev/cdc-wdm0 --client-no-release-cid --client-cid=16 --wds-start-network=apn=telenor.smart,ip-type=6 [/dev/cdc-wdm0] Network started Packet data handle: '4277618480' [/dev/cdc-wdm0] Client ID not released: Service: 'wds' CID: '16' root@finn:~# qmicli -p -d /dev/cdc-wdm0 --client-no-release-cid --client-cid=16 --wds-get-current-settings [/dev/cdc-wdm0] Current settings retrieved: IP Family: IPv6 IPv6 address: 2a02:2121:286:1ec2:65b9:c9a9:2c9c:4a29/64 IPv6 gateway address: 2a02:2121:286:1ec2:a550:56eb:e806:5a4e/64 IPv6 primary DNS: 2001:4600:4:fff::52 IPv6 secondary DNS: 2001:4600:4:1fff::52 MTU: 1540 Domains: none [/dev/cdc-wdm0] Client ID not released: Service: 'wds' CID: '16' root@finn:~# qmicli -p -d /dev/cdc-wdm0 --client-no-release-cid --client-cid=15 --wds-get-current-settings [/dev/cdc-wdm0] Current settings retrieved: IP Family: IPv4 IPv4 address: 10.205.79.109 IPv4 subnet mask: 255.255.255.252 IPv4 gateway address: 10.205.79.110 IPv4 primary DNS: 193.213.112.4 IPv4 secondary DNS: 130.67.15.198 MTU: 1500 Domains: none [/dev/cdc-wdm0] Client ID not released: Service: 'wds' CID: '15' root@finn:~# ifconfig qmimux0 10.205.79.109 netmask 255.255.255.252 up root@finn:~# ip addr add 2a02:2121:286:1ec2:65b9:c9a9:2c9c:4a29/64 dev qmimux0 root@finn:~# ip route add 148.122.164.253 dev qmimux0 root@finn:~# ip route add 2001:4600:4:fff::52 dev qmimux0 root@finn:~# ping 148.122.164.253 PING 148.122.164.253 (148.122.164.253): 56 data bytes 64 bytes from 148.122.164.253: seq=0 ttl=60 time=181.303 ms 64 bytes from 148.122.164.253: seq=1 ttl=60 time=41.434 ms 64 bytes from 148.122.164.253: seq=2 ttl=60 time=41.432 ms 64 bytes from 148.122.164.253: seq=3 ttl=60 time=52.427 ms ^C --- 148.122.164.253 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max = 41.432/79.149/181.303 ms root@finn:~# ping 2001:4600:4:fff::52 PING 2001:4600:4:fff::52 (2001:4600:4:fff::52): 56 data bytes 64 bytes from 2001:4600:4:fff::52: seq=0 ttl=60 time=186.993 ms 64 bytes from 2001:4600:4:fff::52: seq=1 ttl=60 time=41.186 ms 64 bytes from 2001:4600:4:fff::52: seq=2 ttl=60 time=43.383 ms 64 bytes from 2001:4600:4:fff::52: seq=3 ttl=60 time=68.383 ms ^C --- 2001:4600:4:fff::52 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max = 41.186/84.986/186.993 ms ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
