[PATCH v2 0/3] mac80211 suspend/resume

[PATCH v2 0/3] mac80211 suspend/resume

[Bob Copeland]

Here's version 2 of the suspend/resume for mac80211, including
Johannes Berg's patch for the cfg80211 hooks.  

Changes since last time:

 - fixed broken conditional for monitor & ap vlan checking
 - removed pm.h
 - removed frag threshold setting since that's gone now
 - the call to ieee80211_sta_tear_down_BA_sessions was locking up so 
   I just dropped it for now in the interest of getting a stable base

I also tracked down the disappearing interface problem.. turns out this 
was just gnome-power-manager or HAL.  (I do not have 'network_sleep' set 
in gconf, but I didn't bother pinning it down otherwise...)  Using 
'echo mem > /sys/power/state' to suspend keeps the interface up across
suspend.

This seems to work ok for me but can use a lot of testing.

Re: [PATCH v2 0/3] mac80211 suspend/resume

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 677 bytes --]

Sorry, heh, was reading mail in the wrong order I guess.

>  - the call to ieee80211_sta_tear_down_BA_sessions was locking up so 
>    I just dropped it for now in the interest of getting a stable base

Probably due to transmitting again? We'll have to look and add it, but I
agree that we can work on that later.

> I also tracked down the disappearing interface problem.. turns out this 
> was just gnome-power-manager or HAL.  (I do not have 'network_sleep' set 
> in gconf, but I didn't bother pinning it down otherwise...)  Using 
> 'echo mem > /sys/power/state' to suspend keeps the interface up across
> suspend.

Oh ok, that explains things.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH v2 0/3] mac80211 suspend/resume

[Dan Williams]

On Mon, 2008-12-15 at 11:14 +0100, Johannes Berg wrote:
> Sorry, heh, was reading mail in the wrong order I guess.
> 
> >  - the call to ieee80211_sta_tear_down_BA_sessions was locking up so 
> >    I just dropped it for now in the interest of getting a stable base
> 
> Probably due to transmitting again? We'll have to look and add it, but I
> agree that we can work on that later.
> 
> > I also tracked down the disappearing interface problem.. turns out this 
> > was just gnome-power-manager or HAL.  (I do not have 'network_sleep' set 
> > in gconf, but I didn't bother pinning it down otherwise...)  Using 
> > 'echo mem > /sys/power/state' to suspend keeps the interface up across
> > suspend.
> 
> Oh ok, that explains things.

Could be udev event ordering?  We do need to track this down, otherwise
stuff simply won't work when we come back.  The best thing to do here is
run the udev monitoring tool (whatever that is, I forget) and see what
events get emitted from the kernel, then run 'lshal --monitor' and see
what HAL thinks is going on, which it gets from consuming udev events
and inspecting sysfs.  Stuff like this is sometimes caused by
mis-ordered kernel events or drivers/subsystems that don't create their
sysfs directories at the right times, leading to race conditions between
the kernel and HAL.  A possibility.

Dan

Re: [PATCH v2 0/3] mac80211 suspend/resume

[Luis R. Rodriguez]

On Mon, Dec 15, 2008 at 07:22:12AM -0800, Dan Williams wrote:
> On Mon, 2008-12-15 at 11:14 +0100, Johannes Berg wrote:
> > Sorry, heh, was reading mail in the wrong order I guess.
> >
> > >  - the call to ieee80211_sta_tear_down_BA_sessions was locking up so
> > >    I just dropped it for now in the interest of getting a stable base
> >
> > Probably due to transmitting again? We'll have to look and add it, but I
> > agree that we can work on that later.
> >
> > > I also tracked down the disappearing interface problem.. turns out this
> > > was just gnome-power-manager or HAL.  (I do not have 'network_sleep' set
> > > in gconf, but I didn't bother pinning it down otherwise...)  Using
> > > 'echo mem > /sys/power/state' to suspend keeps the interface up across
> > > suspend.
> >
> > Oh ok, that explains things.
> 
> Could be udev event ordering?  We do need to track this down, otherwise
> stuff simply won't work when we come back.  The best thing to do here is
> run the udev monitoring tool (whatever that is, I forget) 

That would be:

udevadm monitor --environment kernel

> and see what
> events get emitted from the kernel, then run 'lshal --monitor' and see
> what HAL thinks is going on, which it gets from consuming udev events
> and inspecting sysfs.  Stuff like this is sometimes caused by
> mis-ordered kernel events or drivers/subsystems that don't create their
> sysfs directories at the right times, leading to race conditions between
> the kernel and HAL.  A possibility.

  Luis

Re: [PATCH v2 0/3] mac80211 suspend/resume

[Bob Copeland]

On Mon, 15 Dec 2008 10:22:12 -0500, Dan Williams wrote
> Could be udev event ordering?  We do need to track this down, otherwise
> stuff simply won't work when we come back.  

Sorry for not following up on this so far; I don't usually have a lot
of time on weeknights.  I haven't done any exhaustive testing yet but
so far, I don't see anything having to do with networking in udev 
monitor, just input, cpus, and virtual consoles.

logs here: http://bobcopeland.com/kernel/wl/ {udev,dbus,hal}.log

Running pm-suspend from pm-utils directly also triggers the problem, 
so that would seem to excuse gnome-power-manager at least.

-- 
Bob Copeland %% www.bobcopeland.com

Re: [PATCH v2 0/3] mac80211 suspend/resume

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 799 bytes --]

On Wed, 2008-12-17 at 13:21 -0500, Bob Copeland wrote:
> On Mon, 15 Dec 2008 10:22:12 -0500, Dan Williams wrote
> > Could be udev event ordering?  We do need to track this down, otherwise
> > stuff simply won't work when we come back.  
> 
> Sorry for not following up on this so far; I don't usually have a lot
> of time on weeknights.  I haven't done any exhaustive testing yet but
> so far, I don't see anything having to do with networking in udev 
> monitor, just input, cpus, and virtual consoles.
> 
> logs here: http://bobcopeland.com/kernel/wl/ {udev,dbus,hal}.log
> 
> Running pm-suspend from pm-utils directly also triggers the problem, 
> so that would seem to excuse gnome-power-manager at least.

What's the status of this? Should I look into things a bit?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH v2 0/3] mac80211 suspend/resume

[Bob Copeland]

On Tue, Dec 23, 2008 at 09:30:16PM +0100, Johannes Berg wrote:
> > Running pm-suspend from pm-utils directly also triggers the problem, 
> > so that would seem to excuse gnome-power-manager at least.
> 
> What's the status of this? Should I look into things a bit?

Well, I guess I should have noticed this a lot earlier, but anyway the 
problem was pm-utils on Fedora 10:

/usr/lib/pm-utils/sleep.d/55NetworkManager:

    suspend_nm()
    {
        # Tell NetworkManager to shut down networking
        dbus-send --system                         \
            --dest=org.freedesktop.NetworkManager  \
            /org/freedesktop/NetworkManager        \
            org.freedesktop.NetworkManager.sleep
    }

I really don't think this is necessary (g-p-m will also do it if you 
set the proper gconf setting.)

