wda-get-data-format randomly returns error: couldn't create client for the 'wda' service

Wed Apr 8 15:45:58 UTC 2020

Hey,

> tir. 7. apr. 2020 kl. 17:17 skrev Aleksander Morgado <aleksander at aleksander.es>:
>>
>> > I have some further updates here. I read another thread about the '-p' option,
>> > which, when added to all instances of qmicli invocation in the init.d file makes
>> > the problem go away in at least more than 9 out of 10 cases. So it is
>> > apparently a timing issue. Still have to test this on more than one
>> > system, but I am optimistic. :)
>>
>> The "-p" option, if used, must be used in ALL qmicli commands, so that
>> all use the intermediate qmi-proxy.
>> I wonder what init.d file you're talking about, though?
>
>
> We initialise the modem with this routine (somewhat simplified to illustrate the points):
>
> START_NETWORK_ARGS=apn="internet",ip-type=4,autoconnect=yes
>
> #QMICMD='qmicli -p '
> QMICMD='qmicli '
>
> for DEV in $(find /dev -maxdepth 1 -name "cdc-wdm*" | sort)
> do
>     WANIF=$($QMICMD -d "$DEV" -w)
>     if $QMICMD -d "$DEV" --wds-get-packet-service-status | grep -q status:..connected ; then
>         echo "Stopping as it was already connected $DEV $WANIF"
>         $QMICMD -d "$DEV" --wds-stop-network=disable-autoconnect

That above is not a good way to disconnect if you're manually running
Start Network, see other comments below.

>         ip link set "$WANIF" down 2>&1
>         ip addr flush dev "$WANIF" 2>&1
>         echo "Stopped broadband on $DEV $WANIF to restart connection"
>     fi
>
>     # Does it work at all....?
>     if ! $QMICMD -d "$DEV" --wda-get-data-format ; then
>         echo "Modem does not respond as expected - trying to reset it"
>         # Here we had some code to try various things to get it working, like resetting the usb port it is connected to.
>         # However, following commands could still fail
>     fi
>
>     # Change to 802-3
>     if $QMICMD -d "$DEV" --wda-get-data-format | grep -q 'raw-ip'; then
>         echo "Identified $DEV $WANIF as raw-ip, changing to 802-3"
>         if ! $QMICMD -d "$DEV" --wda-set-data-format=802-3 ; then
>             echo "wda-set-data-format=802-3 failed"

You cannot change data format after having started the connection. In
the logic below you're connecting in 2 different ways (start network
with apn, and autoconnect), but you're only stopping in one way
(autoconnect). It may happen that the set data format fails because
the modem is already connected?

>             exit 1
>         fi
>     else
>         echo "Failed to set $DEV $WANIF data format to 802-3"
>     fi
>
>     # Set up if correct mode
>     if ! $QMICMD -d "$DEV" --wda-get-data-format | grep -q '802-3'; then
>         echo "Modem is not is correct data format mode"

Don't rely on devices supporting all 802.3. All new QMI devices don't
support 802.3, they only support raw-ip. If you're stuck with an older
model, this may be enough though, so just a heads up.

>         exit 1
>     fi
>     echo "Starting broadband on $DEV $WANIF with args '$START_NETWORK_ARGS'"
>     $QMICMD -d "$DEV" --wds-start-network=${START_NETWORK_ARGS:-apn=\"internet\"} --client-no-release-cid
>     $QMICMD -d "$DEV" --wds-set-autoconnect-settings=enabled,roaming-allowed

You're attempting to manually connect with start network and then
enabling autoconnect, and that doesn't make sense, these are 2
different things. Autoconnect will use the "default 3GPP" profile
settings, and the manual start network will try to use whatever
settings you're passing. You should either use one approach or the
other, using both won't work properly I believe.

Also, if you run start network manually, you need to keep track of the
CID you used to connect, and also track of the "connection id"
returned by the command, so that you can then perform the associated
stop network passing the correct cid and the correct connection id.

>     echo "Started broadband on $DEV $WANIF"
>     killall -HUP dhcpcd
>     exit 0 # Done
> done
>
> einfo "Failed to set up broadband adapter"
> exit 1 # Failed
>
> If I use -p it seems to work close to 100% (maybe 100% of the times). Without the script fails too often on the first wda-get-data-format.
>
> (Btw, --wds-start-network also gives an error, but it does not seem to affect anything:
> qmicli -p -d /dev/cdc-wdm0 --wds-start-network=apn=internet,ip-type=4,autoconnect=yes --client-no-release-cid
> error: couldn't start network: QMI protocol error (14): 'CallFailed'
> call end reason (3): generic-no-service
> verbose call end reason (2,210): [internal] pdn-ipv6-call-disallowed
> [/dev/cdc-wdm0] Client ID not released:
>        Service: 'wds'
>            CID: '9')

If start network fails, but anyway you're connected it means the modem
may be setup to autoconnect using the default 3GPP profile (see qmicli
--wds-get-profile-list=3gpp and qmicli
--wds-get-default-profile-num=3gpp). So it is not that it doesn't
affect anything, it's that you may be trying to connect with different
settings to the default ones, and the settings you used explicitly are
failing.

>
> Actually, while writing this mail, I made a new discovery: It looks like if  -wda-get-data-format fails once, for example when running it first without -p, it will keep on failing, even if run with -p later. However, a usb port reset (unbind/bind) will make it work again if I then run with -p directly afterwards.
>
> I have very few clues on what is going on. It could very well be that we are doing something wrong....(?)
>

The use of "-p" just makes all your qmicli requests be forwarded to
the device through an intermediate qmi-proxy process. This is done so
that multiple applications can use the port at the same time for
different commands; either multiple qmicli calls or even different
programs doing different QMI interactions. E.g. you can use the
"Mobile Radio Monitor" program
(https://sigquit.wordpress.com/2013/09/17/mobile-radio-monitor/) at
the same time as ModemManager is managing the device because both
programs use the intermediate proxy. If there is one program using the
proxy, all programs must use it.

If some programs use it and some others don't, the ones not using it
will all fight each other with the qmi-proxy for the access to the QMI
control port.

If you're on doubt on what to do, just use the proxy always always,
and never attempt a qmicli command without using the proxy, as that
will break the comm between the device and the proxy. So, the tests
sometimes trying with "-p" and sometimes without "-p" don't really
make sense because the testing itself is breaking the flow.

Also, a lot of this logic is already handled in the qmi-network
script, I'd suggest you take a look at its source code, it's quite
simple.

Cheers!

-- 
Aleksander
https://aleksander.es