Sierra Wireless EM7305

[Bjørn Mork]

Aleksander Morgado <aleksander at aleksander.es> writes:

> Hey guys,
>
> Just got this bugreport in ModemManager:
>
> https://bugzilla.gnome.org/show_bug.cgi?id=726613
>
> This is a Sierra device which exposes a cdc-wdm MBIM port. The port
> seems to send radio-state MBIM indications over and over again, but
> won't reply to our MBIM open requests, so ModemManager ends up
> deciding it is not MBIM. Has anyone seen something like this before?
>
> https://bug726613.bugzilla-attachments.gnome.org/attachment.cgi?id=272245

Looks like something else might be interferring?  I do not find it
likely that the device sends radio-state indications without being in
an "open" state, so something has probably opened it. 

And the device does reply to your OPENs, just not while your you are
waiting for the reply....  Looking a bit down in the log, I see:

ModemManager[26227]: [/dev/cdc-wdm0] Sent message (translated)...
<<<<<< Header:
<<<<<<   length      = 16
<<<<<<   type        = open (0x00000001)
<<<<<<   transaction = 9
<<<<<< Contents:
<<<<<<   max_control_transfer = 4096
ModemManager[26227]: [/dev/cdc-wdm0] Received message...
>>>>>> RAW:
>>>>>>   length = 16
>>>>>>   data   = 01:00:00:80:10:00:00:00:04:00:00:00:00:00:00:00
ModemManager[26227]: [/dev/cdc-wdm0] No transaction matched in received message
ModemManager[26227]: <debug> [1395124804.853091] [mm-qcdm-serial-port.c:205] debug_log(): (ttyS0): --> 7e 00 78 f0 7e
ModemManager[26227]: [/dev/cdc-wdm0] Sent message...
<<<<<< RAW:
<<<<<<   length = 16
<<<<<<   data   = 01:00:00:00:10:00:00:00:0A:00:00:00:00:10:00:00
ModemManager[26227]: [/dev/cdc-wdm0] Sent message (translated)...
<<<<<< Header:
<<<<<<   length      = 16
<<<<<<   type        = open (0x00000001)
<<<<<<   transaction = 10
<<<<<< Contents:
<<<<<<   max_control_transfer = 4096
ModemManager[26227]: [/dev/cdc-wdm0] Received message...
>>>>>> RAW:
>>>>>>   length = 16
>>>>>>   data   = 01:00:00:80:10:00:00:00:05:00:00:00:00:00:00:00


Here you get replies to your OPEN requests with transaction IDs 4 and 5,
but ignore them because you have already moved on to transaction ID 9
and 10 etc.  I guess this needs to be handled somehow. Maybe increase
the timeout if you ever receive an outdated MBIM_OPEN_DONE reply?

At this point you have already sent the tid 10 MBIM_OPEN, so you have no
other option than waiting for the reply to that request.  But you could
use the other MBIM_OPEN_DONE messages to figure out that the timeout is
too short and adjust accordingly.


Bjørn