<div dir="ltr"><div dir="ltr">Hi Bjørn,<div><br></div><div>thank you for your views.</div><div><br></div></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Sep 13, 2020 at 6:44 PM Bjørn Mork <<a href="mailto:bjorn@mork.no">bjorn@mork.no</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Giacinto Cifelli <<a href="mailto:gciofono@gmail.com" target="_blank">gciofono@gmail.com</a>> writes:<br>
> On Sun, Sep 13, 2020 at 10:56 AM Bjørn Mork <<a href="mailto:bjorn@mork.no" target="_blank">bjorn@mork.no</a>> wrote:<br>
>> Aleksander Morgado <<a href="mailto:aleksander@aleksander.es" target="_blank">aleksander@aleksander.es</a>> writes:<br>
>><br>
>> > This is something that could obviously be fixed in the side of the<br>
>> > device, but it is also something we can avoid in the host side, by<br>
>> > making sure all MBIM sessions between host and device are brought down<br>
>> > on suspend, and brought up again automatically on resume.<br>
>><br>
>> Won't that disconnect all IP sessions as a side effect?  I can imagine<br>
>> use cases where that's unwanted.<br>
>><br>
><br>
> This patch is for host suspended, which drops the USB VBUS line<br>
<br>
That's not always true.  There is no such requirement. And some hosts<br>
can be confgured to keep VBUS always on.<br><br>
> (ie:<br>
> disconnects). At least I have not seen any application/controller that<br>
> keeps the line up.<br>
> And when it is re-connected on resume, then the device is re-enumerated and<br>
> all PDNs are inevitably lost.<br>
><br>
><br>
>> IMHO, the host should (and do) suspend the USB bus, but not touch any<br>
>> higher level stuff unless explicitly configured to do so.  This will<br>
>> allow a powered modem to maintain active connections, so that the host<br>
>> can resume them when it wakes up.<br>
>><br>
><br>
> It doesn't work if VBUS goes down (USB suspend/resume transit on VBUS, not<br>
> on the data lines).<br>
<br>
No, USB suspend is a data line thingy.  We do that all the time with<br>
autosuspend, even with active connections if the modem supports remote<br>
wakeup.<br></blockquote><div><br></div><div>I stand corrected on this. Thanks.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> And it does.<br>
> This strategy would work seamlessly on plain RS232/422 lines, thou. But in<br>
> that case no MBIM.<br>
<br>
FWIW, I just tested this since you made me unsure of myself :-)<br>
<br>
It has been a while since the last time I tested.  None of my laptops<br>
have been able to keep the internal modem slot powered, so it's not a<br>
feature I am able to use for real.  In fact, I don't think I've ever<br>
tested it with MBIM before, since my previous test most likely was<br>
before the cdc_mbim driver was written.  But I know it worked fine with<br>
qmi_wwan a very long time ago.<br>
<br>
Anyway, I just tried now with an EM7565 in MBIM mode, connected to an<br>
external USB port on my laptop (Thinkpad X1 4th gen) using a USB3<br>
adapter and cable.  This did not work...  The device is reset when the<br>
host resumes. <br>
<br>
So I dug out my old laptop (Thinkpad X301), which is the one I use for<br>
the previous test.  And it worked with the modem in MBIM mode too.<br>
Connected, logged into a remote server over ssh with TCPKeepAlive=no,<br>
suspended the laptop, resumed it, and watched the ssh connection still<br>
being alive.<br>
<br>
What didn't work so well was ModemManager forgetting all about the modem<br>
on resume, and "discovering" it as a new modem.  So the active<br>
connection was not unmanaged after resume.<br>
<br>
But suspending and resuming with an active MBIM session does definitely<br>
work, given the right conditions.  So I think we should rather try to<br>
fix the current issues, and not add more problems.<br></blockquote><div><br></div><div>Let me highlight that Aleksander gives it as an option.</div><div>And from your tests and what I saw out in the field, it looks like it is the right default.</div><div>You have to hit just the right set of conditions to make it work, and this not even considering the points below.</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">Note that a device doesn't have to draw much power in this state.  The<br>
USB controller is suspended, and the radio can also be suspended most of<br>
the time.  This is actually the same when the host is alive too, as long<br>
as there is no traffic.   Whether the host cpu is suspended or not is<br>
pretty irrelevant to the device.<br></blockquote><div><br></div><div>This is a bit beside the point, interesting nevertheless.</div><div>The modems, especially the higher LTE categories, are in general self-powered.</div><div>As for the power effectively consumed, it depends.</div><div>If it is a moving application, it must do location updates and cell reselections as the tracking area changes, and this consumes quite some power because it is done (almost by definition) at the cell edge.</div><div>It has to listen to paging messages for SMS and incoming voice calls (even if nobody will answer them).</div><div>The network can configure a DRX to keep the modem in low-power longer, but there is a limit, especially for voice-supporting devices, not to ring too much time later the remote part starts the call.</div><div>There is the option about going in airplane mode, but here there isn't really any reason to keep the modem powered.</div><div>Most modems even have an IRQ line to wakeup the application (as a backup for remote wakeup when the USB is disconnected), and this is additional processing.</div><div><br></div><div>As for the frequency of local events, MM configures the MBIM modems for signal quality reporting, and this happens every 5 seconds per MBIM specification.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">>> Killing connections on suspend and reconnecting on resume is sub-optimal<br>
>> behaviour.  It breaks all established tcp sessions unless you have a<br>
>> static address.  Completely unnecessary.<br>
>><br>
><br>
> From a device point of view, the application asks for notifications, and<br>
> then doesn't read them.<br>
> It is forced to buffer them, and the buffer is limited.<br>
<br>
The device knows the USB connection is suspended.  It should not attempt<br>
to send any USB data when this happens.  This is the same on the host<br>
side.  We kill URBs before suspending.<br>
<br>
There is no obligation to buffer everything on the device.  That would<br>
not scale at all. The device can and should drop anything it cannot<br>
deliver in a timely manner, whether that is a notification for the host<br>
or incoming data packets from the network.<br></blockquote><div><br></div><div>As I have mentioned above, several modems are configured for remote wakeup of the host.</div><div>This is the only way to wakeup some applications remotely.</div><div>And so it must keep the buffer that awakens the host.</div><div>You could say that after a timeout it could be discarded, but what is a sensible timeout?</div><div>Some applications do switch off completely, and so take a few seconds to respond, and in the meanwhile additional data comes in the buffer.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">>> I hate all sort of "bring down networking" on suspend.  It just makes<br>
>> suspend pointless.  You might as well power off then.<br>
>><br>
><br>
> Power off has a much higher cost in terms of reboot of the host and the<br>
> device.<br>
> Re-establishing the PDNs is fast if the modem is already registered.<br>
<br>
It's fast, but usually associated with a new dynamic ip address, which<br>
means that you lose all existing tcp sessions.  To me, that's the<br>
highest cost of a reboot.<br>
<br>
Ok, if you want to argue that this is broken by those networks that<br>
can't even keep your address stable, then I have to agree.  The ever<br>
changing address on mobile networks makes this much harder than<br>
necessary.<br></blockquote><div><br></div><div>so, again, in a perfect world everything would work, but out there these cases are all to consider.</div><div>What is more, all mobile applications must already have procedures to recover from a severed connection (also non-mobile good code actually, but it isn't a primary concern sometimes, as some lines are highly reliable).</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> It is inconvenient for the high-level, for sure, but some applications stay<br>
> suspended for days. It also costs resources on the remote side to keep<br>
> unused TCP connection structures in memory.<br>
<br>
Whatever.  That's how tcp works.  You can suspend it just fine until<br>
someone comes along and breaks it with a lot of assumptions.  Stupid<br>
stateful firewalls are another part of this.  But don't get me started<br>
on that one :-)<br></blockquote><div><br></div><div>Yes, these TCP issues were known already at the time of Stevens' TCP/IP illustrated. And nothing has improved there.</div><div>But there is memory reserved in the final host. If a connection is never released, then in case of change of IP address of the client, or any other problem, this will be kept forever.</div><div>Over time, the memory of the server would get clogged by these vestigial connections. Or something bad  would happen in case of collision due to re-assigned IP addresses.</div><div>Bottom line: for practical reasons, there must be a keepalive or a timeout.</div><div><br></div><div>Giacinto</div><div><br></div></div></div>