-- 
Bob Copeland %% www.bobcopeland.com

Re: [PATCH v2 0/3] mac80211 suspend/resume

[Marcel Holtmann]

Hi Bob,

> > > Running pm-suspend from pm-utils directly also triggers the problem, 
> > > so that would seem to excuse gnome-power-manager at least.
> > 
> > What's the status of this? Should I look into things a bit?
> 
> Well, I guess I should have noticed this a lot earlier, but anyway the 
> problem was pm-utils on Fedora 10:
> 
> /usr/lib/pm-utils/sleep.d/55NetworkManager:
> 
>     suspend_nm()
>     {
>         # Tell NetworkManager to shut down networking
>         dbus-send --system                         \
>             --dest=org.freedesktop.NetworkManager  \
>             /org/freedesktop/NetworkManager        \
>             org.freedesktop.NetworkManager.sleep
>     }
> 
> I really don't think this is necessary (g-p-m will also do it if you 
> set the proper gconf setting.)

this should not be needed at all. I have systems running wpa_supplicant
and not any of the pm-utils scripts messing with it. During suspend and
later resume it indicates normally just only a new handshake with the AP
or a disconnect if the AP got out of range.

I think Network Manager is perfectly capable of handling state changes
from wpa_supplicant. I really do think that this hack only exists of
some broken drivers from really old kernels or for the 0.6 version of
Network Manager. Remember that Ubuntu's suspend/resume solution used to
be to unload all networking drivers on suspend.

Regards

Marcel

Re: [PATCH v2 0/3] mac80211 suspend/resume

[Dan Williams]

On Wed, 2008-12-24 at 08:16 +0100, Marcel Holtmann wrote:
> Hi Bob,
> 
> > > > Running pm-suspend from pm-utils directly also triggers the problem, 
> > > > so that would seem to excuse gnome-power-manager at least.
> > > 
> > > What's the status of this? Should I look into things a bit?
> > 
> > Well, I guess I should have noticed this a lot earlier, but anyway the 
> > problem was pm-utils on Fedora 10:
> > 
> > /usr/lib/pm-utils/sleep.d/55NetworkManager:
> > 
> >     suspend_nm()
> >     {
> >         # Tell NetworkManager to shut down networking
> >         dbus-send --system                         \
> >             --dest=org.freedesktop.NetworkManager  \
> >             /org/freedesktop/NetworkManager        \
> >             org.freedesktop.NetworkManager.sleep
> >     }
> > 
> > I really don't think this is necessary (g-p-m will also do it if you 
> > set the proper gconf setting.)
> 
> this should not be needed at all. I have systems running wpa_supplicant
> and not any of the pm-utils scripts messing with it. During suspend and
> later resume it indicates normally just only a new handshake with the AP
> or a disconnect if the AP got out of range.
> 
> I think Network Manager is perfectly capable of handling state changes
> from wpa_supplicant. I really do think that this hack only exists of
> some broken drivers from really old kernels or for the 0.6 version of
> Network Manager. Remember that Ubuntu's suspend/resume solution used to
> be to unload all networking drivers on suspend.

