wda-get-data-format randomly returns error: couldn't create client for the 'wda' service
Dan Williams
dcbw at redhat.com
Tue Apr 14 19:17:53 UTC 2020
On Tue, 2020-04-14 at 19:59 +0200, Tor Rune Skoglund wrote:
> Hi Aleksander,
>
> thank you very much for your suggestions. It has helped us a lot to
> understand more on what is happening.
>
> I have tried to simplify and test the manual connection procedure.
> It
> seems that the way autoconnect was used before messed up things, as
> you
> suggested.
>
> We still have issues getting connected using manual-only, which I
> think
> *should* work. This is on a newly booted system and no software has
> yet
> been run on the interface, so it should be in a "cleanly booted"
> stage:
>
> # Checking that we are not connected and that autoconnect is not
> enabled
> $ qmicli -d /dev/cdc-wdm0 --wds-get-packet-service-status
> [/dev/cdc-wdm0] Connection status: 'disconnected'
> $ qmicli -d /dev/cdc-wdm0 --wds-get-autoconnect-settings
> Autoconnect settings retrieved:
> Status: 'disabled'
> Roaming: 'allowed'
> # Seems OK
>
> # Check which data format we have
> $ qmicli -d /dev/cdc-wdm0 --wda-get-data-format
> [/dev/cdc-wdm0] Successfully got data format
> QoS flow header: no
> Link layer protocol: 'raw-ip'
> Uplink data aggregation protocol: 'disabled'
> Downlink data aggregation protocol: 'disabled'
> NDP signature: '0'
> Uplink data aggregation max size: '0'
> Downlink data aggregation max size: '0'
>
> # Change to 802-3
> $ qmicli -d /dev/cdc-wdm0 --wda-set-data-format=802-3
> [/dev/cdc-wdm0] Successfully set data format
> QoS flow header: no
> Link layer protocol: '802-3'
> Uplink data aggregation protocol: 'disabled'
> Downlink data aggregation protocol: 'disabled'
> NDP signature: '0'
> Downlink data aggregation max datagrams: '0'
> Downlink data aggregation max size: '0'
If you really need to switch to 802-3 mode, OK. But that needs ot
happen on both ends: QMI (eg what the firmware expects) and the kernel
. This command only changes one (firmware).
You also need to change the kernel side with --set-expected-data-
format=<same>. Both need to agree.
qmicli will try to do this for you, but as you see below it fails.
In any case, try both the --wda-set-data-format and --set-expected-
data-format.
If that works, then we can move on to the pdn-ipv6-call-disallowed
issue. For that, please add the "-v" flag (for verbose mode) when
calling --wds-start-network so we can see the actual QMI commands
passed to the device.
Maybe it was asked before, but what qmicli version are you using?
Dan
> # Seemed to work.
> # Just check again to be sure
> $ qmicli -d /dev/cdc-wdm0 --wda-get-data-format
> [/dev/cdc-wdm0] Successfully got data format
> QoS flow header: no
> Link layer protocol: '802-3'
> Uplink data aggregation protocol: 'disabled'
> Downlink data aggregation protocol: 'disabled'
> NDP signature: '0'
> Uplink data aggregation max size: '0'
> Downlink data aggregation max size: '0'
>
> # Start the network manually
> $ qmicli -d /dev/cdc-wdm0 --wds-start-network=apn=internet,ip-type=4
> --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'
> # Failed with exit code 1 and no handle returned
>
> Any idea why this fails?
>
> Btw, we also tried the qmi-network script, which fails similarly:
>
> $ qmi-network /dev/cdc-wdm0 start
> Loading profile at /etc/qmi-network.conf...
> APN: internet
> APN user: unset
> APN password: unset
> qmi-proxy: yes
> Checking data format with 'qmicli -d /dev/cdc-wdm0 --wda-get-data-
> format
> --device-open-proxy'...
> Device link layer protocol retrieved: raw-ip
> Getting expected data format with 'qmicli -d /dev/cdc-wdm0
> --get-expected-data-format'...
> Expected link layer protocol retrieved: 802-3
> Updating kernel link layer protocol with 'qmicli -d /dev/cdc-wdm0
> --set-expected-data-format=raw-ip'...
> error: cannot set expected data format: Expected data format not
> updated
> properly to 'raw-ip': got '802-3' instead
> Error updating kernel link layer protocol
> Starting network with 'qmicli -d /dev/cdc-wdm0
> --wds-start-network=apn='internet' --client-no-release-cid
> --device-open-proxy'...
> 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
> Saving state at /tmp/qmi-network-state-cdc-wdm0... (CID: 9)
> error: network start failed, no packet data handle
> Clearing state at /tmp/qmi-network-state-cdc-wdm0...
>
> Best regards,
>
> *Tor Rune Skoglund*
>
>
> Den 08.04.2020 17:45, skrev Aleksander Morgado:
> > 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!
> >
>
> _______________________________________________
> libqmi-devel mailing list
> libqmi-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/libqmi-devel
More information about the libqmi-devel
mailing list