<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body> 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' # 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... <div class="moz-signature"> Best regards, Tor Rune Skoglund </div> <div class="moz-cite-prefix"> </div> <div class="moz-cite-prefix">Den 08.04.2020 17:45, skrev Aleksander Morgado: </div> <blockquote type="cite" cite="mid:CAAP7uc+2SQp8CaDOPxuAG4-jPpQUJgpC9c0PMVOCHANjr=pRaQ@mail.gmail.com"> <pre class="moz-quote-pre" wrap="">Hey, </pre> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">tir. 7. apr. 2020 kl. 17:17 skrev Aleksander Morgado <a class="moz-txt-link-rfc2396E" href="mailto:aleksander@aleksander.es"><aleksander@aleksander.es></a>: </pre> <blockquote type="cite"> <pre class="moz-quote-pre" wrap=""> </pre> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">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. :) </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> 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? </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> 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 </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> That above is not a good way to disconnect if you're manually running Start Network, see other comments below. </pre> <blockquote type="cite"> <pre class="moz-quote-pre" wrap=""> 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" </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> 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? </pre> <blockquote type="cite"> <pre class="moz-quote-pre" wrap=""> 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" </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> 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. </pre> <blockquote type="cite"> <pre class="moz-quote-pre" wrap=""> 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 </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> 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. </pre> <blockquote type="cite"> <pre class="moz-quote-pre" wrap=""> 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') </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> 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. </pre> <blockquote type="cite"> <pre class="moz-quote-pre" wrap=""> 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....(?) </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> 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 (<a class="moz-txt-link-freetext" href="https://sigquit.wordpress.com/2013/09/17/mobile-radio-monitor/">https://sigquit.wordpress.com/2013/09/17/mobile-radio-monitor/</a>) 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! </pre> </blockquote> </body> </html>