Sierra Wireless EM7455, MBIM connect

[Bjørn Mork]

Fabian Schörghofer <fabian.schoergi at gmail.com> writes:

> This is my attempt to connect with umbim and OpenWrt:
>
> Device plugged in:
>
> Linux OpenWrt 4.1.20 #1 Mon Apr 18 16:04:52 UTC 2016 mips GNU/Linux
>
> root at OpenWrt:/# [ 3499.696668] usb 1-1: new high-speed USB device
> number 4 using ehci-platform
> [ 3499.847624] usb 1-1: config 1 has an invalid interface number: 12
> but max is 3
> [ 3499.854927] usb 1-1: config 1 has an invalid interface number: 13
> but max is 3
> [ 3499.862243] usb 1-1: config 1 has an invalid interface number: 13
> but max is 3
> [ 3499.869533] usb 1-1: config 1 has no interface number 1
> [ 3499.874801] usb 1-1: config 1 has no interface number 2
> [ 3499.885599] qcserial 1-1:1.0: Qualcomm USB modem converter detected
> [ 3499.892407] usb 1-1: Qualcomm USB modem converter now attached to ttyUSB0
> [ 3499.917052] qcserial 1-1:1.3: Qualcomm USB modem converter detected
> [ 3499.923796] usb 1-1: Qualcomm USB modem converter now attached to ttyUSB1
> [ 3499.946248] cdc_mbim 1-1:1.12: cdc-wdm0: USB WDM device
> [ 3499.953031] cdc_mbim 1-1:1.12 wwan0: register 'cdc_mbim' at
> usb-ehci-platform-1, CDC MBIM, 0a:22:35:a2:a5:29
> [ 3499.966301] 8021q: adding VLAN 0 to HW filter on device wwan0
>
> Leaving the device open with: cat >/dev/cdc-wdm0
>
> root at OpenWrt:/# umbim -n -d /dev/cdc-wdm0 caps
>   devicetype: 0003 - remote
>   cellularclass: 0001
>   voiceclass: 0001 - no-voice
>   simclass: 0002
>   dataclass: 003C
>   smscaps: 0003
>   controlcaps: 0001
>   maxsessions: 0008
>   deviceid: 35432407xxxxxxx
>   firmwareinfo: SWI9X30C_02.08.02.00
>   hardwareinfo: EM7455
>
> Somehow umbim (or the modem) thinks that it needs pin2, but I have
> deactivated the pin with a normal mobile phone:
>
> root at OpenWrt:/# umbim -n -d /dev/cdc-wdm0 pinstate
> required pin: 3 - pin2
> remaining attempts: 3

This is normal for many of these Qualcomm based modems.  It's the state
they report when pin1 is verified but pin2 is not.  But it doesn't mean
that you have to verify pin2.  You only need that if you're going to run
any pin2 protected command.  Which I'm not even sure you can at all
using only standard MBIM requests? 

Well, simply ignore it.  It means that pin1 is verified and that's all
you need.

> I then try to connect:
>
> root at OpenWrt:/# umbim -v -n -d /dev/cdc-wdm0 connect
> sending (16): 01 00 00 00 10 00 00 00 01 00 00 00 00 04 00 00
>   header_type: 0001
>   header_length: 0010
>   header_transaction: 0001
> reading (16): 01 00 00 80 10 00 00 00 01 00 00 00 00 00 00 00
>   header_type: 80000001
>   header_length: 0010
>   header_transaction: 0001
> sending (108): 03 00 00 00 6c 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 0c 00 00 00 01
> 00 00 00 3c 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00 7e 5e 2a 7e 4e 6f 72 72 73 6b 65 6e 7e 5e 2a 7e
>   header_type: 0003
>   header_length: 006C
>   header_transaction: 0002
> reading (48): 03 00 00 80 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 0c 00 00 00 0e 00
> 00 00 00 00 00 00
>   header_type: 80000003
>   header_length: 0030
>   header_transaction: 0002
>   command_id: 000C
>   status_code: 000E

Note the non-zero status_code.  umbim should probably emphasize this a
bit...  It means failure, and the way umbim handles failures makes them
pretty final.  Which is fine, really. You just need to be aware.

umbim sends close because of the error, and there is no point in trying
any more commands after this:

> sending (16): 02 00 00 00 10 00 00 00 03 00 00 00 01 00 00 00
>   header_type: 0002
>   header_length: 0010
>   header_transaction: 0003
> reading (16): 02 00 00 80 10 00 00 00 03 00 00 00 00 00 00 00
>   header_type: 80000002
>   header_length: 0010
>   header_transaction: 0003



I debugged this case recently (yet again...) and discovered (for
probably the 5th time or so), that these modems need a
SUBSCRIBER_READY_STATUS request before connect.  Try to do a

  umbim -n -d /dev/cdc-wdm0 subscriber

before the connect and see if that helps.


Bjørn