[RFC] wpa_supplicant: add fast reconnect support

[Sam Leffler]

On Sun, Dec 4, 2011 at 12:17 PM, Jouni Malinen <j at w1.fi> wrote:

> On Tue, Sep 27, 2011 at 04:35:02PM +0200, Johannes Berg wrote:
> > On Wed, 2011-09-21 at 11:36 -0700, Sam Leffler wrote:
> > > I totally agree.  Since that patch I had to fix some edge cases and
> > > there may still be more.  I think to make this work right it needs to
> > > be carefully tied to the SME pieces of supplicant or madness will
> > > ensue.  OTOH all this could be dramatically simplified if one could
> > > just re-auth w/o having to re-establish the BSS entry in the kernel by
> > > doing the 1-channel scan...
>
> > I don't think it's actually possible though since we rely on the BSS
> > entry for a whole bunch of things like knowing what we're connected to.
>
> This is probably fine as long as you can use wpa_supplicant for the
> connection.. If you try to implement your own nl80211 commands and SME
> handler, you'll likely soon wish you had used something that had already
> implemented this.. ;-)
>
> > Maybe it'd be possible to hide it in driver_nl80211?
>
> Yes, that sounds like a good approach here and it certainly makes core
> wpa_supplicant implementation much simpler. This turned out to be quite
> a bit of code, but it's there now:
>
> commit 536fd62dba5480a2490726f0e3a9bc38225b0904
>    nl80211: Recover from auth req ENOENT with a scan
>  1 file changed, 149 insertions(+)
>
>
> The core code changes to kick this on recoverable reason codes in
> deauth/disassoc:
>
> commit d00821e913eda00e3c61aaacc78687766f150d11
>    Try to reconnect to the same BSS on recoverable disconnection
>  1 file changed, 34 insertions(+), 3 deletions(-)
>
>
> This goes through all the wpa_state values in the same way as normal
> connection would (well, apart from SCANNING). In the case the cfg80211
> BSS entry exists, the reconnection is pretty much instant. In case the
> single channel scan has to be done, about 100 msec seems to get added
> (with mac80211_hwsim; maybe some more with real hardware).
>
> I've done only limited testing on this so far and would be interested in
> hearing whether this addresses all optimizations done in the chromiumos
> patches (there was more than just the one posted on this list). At least
> the filtering of old scan results is not included here, so it might be
> worth consideration of adding it.
>
> Actually, the scan results are not even fetched to user space at this
> point, so BSS missing from there would not be noticed anyway.. Though,
> it should be easy to fetch the results for this special
> within-driver_nl80211.c scan, too, and at least check that the target
> BSS is included. Now this happens kind of implicitly if the second
> attempt at nl80211 auth command fails.
>
>
These changes fail our roaming test suite (which explicitly check fast
reconnect).  A quick glance indicates at least some failures are due to the
cached scan results.  I'll have to go through the logs to understand.

As to other changes in our code base that are not in yours; I pulled our
supplicant code forward to your ToT and it looks like we've got 3
differences:

1. support for raw psk
2. bgscan_simple algorithm changes
3. better roaming (but still not complete)

You can find our stuff by searching for commits marked CHROMIUMOS
here<http://git.chromium.org/gitweb/?p=chromiumos/third_party/hostap.git;a=summary>
.

-Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.shmoo.com/pipermail/hostap/attachments/20111220/a25557e5/attachment.htm