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

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

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 >

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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