You still want to tell NM to go to sleep so it doesn't see the
disconnection from the supplicant (triggered by the driver because it
was going to sleep), and thus try to reconnect, or try a different AP.
Ideally NM would simply listen for signals from some power service such
that we wouldn't have to have this hack, but there isn't a global power
service yet on the system bus.

Furthermore, it's nice to know if we've gone to sleep or not so that we
can do some optimizations on wakeup to find APs and reconnect faster.

Dan

Re: [PATCH v2 0/3] mac80211 suspend/resume

[Bob Copeland]

On Tue, 06 Jan 2009 11:45:06 -0500, Dan Williams wrote
> You still want to tell NM to go to sleep so it doesn't see the
> disconnection from the supplicant (triggered by the driver because it
> was going to sleep), and thus try to reconnect, or try a different AP.

Well, I tried it without the hack and it works (connection stays up 
over a short suspend period).  This is with the new mac80211 suspend
patches, where suspend/resume looks like this:

suspend:
  suspend userspace (freezes NM)
  save bssid, keys etc
  if wlan0 up
     ifdown wlan0 (note NM is already frozen)
  power down hw

resume:
  power up hw
  if wlan0 was up
     ifup wlan0
  reload config, bssid, ...
  resume userspace

However, _with_ the current procedure of telling NM to go to sleep, it
tries to reconnect after resume because NM takes care of downing the
interfaces.  As a result mac80211 never gets the chance to save the
state of the running interfaces.

-- 
Bob Copeland %% www.bobcopeland.com

Re: [PATCH v2 0/3] mac80211 suspend/resume

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1243 bytes --]

On Tue, 2009-01-06 at 12:07 -0500, Bob Copeland wrote:
> On Tue, 06 Jan 2009 11:45:06 -0500, Dan Williams wrote
> > You still want to tell NM to go to sleep so it doesn't see the
> > disconnection from the supplicant (triggered by the driver because it
> > was going to sleep), and thus try to reconnect, or try a different AP.
> 
> Well, I tried it without the hack and it works (connection stays up 
> over a short suspend period).  This is with the new mac80211 suspend
> patches, where suspend/resume looks like this:
> 
> suspend:
>   suspend userspace (freezes NM)
>   save bssid, keys etc
>   if wlan0 up
>      ifdown wlan0 (note NM is already frozen)
>   power down hw
> 
> resume:
>   power up hw
>   if wlan0 was up
>      ifup wlan0
>   reload config, bssid, ...
>   resume userspace
> 
> However, _with_ the current procedure of telling NM to go to sleep, it
> tries to reconnect after resume because NM takes care of downing the
> interfaces.  As a result mac80211 never gets the chance to save the
> state of the running interfaces.

You mean restore?

Does that mean there's a race condition now, between userspace config
and the resume stuff? Can't we fix that by taking the rtnl?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH v2 0/3] mac80211 suspend/resume

[Bob Copeland]

On Tue, 06 Jan 2009 18:14:41 +0100, Johannes Berg wrote
> > However, _with_ the current procedure of telling NM to go to sleep, it
> > tries to reconnect after resume because NM takes care of downing the
> > interfaces.  As a result mac80211 never gets the chance to save the
> > state of the running interfaces.
> 
> You mean restore?
> 
> Does that mean there's a race condition now, between userspace config
> and the resume stuff? Can't we fix that by taking the rtnl?

No, I mean that with dbus telling NM to go to sleep (as part of pm-utils)
NM then takes down the interfaces -- userspace is still running, this is
before the kernel actually suspends.

Consequently, all the interfaces look down to mac80211 when suspend() is
actually called so the suspend/resume in mac80211 doesn't wind up doing
anything with interfaces.  No race condition, but a re-association must 
happen from userspace on the resume side (NM will do this, though).

At least this appears the case on f10, correct me if I'm wrong, Dan.

-- 
Bob Copeland %% www.bobcopeland.com

Re: [PATCH v2 0/3] mac80211 suspend/resume

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 966 bytes --]

On Tue, 2009-01-06 at 12:35 -0500, Bob Copeland wrote:

> No, I mean that with dbus telling NM to go to sleep (as part of pm-utils)
> NM then takes down the interfaces -- userspace is still running, this is
> before the kernel actually suspends.
> 
> Consequently, all the interfaces look down to mac80211 when suspend() is
> actually called so the suspend/resume in mac80211 doesn't wind up doing
> anything with interfaces.  No race condition, but a re-association must 
> happen from userspace on the resume side (NM will do this, though).

Ok, but that's fine, that means the mac80211 resume code will also not
do anything. Hence, we can put this code in, but it won't be used on
such systems initially.

We should probably take the rtnl anyway though to be prepared for when
userspace is not suspended.. Need to think about that more though, and
possibly add a new "suspended" flag that makes it block all
configuration attempts.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH v2 0/3] mac80211 suspend/resume

[Bob Copeland]

On Tue, 06 Jan 2009 18:43:22 +0100, Johannes Berg wrote
> We should probably take the rtnl anyway though to be prepared for when
> userspace is not suspended.. Need to think about that more though, and
> possibly add a new "suspended" flag that makes it block all
> configuration attempts.

