Anyone testing an MC7430 or other MDM9x30 based modem
Aleksander Morgado
aleksander at aleksander.es
Mon Nov 23 09:05:52 PST 2015
On Mon, Nov 23, 2015 at 5:51 PM, Bjørn Mork <bjorn at mork.no> wrote:
> There seems to be a few minor things to fixup before MM + libqmi will
> support this modem. Ehrrm, the DataFormat thing isn't necessarily minor
> either. That's probably a v4.5 kernel thing now. Unless we can find a
> way around it.
>
> This is the list of issues at the moment
>
Thanks for all this info; very useful indeed.
>
> 1) firmware needs USB_CDC_REQ_SET_CONTROL_LINE_STATE requests to wake up
> from sleep. Wkaing up takes a measurable amount of time.
>
> I have a qmi_wwan driver fix for this. But it might need further
> userspace adjustments to account for the wakeup delay. Yes, we could
> add a delay to the driver, but that will slow down every device wakeup
> for no good reason.
>
> Still have to do some testing with an active connection, to see how the
> effect on that will be.
>
Is the state of the modem kept after resuming from sleep; or is it to
be treated as a full reboot?
Any idea what the GobiAPI/GobiNet setup does with this delay?
Would it be worth having in the kernel a list of devices which require
the delay? :(
Does it just ignore requests fully until ready? Or does it instead
reply to the first one we sent after a long time?
>
>
> 2) QMI_DMS "UIM Get PIN Status" is not supported anymore, making MM
> report the SIM as missing:
>
>
>
> ModemManager[16087]: <debug> [1448296269.758618] [mm-iface-modem.c:290] load_unlock_required_ready(): Retrying (3) unlock required check
> ModemManager[16087]: <debug> [1448296271.719114] [mm-broadband-modem-qmi.c:1533] modem_load_unlock_required(): loading unlock required...
> ModemManager[16087]: [/dev/cdc-wdm1] Sent message...
> <<<<<< RAW:
> <<<<<< length = 13
> <<<<<< data = 01:0C:00:00:02:04:00:0C:00:2B:00:00:00
> ModemManager[16087]: [/dev/cdc-wdm1] Sent message (translated)...
> <<<<<< QMUX:
> <<<<<< length = 12
> <<<<<< flags = 0x00
> <<<<<< service = "dms"
> <<<<<< client = 4
> <<<<<< QMI:
> <<<<<< flags = "none"
> <<<<<< transaction = 12
> <<<<<< tlv_length = 0
> <<<<<< message = "UIM Get PIN Status" (0x002B)
> ModemManager[16087]: [/dev/cdc-wdm1] Received message...
>>>>>>> RAW:
>>>>>>> length = 20
>>>>>>> data = 01:13:00:80:02:04:02:0C:00:2B:00:07:00:02:04:00:01:00:47:00
> ModemManager[16087]: [/dev/cdc-wdm1] Received message (translated)...
>>>>>>> QMUX:
>>>>>>> length = 19
>>>>>>> flags = 0x80
>>>>>>> service = "dms"
>>>>>>> client = 4
>>>>>>> QMI:
>>>>>>> flags = "response"
>>>>>>> transaction = 12
>>>>>>> tlv_length = 7
>>>>>>> message = "UIM Get PIN Status" (0x002B)
>>>>>>> TLV:
>>>>>>> type = "Result" (0x02)
>>>>>>> length = 4
>>>>>>> value = 01:00:47:00
>>>>>>> translated = FAILURE: InvalidQmiCommand
> ModemManager[16087]: <debug> [1448296271.739669] [mm-iface-modem.c:266] load_unlock_required_ready(): Couldn't check if unlock required: 'Couldn't get PIN status: QMI protocol error (71): 'InvalidQmiCommand''
>
>
> bjorn at nemi:~$ mmcli -m 1
>
> /org/freedesktop/ModemManager1/Modem/1 (device id '4c16d71088ff667ce14b9f85930e42fa0ac9fde8')
> -------------------------
> Hardware | manufacturer: 'Sierra Wireless, Incorporated'
> | model: 'MC7455'
> | revision: 'SWI9X30C_01.08.07.00 r3743 CARMD-EV-FRMWR2 2015/08/13 23:07:36'
> | supported: 'gsm-umts
> | lte
> | gsm-umts, lte'
> | current: 'gsm-umts, lte'
> | equipment id: '359072060005564'
> -------------------------
> System | device: '/sys/devices/pci0000:00/0000:00:1d.0/usb6/6-1'
> | drivers: 'qcserial, qmi_wwan'
> | plugin: 'Gobi'
> | primary port: 'cdc-wdm1'
> | ports: 'ttyUSB0 (qcdm), ttyUSB2 (at), cdc-wdm1 (qmi), cdc-wdm2 (qmi), wwan1 (net), wwan2 (net)'
> -------------------------
> Numbers | own : 'unknown'
> -------------------------
> Status | lock: 'unknown'
> | unlock retries: 'unknown'
> | state: 'failed'
> | failed reason: 'sim-missing'
> | power state: 'on'
> | access tech: 'unknown'
> | signal quality: '0' (cached)
> -------------------------
> Modes | supported: 'allowed: 2g, 3g, 4g; preferred: none'
> | current: 'allowed: any; preferred: none'
> -------------------------
> Bands | supported: 'cdma-bc15-aws, u2100, u1800, u1900, u17iv, u850, u900, eutran-i, eutran-ii, eutran-iii, eutran-iv, eutran-v, eutran-vii, eutran-viii, eutran-xii, eutran-xiii, eutran-xx, eutran-xxv, eutran-xli'
> | current: 'unknown'
> -------------------------
> IP | supported: 'ipv4, ipv6, ipv4v6'
> -------------------------
> SIM | path: 'none'
>
> -------------------------
> Bearers | paths: 'none'
>
>
> This happens even if I manually verified the PIN using
> QMI_UIM_VERIFY_PIN before starting MM. I assume this is how we have to
> verify PIN in the future, if UIM and this request is supported:
>
>
>
> bjorn at nemi:~$ ~/privat/prog/git/wwan/scripts/qmi.pl --device=wwan1 --system=11 0x0026 0x01 00 00 0x02 01 04 37 35 31 33
> wwan1: will use /dev/cdc-wdm1 for management
> sending to /dev/cdc-wdm1:
> 01 1a 00 00 0b 02 00 02 00 26 00 0e 00 02 06 00 01 04 31 32 33 34 01 02 00 00 00
> => QMUX Header:
> => len: 0x001a
> => sender: 0x00
> => svc: 0x0b
> => cid: 0x02
>
> => QMI Header:
> => Flags: 0x00
> => TXN: 0x0002
> => Cmd: 0x0026
> => Size: 0x000e
> => [0x01] ( 2) 00 00 ..
> => [0x02] ( 6) 01 04 31 32 33 34 ..1234
> reading from /dev/cdc-wdm1
> [Mon Nov 23 17:28:39 2015] read 25 bytes from /dev/cdc-wdm1
> 01 18 00 80 0b 02 02 02 00 26 00 0c 00 02 04 00 00 00 00 00 13 02 00 90 00
> <= QMUX Header:
> <= len: 0x0018
> <= sender: 0x80
> <= svc: 0x0b
> <= cid: 0x02
>
> <= QMI Header:
> <= Flags: 0x02
> <= TXN: 0x0002
> <= Cmd: 0x0026
> <= Size: 0x000c
> <= [0x02] ( 4) 00 00 00 00 SUCCESS - QMI_ERR_NONE
> <= [0x13] ( 2) 90 00 ..
>
Ok, we'll need to add a fallback mechanism in ModemManager and if we
get InvalidQmiCommand for "DMS UIM Get PIN status", just retry with
the newer command.
>
>
> 3) and then there's the Data Format, which has been reported as an issue
> with the GobiNet driver from Sierra Wireless too (when built for 802.3):
>
>
> bjorn at nemi:~$ qmicli -d /dev/cdc-wdm1 --wda-get-data-format
> [/dev/cdc-wdm1] 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'
> bjorn at nemi:~$ qmicli -d /dev/cdc-wdm2 --wda-get-data-format
> [/dev/cdc-wdm2] 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'
>
>
> [23 Nov 2015, 17:15:19] [Debug] [/dev/cdc-wdm1] Sent message (translated)...
> <<<<<< QMUX:
> <<<<<< length = 19
> <<<<<< flags = 0x00
> <<<<<< service = "wda"
> <<<<<< client = 1
> <<<<<< QMI:
> <<<<<< flags = "none"
> <<<<<< transaction = 1
> <<<<<< tlv_length = 7
> <<<<<< message = "Set Data Format" (0x0020)
> <<<<<< TLV:
> <<<<<< type = "Link Layer Protocol" (0x11)
> <<<<<< length = 4
> <<<<<< value = 01:00:00:00
> <<<<<< translated = 802-3
>
> [23 Nov 2015, 17:15:19] [Debug] [/dev/cdc-wdm1] Received message...
>>>>>>> RAW:
>>>>>>> length = 20
>>>>>>> data = 01:13:00:80:1A:01:02:01:00:20:00:07:00:02:04:00:01:00:46:00
>
> [23 Nov 2015, 17:15:19] [Debug] [/dev/cdc-wdm1] Received message (translated)...
>>>>>>> QMUX:
>>>>>>> length = 19
>>>>>>> flags = 0x80
>>>>>>> service = "wda"
>>>>>>> client = 1
>>>>>>> QMI:
>>>>>>> flags = "response"
>>>>>>> transaction = 1
>>>>>>> tlv_length = 7
>>>>>>> message = "Set Data Format" (0x0020)
>>>>>>> TLV:
>>>>>>> type = "Result" (0x02)
>>>>>>> length = 4
>>>>>>> value = 01:00:46:00
>>>>>>> translated = FAILURE: InvalidOperation
>
>
>
> If we can't find a way to work around this, then I guess we can't avoid
> supporting 'raw IP' any longer. But it will be a mess... Guess I made
> the wrong choice a few years ago. Well, I'm sure it won't be the last
> time.
>
Oh, how sad is this... :/
Does the CTL command help changing the data format?
Have you tried to Set Data Format as soon as the device is exposed?
--
Aleksander
https://aleksander.es
More information about the libqmi-devel
mailing list