Anyone testing an MC7430 or other MDM9x30 based modem
Bjørn Mork
bjorn at mork.no
Mon Nov 23 08:51:25 PST 2015
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
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.
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 ..
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.
Bjørn
More information about the libqmi-devel
mailing list