[RFC] wpa_supplicant: add fast reconnect support

Sam Leffler sleffler at google.com
Wed Dec 21 18:53:21 EST 2011


On Wed, Dec 21, 2011 at 3:23 PM, Jouni Malinen <j at w1.fi> wrote:

> On Tue, Dec 20, 2011 at 09:53:47AM -0800, Sam Leffler wrote:
> > 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.
>
> OK, that sounds reasonable. It sounds like we should try to eventually
> try to get some of those scan changes into upstream..
>

I went through the logs and found three issues, only one seems to be in
wpa_supplicant.  This test

http://git.chromium.org/gitweb/?p=chromiumos/third_party/autotest.git;a=blob;f=server/site_tests/network_WiFiRoaming/000ChannelHop;h=d933ad05a850489625c57f9f484faba15d73e8dc;hb=HEAD

fails because the kernel looks to cache the old BSS entry so our code to
verify frequency on the client aborts (it still thinks we're associated at
2412 and not at 2437).  This is not your problem as we roamed correctly and
passed traffic.

The test the demonstrates a problem is this one:

http://git.chromium.org/gitweb/?p=chromiumos/third_party/autotest.git;a=blob;f=server/site_tests/network_WiFiRoaming/006BeaconLoss;h=35e1c01b952a71ba86c5c977ad5ddd22b676c448;hb=HEAD

The issue is that when the AP is silently taken down (i.e. w/o sending
deauth) the client trys to reauth but fails--but never notifies the
connection manager over D-bus so it thinks it's still associated.  I
believe when I split the state machine for fast reconnect I had to handle
this case in sme.c for reauth failure.

There's a third test that fails but it's our problem
(003SSIDMultiSwitchBack assumes you can change the txpower on one VIF of a
multi-VIF AP setup).


>
> > 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
> >
>
> I actually have a git repository with the latest chromiumos hostap.git
> rebased on top on hostap.git master and with patches a bit cleaned up
> and merged together to keep things in easier to track state.
>
> At the moment, it looks like this (the "[NO]" prefix identifies commits
> that are not applicable to upstream):
>
>
> Anush Elangovan (1):
>      [NO] CHROMIUMOS: Setup code review inheritance
>
> Nathan Williams (1):
>      [NO] CHROMIUMOS: wpa_supplicant: Permit the at_console user access
>
> Paul Stewart (3):
>      CHROMIUMOS: bgscan: Add centralized signal_monitor
>      CHROMIUMOS: wpa_supplicant: Refinements to fast-scan backoff
>      [NO] CHROMIUMOS: wpa_supplicant: Create presubmit config for
> wpa_supplicant
>
> Ryan Cairns (1):
>      [NO] CHROMIUMOS: Adds a link from . to hostap.git
>
> Sam Leffler (11):
>      CHROMIUMOS: wpa_supplicant: add fast reconnect support
>      CHROMIUMOS: wpa_supplicant: Accept raw PMK in new DBus API
>      CHROMIUMOS: wpa_supplicant: filter scan results during fast reconnect
>      CHROMIUMOS: wpa_supplicant: handle auth failure during fast reconnect
>      wpa_supplicant: add support for tx aborting a scan
>      bgscan_simple: mark scans so that tx will abort
>      wpa_supplicant: do not expire bss entries when a scan is aborted
>      [NO] CHROMIUMOS: wpa_supplicant: change dbus access policy
>      [NO] CHROMIUMOS: wpa_supplicant: remove d-bus specification for the
> old api
>      [NO] CHROMIUMOS: do not auto-startup wpa_supplicant
>      CHROMIUMOS: wpa_supplicant: improve roaming when noise floor available
>
>
> Wow, thanks, that looks right  I'm actively trying to pull us up to ToT in
master and would love to sync up.  The roaming changes are unfinished
(think I told you that).

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


More information about the HostAP mailing list