Anyone testing an MC7430 or other MDM9x30 based modem
Bjørn Mork
bjorn at mork.no
Tue Nov 24 00:10:53 PST 2015
Bjørn Mork <bjorn at mork.no> writes:
> I have to pause the testing for a while now. Not enough time for these
> things...
Not that I'm able to keep my hands off shiny new toys for very long :)
Testing immediately after device discovery made no difference. Still
unable to switch from 'raw IP' mode, so I am going to let that be for
now.
But it doesn't stop there. There is more unexpected behaviour from this
modem. Not directly related to QMI, but it might help explain the
firmware behaviour in general.
I thought MBIM mode would be easy. That should just work. Right....
It doesn't. Or rather, it works, but so far from what ModemManager/
libmbim expects that they fail to detect it as MBIM at all.
ModemManager probing times out on the 'proxy-control' message ( cdc-wdm0
is EM7345, cdc-wdm1 is MC7455 ):
ModemManager[4175]: <debug> [1448315918.355566] [mm-port-probe.c:525] wdm_probe_mbim(): (usbmisc/cdc-wdm1) probing MBIM...
ModemManager[4175]: <debug> [1448315918.358173] [mm-port-probe.c:525] wdm_probe_mbim(): (usbmisc/cdc-wdm0) probing MBIM...
ModemManager[4175]: opening device...
ModemManager[4175]: [/dev/cdc-wdm1] Read max control message size from descriptors file: 4096
ModemManager[4175]: opening device...
ModemManager[4175]: [/dev/cdc-wdm0] Read max control message size from descriptors file: 512
ModemManager[4175]: [/dev/cdc-wdm1] Sent message...
<<<<<< RAW:
<<<<<< length = 88
<<<<<< data = 03:00:00:00:58:00:00:00:01:00:00:00:01:00:00:00:00:00:00:00:83:8C:F7:FB:8D:0D:4D:7F:87:1E:D7:1D:BE:FB:B3:9B:01:00:00:00:01:00:00:00:28:00:00:00:0C:00:00:00:1A:00:00:00:1E:00:00:00:2F:00:64:00:65:00:76:00:2F:00:63:00:64:00:63:00:2D:00:77:00:64:00:6D:00:31:00:00:00
ModemManager[4175]: [/dev/cdc-wdm1] Sent message (translated)...
<<<<<< Header:
<<<<<< length = 88
<<<<<< type = command (0x00000003)
<<<<<< transaction = 1
<<<<<< Fragment header:
<<<<<< total = 1
<<<<<< current = 0
<<<<<< Contents:
<<<<<< service = 'proxy-control' (838cf7fb-8d0d-4d7f-871e-d71dbefbb39b)
<<<<<< cid = 'configuration' (0x00000001)
<<<<<< type = 'set' (0x00000001)
..
ModemManager[4175]: <debug> [1448315918.431190] [mm-port-probe.c:303] mm_port_probe_set_result_mbim(): (usbmisc/cdc-wdm0) port is MBIM-capable
..
ModemManager[4175]: <debug> [1448315948.376533] [mm-port-probe.c:503] mbim_port_open_ready(): (usbmisc/cdc-wdm1) error checking MBIM support: 'Transaction timed out'
ModemManager[4175]: <debug> [1448315948.377327] [mm-port-probe.c:320] mm_port_probe_set_result_mbim(): (usbmisc/cdc-wdm1) port is not MBIM-capable
ModemManager[4175]: <debug> [1448315948.377873] [mm-plugin-manager.c:462] plugin_supports_port_ready(): (Plugin Manager) (Generic) [cdc-wdm1] found best plugin for port
Testing with mbimcli isn't much more success, but provides some insight
into the problem:
bjorn at nemi:~$ mbimcli -v -d /dev/cdc-wdm1 --no-close --query-device-caps
[24 Nov 2015, 08:18:04] [Debug] opening device...
[24 Nov 2015, 08:18:04] [Debug] [/dev/cdc-wdm1] Queried max control message size: 4096
[24 Nov 2015, 08:18:04] [Debug] [/dev/cdc-wdm1] Sent message...
<<<<<< RAW:
<<<<<< length = 16
<<<<<< data = 01:00:00:00:10:00:00:00:01:00:00:00:00:10:00:00
[24 Nov 2015, 08:18:04] [Debug] [/dev/cdc-wdm1] Sent message (translated)...
<<<<<< Header:
<<<<<< length = 16
<<<<<< type = open (0x00000001)
<<<<<< transaction = 1
<<<<<< Contents:
<<<<<< max_control_transfer = 4096
[24 Nov 2015, 08:18:05] [Debug] [/dev/cdc-wdm1] Sent message...
<<<<<< RAW:
<<<<<< length = 16
<<<<<< data = 01:00:00:00:10:00:00:00:02:00:00:00:00:10:00:00
[24 Nov 2015, 08:18:05] [Debug] [/dev/cdc-wdm1] Sent message (translated)...
<<<<<< Header:
<<<<<< length = 16
<<<<<< type = open (0x00000001)
<<<<<< transaction = 2
<<<<<< Contents:
<<<<<< max_control_transfer = 4096
[24 Nov 2015, 08:18:06] [Debug] [/dev/cdc-wdm1] Sent message...
<<<<<< RAW:
<<<<<< length = 16
<<<<<< data = 01:00:00:00:10:00:00:00:03:00:00:00:00:10:00:00
[24 Nov 2015, 08:18:06] [Debug] [/dev/cdc-wdm1] Sent message (translated)...
<<<<<< Header:
<<<<<< length = 16
<<<<<< type = open (0x00000001)
<<<<<< transaction = 3
<<<<<< Contents:
<<<<<< max_control_transfer = 4096
[etc until it gives up]
So there is no reply to any of the 'open' messages. Which surprised me,
because I had already used one of my more hackish perl scripts to run
the Sierra specific 0x555b and 0x555c QMI_DMS commands over MBIM. And
that was successful!
I wonder if the main difference is patience? I send a single MBIM OPEN
and then wait. Trying to do that again is successful, and allows me to
use mbimcli just fine. So the problem seems to be the aggressive
'open'. mbimcli output for anyone interested. 8 IP sessions and no
DSS. No suprises here:
bjorn at nemi:~$ mbimcli --no-close --no-open=2 --device=/dev/cdc-wdm1 --query-device-caps
[/dev/cdc-wdm1] Device capabilities retrieved:
Device type: 'remote'
Cellular class: 'gsm'
Voice class: 'no-voice'
Sim class: 'removable'
Data class: 'umts, hsdpa, hsupa, lte'
SMS caps: 'pdu-receive, pdu-send'
Ctrl caps: 'reg-manual, multi-carrier'
Max sessions: '8'
Custom data class: 'unknown'
Device ID: '359072060005564'
Firmware info: 'SWI9X30C_01.08.07.00'
Hardware info: 'MC7455'
[/dev/cdc-wdm1] Session not closed:
TRID: '3'
bjorn at nemi:~$ mbimcli --no-close --no-open=2 --device=/dev/cdc-wdm1 --query-device-services
[/dev/cdc-wdm1] Device services retrieved:
Max DSS sessions: '0'
Services: (13)
Service: 'basic-connect'
UUID: [a289cc33-bcbb-8b4f-b6b0-133ec2aae6df]:
DSS payload: 0
Max DSS instances: 0
CIDs: device-caps (1),
subscriber-ready-status (2),
radio-state (3),
pin (4),
pin-list (5),
home-provider (6),
preferred-providers (7),
visible-providers (8),
register-state (9),
packet-service (10),
signal-state (11),
connect (12),
provisioned-contexts (13),
ip-configuration (15),
device-services (16),
device-service-subscribe-list (19),
packet-statistics (20),
network-idle-hint (21),
emergency-mode (22),
ip-packet-filters (23)
Service: 'sms'
UUID: [533fbeeb-14fe-4467-9f90-33a223e56c3f]:
DSS payload: 0
Max DSS instances: 0
CIDs: configuration (1),
read (2),
send (3),
delete (4),
message-store-status (5)
Service: 'ussd'
UUID: [e550a0c8-5e82-479e-82f7-10abf4c3351f]:
DSS payload: 0
Max DSS instances: 0
CIDs: ussd (1)
Service: 'phonebook'
UUID: [4bf38476-1e6a-41db-b1d8-bed289c25bdb]:
DSS payload: 0
Max DSS instances: 0
CIDs: configuration (1),
read (2),
delete (3),
write (4)
Service: 'stk'
UUID: [d8f20131-fcb5-4e17-8602-d6ed3816164c]:
DSS payload: 0
Max DSS instances: 0
CIDs: pac (1),
terminal-response (2),
envelope (3)
Service: 'auth'
UUID: [1d2b5ff7-0aa1-48b2-aa52-50f15767174e]:
DSS payload: 0
Max DSS instances: 0
CIDs: aka (1),
sim (3)
Service: 'unknown'
UUID: [d1a30bc2-f97a-6e43-bf65-c7e24fb0f0d3]:
DSS payload: 0
Max DSS instances: 0
CIDs: 1
Service: 'unknown'
UUID: [8b569648-628d-4653-9b9f-1025404424e1]:
DSS payload: 0
Max DSS instances: 0
CIDs: 1, 2, 3
Service: 'ms-host-shutdown'
UUID: [883b7c26-985f-43fa-9804-27d7fb80959c]:
DSS payload: 0
Max DSS instances: 0
CIDs: notify (1)
Service: 'unknown'
UUID: [2d0c12c9-0e6a-495a-915c-8d174fe5d63c]:
DSS payload: 0
Max DSS instances: 0
CIDs: 1, 2
Service: 'ms-firmware-id'
UUID: [e9f7dea2-feaf-4009-93ce-90a3694103b6]:
DSS payload: 0
Max DSS instances: 0
CIDs: get (1)
Service: 'unknown'
UUID: [5967bdcc-7fd2-49a2-9f5c-b2e70e527db3]:
DSS payload: 0
Max DSS instances: 0
CIDs: 1, 2, 3, 4, 9, 10
Service: 'unknown'
UUID: [6427015f-579d-48f5-8c54-f43ed1e76f83]:
DSS payload: 0
Max DSS instances: 0
CIDs: 1, 2, 3
[/dev/cdc-wdm1] Session not closed:
TRID: '3'
Argh. I hate it when this happens. We believe we have a generic
implementation that can handle anything, and then some firmware shows up
with a whole new set of expectations and restrictions.
In case anyone wants to try this at home: The firmware doesn't support
the AT!UDUSBCOMP command, so you have to use QMI to switch modes - or
QMI over MBIM if already in MBIM mode. There are only 3 modes supported:
6 (QMI+AT+QCDM), 8 (MBIM+AT+QCDM) and 9 (MBIM). No dual config mode. At
least not with the PID and firmware I have (9071 and 01.08.07).
Bjørn
More information about the libqmi-devel
mailing list