Well, luckily we do take the rtnl already, wiphy_suspend() and _resume()
do that around the cfg ops.

IMHO a suspended flag would be extra complexity that we should just
hold off on until the freezer really is getting removed.

For now is there anything besides driver support we need to do for this
patchset?  I guess that the drivers will actually be OK as-is too unless
there are any that do release_firmware in ->stop(), but it will be nice
to clean them up.

-- 
Bob Copeland %% www.bobcopeland.com

Re: [PATCH v2 0/3] mac80211 suspend/resume

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1201 bytes --]

On Tue, 2009-01-06 at 13:01 -0500, Bob Copeland wrote:
> On Tue, 06 Jan 2009 18:43:22 +0100, Johannes Berg wrote
> > We should probably take the rtnl anyway though to be prepared for when
> > userspace is not suspended.. Need to think about that more though, and
> > possibly add a new "suspended" flag that makes it block all
> > configuration attempts.
> 
> Well, luckily we do take the rtnl already, wiphy_suspend() and _resume()
> do that around the cfg ops.

Good point.

> IMHO a suspended flag would be extra complexity that we should just
> hold off on until the freezer really is getting removed.

Well, kinda a chicken-and-egg problem here, can't remove the freezer
without looking at all this, but yeah, we can defer that and put it on
the todo list.

> For now is there anything besides driver support we need to do for this
> patchset?  I guess that the drivers will actually be OK as-is too unless
> there are any that do release_firmware in ->stop(), but it will be nice
> to clean them up.

I don't see anything, drivers need to do at all. They should all be fine
with suspending when hw is stopped anyway. We can remove some driver
code though.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH v2 0/3] mac80211 suspend/resume

[Marcel Holtmann]

Hi Dan,

> > > > > Running pm-suspend from pm-utils directly also triggers the problem, 
> > > > > so that would seem to excuse gnome-power-manager at least.
> > > > 
> > > > What's the status of this? Should I look into things a bit?
> > > 
> > > Well, I guess I should have noticed this a lot earlier, but anyway the 
> > > problem was pm-utils on Fedora 10:
> > > 
> > > /usr/lib/pm-utils/sleep.d/55NetworkManager:
> > > 
> > >     suspend_nm()
> > >     {
> > >         # Tell NetworkManager to shut down networking
> > >         dbus-send --system                         \
> > >             --dest=org.freedesktop.NetworkManager  \
> > >             /org/freedesktop/NetworkManager        \
> > >             org.freedesktop.NetworkManager.sleep
> > >     }
> > > 
> > > I really don't think this is necessary (g-p-m will also do it if you 
> > > set the proper gconf setting.)
> > 
> > this should not be needed at all. I have systems running wpa_supplicant
> > and not any of the pm-utils scripts messing with it. During suspend and
> > later resume it indicates normally just only a new handshake with the AP
> > or a disconnect if the AP got out of range.
> > 
> > I think Network Manager is perfectly capable of handling state changes
> > from wpa_supplicant. I really do think that this hack only exists of
> > some broken drivers from really old kernels or for the 0.6 version of
> > Network Manager. Remember that Ubuntu's suspend/resume solution used to
> > be to unload all networking drivers on suspend.
> 
> You still want to tell NM to go to sleep so it doesn't see the
> disconnection from the supplicant (triggered by the driver because it
> was going to sleep), and thus try to reconnect, or try a different AP.
> Ideally NM would simply listen for signals from some power service such
> that we wouldn't have to have this hack, but there isn't a global power
> service yet on the system bus.
> 
> Furthermore, it's nice to know if we've gone to sleep or not so that we
> can do some optimizations on wakeup to find APs and reconnect faster.

actually the fastest way to re-connect is to just let wpa_supplicant do
it and then you don't even have to go through DHCP again if the lease
time is still valid. This works great if the AP is still in range.

What is your downside with the letting wpa_supplicant send you a
disconnect when the AP is out of range after resume?

Regards

Marcel

Re: [PATCH v2 0/3] mac80211 suspend/resume

[Dan Williams]

