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

[Bjørn Mork]

morten <mortenlarsens@gmail.com> 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