mbim-proxy listening to systemd suspend/resume events

[Bjørn Mork]

Giacinto Cifelli <gciofono at gmail.com> writes:
> 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

That's not always true.  There is no such requirement. And some hosts
can be confgured to keep VBUS always on.


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

No, USB suspend is a data line thingy.  We do that all the time with
autosuspend, even with active connections if the modem supports remote
wakeup.

> And it does.
> This strategy would work seamlessly on plain RS232/422 lines, thou. But in
> that case no MBIM.

FWIW, I just tested this since you made me unsure of myself :-)

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.

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.

Note that a device doesn't have to draw much power in this state.  The
USB controller is suspended, and the radio can also be suspended most of
the time.  This is actually the same when the host is alive too, as long
as there is no traffic.   Whether the host cpu is suspended or not is
pretty irrelevant to the device.

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

>> 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's fast, but usually associated with a new dynamic ip address, which
means that you lose all existing tcp sessions.  To me, that's the
highest cost of a reboot.

Ok, if you want to argue that this is broken by those networks that
can't even keep your address stable, then I have to agree.  The ever
changing address on mobile networks makes this much harder than
necessary.

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

Whatever.  That's how tcp works.  You can suspend it just fine until
someone comes along and breaks it with a lot of assumptions.  Stupid
stateful firewalls are another part of this.  But don't get me started
on that one :-)


Bjørn