<div dir="ltr">On Sun, Jul 27, 2014 at 3:56 PM, Aleksander Morgado <span dir="ltr"><<a href="mailto:aleksander@aleksander.es" target="_blank">aleksander@aleksander.es</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hey Greg,<br>
<br>
Next thing I've found during my tests, is that when using the proxy<br>
the open retries logic that we have doesn't make proper sense any<br>
more.<br>
<br>
One of the issues I found is that we assume the MbimDevice is open as<br>
soon as we have a iochannel internally. That's wrong, because the<br>
iochannel is created during the MBIM Open procedure, but it is kept<br>
open both while we're still trying to open and also if we fail the<br>
open. The tests I've done are with non-MBIM /dev/cdc-wdm ports; in<br>
this case, we never get an MBIM Open response, but still clients using<br>
the proxy will get notified that the device is open (so, e.g.<br>
ModemManager could end up thinking the /dev/cdc-wdm port is really an<br>
MBIM device while it's not). That's something we should handle<br>
somehow.<br></blockquote><div><br></div><div>Yes, we should track the open state of the device with a flag i.e.<br></div><div>DEVICE_STATE_CLOSED,<br></div><div>DEVICE_STATE_OPEN_IN_PROGRESS,<br></div><div>DEVICE_STATE_OPEN<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
The other issue is regarding open retries. We added a set of open<br>
retries in case some devices needed time to settle before correctly<br>
replying to the Open request. With the proxy running in, the proxy<br>
itself ends up handling the retries; but the clients who requested<br>
that open will not (as soon as the iochannel is built, the MbimDevice<br>
is assumed open, as in the previous paragraph). So that takes us to<br>
what to do with the retries. Should clients handle those themselves<br>
(i.e. the proxy would just be proxying the retry Open requests)? Or<br>
should the proxy itself somehow take care of the full Open logic with<br>
the device, including the retries logic? In this latter case, we could<br>
delay the Open requests from the client until we get one of the Open<br>
retries replied by the device. We would need to queue these requests<br>
one after the other, and reply them all together. Clients will have<br>
their own timeouts anyway for each reply, so that shouldn't be an<br>
issue.<br></blockquote><div><br></div><div>I don't think there's any other choice than for the proxy to handle the retries<br>itself.  We can't have multiple clients sending multiple opens to the device.<br> <br>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
If the proxy ends up taking care of the actual open status of the<br>
device, we could also monitor for "not open" errors reported by the<br>
device (e.g. when coming back from suspend/resume cycle) and<br>
automatically re-open the device internally in the proxy.<br></blockquote><div><br></div><div>Agreed<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<br>
I believe that, since we're not going to explicitly close MBIM devices<br>
when using the proxy, the proxy itself should handle opening them as<br>
soon as it gets notified about the port to use. So, we could directly<br>
open (try to open) the device as soon as we get the internal proxy<br>
configuration message; then when Open requests come from clients, just<br>
delay them until the internal Open is finished.<br></blockquote><div><br></div><div>This would require passing the "--no-open" option with the <br>MBIM_CID_PROXY_CONTROL_CONFIGURATION.<br></div><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<br>
If we do that that way there should also not be any problem with<br>
multiple processes requesting MBIM Open, which is also another issue<br>
going on right now...<br>
<br>
What do you think?<br>
<br>
P.S.: thinking in making a new stable libmbim release, and just merge<br>
the proxy stuff afterwards in git master to keep experimenting.<br>
<span class=""><font color="#888888"><br>
--<br>
Aleksander<br>
<a href="https://aleksander.es" target="_blank">https://aleksander.es</a><br></font></span></blockquote><div><br></div><div>Greg <br></div></div><br></div></div>