[ltp] 2nd gen X1 carbon 3g/lte Sierra Wireless EM7345 4G LTE

[Bjørn Mork]

morten <mortenlarsens@gmail.com> writes:

> Hello
>
> I have tested libmbim (git-ref: b1ae81a75a1a68ea1c7316047528e79092bf0d37)
> on Ubuntu 12.04 (Linux thinkpad 3.11.0-18-generic #32~precise1-Ubuntu
> SMP Thu Feb 20 17:52:10 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux)
> with the Sierra Wireless EM7345 modem module.

Perfect!  Thanks.

Looks like we still have a few things to sort out.  Might be better to
move the discussion to the libmbim-devel, netdev, linux-usb or
modemmanager-devel lists, but I don't know exactly which one.  The
libmbim list is probably best until we've narrowed it down?:
http://lists.freedesktop.org/mailman/listinfo/libmbim-devel

Anyway, we can continue here for now if you like and noone protests.

> I am capable of querying the device of various properties e.g.
>
> sudo mbimcli -d /dev/cdc-wdm0 --query-device-caps
> [/dev/cdc-wdm0] Device capabilities retrieved:
>           Device type: 'embedded'
>        Cellular class: 'gsm'
>           Voice class: 'no-voice'
>             Sim class: 'removable'
>            Data class: 'gprs, edge, umts, hsdpa, hsupa, lte'
>              SMS caps: 'pdu-receive, pdu-send'
>             Ctrl caps: 'reg-manual'
>          Max sessions: '8'

Yeeha!  8 sessions!  Let's hope that is for real.

In theory this means that you can connect to 8 separate IP services,
having separate sessions and IP interfaces for e.g Internet + Voice
(over IP) + VPN +++ 

Not that I know of any service provider offering that many different
services.

Hmm, doesn't seem like there is any way to use it from mbimcli yet
either. The sessionid is hard coded to '0'. Well, let's worry about that
when we have the basics working.


>     Custom data class: 'unknown'
>             Device ID: '013937000188621'
>         Firmware info: 'FIH7160_V1.1_MODEM_01.1349.12'
>         Hardware info: 'XMM7160_V1.1_MBIM_GNSS_NAND_RE'
>
> sudo mbimcli -d /dev/cdc-wdm0 --query-radio-state
> [/dev/cdc-wdm0] Radio state retrieved:
>          Hardware Radio State: 'on'
>          Software Radio State: 'on'
>
> sudo mbimcli -d /dev/cdc-wdm0 --query-subscriber-ready-status
> [/dev/cdc-wdm0] Subscriber ready status retrieved:
>           Ready state: 'initialized'
>         Subscriber ID: '==REDACTED=='
>             SIM ICCID: '==REDACTED=='
>            Ready info: 'unknown'
>     Telephone numbers: (0) 'unknown'
>
> but the following command times-out at some point
>
> sudo mbimcli -d /dev/cdc-wdm0 --query-device-services
> [/dev/cdc-wdm0] Device services retrieved:
>     Max DSS sessions: '0'

OK, no DSS.  Well, you probably don't need it.  But I was hoping to see
a MBIM device actually implementing it for something useful...

(DSS = Device Service Stream - a way to multiplex non-IP transport
streams over the MBIM data link.  We can imagine stuff like NMEA GPS
data or AT command channels using it)

[..]

>                   Service: 'unknown'
>                      UUID: [10e40d69-375a-42ce-a297-906164f2754c]:
>               DSS payload: 0
>         Max DSS instances: 0
>                      CIDs: 1

Lots of unknown services here.  Wouldn't it have been nice if other
vendors than Microsoft actually *used* the registry at
http://compliance.usb.org/mbim/ ?  

>                   Service: 'ms-host-shutdown'
>                      UUID: [883b7c26-985f-43fa-9804-27d7fb80959c]:
>               DSS payload: 0
>         Max DSS instances: 0
>                      CIDs: notify (1)

Time to send a big thanks to Microsoft for documenting their stuff!
That's why we know what this is, and we sort of know how to use it.

>                   Service: 'unknown'
>                      UUID: [5967bdcc-7fd2-49a2-9f5c-b2e70e527db3]:
>               DSS payload: 0
>         Max DSS instances: 0
>                      CIDs: 2, 3, 1, 11, 4, 10, 9

This is an AT&T specific service.  My MC7710 implements the exact samt
serivice and set of CIDs:

                          Service: 'unknown'
                             UUID: [5967bdcc-7fd2-49a2-9f5c-b2e70e527db3]:
                      DSS payload: 0
                Max DSS instances: 0
                             CIDs: 1, 2, 3, 4, 9, 10, 11


>                   Service: 'unknown'
>                      UUID: [0ed374cb-f835-4474-bc11-3b3fd76f5641]:
>               DSS payload: 0
>         Max DSS instances: 0
>                      CIDs: 1
>
>                   Service: 'unknown'
>                      UUID: [ed19555d-a6ac-4327-8eb1-fc022e5e2388]:
>               DSS payload: 0
>         Max DSS instances: 0
>                      CIDs: 33554448