On Tue, 2009-01-06 at 18:12 +0100, Marcel Holtmann wrote:
> Hi Dan,
> 
> > > > > > Running pm-suspend from pm-utils directly also triggers the problem, 
> > > > > > so that would seem to excuse gnome-power-manager at least.
> > > > > 
> > > > > What's the status of this? Should I look into things a bit?
> > > > 
> > > > Well, I guess I should have noticed this a lot earlier, but anyway the 
> > > > problem was pm-utils on Fedora 10:
> > > > 
> > > > /usr/lib/pm-utils/sleep.d/55NetworkManager:
> > > > 
> > > >     suspend_nm()
> > > >     {
> > > >         # Tell NetworkManager to shut down networking
> > > >         dbus-send --system                         \
> > > >             --dest=org.freedesktop.NetworkManager  \
> > > >             /org/freedesktop/NetworkManager        \
> > > >             org.freedesktop.NetworkManager.sleep
> > > >     }
> > > > 
> > > > I really don't think this is necessary (g-p-m will also do it if you 
> > > > set the proper gconf setting.)
> > > 
> > > this should not be needed at all. I have systems running wpa_supplicant
> > > and not any of the pm-utils scripts messing with it. During suspend and
> > > later resume it indicates normally just only a new handshake with the AP
> > > or a disconnect if the AP got out of range.
> > > 
> > > I think Network Manager is perfectly capable of handling state changes
> > > from wpa_supplicant. I really do think that this hack only exists of
> > > some broken drivers from really old kernels or for the 0.6 version of
> > > Network Manager. Remember that Ubuntu's suspend/resume solution used to
> > > be to unload all networking drivers on suspend.
> > 
> > You still want to tell NM to go to sleep so it doesn't see the
> > disconnection from the supplicant (triggered by the driver because it
> > was going to sleep), and thus try to reconnect, or try a different AP.
> > Ideally NM would simply listen for signals from some power service such
> > that we wouldn't have to have this hack, but there isn't a global power
> > service yet on the system bus.
> > 
> > Furthermore, it's nice to know if we've gone to sleep or not so that we
> > can do some optimizations on wakeup to find APs and reconnect faster.
> 
> actually the fastest way to re-connect is to just let wpa_supplicant do
> it and then you don't even have to go through DHCP again if the lease
> time is still valid. This works great if the AP is still in range.
> 
> What is your downside with the letting wpa_supplicant send you a
> disconnect when the AP is out of range after resume?

Depends on the driver what the resume behavior is with the supplicant.
But you want to alert *something* that the system is now going to sleep,
so that it can clean up state before doing so.

The problem is that you have absolutely no idea how long the sleep will
be.  It's at least 2 minutes with S2D, because that's how long it takes
to write your state out to disk.  It's less with S2R obviously, but when
you resume, there's no guarantee that you'll be in the same place.  You
cannot assume that you will be.

If you keep trying to reconnect to the same AP, many times you simply
won't be there and you'll spend the 10 or 20 seconds reconnecting to an
AP miles away, time that could have been spent scanning for the AP
that's *really* where you are.  Many people I know don't often suspend
at the same location they resume, thus trying to reconnect hurts
reconnection latency.

The ideal way to handle all this is to be *aware* of suspend/resume in
the supplicant (or NM), and on resume, do a quick probe-scan or two to
find out if the old AP is still around.  If it's not, do a full scan to
find all APs, and then pick the best one, which is probably not the one
you were associated with before.  Then you actually start the auth/assoc
process with an AP you know exists.

So my point is that *something* needs to be aware of the suspend/resume
at a userlevel, whether it's NM or the supplicant doesn't really matter
as long as you can do what I describe above on resume.

Dan

Re: [PATCH v2 0/3] mac80211 suspend/resume

[Marcel Holtmann]

Hi Dan,

> > > > > > > Running pm-suspend from pm-utils directly also triggers the problem, 
> > > > > > > so that would seem to excuse gnome-power-manager at least.
> > > > > > 
> > > > > > What's the status of this? Should I look into things a bit?
> > > > > 
> > > > > Well, I guess I should have noticed this a lot earlier, but anyway the 
> > > > > problem was pm-utils on Fedora 10:
> > > > > 
> > > > > /usr/lib/pm-utils/sleep.d/55NetworkManager:
> > > > > 
> > > > >     suspend_nm()
> > > > >     {
> > > > >         # Tell NetworkManager to shut down networking
> > > > >         dbus-send --system                         \
> > > > >             --dest=org.freedesktop.NetworkManager  \
> > > > >             /org/freedesktop/NetworkManager        \
> > > > >             org.freedesktop.NetworkManager.sleep
> > > > >     }
> > > > > 
> > > > > I really don't think this is necessary (g-p-m will also do it if you 
> > > > > set the proper gconf setting.)
> > > > 
> > > > this should not be needed at all. I have systems running wpa_supplicant
> > > > and not any of the pm-utils scripts messing with it. During suspend and
> > > > later resume it indicates normally just only a new handshake with the AP
> > > > or a disconnect if the AP got out of range.
> > > > 
> > > > I think Network Manager is perfectly capable of handling state changes
> > > > from wpa_supplicant. I really do think that this hack only exists of
> > > > some broken drivers from really old kernels or for the 0.6 version of
> > > > Network Manager. Remember that Ubuntu's suspend/resume solution used to
> > > > be to unload all networking drivers on suspend.
> > > 
> > > You still want to tell NM to go to sleep so it doesn't see the
> > > disconnection from the supplicant (triggered by the driver because it
> > > was going to sleep), and thus try to reconnect, or try a different AP.
> > > Ideally NM would simply listen for signals from some power service such
> > > that we wouldn't have to have this hack, but there isn't a global power
> > > service yet on the system bus.
> > > 
> > > Furthermore, it's nice to know if we've gone to sleep or not so that we
> > > can do some optimizations on wakeup to find APs and reconnect faster.
> > 
> > actually the fastest way to re-connect is to just let wpa_supplicant do
> > it and then you don't even have to go through DHCP again if the lease
> > time is still valid. This works great if the AP is still in range.
> > 
> > What is your downside with the letting wpa_supplicant send you a
> > disconnect when the AP is out of range after resume?
> 
> Depends on the driver what the resume behavior is with the supplicant.
> But you want to alert *something* that the system is now going to sleep,
> so that it can clean up state before doing so.
> 
> The problem is that you have absolutely no idea how long the sleep will
> be.  It's at least 2 minutes with S2D, because that's how long it takes
> to write your state out to disk.  It's less with S2R obviously, but when
> you resume, there's no guarantee that you'll be in the same place.  You
> cannot assume that you will be.
> 
> If you keep trying to reconnect to the same AP, many times you simply
> won't be there and you'll spend the 10 or 20 seconds reconnecting to an
> AP miles away, time that could have been spent scanning for the AP
> that's *really* where you are.  Many people I know don't often suspend
> at the same location they resume, thus trying to reconnect hurts
> reconnection latency.
> 
> The ideal way to handle all this is to be *aware* of suspend/resume in
> the supplicant (or NM), and on resume, do a quick probe-scan or two to
> find out if the old AP is still around.  If it's not, do a full scan to
> find all APs, and then pick the best one, which is probably not the one
> you were associated with before.  Then you actually start the auth/assoc
> process with an AP you know exists.
> 
> So my point is that *something* needs to be aware of the suspend/resume
> at a userlevel, whether it's NM or the supplicant doesn't really matter
> as long as you can do what I describe above on resume.

