mbim-proxy listening to systemd suspend/resume events

[Aleksander Morgado]

Hey!

> It has been a while since the last time I tested.  None of my laptops
> have been able to keep the internal modem slot powered, so it's not a
> feature I am able to use for real.  In fact, I don't think I've ever
> tested it with MBIM before, since my previous test most likely was
> before the cdc_mbim driver was written.  But I know it worked fine with
> qmi_wwan a very long time ago.
>
> Anyway, I just tried now with an EM7565 in MBIM mode, connected to an
> external USB port on my laptop (Thinkpad X1 4th gen) using a USB3
> adapter and cable.  This did not work...  The device is reset when the
> host resumes.
>
> So I dug out my old laptop (Thinkpad X301), which is the one I use for
> the previous test.  And it worked with the modem in MBIM mode too.
> Connected, logged into a remote server over ssh with TCPKeepAlive=no,
> suspended the laptop, resumed it, and watched the ssh connection still
> being alive.
>
> What didn't work so well was ModemManager forgetting all about the modem
> on resume, and "discovering" it as a new modem.  So the active
> connection was not unmanaged after resume.
>

I may have been biased when I proposed the solution bause it "fits"
the ModemManager use case, and didn't think about other cases... The
truth is that upon suspend, right now ModemManager does close (at
MM<->proxy level) the MBIM session (and explicitly release QMI clients
in QMI modems, and close all TTYs in AT-controlled modems). So, MM
does not make any attempt on keeping the connection up during the
suspend, on the contrary, it attempts to release everything. And on
resume, it re-probes the devices from scratch, because it is assumed
that usually the modems get reseted on a suspend/resume cycle. This is
the "default", which can be disabled by avoiding the suspend/resume
monitoring when building MM.

The change I proposed for the proxy follows this same pattern really;
it doesn't add any additional limitation for the ModemManager case,
because MM would already close the MBIM session with the proxy. But I
understand that adding this logic may affect non-MM libmbim users.

Another solution that I thought of was to have MM notify the
mbim-proxy that upon the MBIM session close (which MM will do on
suspend anyway at MM<->proxy level), it should also force closing the
MBIM session with the device (at proxy<->device level). But, then,
this logic would only apply to the MM usecase, and if there are
systems out there that require this change without using MM, they
wouldn't get it...


> But suspending and resuming with an active MBIM session does definitely
> work, given the right conditions.  So I think we should rather try to
> fix the current issues, and not add more problems.
>

The problem is that the issues are at device firmware level; this is
something Giacinto may help with in the special case of the mPLS62,
but I wouldn't call this a general solution. Plus, I'm again biased
with what ModemManager does in this regard, as there is no effect in
the MM behavior when this new logic is added.

> >> Killing connections on suspend and reconnecting on resume is sub-optimal
> >> behaviour.  It breaks all established tcp sessions unless you have a
> >> static address.  Completely unnecessary.
> >>
> >
> > From a device point of view, the application asks for notifications, and
> > then doesn't read them.
> > It is forced to buffer them, and the buffer is limited.
>
> The device knows the USB connection is suspended.  It should not attempt
> to send any USB data when this happens.  This is the same on the host
> side.  We kill URBs before suspending.
>
> There is no obligation to buffer everything on the device.  That would
> not scale at all. The device can and should drop anything it cannot
> deliver in a timely manner, whether that is a notification for the host
> or incoming data packets from the network.
>

Yes, I do agree that the device firmware should be robust enough to
handle this, and this has also been my suggestion when I learned about
this issue. The device should be able to handle this nicely, not rely
on the host requiring the MBIM session close.

As with MM's own suspend/resume logic, it's really optional at build
time, and if there are systems that require to keep open TCP sessions
during suspend, this can be disabled. Don't take me wrong, I totally
understand your point regarding the open TCP sessions, but if we were
to support that I would first focus on doing it at MM level in a
generic way. Until that is not working in MM, I personally wouldn't
care much about supporting it in libmbim/proxy, but again, that is my
extremely biased view :)

One thing we could do, though, is to have a new
MBIM_DEVICE_OPEN_FLAGS_PROXY_SUSPEND_RESUME flag applicable when
mbim_device_open() is called. ModemManager could set that to request
the proxy to handle the suspend/resume session closing, and we would
also add it as a new optional flag in mbimcli so that mbimcli users
can also request it if needed (or avoid it if not needed). I think
this would fit everyone's needs? It does add complexity to the proxy
to solve problems that we shouldn't take care of at host level, but
aren't we all doing this all the time everywhere from kernel up to MM?
:/

-- 
Aleksander
https://aleksander.es