<div dir="auto">What carrier are you using?<div dir="auto">Does carrier support your modem, imei?</div><div dir="auto">Does carrier require provisioning before imei can be on network?</div><div dir="auto">What drivers are used? # lsusb -t</div><div dir="auto">Can you run get home network? </div><div dir="auto">Paste results from --dms-list-stored-images</div><div dir="auto">What is result from --dms-get-power-state</div><div dir="auto">When manual, issue --wds-set-ip-family=,4</div><div dir="auto">After manual run, issue cmd --wds-get-current-settings </div><div dir="auto">Remember to run all with -v while troubleshoot.</div><div dir="auto"> </div><div dir="auto">I ran into similar issue, with internal error, it was carrier not liking my modem.</div></div> <div class="gmail_quote"><div dir="ltr">On Wed, Apr 15, 2020, 1:57 AM Tor Rune Skoglund <<a href="mailto:trs@fourc.eu">trs@fourc.eu</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Dan, thank you very much for your input. Den 14.04.2020 21:17, skrev Dan Williams: >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? It is version 1.22.2. There is no change when adding --set-expected-data-format. Below is the log: Btw, the Linux kernel is compiled without IPv6 on this system. That is why we have specfied ip-type=4. But maybe it is still related to the kernel not supporting v6 here? # 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 # Settings expected data format $ qmicli -d /dev/cdc-wdm0 --set-expected-data-format=802-3 [/dev/cdc-wdm0] expected data format set to: 802-3 # 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 -v -d /dev/cdc-wdm0 --wds-start-network=apn=internet,ip-type=4 --client-no-release-cid [15 Apr 2020, 08:40:59] [Debug] [/dev/cdc-wdm0] Opening device with flags 'auto'... [15 Apr 2020, 08:40:59] [Debug] [/dev/cdc-wdm0] loaded driver of cdc-wdm port: qmi_wwan [15 Apr 2020, 08:40:59] [Debug] [/dev/cdc-wdm0] automatically selecting QMI mode [15 Apr 2020, 08:40:59] [Debug] QMI Device at '/dev/cdc-wdm0' ready [15 Apr 2020, 08:40:59] [Debug] [/dev/cdc-wdm0] Assuming service 'wds' is supported... [15 Apr 2020, 08:40:59] [Debug] [/dev/cdc-wdm0] Allocating new client ID... [15 Apr 2020, 08:40:59] [Debug] [/dev/cdc-wdm0] sent message... <<<<<< RAW: <<<<<< length = 16 <<<<<< data = 01:0F:00:00:00:00:00:01:22:00:04:00:01:01:00:01 [15 Apr 2020, 08:40:59] [Debug] [/dev/cdc-wdm0] sent generic request (translated)... <<<<<< QMUX: <<<<<< length = 15 <<<<<< flags = 0x00 <<<<<< service = "ctl" <<<<<< client = 0 <<<<<< QMI: <<<<<< flags = "none" <<<<<< transaction = 1 <<<<<< tlv_length = 4 <<<<<< message = "Allocate CID" (0x0022) <<<<<< TLV: <<<<<< type = "Service" (0x01) <<<<<< length = 1 <<<<<< value = 01 <<<<<< translated = wds [15 Apr 2020, 08:40:59] [Debug] [/dev/cdc-wdm0] received message... <<<<<< RAW: <<<<<< length = 24 <<<<<< data = 01:17:00:80:00:00:01:01:22:00:0C:00:02:04:00:00:00:00:00:01:02:00:01:09 [15 Apr 2020, 08:40:59] [Debug] [/dev/cdc-wdm0] received generic response (translated)... <<<<<< QMUX: <<<<<< length = 23 <<<<<< flags = 0x80 <<<<<< service = "ctl" <<<<<< client = 0 <<<<<< QMI: <<<<<< flags = "response" <<<<<< transaction = 1 <<<<<< tlv_length = 12 <<<<<< message = "Allocate CID" (0x0022) <<<<<< TLV: <<<<<< type = "Result" (0x02) <<<<<< length = 4 <<<<<< value = 00:00:00:00 <<<<<< translated = SUCCESS <<<<<< TLV: <<<<<< type = "Allocation Info" (0x01) <<<<<< length = 2 <<<<<< value = 01:09 <<<<<< translated = [ service = 'wds' cid = '9' ] [15 Apr 2020, 08:40:59] [Debug] [/dev/cdc-wdm0] Registered 'wds' (version unknown) client with ID '9' [15 Apr 2020, 08:40:59] [Debug] Network start parameters set (apn: 'internet', 3gpp_profile: '0', 3gpp2_profile: '0', auth: 'unspecified', ip-type: '4', username: 'unspecified', password: 'unspecified', autoconnect: 'unspecified') [15 Apr 2020, 08:40:59] [Debug] Asynchronously starting network... [15 Apr 2020, 08:40:59] [Debug] [/dev/cdc-wdm0] sent message... <<<<<< RAW: <<<<<< length = 28 <<<<<< data = 01:1B:00:00:01:09:00:01:00:20:00:0F:00:19:01:00:04:14:08:00:69:6E:74:65:72:6E:65:74 [15 Apr 2020, 08:40:59] [Debug] [/dev/cdc-wdm0] sent generic request (translated)... <<<<<< QMUX: <<<<<< length = 27 <<<<<< flags = 0x00 <<<<<< service = "wds" <<<<<< client = 9 <<<<<< QMI: <<<<<< flags = "none" <<<<<< transaction = 1 <<<<<< tlv_length = 15 <<<<<< message = "Start Network" (0x0020) <<<<<< TLV: <<<<<< type = "IP Family Preference" (0x19) <<<<<< length = 1 <<<<<< value = 04 <<<<<< translated = ipv4 <<<<<< TLV: <<<<<< type = "APN" (0x14) <<<<<< length = 8 <<<<<< value = 69:6E:74:65:72:6E:65:74 <<<<<< translated = internet [15 Apr 2020, 08:41:01] [Debug] [/dev/cdc-wdm0] received message... <<<<<< RAW: <<<<<< length = 32 <<<<<< data = 01:1F:00:80:01:09:02:01:00:20:00:13:00:02:04:00:01:00:0E:00:10:02:00:03:00:11:04:00:02:00:D2:00 [15 Apr 2020, 08:41:01] [Debug] [/dev/cdc-wdm0] received generic response (translated)... <<<<<< QMUX: <<<<<< length = 31 <<<<<< flags = 0x80 <<<<<< service = "wds" <<<<<< client = 9 <<<<<< QMI: <<<<<< flags = "response" <<<<<< transaction = 1 <<<<<< tlv_length = 19 <<<<<< message = "Start Network" (0x0020) <<<<<< TLV: <<<<<< type = "Result" (0x02) <<<<<< length = 4 <<<<<< value = 01:00:0E:00 <<<<<< translated = FAILURE: CallFailed <<<<<< TLV: <<<<<< type = "Call End Reason" (0x10) <<<<<< length = 2 <<<<<< value = 03:00 <<<<<< translated = generic-no-service <<<<<< TLV: <<<<<< type = "Verbose Call End Reason" (0x11) <<<<<< length = 4 <<<<<< value = 02:00:D2:00 <<<<<< translated = [ type = 'internal' reason = '210' ] 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' [15 Apr 2020, 08:41:01] [Debug] [/dev/cdc-wdm0] Releasing 'wds' client with flags 'none'... [15 Apr 2020, 08:41:01] [Debug] [/dev/cdc-wdm0] Unregistered 'wds' client with ID '9' [15 Apr 2020, 08:41:01] [Debug] Client released [15 Apr 2020, 08:41:01] [Debug] Closed # Failed with exit code 1 and no handle returned >> 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 < >>>> <a href="mailto:aleksander@aleksander.es" target="_blank" rel="noreferrer">aleksander@aleksander.es</a>>: >>>>>> 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 >>> (<a href="https://sigquit.wordpress.com/2013/09/17/mobile-radio-monitor/" rel="noreferrer noreferrer" target="_blank">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! >>> >> _______________________________________________ >> libqmi-devel mailing list >> <a href="mailto:libqmi-devel@lists.freedesktop.org" target="_blank" rel="noreferrer">libqmi-devel@lists.freedesktop.org</a> >> <a href="https://lists.freedesktop.org/mailman/listinfo/libqmi-devel" rel="noreferrer noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/libqmi-devel</a> _______________________________________________ libqmi-devel mailing list <a href="mailto:libqmi-devel@lists.freedesktop.org" target="_blank" rel="noreferrer">libqmi-devel@lists.freedesktop.org</a> <a href="https://lists.freedesktop.org/mailman/listinfo/libqmi-devel" rel="noreferrer noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/libqmi-devel</a> </blockquote></div>