since mac80211 gets suspend/resume support, I think it is the best that
we signal this to wpa_supplicant. In that case it can do the hard work
here. Either it re-connects to the last AP or signals a disconnected
state or trigger scanning.

Having the suspend scripts to tell NM to disconnect is just not a good
solution and especially in the embedded world this is a broken design
concept.

Regards

Marcel

Re: [PATCH v2 0/3] mac80211 suspend/resume

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 838 bytes --]

On Tue, 2009-01-06 at 20:36 +0100, Marcel Holtmann wrote:

> since mac80211 gets suspend/resume support, I think it is the best that
> we signal this to wpa_supplicant. In that case it can do the hard work
> here. Either it re-connects to the last AP or signals a disconnected
> state or trigger scanning.

Let me just say once again that all this discussion is entirely
orthogonal to properly supporting suspend/resume in mac80211, it's
always possible for userspace to do anything with the devices before
going into suspend, but the kernel should take some care to resume as it
was at suspend time, which is what we're aiming for here. Of course,
this may mean that at resume we lose the AP connection that we think we
still have right away, but that's great since then wpa_supplicant will
reconnect quickly.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH v2 0/3] mac80211 suspend/resume

[Tomas Winkler]

On Tue, Jan 6, 2009 at 10:05 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Tue, 2009-01-06 at 20:36 +0100, Marcel Holtmann wrote:
>
>> since mac80211 gets suspend/resume support, I think it is the best that
>> we signal this to wpa_supplicant. In that case it can do the hard work
>> here. Either it re-connects to the last AP or signals a disconnected
>> state or trigger scanning.
>
> Let me just say once again that all this discussion is entirely
> orthogonal to properly supporting suspend/resume in mac80211, it's
> always possible for userspace to do anything with the devices before
> going into suspend, but the kernel should take some care to resume as it
> was at suspend time, which is what we're aiming for here. Of course,
> this may mean that at resume we lose the AP connection that we think we
> still have right away, but that's great since then wpa_supplicant will
> reconnect quickly.

I second this by stressing another issue. in the point that
suspend/resume events shell be present to user space regardless of
mac80211 specific talk with wpa_supplicant. Not only Wifi but also in
my knowledge BT and other coms need user space application
to close gracefully connection before kernel shuts in down.
Even sometime leavening shutting down interface managing application
may reduce the crosstalk so that driver doesn't have go guess when
application has finished it's shutdown. rtnl is probably not enough as
there is still race who grabs it first.

Thanks
Tomas

Re: [PATCH v2 0/3] mac80211 suspend/resume

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1014 bytes --]

On Sat, 2009-01-10 at 01:53 +0200, Tomas Winkler wrote:

> I second this by stressing another issue. in the point that
> suspend/resume events shell be present to user space regardless of
> mac80211 specific talk with wpa_supplicant. Not only Wifi but also in
> my knowledge BT and other coms need user space application
> to close gracefully connection before kernel shuts in down.

But userspace is usually the one _invoking_ the suspend, so what I was
trying to say is that we don't care what userspace did right before
invoking suspend.

> Even sometime leavening shutting down interface managing application
> may reduce the crosstalk so that driver doesn't have go guess when
> application has finished it's shutdown. rtnl is probably not enough as
> there is still race who grabs it first.

No, the rtnl definitely is enough right now since userspace will do
whatever it needs to _before_ invoking the kernel suspend.

I say we should just put these patches in as they are.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH v2 0/3] mac80211 suspend/resume

[Tomas Winkler]

