mbim-proxy: open retries
gpsuarez2512 at gmail.com
Mon Jul 28 12:25:22 PDT 2014
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
> 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
Yes, we should track the open state of the device with a flag i.e.
> 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
I don't think there's any other choice than for the proxy to handle the
itself. We can't have multiple clients sending multiple opens to the
> 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.
> 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
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the libmbim-devel