mbim-proxy listening to systemd suspend/resume events

[Giacinto Cifelli]

Hi Bjørn,

On Sun, Sep 13, 2020 at 10:56 AM Bjørn Mork <bjorn at mork.no> wrote:

> Aleksander Morgado <aleksander at aleksander.es> writes:
>
> > This is something that could obviously be fixed in the side of the
> > device, but it is also something we can avoid in the host side, by
> > making sure all MBIM sessions between host and device are brought down
> > on suspend, and brought up again automatically on resume.
>
> Won't that disconnect all IP sessions as a side effect?  I can imagine
> use cases where that's unwanted.
>

This patch is for host suspended, which drops the USB VBUS line (ie:
disconnects). At least I have not seen any application/controller that
keeps the line up.
And when it is re-connected on resume, then the device is re-enumerated and
all PDNs are inevitably lost.


> IMHO, the host should (and do) suspend the USB bus, but not touch any
> higher level stuff unless explicitly configured to do so.  This will
> allow a powered modem to maintain active connections, so that the host
> can resume them when it wakes up.
>

It doesn't work if VBUS goes down (USB suspend/resume transit on VBUS, not
on the data lines). And it does.
This strategy would work seamlessly on plain RS232/422 lines, thou. But in
that case no MBIM.


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


> I hate all sort of "bring down networking" on suspend.  It just makes
> suspend pointless.  You might as well power off then.
>

Power off has a much higher cost in terms of reboot of the host and the
device.
Re-establishing the PDNs is fast if the modem is already registered.

It is inconvenient for the high-level, for sure, but some applications stay
suspended for days. It also costs resources on the remote side to keep
unused TCP connection structures in memory.

Regards,
Giacinto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libmbim-devel/attachments/20200913/89a7e294/attachment.htm>