We've seen this service and CID on an Ericsson H5321gw before.  The fact
that it is implemented by two different vendors indicates that this most
likely is an operator specific service as well.


>                   Service: 'unknown'
>                      UUID: [fa142322-166b-4fd9-89f0-99be90ae8e3d]:
>               DSS payload: 0
>         Max DSS instances: 0
>                      CIDs: 1
>
>                   Service: 'unknown'
>                      UUID: [6a2a8150-abca-4b11-a4e2-f2fc879f5481]:
>               DSS payload: 0
>         Max DSS instances: 0
>                      CIDs: 1
> error: couldn't close device: Transaction timed out


Is 'query-device-services' always the first command to fail?  I wonder
if this might be related to how we handle fragmented replies.  That
reply is one of the longer ones, and it might need fragmentation. 

It would be good to have a test with a newer kernel.  v3.13.2 or
newer will do.  If we have driver problems related to fragmented
replies, then this commit which went into v3.13 is most likely
necessary:

  73e06865ead1 USB: cdc-wdm: support back-to-back USB_CDC_NOTIFY_RESPONSE_AVAILABLE notifications

Unfortunately, that commit is much too intrusive for stable.  And it
also introduced new bugs as a result, which is why you need at least
v3.13.2 for your test. This is still to be considered work-in-progress,
so there is a good chance we have some more issues to sort out before it
will work properly...


> Furtermore when I try to connect using sudo mbim-network /dev/cdc-wdm0 st=
art
> it is unable to connect giving a timeout as a reason. It should be
> noted, that after the first timeout occurs, all of the following query
> gives an error similar to this:
>
> [01 Apr 2014, 15:53:07] -Error ** mbim_message_open_done_get_result:
> assertion `MBIM_MESSAGE_GET_MESSAGE_TYPE (self) ==
> MBIM_MESSAGE_TYPE_OPEN_DONE' failed
>
> (mbimcli:3189): GLib-GIO-CRITICAL **:
> g_simple_async_result_take_error: assertion `error != NULL' failed
>
> A verbose example of the --query-device-services command

Thanks!  I was just about to ask for that :-)


> sudo mbimcli -d /dev/cdc-wdm0 --query-device-services -v

[..]

> [01 Apr 2014, 21:38:59] [Debug] [/dev/cdc-wdm0] Received
> message... (partial fragment)
>>>>>>> RAW:
>>>>>>>   length = 512
>>>>>>>   data   = 
> 03:00:00:80:00:02:00:00:02:00:00:00:02:00:00:00:00:00:00:00:A2:89:CC:33:B=
C:BB:8B:4F:B6:B0:13:3E:C2:AA:E6:DF:10:00:00:00:00:00:00:00:B4:02:00:00:0E:00:00:00:00:00:00:00:78:00:00:00:64:00:00:00:DC:00:00:00:30:00:00:00:0C:01:00:00:20:00:00:00:2C:01:00:00:2C:00:00:00:58:01:00:00:24:00:00:00:7C:01:00:00:20:00:00:00:9C:01:00:00:20:00:00:00:BC:01:00:00:20:00:00:00:DC:01:00:00:20:00:00:00:FC:01:00:00:38:00:00:00:34:02:00:00:20:00:00:00:54:02:00:00:20:00:00:00:74:02:00:00:20:00:00:00:94:02:00:00:20:00:00:00:A2:89:CC:33:BC:BB:8B:4F:B6:B0:13:3E:C2:AA:E6:DF:00:00:00:00:00:00:00:00:12:00:00:00:01:00:00:00:02:00:00:00:03:00:00:00:04:00:00:00:05:00:00:00:09:00:00:00:06:00:00:00:0B:00:00:00:08:00:00:00:07:00:00:00:15:00:00:00:0A:00:00:00:0F:00:00:00:0C:00:00:00:10:00:00:00:13:00:00:00:17:00:00:00:0D:00:00:00:53:3F:BE:EB:14:FE:44:67:9F:90:33:A2:23:E5:6C:3F:00:00:00:00:00:00:00:00:05:00:00:00:01:00:00:00:02:00:00:00:03:00:00:00:04:00:00:00:05:00:00:00:E5:50:A0:C8:5E:82:47:9E:82:F7:10:AB:F4:C3:35:1F:00:00:00:00:00:00:00:00:01:00:00:00:01:00:00:00:4B:F3:84:76:1E:6A:41:DB:B1:D8:BE:D2:89:C2:5B:DB:00:00:00:00:00:00:00:00:04:00:00:00:01:00:00:00:02:00:00:00:03:00:00:00:04:00:00:00:1D:2B:5F:F7:0A:A1:48:B2:AA:52:50:F1:57:67:17:4E:00:00:00:00:00:00:00:00:02:00:00:00:01:00:00:00:03:00:00:00:10:E4:0D:69:37:5A:42:CE:A2:97:90:61:64:F2:75:4C:00:00:00:00:00:00:00:00:01:00:00:00:01:00:00:00:59:A7:F3:23:FE:5A:43:01:B1:85:B8:EA:9E:61:67:B7:00:00:00:00:00:00:00:00:01:00:00:00:01:00:00:00:FD:C2:2A:F2:F4:41:4D:46:AF:8D:25:9F:CD:DE:46:35:00:00:00:00
>
> [01 Apr 2014, 21:38:59] [Debug] [/dev/cdc-wdm0] Received message
> fragment (translated)...
>>>>>>> Header:
>>>>>>>   length      = 512
>>>>>>>   type        = command-done (0x80000003)
>>>>>>>   transaction = 2
>>>>>>> Fragment header:
>>>>>>>   total   = 2
>>>>>>>   current = 0

