All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Williams <dcbw@redhat.com>
To: Marcel Holtmann <marcel@holtmann.org>
Cc: Bob Copeland <me@bobcopeland.com>,
	Johannes Berg <johannes@sipsolutions.net>,
	linux-wireless@vger.kernel.org, mabbaswireless@gmail.com
Subject: Re: [PATCH v2 0/3] mac80211 suspend/resume
Date: Thu, 08 Jan 2009 11:39:38 -0500	[thread overview]
Message-ID: <1231432778.21643.40.camel@localhost.localdomain> (raw)
In-Reply-To: <1231270575.14901.6.camel@californication>

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


  parent reply	other threads:[~2009-01-08 16:41 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-15  3:50 [PATCH v2 0/3] mac80211 suspend/resume Bob Copeland
2008-12-15 10:14 ` Johannes Berg
2008-12-15 15:22   ` Dan Williams
2008-12-15  9:28     ` Luis R. Rodriguez
2008-12-17 18:21     ` Bob Copeland
2008-12-23 20:30       ` Johannes Berg
2008-12-24  5:49         ` Bob Copeland
2008-12-24  7:16           ` Marcel Holtmann
2009-01-06 16:45             ` Dan Williams
2009-01-06 17:07               ` Bob Copeland
2009-01-06 17:14                 ` Johannes Berg
2009-01-06 17:35                   ` Bob Copeland
2009-01-06 17:43                     ` Johannes Berg
2009-01-06 18:01                       ` Bob Copeland
2009-01-06 18:16                         ` Johannes Berg
2009-01-06 17:12               ` Marcel Holtmann
2009-01-06 18:52                 ` Dan Williams
2009-01-06 19:36                   ` Marcel Holtmann
2009-01-06 20:05                     ` Johannes Berg
2009-01-09 23:53                       ` Tomas Winkler
2009-01-10  9:27                         ` Johannes Berg
2009-01-11 11:11                           ` Tomas Winkler
2009-01-11 14:40                             ` Bob Copeland
2009-01-08 16:39                     ` Dan Williams [this message]
2009-01-09  7:55                       ` Kalle Valo
2009-01-09 16:35                         ` Dan Williams
2009-01-09 16:44                           ` Kalle Valo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1231432778.21643.40.camel@localhost.localdomain \
    --to=dcbw@redhat.com \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=mabbaswireless@gmail.com \
    --cc=marcel@holtmann.org \
    --cc=me@bobcopeland.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.