Wi-Fi Disconnection on Suspend for no wowlan triggers

Wi-Fi Disconnection on Suspend for no wowlan triggers

[Sunil Dutt Undekari]

Hi All ,

I would like to discuss on the commit 8125696991194aacb1173b6e8196d19098b44=
e17 (cfg80211/mac80211: disconnect on suspend) which triggers the STA disco=
nnection on suspend if no wowlan triggers are registered.
I guess the intention here is to disconnect from the AP if the device canno=
t wake up on a packet / not configured with wowlan triggers .=20
Can this behavior get enhanced to only do so on driver's preference -  do a=
 disconnect for only the host drivers that would want to do so (through an =
additional feature capability) ?

Regards,
Sunil
=20

Re: Wi-Fi Disconnection on Suspend for no wowlan triggers

[Steve deRosier]

Hi Sunil,

On Tue, Apr 3, 2018 at 5:39 AM, Sunil Dutt Undekari
<usdutt@qti.qualcomm.com> wrote:
> Hi All ,
>
> I would like to discuss on the commit 8125696991194aacb1173b6e8196d19098b44e17 (cfg80211/mac80211: disconnect on suspend) which triggers the STA disconnection on suspend if no wowlan triggers are registered.

This commit went in over five years ago. Sometime around v3.9

> I guess the intention here is to disconnect from the AP if the device cannot wake up on a packet / not configured with wowlan triggers .

It being a long time and not feeling like digging too deep into the
patch, what I can guess from a quick look is basically this:

* Before the patch, waking up from suspend would throw warnings into
the log. This patch fixes this.
* As you can't wake the processor, and you're a thin-mac chip who
depends on mac80211, you _can't_ do anything without wowlan.
* If your chip is not configured for wowlan, on a suspend, it might as
well go to sleep, as there's no sense in wasting power as you can't do
anything anyway.
* If you're going to sleep and can't respond to the AP, it's polite to
disconnect. And the AP is going to forcibly do so to you anyway after
some time of not hearing from you.

Hence the above in general concept seems perfectly correct and I don't
see any point in doing anything else with a mac80211 device.

> Can this behavior get enhanced to only do so on driver's preference -  do a disconnect for only the host drivers that would want to do so (through an additional feature capability) ?
>

Can? Perhaps. Send a patch. And maybe you could explain in detail what
the actual problem is you're trying to solve. Patches that are "maybe,
someday, someone might want to..." don't have a terribly high chance
of getting merged.  But solutions to real-life actual problems do. And
it's really difficult for us to speak on vague hypothetical musings.

- Steve

--
Steve deRosier
Cal-Sierra Consulting LLC
https://www.cal-sierra.com/

Re: Wi-Fi Disconnection on Suspend for no wowlan triggers

[Kalle Valo]

Steve deRosier <derosier@gmail.com> writes:

> On Tue, Apr 3, 2018 at 5:39 AM, Sunil Dutt Undekari
> <usdutt@qti.qualcomm.com> wrote:
>> Hi All ,
>>
>> I would like to discuss on the commit
>> 8125696991194aacb1173b6e8196d19098b44e17 (cfg80211/mac80211:
>> disconnect on suspend) which triggers the STA disconnection on
>> suspend if no wowlan triggers are registered.
>
> This commit went in over five years ago. Sometime around v3.9

Yup, v3.10-rc2 was the first release.

-- 
Kalle Valo

Re: Wi-Fi Disconnection on Suspend for no wowlan triggers

[Arend van Spriel]

On 4/3/2018 6:55 PM, Steve deRosier wrote:
> Hi Sunil,
>
> On Tue, Apr 3, 2018 at 5:39 AM, Sunil Dutt Undekari
> <usdutt@qti.qualcomm.com> wrote:
>> Hi All ,
>>
>> I would like to discuss on the commit 8125696991194aacb1173b6e8196d19098b44e17 (cfg80211/mac80211: disconnect on suspend) which triggers the STA disconnection on suspend if no wowlan triggers are registered.
>
> This commit went in over five years ago. Sometime around v3.9
>
>> I guess the intention here is to disconnect from the AP if the device cannot wake up on a packet / not configured with wowlan triggers .
>
> It being a long time and not feeling like digging too deep into the
> patch, what I can guess from a quick look is basically this:
>
> * Before the patch, waking up from suspend would throw warnings into
> the log. This patch fixes this.
> * As you can't wake the processor, and you're a thin-mac chip who
> depends on mac80211, you _can't_ do anything without wowlan.
> * If your chip is not configured for wowlan, on a suspend, it might as
> well go to sleep, as there's no sense in wasting power as you can't do
> anything anyway.
> * If you're going to sleep and can't respond to the AP, it's polite to
> disconnect. And the AP is going to forcibly do so to you anyway after
> some time of not hearing from you.
>
> Hence the above in general concept seems perfectly correct and I don't
> see any point in doing anything else with a mac80211 device.
>
>> Can this behavior get enhanced to only do so on driver's preference -  do a disconnect for only the host drivers that would want to do so (through an additional feature capability) ?
>>
>
> Can? Perhaps. Send a patch. And maybe you could explain in detail what
> the actual problem is you're trying to solve. Patches that are "maybe,
> someday, someone might want to..." don't have a terribly high chance
> of getting merged.  But solutions to real-life actual problems do. And
> it's really difficult for us to speak on vague hypothetical musings.

