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

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

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

morten
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.

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'
     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'
             Services: (14)

                   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),
                            register-state (9),
                            home-provider (6),
                            signal-state (11),
                            visible-providers (8),
                            preferred-providers (7),
                            network-idle-hint (21),
                            packet-service (10),
                            ip-configuration (15),
                            connect (12),
                            device-services (16),
                            device-service-subscribe-list (19),
                            ip-packet-filters (23),
                            provisioned-contexts (13)

                   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: 'auth'
                      UUID: [1d2b5ff7-0aa1-48b2-aa52-50f15767174e]:
               DSS payload: 0
         Max DSS instances: 0
                      CIDs: aka (1),
                            sim (3)

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

                   Service: 'unknown'
                      UUID: [59a7f323-fe5a-4301-b185-b8ea9e6167b7]:
               DSS payload: 0
         Max DSS instances: 0
                      CIDs: 1

                   Service: 'unknown'
                      UUID: [fdc22af2-f441-4d46-af8d-259fcdde4635]:
               DSS payload: 0
         Max DSS instances: 0
                      CIDs: 33554688

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

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

                   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

                   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

Furtermore when I try to connect using sudo mbim-network /dev/cdc-wdm0 start
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

sudo mbimcli -d /dev/cdc-wdm0 --query-device-services -v
[01 Apr 2014, 21:38:59] [Debug] [/dev/cdc-wdm0] Queried max control
message size: 512
[01 Apr 2014, 21:38:59] [Debug] [/dev/cdc-wdm0] Sent message...
<<<<<< RAW:
<<<<<<   length = 16
<<<<<<   data   = 01:00:00:00:10:00:00:00:01:00:00:00:00:02:00:00

[01 Apr 2014, 21:38:59] [Debug] [/dev/cdc-wdm0] Sent message (translated)...
<<<<<< Header:
<<<<<<   length      = 16
<<<<<<   type        = open (0x00000001)
<<<<<<   transaction = 1
<<<<<< Contents:
<<<<<<   max_control_transfer = 512

[01 Apr 2014, 21:38:59] [Debug] [/dev/cdc-wdm0] Received message...
 >>>>>> RAW:
 >>>>>>   length = 16
 >>>>>>   data   = 01:00:00:80:10:00:00:00:01:00:00:00:00:00:00:00

[01 Apr 2014, 21:38:59] [Debug] MBIM Device at '/dev/cdc-wdm0' ready
[01 Apr 2014, 21:38:59] [Debug] Asynchronously querying device services...
[01 Apr 2014, 21:38:59] [Debug] [/dev/cdc-wdm0] Sent message...
<<<<<< RAW:
<<<<<<   length = 48
<<<<<<   data   =
03:00:00:00:30:00:00:00:02:00:00:00:01:00:00:00:00:00:00:00:A2:89:CC:33:BC:BB:8B:4F:B6:B0:13:3E:C2:AA:E6:DF:10:00:00:00:00:00:00:00:00:00:00:00

[01 Apr 2014, 21:38:59] [Debug] [/dev/cdc-wdm0] Sent message (translated)...
<<<<<< Header:
<<<<<<   length      = 48
<<<<<<   type        = command (0x00000003)
<<<<<<   transaction = 2
<<<<<< Fragment header:
<<<<<<   total   = 1
<<<<<<   current = 0
<<<<<< Contents:
<<<<<<   service = 'basic-connect' (a289cc33-bcbb-8b4f-b6b0-133ec2aae6df)
<<<<<<   cid     = 'device-services' (0x00000010)
<<<<<<   type    = 'query' (0x00000000)