On Sat, Jan 10, 2009 at 11:27 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Sat, 2009-01-10 at 01:53 +0200, Tomas Winkler wrote:
>
>> I second this by stressing another issue. in the point that
>> suspend/resume events shell be present to user space regardless of
>> mac80211 specific talk with wpa_supplicant. Not only Wifi but also in
>> my knowledge BT and other coms need user space application
>> to close gracefully connection before kernel shuts in down.
>
> But userspace is usually the one _invoking_ the suspend, so what I was
> trying to say is that we don't care what userspace did right before
> invoking suspend.

Exactly, so routing suspend event from mac80211 to wpa_supplicant or
NM just doesn't look right to me, if I understood properly Marcel
suggestion.

>
>> Even sometime leavening shutting down interface managing application
>> may reduce the crosstalk so that driver doesn't have go guess when
>> application has finished it's shutdown. rtnl is probably not enough as
>> there is still race who grabs it first.
>
> No, the rtnl definitely is enough right now since userspace will do
> whatever it needs to _before_ invoking the kernel suspend.
>
> I say we should just put these patches in as they are.

No objections to that.

Tomas

Re: [PATCH v2 0/3] mac80211 suspend/resume

[Bob Copeland]

On Sun, Jan 11, 2009 at 01:11:23PM +0200, Tomas Winkler wrote:
> On Sat, Jan 10, 2009 at 11:27 AM, Johannes Berg
> > I say we should just put these patches in as they are.
> 
> No objections to that.

Ok, it doesn't sound like there are objections to the substance of
the patches now.  

John, do you want a rebase/resend?  I have only one minor change to 
v2 posting: adding my s-o-b to Johannes's patch.

-- 
Bob Copeland %% www.bobcopeland.com

Re: [PATCH v2 0/3] mac80211 suspend/resume

[Dan Williams]

On Tue, 2009-01-06 at 20:36 +0100, Marcel Holtmann wrote:
> Hi Dan,
> 
> > > > > > > > Running pm-suspend from pm-utils directly also triggers the problem, 
> > > > > > > > so that would seem to excuse gnome-power-manager at least.
> > > > > > > 
> > > > > > > What's the status of this? Should I look into things a bit?
> > > > > > 
> > > > > > Well, I guess I should have noticed this a lot earlier, but anyway the 
> > > > > > problem was pm-utils on Fedora 10:
> > > > > > 
> > > > > > /usr/lib/pm-utils/sleep.d/55NetworkManager:
> > > > > > 
> > > > > >     suspend_nm()
> > > > > >     {
> > > > > >         # Tell NetworkManager to shut down networking
> > > > > >         dbus-send --system                         \
> > > > > >             --dest=org.freedesktop.NetworkManager  \
> > > > > >             /org/freedesktop/NetworkManager        \
> > > > > >             org.freedesktop.NetworkManager.sleep
> > > > > >     }
> > > > > > 
> > > > > > I really don't think this is necessary (g-p-m will also do it if you 
> > > > > > set the proper gconf setting.)
> > > > > 
> > > > > this should not be needed at all. I have systems running wpa_supplicant
> > > > > and not any of the pm-utils scripts messing with it. During suspend and
> > > > > later resume it indicates normally just only a new handshake with the AP
> > > > > or a disconnect if the AP got out of range.
> > > > > 
> > > > > I think Network Manager is perfectly capable of handling state changes
> > > > > from wpa_supplicant. I really do think that this hack only exists of
> > > > > some broken drivers from really old kernels or for the 0.6 version of
> > > > > Network Manager. Remember that Ubuntu's suspend/resume solution used to
> > > > > be to unload all networking drivers on suspend.
> > > > 
> > > > You still want to tell NM to go to sleep so it doesn't see the
> > > > disconnection from the supplicant (triggered by the driver because it
> > > > was going to sleep), and thus try to reconnect, or try a different AP.
> > > > Ideally NM would simply listen for signals from some power service such
> > > > that we wouldn't have to have this hack, but there isn't a global power
> > > > service yet on the system bus.
> > > > 
> > > > Furthermore, it's nice to know if we've gone to sleep or not so that we
> > > > can do some optimizations on wakeup to find APs and reconnect faster.
> > > 
> > > actually the fastest way to re-connect is to just let wpa_supplicant do
> > > it and then you don't even have to go through DHCP again if the lease
> > > time is still valid. This works great if the AP is still in range.
> > > 
> > > What is your downside with the letting wpa_supplicant send you a
> > > disconnect when the AP is out of range after resume?
> > 
> > Depends on the driver what the resume behavior is with the supplicant.
> > But you want to alert *something* that the system is now going to sleep,
> > so that it can clean up state before doing so.
> > 
> > The problem is that you have absolutely no idea how long the sleep will
> > be.  It's at least 2 minutes with S2D, because that's how long it takes
> > to write your state out to disk.  It's less with S2R obviously, but when
> > you resume, there's no guarantee that you'll be in the same place.  You
> > cannot assume that you will be.
> > 
> > If you keep trying to reconnect to the same AP, many times you simply
> > won't be there and you'll spend the 10 or 20 seconds reconnecting to an
> > AP miles away, time that could have been spent scanning for the AP
> > that's *really* where you are.  Many people I know don't often suspend
> > at the same location they resume, thus trying to reconnect hurts
> > reconnection latency.
> > 
> > The ideal way to handle all this is to be *aware* of suspend/resume in
> > the supplicant (or NM), and on resume, do a quick probe-scan or two to
> > find out if the old AP is still around.  If it's not, do a full scan to
> > find all APs, and then pick the best one, which is probably not the one
> > you were associated with before.  Then you actually start the auth/assoc
> > process with an AP you know exists.
> > 
> > So my point is that *something* needs to be aware of the suspend/resume
> > at a userlevel, whether it's NM or the supplicant doesn't really matter
> > as long as you can do what I describe above on resume.
> 
> since mac80211 gets suspend/resume support, I think it is the best that
> we signal this to wpa_supplicant. In that case it can do the hard work
> here. Either it re-connects to the last AP or signals a disconnected
> state or trigger scanning.
> 
> Having the suspend scripts to tell NM to disconnect is just not a good
> solution and especially in the embedded world this is a broken design
> concept.

