Delayed response to MBIM OPEN message

Aleksander Morgado aleksander at
Thu Feb 20 00:52:43 PST 2014

On Wed, Feb 19, 2014 at 6:56 PM, Ben Chan <benchan at> wrote:
>> libmbim currently retries the OPEN message
>> (mbim-device.c:open_message) every 1s, if the modem does not respond.
>> However, MS recommends delaying MBIM OPEN
>> (
>> as follows:
>> "MBIM devices may require time to complete initialization when they
>> receive MBIM OPEN message from the host. The device should wait for
>> its initialization to complete before responding to the MBIM OPEN
>> message. The device should not respond to the message with error
>> status like MBIM_STATUS_BUSY and expect the host to poll the device
>> with MBIM OPEN messages. Responding to MBIM OPEN with a status other
>> than MBIM_STATUS_SUCCESS terminates the initialization process on the
>> host."
>> From my observation, it looks like modem vendors follow this
>> recommendation and delay the response to the OPEN message while the
>> modem is still initializing. The initialization process gets
>> unnecessarily terminated if libmbim retries the OPEN message too soon.
>> Other than letting libmbim to wait (much) longer before retrying the
>> OPEN message, I'm not sure if there is any better solution.
>> How do you think?
>> Thanks,
>> Ben
> As the transaction already has a timeout and a cancelable object, perhaps we
> can simply increase the retry interval. I can help gather some data on how
> long it takes for modems to initialize.

I'm not sure what the problem is, as I believe we're already doing
what the recommendation says. The recommendation says that the
function should expect the host to poll the device with MBIM_OPEN, and
that is what we do: mbim_device_open() will launch a MBIM_OPEN every
1s until it gets a correct reply. Or, have you seen that subsequent
MBIM_OPEN messages end up terminating the initialization process? One
thing to do would be to increase the time between MBIM_OPEN replies;
i.e. giving more timeout to each MBIM_OPEN message to get the reply,
but not sure why that would help. If we increase too much the
MBIM_OPEN message retry, e.g. to 10s or so, we would be expecting for
the first MBIM_OPEN message to get completed, but at that time we
don't know whether the modem accepted that message or not (and
therefore the whole port probing would get delayed even more).

One thing to do would be to check, with all the MBIM devices that we
have around, whether the modem always accepts the first MBIM_OPEN that
it gets (e.g. looking at which responses it sends back).

Which is the device showing the weird behaviour, if there is any? Is
this the ZTE one?


More information about the libmbim-devel mailing list