[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:BC: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

error: operation failed: Fragment timed out
[01 Apr 2014, 21:39:09] [Debug] [/dev/cdc-wdm0] Sent message...
<<<<<< RAW:
<<<<<<   length = 12
<<<<<<   data   = 02:00:00:00:0C:00:00:00:03:00:00:00

[01 Apr 2014, 21:39:09] [Debug] [/dev/cdc-wdm0] Sent message (translated)...
<<<<<< Header:
<<<<<<   length      = 12
<<<<<<   type        = close (0x00000002)
<<<<<<   transaction = 3

[01 Apr 2014, 21:39:09] [Debug] [/dev/cdc-wdm0] Sent message...
<<<<<< RAW:
<<<<<<   length = 16
<<<<<<   data   = 04:00:00:00:10:00:00:00:02:00:00:00:01:00:00:00

[01 Apr 2014, 21:39:09] [Debug] [/dev/cdc-wdm0] Sent message (translated)...
<<<<<< Header:
<<<<<<   length      = 16
<<<<<<   type        = host-error (0x00000004)
<<<<<<   transaction = 2
<<<<<< Contents:
<<<<<<   error = 'TimeoutFragment' (0x00000001)

[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:01: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


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


best regards
Morten Larsen


--
The linux-thinkpad mailing list home page is at:
http://mailman.linux-thinkpad.org/mailman/listinfo/linux-thinkpad
Reply | Threaded
Open this post in threaded view
|

Re: 2nd gen X1 carbon 3g/lte Sierra Wireless EM7345 4G LTE

Bjørn Mork
morten <[hidden email]> 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 start
> 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:BC: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:01: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
--
The linux-thinkpad mailing list home page is at:
http://mailman.linux-thinkpad.org/mailman/listinfo/linux-thinkpad
Reply | Threaded
Open this post in threaded view
|

Re: 2nd gen X1 carbon 3g/lte Sierra Wireless EM7345 4G LTE

Chuck Aurora
On Wed, Apr 02, 2014 at 10:24:27AM +0200, Bjørn Mork wrote:

> morten <[hidden email]> writes:
> > 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?

That's what I was wondering. I have an external USB device, the
Pantech UML295 (Verizon being the carrier.) It gives me this
cdc_ether driver:

Mar 31 17:25:26 tp kernel: [379939.016993] cdc_ether 3-6:1.0 eth1:
register 'cdc_ether' at usb-0000:00:14.0-6, CDC Ethernet Device,
d0:57:85:7a:a6:09

All I have to do is to DHCP on this Ethernet interface, and
"mbb.vzw.com[192.168.32.2]" becomes my gateway. It gives me a
little HTTP interface ( http://mbb.vzw.com/ ) to manage the
connection. Click connect, and Bob's your uncle, I'm online.

The internal mini-PCI cards do not have this? Or does cdc_mbim
conflict with cdc_ether? (Hmm, I guess not, unless cdc_mbim was
blacklisted somehow; I have both drivers.)

I'm looking at a Gobi 5000 for my Thinkpad T440p, but it is a $200
gamble, more if I have to pay for SIM activation. (I'm guessing I
might be able to use the Pantech's SIM for testing?)

It would be nice to have a real, routeable IP address, but the
important thing is to be able to USE the Internet connection.

So, Bjørn, do you need another tester for the Gobi? Does the
prognosis look good?
--
    Chuck Aurora | [hidden email] | ISC Support
--
The linux-thinkpad mailing list home page is at:
http://mailman.linux-thinkpad.org/mailman/listinfo/linux-thinkpad
Reply | Threaded
Open this post in threaded view
|

Re: 2nd gen X1 carbon 3g/lte Sierra Wireless EM7345 4G LTE

Bjørn Mork
Chuck Aurora <[hidden email]> writes:

> On Wed, Apr 02, 2014 at 10:24:27AM +0200, Bjørn Mork wrote:
>> morten <[hidden email]> writes:
>> > 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?
>
> That's what I was wondering. I have an external USB device, the
> Pantech UML295 (Verizon being the carrier.) It gives me this
> cdc_ether driver:
>
> Mar 31 17:25:26 tp kernel: [379939.016993] cdc_ether 3-6:1.0 eth1:
> register 'cdc_ether' at usb-0000:00:14.0-6, CDC Ethernet Device,
> d0:57:85:7a:a6:09
>
> All I have to do is to DHCP on this Ethernet interface, and
> "mbb.vzw.com[192.168.32.2]" becomes my gateway. It gives me a
> little HTTP interface ( http://mbb.vzw.com/ ) to manage the
> connection. Click connect, and Bob's your uncle, I'm online.
>
> The internal mini-PCI cards do not have this?

Mostly not.  But it's really unrelated to internal/external.  The
difference is the management interface exported by the modem firmware.
Most firmwares on internal modems depend on the host PC doing management
like configuring APN, selecting bands and/or networks etc.

You have a http interface, which has the advantages that it is simple to
set up and use, and works on almost any system. But the interface is
non-standard so you cannot expect any connection manager software like
ModemManager to support it.  Every modem will have a different http
interface, which you as a human can easily adapt to.  That's of course
not so with software.

The alternative is a more standardized API for the management software,
shared by a set of modems.  Traditially this has been AT commands, where
each vendor have created their own command set in addition to the
standard ITU-T and 3GPP ones.  This is still a lot better than an
model/operator specific http interface, because one application can
support a family of modems.  For a while we've had the Qualcomm
proprietary QMI as another alternative. This is now widely used because
Qualcomm chips have been dominating the market.

CDC MBIM is the latest alternative.  It's a USB-IF standard for Mobile
Broadband devices, just like the CDC ECM (cdc_ether) your modem use.
The main difference is that it standardizes a control channel and some
basic management messages for Mobile Broadband in addition to the IP
datagram transport.

MBIM is a requirement for Windows8 certification of Mobile Broadband
devices.  Microsoft got tired of all the vendor proprietary solutions
and wanted to integrate Mobile Broadband mangement tighter in the OS.
Good thing for us as well.

> Or does cdc_mbim
> conflict with cdc_ether? (Hmm, I guess not, unless cdc_mbim was
> blacklisted somehow; I have both drivers.)

These are both USB class drivers.  The USB device configuration
descriptor tells the host what type of function(s) a device supports.
That's what you see when you do a "lsusb -v", and that's what the OS and
drivers use to filter out which devices they should handle. There is no
conflict.  A CDC ECM function will be handled by the cdc_ether driver
and never touched by the cdc_mbim driver, and a CDC MBIM function will
be handled by the cdc_mbim driver and never touched by the cdc_ether
driver.


> I'm looking at a Gobi 5000 for my Thinkpad T440p, but it is a $200
> gamble, more if I have to pay for SIM activation. (I'm guessing I
> might be able to use the Pantech's SIM for testing?)

"Gobi" is Qualcomm's marketing name for devices supporting a standard
set of QMI services for management.  Most modern Qualcomm devices will
also do MBIM, usually selectable using multiple USB configurations.
Microsoft requires MBIM support in the default device identity for
Windows8 conformance.  Using multiple configurations conforms to that
requirement while still allowing support for "legacy systems"
(i.e. Windows7 and older - noone cares about Linux here :-)

I believe the Thinkpad Gobi 5000 device is a Sierra Wireless MC7750,
which should be supported pretty well in Linux using either QMI or MBIM.
I use a MC7710 myself (mostly same thing, but for Europe). In QMI mode
it even has serial ports supporting AT commands and PPP. So driver and
application support is not a problem.  The SIM activation and possible
operator locks and such stuff still makes it a gamble unfortunately.
Whether you can use the SIM from the Pantech depends on what your
operator allows you to do.

> It would be nice to have a real, routeable IP address, but the
> important thing is to be able to USE the Internet connection.
>
> So, Bjørn, do you need another tester for the Gobi? Does the
> prognosis look good?

Gobi devices should be supported by default, provided you use a somewhat
recent kernel (v3.6 or newer) and ModemManager (1.0 or newer) with
libqmi-glib support.



Bjørn
--
The linux-thinkpad mailing list home page is at:
http://mailman.linux-thinkpad.org/mailman/listinfo/linux-thinkpad
Reply | Threaded
Open this post in threaded view
|

Re: 2nd gen X1 carbon 3g/lte Sierra Wireless EM7345 4G LTE

Bjørn Mork
Bjørn Mork <[hidden email]> writes:

> I believe the Thinkpad Gobi 5000 device is a Sierra Wireless MC7750,

Ouch, this was wrong, wasn't it?  The Thinkpad Gobi 4000 is a Sierra
Wireless MC7750.  The 5000 is probably one of the newer Sierra modems,
like the MC7355?  Should still be supported, but might need adding a
device ID to the driver for QMI support.  MBIM should work out of the
box.


Bjørn
--
The linux-thinkpad mailing list home page is at:
http://mailman.linux-thinkpad.org/mailman/listinfo/linux-thinkpad
Reply | Threaded
Open this post in threaded view
|

Re: 2nd gen X1 carbon 3g/lte Sierra Wireless EM7345 4G LTE

Chuck Aurora
On Wed, Apr 02, 2014 at 01:04:44PM +0200, Bjørn Mork wrote:

> Bjørn Mork <[hidden email]> writes:
>
> > I believe the Thinkpad Gobi 5000 device is a Sierra Wireless
> > MC7750,
>
> Ouch, this was wrong, wasn't it?  The Thinkpad Gobi 4000 is a
> Sierra Wireless MC7750.  The 5000 is probably one of the newer
> Sierra modems, like the MC7355?  Should still be supported, but
> might need adding a device ID to the driver for QMI support.
> MBIM should work out of the box.

Thank you! This sounds very encouraging. I guess I will look at
ModemManager and see what it does with my USB dongle.
--
    Chuck Aurora | [hidden email] | ISC Support
--
The linux-thinkpad mailing list home page is at:
http://mailman.linux-thinkpad.org/mailman/listinfo/linux-thinkpad
Reply | Threaded
Open this post in threaded view
|

Re: 2nd gen X1 carbon 3g/lte Sierra Wireless EM7345 4G LTE

morten
In reply to this post by Bjørn Mork
Hello Bjørn

Thanks for you quick reply.

I have created a virtual machine for trying out different kernel
versions. My results are below.

On 04/02/2014 10:24 AM, Bjørn Mork wrote:

> morten <[hidden email]> 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.
Yes it was, however the fail was also triggered when trying to use
mbim-network script.

>
> 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...
with uname -a
Linux ubuntuexp-VirtualBox 3.14.0-031400-generic #201403310035 SMP Mon
Mar 31 04:36:23 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

modinfo cdc_mbim
filename:
/lib/modules/3.14.0-031400-generic/kernel/drivers/net/usb/cdc_mbim.ko
license:        GPL
description:    USB CDC MBIM host driver
author:         Bjørn Mork <[hidden email]>
author:         Greg Suarez <[hidden email]>
srcversion:     FE916B594C0D87867310A9D
alias:          usb:v*p*d*dc*dsc*dp*ic02isc0Eip00in*
alias:          usb:v0BDBp*d*dc*dsc*dp*ic02isc0Eip00in*
alias:          usb:v*p*d*dc*dsc*dp*ic02isc0Dip00in*
depends:        usbnet,cdc_ncm,cdc-wdm
intree:         Y
vermagic:       3.14.0-031400-generic SMP mod_unload modversions
signer:         Magrathea: Glacier signing key
sig_key: 81:29:87:03:9D:4A:1E:B1:AC:7B:5D:2B:4E:CD:B3:BA:9E:78:5C:D3
sig_hashalgo:   sha512

It got much worse. Now most commands fail, or gets a reply after a few
tries.

sudo mbimcli -d /dev/cdc-wdm0 --query-radio-state -v
[07 Apr 2014, 12:39:55] [Debug] [/dev/cdc-wdm0] Queried max control
message size: 512
[07 Apr 2014, 12:39:55] [Debug] [/dev/cdc-wdm0] Sent message...
<<<<<< RAW:
<<<<<<   length = 16
<<<<<<   data   = 01:00:00:00:10:00:00:00:01:00:00:00:00:02:00:00

[07 Apr 2014, 12:39:55] [Debug] [/dev/cdc-wdm0] Sent message (translated)...
<<<<<< Header:
<<<<<<   length      = 16
<<<<<<   type        = open (0x00000001)
<<<<<<   transaction = 1
<<<<<< Contents:
<<<<<<   max_control_transfer = 512

[07 Apr 2014, 12:39:55] [Debug] [/dev/cdc-wdm0] Received message...
 >>>>>> RAW:
 >>>>>>   length = 16
 >>>>>>   data   = 02:00:00:80:10:00:00:00:02:00:00:00:00:00:00:00

[07 Apr 2014, 12:39:55] [Debug] [/dev/cdc-wdm0] No transaction matched
in received message
[07 Apr 2014, 12:39:56] [Debug] [/dev/cdc-wdm0] Sent message...
<<<<<< RAW:
<<<<<<   length = 16
<<<<<<   data   = 01:00:00:00:10:00:00:00:02:00:00:00:00:02:00:00

[07 Apr 2014, 12:39:56] [Debug] [/dev/cdc-wdm0] Sent message (translated)...
<<<<<< Header:
<<<<<<   length      = 16
<<<<<<   type        = open (0x00000001)
<<<<<<   transaction = 2
<<<<<< Contents:
<<<<<<   max_control_transfer = 512

[07 Apr 2014, 12:39:56] [Debug] [/dev/cdc-wdm0] Received message...
 >>>>>> RAW:
 >>>>>>   length = 16
 >>>>>>   data   = 02:00:00:80:10:00:00:00:02:00:00:00:00:00:00:00

[07 Apr 2014, 12:39:56] -Error ** mbim_message_open_done_get_result:
assertion 'MBIM_MESSAGE_GET_MESSAGE_TYPE (self) ==
MBIM_MESSAGE_TYPE_OPEN_DONE' failed

(mbimcli:6221): GLib-GIO-CRITICAL **: g_simple_async_result_take_error:
assertion 'error != NULL' failed
[07 Apr 2014, 12:39:56] [Debug] MBIM Device at '/dev/cdc-wdm0' ready
[07 Apr 2014, 12:39:56] [Debug] Asynchronously querying radio state...
[07 Apr 2014, 12:39:56] [Debug] [/dev/cdc-wdm0] Sent message...
<<<<<< RAW:
<<<<<<   length = 48
<<<<<<   data   =
03:00:00:00:30:00:00:00:03:00:00:00:01:00:00:00:00:00:00:00:A2:89:CC:33:BC:BB:8B:4F:B6:B0:13:3E:C2:AA:E6:DF:03:00:00:00:00:00:00:00:00:00:00:00

[07 Apr 2014, 12:39:56] [Debug] [/dev/cdc-wdm0] Sent message (translated)...
<<<<<< Header:
<<<<<<   length      = 48
<<<<<<   type        = command (0x00000003)
<<<<<<   transaction = 3
<<<<<< Fragment header:
<<<<<<   total   = 1
<<<<<<   current = 0
<<<<<< Contents:
<<<<<<   service = 'basic-connect' (a289cc33-bcbb-8b4f-b6b0-133ec2aae6df)
<<<<<<   cid     = 'radio-state' (0x00000003)
<<<<<<   type    = 'query' (0x00000000)

[07 Apr 2014, 12:39:56] [Debug] [/dev/cdc-wdm0] Received message...
 >>>>>> RAW:
 >>>>>>   length = 16
 >>>>>>   data   = 02:00:00:80:10:00:00:00:02:00:00:00:00:00:00:00

[07 Apr 2014, 12:39:56] [Debug] [/dev/cdc-wdm0] No transaction matched
in received message
[07 Apr 2014, 12:39:57] [Debug] [/dev/cdc-wdm0] Received message...
 >>>>>> RAW:
 >>>>>>   length = 56
 >>>>>>   data   =
03:00:00:80:38:00:00:00:03:00:00:00:01:00:00:00:00:00:00:00:A2:89:CC:33:BC:BB:8B:4F:B6:B0:13:3E:C2:AA:E6:DF:03:00:00:00:00:00:00:00:08:00:00:00:01:00:00:00:01:00:00:00

[07 Apr 2014, 12:39:57] [Debug] [/dev/cdc-wdm0] Received message
(translated)...
 >>>>>> Header:
 >>>>>>   length      = 56
 >>>>>>   type        = command-done (0x80000003)
 >>>>>>   transaction = 3
 >>>>>> Fragment header:
 >>>>>>   total   = 1
 >>>>>>   current = 0
 >>>>>> Contents:
 >>>>>>   status error = 'None' (0x00000000)
 >>>>>>   service      = 'basic-connect'
(a289cc33-bcbb-8b4f-b6b0-133ec2aae6df)
 >>>>>>   cid          = 'radio-state' (0x00000003)

[/dev/cdc-wdm0] Radio state retrieved:
          Hardware Radio State: 'on'
          Software Radio State: 'on'
[07 Apr 2014, 12:39:57] [Debug] [/dev/cdc-wdm0] Sent message...
<<<<<< RAW:
<<<<<<   length = 12
<<<<<<   data   = 02:00:00:00:0C:00:00:00:04:00:00:00

[07 Apr 2014, 12:39:57] [Debug] [/dev/cdc-wdm0] Sent message (translated)...
<<<<<< Header:
<<<<<<   length      = 12
<<<<<<   type        = close (0x00000002)
<<<<<<   transaction = 4

error: couldn't close device: Transaction timed out

So now all commands have issues, I have tried to reboot both virtual
machine and physical machine, but it does not seem
to change anything.

>
>> Furtermore when I try to connect using sudo mbim-network /dev/cdc-wdm0 start
>> 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:BC: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:01: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.
The /dev/ttyACM0 can be openend but it does not appear to accept AT
commands tried with  echo "AT\r\n" > /dev/ttyACM0
> 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?
Not sure how to figure out, can you provide help?
>
> Bjørn
Lastly, is there any way to use the built in modem using pppd +
chatscript ?


--
The linux-thinkpad mailing list home page is at:
http://mailman.linux-thinkpad.org/mailman/listinfo/linux-thinkpad
Reply | Threaded
Open this post in threaded view
|

Re: 2nd gen X1 carbon 3g/lte Sierra Wireless EM7345 4G LTE

Bjørn Mork
morten <[hidden email]> writes:

>> 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.
>
> Yes it was, however the fail was also triggered when trying to use
> mbim-network script.

OK, and that script only does

    mbimcli -d $DEVICE --query-subscriber-ready-status --no-close
    mbimcli -d $DEVICE --query-registration-state --no-open=$TRID --no-close
    mbimcli -d $DEVICE --attach-packet-service --no-open=$TRID --no-close
    mbimcli -d $DEVICE --connect=$APN --no-open=$TRID --no-close
    mbimcli -d $DEVICE --query-connection-state --no-close --no-open=$TRID

which should all be within the 512 byte message size limit.

> It got much worse. Now most commands fail, or gets a reply after a few
> tries.

Ouch.  Unexpected, but very useful feedback.  Thanks.  Looks like we
have a job to do here.

Which would be a lot easier if I had one of these modems.  Unfortunately
I don't know how to get hold of one without buying a new Thinkpad... We
can try doing remote testing and debugging if you are willing to do
that, but I don't even know where to start so I'm not going to promise
success.

> <<<<<<   data   = 01:00:00:00:10:00:00:00:01:00:00:00:00:02:00:00
> >>>>>>   data   = 02:00:00:80:10:00:00:00:02:00:00:00:00:00:00:00
> <<<<<<   data   = 01:00:00:00:10:00:00:00:02:00:00:00:00:02:00:00
> >>>>>>   data   = 02:00:00:80:10:00:00:00:02:00:00:00:00:00:00:00

So that is

 tid 1: open
 tid 2: close done
 tid 2: open
 tid 2: close done

I do not understand how this sequence is possible.  Maybe the driver is
dropping some replies or something? Or maybe it failed to read some
earlier data?  But the "open" message should reset this in any case.



> <<<<<<   data   = 03:00:00:00:30:00:00:00:03:00:00:00:01:00:00:00:00:00:00:00:A2:89:CC:33:BC:BB:8B:4F:B6:B0:13:3E:C2:AA:E6:DF:03:00:00:00:00:00:00:00:00:00:00:00
> >>>>>>   data   = 02:00:00:80:10:00:00:00:02:00:00:00:00:00:00:00

And the device just continues to reply to tid 2 with "close done".  That
is completely unexpected.  There is no acking of these messages, so the
device should never send duplicates unless we send ducplicate
requests. It's normally just fire-and-forget.

> >>>>>>   data   = 03:00:00:80:38:00:00:00:03:00:00:00:01:00:00:00:00:00:00:00:A2:89:CC:33:BC:BB:8B:4F:B6:B0:13:3E:C2:AA:E6:DF:03:00:00:00:00:00:00:00:08:00:00:00:01:00:00:00:01:00:00:00

But then we actually do get a reply to one of our requests anyway?  Strange

> <<<<<<   data   = 02:00:00:00:0C:00:00:00:04:00:00:00
>
> [07 Apr 2014, 12:39:57] [Debug] [/dev/cdc-wdm0] Sent message (translated) ...
> <<<<<< Header:
> <<<<<<   length      = 12
> <<<<<<   type        = close (0x00000002)
> <<<<<<   transaction = 4
>
> error: couldn't close device: Transaction timed out

But we don't see the reply to the "close", after all those unexpected
"close done" replies.

> So now all commands have issues, I have tried to reboot both virtual
> machine and physical machine, but it does not seem
> to change anything.

Yes, this looks very wrong.  And I have no explanation.  I wonder if you
are able to do some usbsnooping?  Maybe it will help to see what data
actually is transmitted over the USB link, and when - looks like maybe
the driver somehow is completely unsyncronized with the device.

If you have a recent Wireshark, USB snooping on Linux is as easy as doing

 modprobe usbmon
 wireshark -i usbmonX

where X is the number of the USB bus you want to snoop on.  This is the
first number in the device address, e.g. reported by the driver probe.
For example, this device is on USB bus 2:

 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

It's best if other devices on the same bus can be kept silent while
snooping, to avoid unrelated packets in the dump.

>> 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.
>
> The /dev/ttyACM0 can be openend but it does not appear to accept AT
> commands tried with  echo "AT\r\n" > /dev/ttyACM0

OK.  Could be something else.  GPS NMEA data maybe?

>> 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?
>
> Not sure how to figure out, can you provide help?

lsusb -vd <vid>:<pid>

should show every available function.

> Lastly, is there any way to use the built in modem using pppd +
> chatscript ?

Probably not, if there is no function supporting AT commands.


Bjørn
--
The linux-thinkpad mailing list home page is at:
http://mailman.linux-thinkpad.org/mailman/listinfo/linux-thinkpad
Reply | Threaded
Open this post in threaded view
|

Re: 2nd gen X1 carbon 3g/lte Sierra Wireless EM7345 4G LTE

Bjørn Mork
Bjørn Mork <[hidden email]> writes:

>>> 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?
>>
>> Not sure how to figure out, can you provide help?
>
> lsusb -vd <vid>:<pid>
>
> should show every available function.

Thinking about it, it would be very interesting to see the output of
this.  Feel free to edit away the serial number (which might be your
IMEI) if you want to hide that.

Every Sierra MBIM device we've seen so far has had the same firmware
bug: The CDC Union functional descriptor is missing.  But all these
devices have been based on Qualcomm chips and used Qualcomm baseband
firmwares as a foundation.  Which probably doesn't include the
descriptors, so the missing union could be a Sierra specific bug.

I am curious whether that bug has crept into the Intel based devices
too, or if they are looking better?  The lsusb output will show.


Bjørn
--
The linux-thinkpad mailing list home page is at:
http://mailman.linux-thinkpad.org/mailman/listinfo/linux-thinkpad
Reply | Threaded
Open this post in threaded view
|

Re: 2nd gen X1 carbon 3g/lte Sierra Wireless EM7345 4G LTE

morten
Hello Bjorn and others

I can report that the 4G modem works on ubuntu 14.04 out of the box
using (i guess) cdc_wdm.

On 04/10/2014 03:19 PM, Bjørn Mork wrote:

> Bjørn Mork <[hidden email]> writes:
>
>>> Please let me know if there are other data you need. I will also be
>>> happy to do more remote testing.
>> I am completely lost wrt how we mess up the MBIM control channel in
>> v3.14.  So it would be nice to have some dumps of the USB traffic when
>> you try to use mbimcli.  So if you could do
>>
>>   modprobe usbmon
>>   tshark -i usbmon2 -w /tmp/foo.pcap
>>
>> and try to connect using mbim-network or mbimcli commands.
>>
>> Stop the capture when mbimcli has started failing and send me the
>> resulting foo.pcap.  I'm hoping it shows something obviously wrong.
>>
>> It's best if you can do this with as little other USB traffic as
>> possible on the same USB bus.
> Correction: Better make the capture command
>
>    tshark -i usbmon2 -s 2000 -w /tmp/foo.pcap
>
> to sure we capture the whole buffer.
It appears that my virtual machine setup was the issue, since the
command did not capture any usb traffic
now that i have upgraded my ubuntu to 14.04
Linux thinkpad 3.13.0-24-generic #46-Ubuntu SMP Thu Apr 10 19:11:08 UTC
2014 x86_64 x86_64 x86_64 GNU/Linux

every thing works as expected.

>
> Bjørn

--
The linux-thinkpad mailing list home page is at:
http://mailman.linux-thinkpad.org/mailman/listinfo/linux-thinkpad
Reply | Threaded
Open this post in threaded view
|

Re: 2nd gen X1 carbon 3g/lte Sierra Wireless EM7345 4G LTE

Bjørn Mork
morten <[hidden email]> writes:

> Hello Bjorn and others
>
> I can report that the 4G modem works on ubuntu 14.04 out of the box
> using (i guess) cdc_wdm.

Yeeha! Good to know.

I was really lost here, so it's very relieving that this worked after
all.  That's how Linux is supposed to be :-)

Thanks for reporting back


Bjørn
--
The linux-thinkpad mailing list home page is at:
http://mailman.linux-thinkpad.org/mailman/listinfo/linux-thinkpad
Reply | Threaded
Open this post in threaded view
|

Re: 2nd gen X1 carbon 3g/lte Sierra Wireless EM7345 4G LTE

Nikos Alexandris
* Bjørn Mork <[hidden email]> [2014-04-25 14:52:03 +0200]:

> morten <[hidden email]> writes:
>
> > Hello Bjorn and others
> >
> > I can report that the 4G modem works on ubuntu 14.04 out of the box
> > using (i guess) cdc_wdm.
>
> Yeeha! Good to know.
>
> I was really lost here, so it's very relieving that this worked after
> all.  That's how Linux is supposed to be :-)
>
How can I try this (in Funtoo/Gentoo)?  I got the networkmanager (KDE)
compiled with support for mobile networking (modemmanager)

I can see the devive "exists" grepping some "cdc" related calls with
dmesg.  But I am not sure how I can proceed in testing if it works.

Also, ifconfig doesn't return any "wwan" related interface.

Thanks for pointers/instructions.

Nikos
>


signature.asc (237 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: 2nd gen X1 carbon 3g/lte Sierra Wireless EM7345 4G LTE

Bjørn Mork
Nikos Alexandris <[hidden email]> writes:

> * Bjørn Mork <[hidden email]> [2014-04-25 14:52:03 +0200]:
>
>> morten <[hidden email]> writes:
>>
>> > Hello Bjorn and others
>> >
>> > I can report that the 4G modem works on ubuntu 14.04 out of the box
>> > using (i guess) cdc_wdm.
>>
>> Yeeha! Good to know.
>>
>> I was really lost here, so it's very relieving that this worked after
>> all.  That's how Linux is supposed to be :-)
>>
> How can I try this (in Funtoo/Gentoo)?  I got the networkmanager (KDE)
> compiled with support for mobile networking (modemmanager)

You need at least modemmanager 1.0 I believe.  And it must be built
with libmbim-support.

If you have that then you should get some output similar to this from
mmcli (it's easiest to start this way, keeping networkmanager out of the
loop until you know MM is working):



bjorn@nemi:~$ mmcli -L

Found 1 modems:
        /org/freedesktop/ModemManager1/Modem/0 [Generic] MBIM [1199:68A2]

bjorn@nemi:~$ mmcli -m 0

/org/freedesktop/ModemManager1/Modem/0 (device id '360f00302125cb70d85ba2caa1190192832f0b93')
  -------------------------
  Hardware |   manufacturer: 'Generic'
           |          model: 'MBIM [1199:68A2]'
           |       revision: 'SWI9200X_03.05.24.00ap'
           |      supported: 'gsm-umts, lte'
           |        current: 'gsm-umts, lte'
           |   equipment id: '358178040092316'
  -------------------------
  System   |         device: '/sys/devices/pci0000:00/0000:00:1d.7/usb3/3-4'
           |        drivers: 'cdc_mbim'
           |         plugin: 'Generic'
           |   primary port: 'cdc-wdm0'
           |          ports: 'cdc-wdm0 (mbim), wwan0 (net)'
  -------------------------
  Numbers  |           own : 'unknown'
  -------------------------
  Status   |           lock: 'sim-pin'
           | unlock retries: 'sim-pin (3)'
           |          state: 'locked'
           |    power state: 'on'
           |    access tech: 'unknown'
           | signal quality: '0' (cached)
  -------------------------
  Modes    |      supported: 'allowed: 2g, 3g, 4g; preferred: none'
           |        current: 'allowed: 2g, 3g, 4g; preferred: none'
  -------------------------
  Bands    |      supported: 'unknown'
           |        current: 'unknown'
  -------------------------
  IP       |      supported: 'ipv4, ipv6, ipv4v6'
  -------------------------
  SIM      |           path: '/org/freedesktop/ModemManager1/SIM/4'

  -------------------------
  Bearers  |          paths: 'none'



If this shows "ports: 'cdc-wdm0 (mbim), wwan0 (net)'" (possibly with
slightly different names and/or more ports), then you are ready to go.

A simple way to test that connecting works without using NM is:

# mmcli -m 0 --simple-connect=pin=1234,apn=yourapn

where you'll of course have to replace "1234" with your SIM PIN code and
"yourapn" with your APN (from your provider).  If you don't need a PIN
then you can just drop the "pin=1234," part.

If this is successful, you'll see "successfully connected the modem" and
you can run dhclient on the network interface:

# dhclient -d -4 wwan0
Internet Systems Consortium DHCP Client 4.2.2
Copyright 2004-2011 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/wwan0/7e:f4:7b:7b:17:47
Sending on   LPF/wwan0/7e:f4:7b:7b:17:47
Sending on   Socket/fallback
DHCPDISCOVER on wwan0 to 255.255.255.255 port 67 interval 5
DHCPREQUEST on wwan0 to 255.255.255.255 port 67
DHCPOFFER from 109.179.248.157
DHCPACK from 109.179.248.157
bound to 109.179.248.156 -- renewal in 3193 seconds.


If all that worked, then the modem should show up in NetworkManager too,
and you should be able to configure a connection there instead.

Further NM/MM debugging tips are found at
http://www.freedesktop.org/wiki/Software/ModemManager/Debugging/


> I can see the devive "exists" grepping some "cdc" related calls with
> dmesg.  But I am not sure how I can proceed in testing if it works.
>
> Also, ifconfig doesn't return any "wwan" related interface.

This is probably because you are using udev with the new style device
names.  Then the interface will be called 'ww...something'.  mmcli
should show the real interface name, and it should also show up in
the output of 'ifconfig -a'.


Bjørn
--
The linux-thinkpad mailing list home page is at:
http://mailman.linux-thinkpad.org/mailman/listinfo/linux-thinkpad
Reply | Threaded
Open this post in threaded view
|

Re: 2nd gen X1 carbon 3g/lte Sierra Wireless EM7345 4G LTE

Bjørn Mork
In reply to this post by Bjørn Mork
Bjørn Mork <[hidden email]> writes:

>> <<<<<<   data   = 03:00:00:00:30:00:00:00:03:00:00:00:01:00:00:00:00:00:00:00:A2:89:CC:33:BC:BB:8B:4F:B6:B0:13:3E:C2:AA:E6:DF:03:00:00:00:00:00:00:00:00:00:00:00
>> >>>>>>   data   = 02:00:00:80:10:00:00:00:02:00:00:00:00:00:00:00
>
> And the device just continues to reply to tid 2 with "close done".  That
> is completely unexpected.  There is no acking of these messages, so the
> device should never send duplicates unless we send ducplicate
> requests. It's normally just fire-and-forget.
>
>> >>>>>>   data   = 03:00:00:80:38:00:00:00:03:00:00:00:01:00:00:00:00:00:00:00:A2:89:CC:33:BC:BB:8B:4F:B6:B0:13:3E:C2:AA:E6:DF:03:00:00:00:00:00:00:00:08:00:00:00:01:00:00:00:01:00:00:00
>
> But then we actually do get a reply to one of our requests anyway?  Strange
>
>> <<<<<<   data   = 02:00:00:00:0C:00:00:00:04:00:00:00
>>
>> [07 Apr 2014, 12:39:57] [Debug] [/dev/cdc-wdm0] Sent message (translated) ...
>> <<<<<< Header:
>> <<<<<<   length      = 12
>> <<<<<<   type        = close (0x00000002)
>> <<<<<<   transaction = 4
>>
>> error: couldn't close device: Transaction timed out
>
> But we don't see the reply to the "close", after all those unexpected
> "close done" replies.


Just FYI: Now that I finally have one of these modems myself I've been
able to figure out what's happening here.  I believe the issue is that
the modem under certain conditions will queue up replies and indications
for which it never successfully have notified the host. The result is
that the driver and modem gets out of sync. The modem keeps adding
messages to its queue and notifying the driver, and the driver will read
the *first* message in the queue.  The problem is that there are more
than one unread messages queued up, and the first message is not the one
corresponding to the current notification.

I don't really know how to fix this.  I sincerely believe it is a modem
firmware bug.  The modem is supposed to notify the host about *every*
message it queues up.  The question is of course how it should handle
notification failures.  I don't see any way the host can possibly deal
with those (as the problem really is that the modem cannot communicate
with the host at the time of failure), so I believe it is up to the
modem firmware to either retry the notification or drop the message.
The usage pattern triggering the bug is probably unexpected seen from
the firmware developers side, but I still think it should be handled
better than this.

The way we trigger this problem is for example by using mbimcli with
--no-close and some command which takes time to complete.  We then send
the command and the modem prepares a reply.  But by the time the modem
is ready to notify us about the reply, we have already closed the
character device and the driver has killed the interrupt URB.  So the
modem is unable to send its notification.  But it still queues the
reply, and we are out-of-sync...

The good news is that this won't happen during what I consider "normal"
usage: If you let ModemManager manage the modem then the character
device is not closed and the interrupt URB is kept active.  So the modem
can successfully send all its notifications, and we will empty the
message queue immediately.


Bjørn
--
The linux-thinkpad mailing list home page is at:
http://mailman.linux-thinkpad.org/mailman/listinfo/linux-thinkpad