[PATCH 2/2 v3] mbimcli: new '--ms-query-firmware-id' action

Bjørn Mork bjorn at mork.no
Thu Feb 27 03:30:12 PST 2014

Bjørn Mork <bjorn at mork.no> writes:

> [27 Feb 2014, 10:51:39] [Debug] [/dev/cdc-wdm1] Received message (translated)...
>>>>>>> Header:
>>>>>>>   length      = 48
>>>>>>>   type        = command-done (0x80000003)
>>>>>>>   transaction = 2
>>>>>>> Fragment header:
>>>>>>>   total   = 1
>>>>>>>   current = 0
>>>>>>> Contents:
>>>>>>>   status error = 'NoDeviceSupport' (0x00000009)
>>>>>>>   service      = 'invalid' (00000000-0000-0000-0000-000000000000)
>>>>>>>   cid          = '(null)' (0x00000001)

I started wondering if this reply is really according to spec or not.
But I cannot say for sure.  Anyone else know?

Unless I've missed something, then the "unsupported service" behaviour
is not clearly defined.  I guess the assumption is that a well behaved
host will never send an unsupported command.

Well, I'm pretty sure hosts will do in the real world, so I do consider
this an error in the spec.

A MBIM_FUNCTION_ERROR_MSG response would have made sense IMO, but there
are no suitable error codes so it cannot be used (without an addional
error code for this purpose).

The MBIM_COMMAND_DONE with a 'NoDeviceSupport' status, like the DWM-156
do, looks like the best alternative within the current spec.  It would
have been nice if the unknown service UUID was copied from the request,
but I cannot find any such requirement. So I guess the response above is
OK.  The 'NoDeviceSupport' is independent of CID and service anyway, so
the service UUID doesn't really matter.

Note that the Huawei E367 firmware doesn't respond to unknown services
at all.  AFAICS, this is also allowed by the spec.  Although I do
believe it is better to do as the DWM-156, allowing errors to be caught
immediately instead of depending on timeouts.


More information about the libmbim-devel mailing list