mbim-proxy: open retries

[Greg Suarez]

On Sun, Jul 27, 2014 at 3:56 PM, Aleksander Morgado <
aleksander at aleksander.es> wrote:

> Hey Greg,
>
> 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


>
> 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.


>
> 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


>
> 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.


> If we do that that way there should also not be any problem with
> multiple processes requesting MBIM Open, which is also another issue
> going on right now...
>
> What do you think?
>
> P.S.: thinking in making a new stable libmbim release, and just merge
> the proxy stuff afterwards in git master to keep experimenting.
>
> --
> Aleksander
> https://aleksander.es
>

Greg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/libmbim-devel/attachments/20140728/ebd360c8/attachment.html>