Yes, there we have it.  This reply consists of 2 fragments.  Which is
fine, of course.  That's how it is supposed to look.

> error: operation failed: Fragment timed out

But we fail to receive the second part of the reply.

It could be something else, but this looks exactly like symptoms of the
bug the "support back-to-back USB_CDC_NOTIFY_RESPONSE_AVAILABLE" commit
is fixing. The issue is that the modem sends a notification for the
second part before the driver has read the first part, and the driver
just isn't prepared for that.  The result is that the driver doesn't
ever fetch the second part.  And from there we've lost...

[..]

> [01 Apr 2014, 21:39:09] [Debug] [/dev/cdc-wdm0] Received
> message... (partial fragment)
>>>>>>> RAW:
>>>>>>>   length = 248
>>>>>>>   data   = 
> 03:00:00:80:F8:00:00:00:02:00:00:00:02:00:00:00:01:00:00:00:00:00:00:00:0=
1:00:00:00:00:01:00:02:88:3B:7C:26:98:5F:43:FA:98:04:27:D7:FB:80:95:9C:00:00:00:00:00:00:00:00:01:00:00:00:01:00:00:00:59:67:BD:CC:7F:D2:49:A2:9F:5C:B2:E7:0E:52:7D:B3:00:00:00:00:00:00:00:00:07:00:00:00:02:00:00:00:03:00:00:00:01:00:00:00:0B:00:00:00:04:00:00:00:0A:00:00:00:09:00:00:00:0E:D3:74:CB:F8:35:44:74:BC:11:3B:3F:D7:6F:56:41:00:00:00:00:00:00:00:00:01:00:00:00:01:00:00:00:ED:19:55:5D:A6:AC:43:27:8E:B1:FC:02:2E:5E:23:88:00:00:00:00:00:00:00:00:01:00:00:00:10:00:00:02:FA:14:23:22:16:6B:4F:D9:89:F0:99:BE:90:AE:8E:3D:00:00:00:00:00:00:00:00:01:00:00:00:01:00:00:00:6A:2A:81:50:AB:CA:4B:11:A4:E2:F2:FC:87:9F:54:81:00:00:00:00:00:00:00:00:01:00:00:00:01:00:00:00
>
> [01 Apr 2014, 21:39:09] [Debug] [/dev/cdc-wdm0] Received message
> fragment (translated)...
>>>>>>> Header:
>>>>>>>   length      = 248
>>>>>>>   type        = command-done (0x80000003)
>>>>>>>   transaction = 2
>>>>>>> Fragment header:
>>>>>>>   total   = 2
>>>>>>>   current = 1
>
> [01 Apr 2014, 21:39:09] [Debug] [/dev/cdc-wdm0] No transaction matched
> in received message

This is the missing fragment, which the driver finally reads here - much
too late, while userspace was expecting a reply for a later command.


> dmesg output at boot
> [    8.530427] usbcore: registered new interface driver cdc_ncm
> [    8.535195] usbcore: registered new interface driver cdc_wdm
> [    8.549669] cdc_mbim 2-4:1.0: cdc-wdm0: USB WDM device
> [    8.554268] cdc_mbim 2-4:1.0 wwan0: register 'cdc_mbim' at
> usb-0000:00:14.0-4, CDC MBIM, c6:92:45:62:05:05
> [    8.555083] usbcore: registered new interface driver cdc_mbim
> [    8.555543] usbcore: registered new interface driver btusb
> [    8.557955] cdc_acm 2-4:1.2: This device cannot do calls on its
> own. It is not a modem.
> [    8.558002] cdc_acm 2-4:1.2: ttyACM0: USB ACM device
> [    8.560226] usbcore: registered new interface driver cdc_acm
> [    8.560230] cdc_acm: USB Abstract Control Model driver for USB
> modems and ISDN adapters

Great!  So there is a serial port (AT command?) as well, and it is also
a proper CDC class function so we don't need any vendor specific stuff
to support it. Thanks Intel.  It's good to see such things.

Are the 4 USB interfaces use by the cdc_mbim and cdc_acm drivers the
only ones on this modem, or are there other (possibly unsupported)
functions as well?


Bjørn