So for a full-mac device or a mac80211 device with certain offloads 
(that we may already have, eg. 4way-hs offloads) you could keep up the 
connection for a while, but if it is receiving data it probably wants to 
wake-up the host at some point. So if such a device has means to do a 
host wake-up you could keep the connection upon suspend. You could 
consider such behavior a wowlan trigger as well and extend that.

Regards,
Arend

Re: Wi-Fi Disconnection on Suspend for no wowlan triggers

[Johannes Berg]

On Thu, 2018-04-05 at 09:41 +0200, Arend van Spriel wrote:
> 
> So for a full-mac device or a mac80211 device with certain offloads 
> (that we may already have, eg. 4way-hs offloads) you could keep up the 
> connection for a while, but if it is receiving data it probably wants to 
> wake-up the host at some point. So if such a device has means to do a 
> host wake-up you could keep the connection upon suspend. You could 
> consider such behavior a wowlan trigger as well and extend that.

There's the "any" trigger that might be appropriate for that, or a
"disconnect" trigger.

But I'm basically thinking the same as Steve - if you're never going to
wake up the host, there's not really much point in keeping the
connection, and if you only suspend briefly like e.g. on Android then
you probably *do* want to wake up the host for pretty much everything
that's going on (hence the "any" trigger).

johannes

Re: Wi-Fi Disconnection on Suspend for no wowlan triggers

[Arend van Spriel]

On 4/5/2018 9:59 AM, Johannes Berg wrote:
> On Thu, 2018-04-05 at 09:41 +0200, Arend van Spriel wrote:
>>
>> So for a full-mac device or a mac80211 device with certain offloads
>> (that we may already have, eg. 4way-hs offloads) you could keep up the
>> connection for a while, but if it is receiving data it probably wants to
>> wake-up the host at some point. So if such a device has means to do a
>> host wake-up you could keep the connection upon suspend. You could
>> consider such behavior a wowlan trigger as well and extend that.
>
> There's the "any" trigger that might be appropriate for that, or a
> "disconnect" trigger.
>
> But I'm basically thinking the same as Steve - if you're never going to
> wake up the host, there's not really much point in keeping the
> connection, and if you only suspend briefly like e.g. on Android then
> you probably *do* want to wake up the host for pretty much everything
> that's going on (hence the "any" trigger).

Agree, which is why I suggested to look at wowlan triggers. If we 
already have an appropriate "any" trigger even better ;-)

Regards,
Arend

Re: Wi-Fi Disconnection on Suspend for no wowlan triggers

[Jouni Malinen]

On Thu, Apr 05, 2018 at 10:07:04AM +0200, Arend van Spriel wrote:
> On 4/5/2018 9:59 AM, Johannes Berg wrote:
> >There's the "any" trigger that might be appropriate for that, or a
> >"disconnect" trigger.
> >
> >But I'm basically thinking the same as Steve - if you're never going to
> >wake up the host, there's not really much point in keeping the
> >connection, and if you only suspend briefly like e.g. on Android then
> >you probably *do* want to wake up the host for pretty much everything
> >that's going on (hence the "any" trigger).
>=20
> Agree, which is why I suggested to look at wowlan triggers. If we already
> have an appropriate "any" trigger even better ;-)

The "any" trigger sounds like a reasonable thing to use, so the question
really is on what the default behavior should be if the driver has
capability of doing this and there is no explicit configuration in user
space. Currently, the default behavior seems to be to force
disconnection. Would it make sense to allow drivers to indicate that
they rather use "any" trigger by default? Or make that the default
behavior is the driver supports "any"?

For example, wpa_supplicant does not currently set any trigger
configuration unless explicitly asked to do so. This in combination with
the kernel default (disconnect) does not seem to result in desired
behavior in number of Android cases.

And if the default behavior should be changed, should that behavior
change be done in the kernel or user space (wpa_supplicant)?

--=20
Jouni Malinen                                            PGP id EFC895FA=

Re: Wi-Fi Disconnection on Suspend for no wowlan triggers

[Johannes Berg]

On Thu, 2018-04-05 at 11:24 +0000, Jouni Malinen wrote:
> 
> The "any" trigger sounds like a reasonable thing to use, 

It really depends what you're after. The "any" trigger means you want to
wake up on all kinds of things, basically everything that would normally
give you an interrupt in regular operation.

> so the question
> really is on what the default behavior should be if the driver has
> capability of doing this and there is no explicit configuration in user
> space. Currently, the default behavior seems to be to force
> disconnection. Would it make sense to allow drivers to indicate that
> they rather use "any" trigger by default? Or make that the default
> behavior is the driver supports "any"?

I don't think that makes sense, TBH. Imagine how dire that situation
would be if you were to have that on your laptop, e.g. with iwlwifi
which in certain configurations can support "any" - you'd basically
never be able to suspend your system properly unless you disconnected
from wifi first!

> For example, wpa_supplicant does not currently set any trigger
> configuration unless explicitly asked to do so. 

Which, again, I think is best really.

> This in combination with
> the kernel default (disconnect) does not seem to result in desired
> behavior in number of Android cases.

So yeah, I guess I could see how on *Android* in particular you'd want a
different configuration - but there are enough ways to configure that on
Android systems in particular, whether by changing the wpa_supplicant
configuration (if it can do this) or by using libwifihal or similar
mechanisms.

Basically, I don't think changing it would make sense for a general
purpose default configuration - it's always a special case that you do
want to wake up on all kinds of wifi things happening.

johannes