mbim-proxy: open retries

[Aleksander Morgado]

Hey,

I've already pushed some commits to the greg/proxy branch. Refactored
quite some things, and added some more complexity. My changes are not
finished yet and I may have introduced more bugs :) so beware... I
hope to keep on working on this some more time this week.

>>
>> Next thing I've found during my tests, is that when using the proxy
>> the open retries logic that we have doesn't make proper sense any
>> more.
>>
>> One of the issues I found is that we assume the MbimDevice is open as
>> soon as we have a iochannel internally. That's wrong, because the
>> iochannel is created during the MBIM Open procedure, but it is kept
>> open both while we're still trying to open and also if we fail the
>> open. The tests I've done are with non-MBIM /dev/cdc-wdm ports; in
>> this case, we never get an MBIM Open response, but still clients using
>> the proxy will get notified that the device is open (so, e.g.
>> ModemManager could end up thinking the /dev/cdc-wdm port is really an
>> MBIM device while it's not). That's something we should handle
>> somehow.
>
>
> Yes, we should track the open state of the device with a flag i.e.
> DEVICE_STATE_CLOSED,
> DEVICE_STATE_OPEN_IN_PROGRESS,
> DEVICE_STATE_OPEN
>

Exactly what I did, just different names.

>>
>>
>> The other issue is regarding open retries. We added a set of open
>> retries in case some devices needed time to settle before correctly
>> replying to the Open request. With the proxy running in, the proxy
>> itself ends up handling the retries; but the clients who requested
>> that open will not (as soon as the iochannel is built, the MbimDevice
>> is assumed open, as in the previous paragraph). So that takes us to
>> what to do with the retries. Should clients handle those themselves
>> (i.e. the proxy would just be proxying the retry Open requests)? Or
>> should the proxy itself somehow take care of the full Open logic with
>> the device, including the retries logic? In this latter case, we could
>> delay the Open requests from the client until we get one of the Open
>> retries replied by the device. We would need to queue these requests
>> one after the other, and reply them all together. Clients will have
>> their own timeouts anyway for each reply, so that shouldn't be an
>> issue.
>
>
> I don't think there's any other choice than for the proxy to handle the
> retries
> itself.  We can't have multiple clients sending multiple opens to the
> device.
>

I updated the proxy configuration message to receive the timeout to
use from the clients; so that during the proxy config we try to open
using that timeout. Also, if there are multiple clients trying to open
the same underlying MBIM port, the requests will now be queued so that
the real MBIM Open operation is only done once (need to properly test
that though). One of the drawbacks here is that mixing different open
timeouts from different clients won't work, but that can be handled
once we get the basics right...

>>
>>
>> If the proxy ends up taking care of the actual open status of the
>> device, we could also monitor for "not open" errors reported by the
>> device (e.g. when coming back from suspend/resume cycle) and
>> automatically re-open the device internally in the proxy.
>
>
> Agreed
>

Still need to play with that. Not sure if we should really do that; as
potentially other processes may still think that the device is in Open
state... e.g. ModemManager would better restart probing the device if
that happens.

>>
>>
>> I believe that, since we're not going to explicitly close MBIM devices
>> when using the proxy, the proxy itself should handle opening them as
>> soon as it gets notified about the port to use. So, we could directly
>> open (try to open) the device as soon as we get the internal proxy
>> configuration message; then when Open requests come from clients, just
>> delay them until the internal Open is finished.
>
>
> This would require passing the "--no-open" option with the
> MBIM_CID_PROXY_CONTROL_CONFIGURATION.
>

Not really. The --no-open message is to allow clients to talk to an
already Open MBIM port. But the proxy itself *always* needs to have it
open in this case.

-- 
Aleksander
https://aleksander.es