wda-get-data-format randomly returns error: couldn't create client for the 'wda' service
Brandon Lee
blee0518 at gmail.com
Wed Apr 8 17:46:16 UTC 2020
To add, and in my experience, when changing the data format the assigned
interface needs to be down.
Also, i have sided not to use the `autoconnect` bc i have had intermittent
issues with it.
My method to startup is simple
//
#find your proper sleep time as modem and your system may vary
Sleep 8s
Ifconfig wwan0 down
Sleep 1s
Qmi-network /dev/cdc-wdm0 stop
Qmicli -d /dev/cdc-wdm0 -E raw-ip
Ifconfig wwan0 up
Sleep 1s
Qmi-network /dev/cdc-wdm0 start
#call for dhcp address, i use systemd
Systemcli restart systemd-networkd
//
This method is used as i am not versed in coding. I also through in some 1s
in case any delays in execution. There is also a if statement that shows
the ip addresses and if there is no address it reruns the script 1 time(in
case something failed)
Alek is well versed in qmicli and can correct anything i suggest.
On Wed, Apr 8, 2020, 8:46 AM Aleksander Morgado <aleksander at aleksander.es>
wrote:
> 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
> _______________________________________________
> libqmi-devel mailing list
> libqmi-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/libqmi-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libqmi-devel/attachments/20200408/5d349e37/attachment-0001.htm>
More information about the libqmi-devel
mailing list