Right; the missing piece is pushing the necessary roaming support down
to the supplicant and letting it make the decisions about what to
connect to.  There's a few things that I need from the supplicant before
I can simply push the entire config set down from NM and let it go wild:

1) A 'frequency' config item that works in infrastructure mode too,
ignoring any AP not matching that frequency

2) Implementing the resume behavior that I mentioned above, with
immediate directed scans for the last-connected AP, followed up by the
normal non-directed scan + ap selection process that already happens.

3) Some method of getting suspend/resume notifications to the supplicant

4) Ensure that the D-Bus interface has the right signals emitted to
notify clients of what network block & exact AP it's connecting to when
it starts to connect.

I agree, the closer to the hardware this stuff happens, the better for
reconnection latency.  I don't object to pushing roaming responsibility
into the supplicant from NM, but more work needs to be done (probably by
me) to support that and preserve the current level of functionality that
NM has.

Dan

Re: [PATCH v2 0/3] mac80211 suspend/resume

[Kalle Valo]

Dan Williams <dcbw@redhat.com> writes:

>> Having the suspend scripts to tell NM to disconnect is just not a good
>> solution and especially in the embedded world this is a broken design
>> concept.
>
> Right; the missing piece is pushing the necessary roaming support down
> to the supplicant and letting it make the decisions about what to
> connect to.  There's a few things that I need from the supplicant before
> I can simply push the entire config set down from NM and let it go wild:
>
> 1) A 'frequency' config item that works in infrastructure mode too,
> ignoring any AP not matching that frequency

Just out of curiosity, why this feature is needed? I can understand
hard-coding bssid, but I don't understand the use for hard-coding the
frequency.

-- 
Kalle Valo

Re: [PATCH v2 0/3] mac80211 suspend/resume

[Dan Williams]

On Fri, 2009-01-09 at 09:55 +0200, Kalle Valo wrote:
> Dan Williams <dcbw@redhat.com> writes:
> 
> >> Having the suspend scripts to tell NM to disconnect is just not a good
> >> solution and especially in the embedded world this is a broken design
> >> concept.
> >
> > Right; the missing piece is pushing the necessary roaming support down
> > to the supplicant and letting it make the decisions about what to
> > connect to.  There's a few things that I need from the supplicant before
> > I can simply push the entire config set down from NM and let it go wild:
> >
> > 1) A 'frequency' config item that works in infrastructure mode too,
> > ignoring any AP not matching that frequency
> 
> Just out of curiosity, why this feature is needed? I can understand
> hard-coding bssid, but I don't understand the use for hard-coding the
> frequency.

If the user wishes to lock the connection to a specific frequency,
irregardless of other values.  Maybe you're right and we don't really
care about it, but one other thing that would be nice is a "band"
argument for a network block to differentiate A vs. B/G APs that might
have the same SSID and security settings, but where the user only wants
to use the A-side for example.

Dan

Re: [PATCH v2 0/3] mac80211 suspend/resume

[Kalle Valo]

Dan Williams <dcbw@redhat.com> writes:

> On Fri, 2009-01-09 at 09:55 +0200, Kalle Valo wrote:
>> Dan Williams <dcbw@redhat.com> writes:
>> 
>> > 1) A 'frequency' config item that works in infrastructure mode too,
>> > ignoring any AP not matching that frequency
>> 
>> Just out of curiosity, why this feature is needed? I can understand
>> hard-coding bssid, but I don't understand the use for hard-coding the
>> frequency.
>
> If the user wishes to lock the connection to a specific frequency,
> irregardless of other values.

I guessed that part :) But I wanted to ask why would user want to do
this? I don't see any benefits from that.

> Maybe you're right and we don't really care about it, but one other
> thing that would be nice is a "band" argument for a network block to
> differentiate A vs. B/G APs that might have the same SSID and
> security settings, but where the user only wants to use the A-side
> for example.

This would be nice to have, most probably I would immediately disable
A band just to get faster scanning. I don't use 802.11a anywhere, for
me it's useless.

-- 
Kalle Valo