wpa_supplicant v0.6.3 loses connection, then reconnects to a different AP

[Dan Williams]

On Wed, 2008-06-04 at 11:19 -0700, David Ehrmann wrote:
> Maybe it's just a coincidence that there's a "PMKID candidate event"
> 35 seconds before the "Wireless event: new AP: 00:00:00:00:00:00."  I
> seemed to be getting PMKID candidate events every minute, anyway, so
> it's expected to see my "problem" event show up between them.
> 
> Time to look into why my driver is sending the new AP event?

Almost always :)  Unfortunately, (if you're using Linux) WEXT doesn't
allow a disassoc/reauth reason code along with the event.  A "new AP"
event of all zeros means a disassociation or deauthentication.

So on Linux you'll be looking for something like:

wireless_send_event(dev, SIOCGIWAP, &wrqu, NULL);

Sometimes they are sent from work queues, so in that case you'll need to
find the source of the workqueue trigger and print something out using
printk() as to why the workqueue is being started.  Other times the
wireless_send_event() call is in the same function as the code the
handles or decides to deauth/disassoc.

It could be any number of reasons; either the AP actually kicked you
off, at which point you should get a reason code in the diassoc/deauth
frames from the AP, or maybe the firmware missed too many beacons from
the AP because you are almost out of range, or because somebody turned
on a microwave, or maybe scans take too long and something is triggering
scans.  A whole lot of reasons but only the driver knows.

Dan

> 
> On Wed, Jun 4, 2008 at 1:20 AM, Jouni Malinen <j at w1.fi> wrote:
> >
> > On Tue, Jun 03, 2008 at 08:56:00PM -0700, David Ehrmann wrote:
> >
> > > Strange thing... xx:xx:xx:04:85:aa IS the AP specified in my config
> > > file.  Looking at my log, I see lots of these message bursts, all
> > > separated by 60 sec (+/- a few sec):
> > >
> > > RTM_NEWLINK: operstate=1 ifi_flags=0x11043 ([UP][RUNNING][LOWER_UP])
> > > Wireless event: cmd=0x8c09 len=32
> > > PMKID candidate wireless event: flags=0x0 index=0 bssid=xx:xx:xx:04:85:aa
> > > RSN: PMKID candidate event - bssid=xx:xx:xx:04:85:aa index=0 preauth=0
> > > RSN: Ignored PMKID candidate without preauth flag
> >
> > These are like generated by the driver based on background scans. The
> > driver is likely reporting all BSSes that match the BSS, including the
> > currently selected BSS.
> >
> > > Then, after the aforementioned ( http://pastebin.com/f491af16d )
> > > sequence, my AP (xx:xx:xx:04:85:aa) gets added to the blacklist, and the
> > > wireless interface ends up appearing unassociated with an AP when I run
> > > iwconfig.
> >
> > I do not think this is directly related to the PMKID candidate messages,
> > but the background scans may cause the driver to try to associate with
> > another BSS.
> >
> > > Is there any special meaning to seeing the event every 60 seconds, or is
> > > it just some value used in the driver?  I'm guessing the driver
> > > shouldn't be spamming wpa_supplicant with these messages, but is
> > > blacklisting the current AP the right behavior?
> >
> > Yes, this is normal behavior for reporting visible BSSes as potential
> > targets for PMKSA caching based on background scan results. The AP is
> > not blacklisted because of these messages; blacklisting is only used to
> > allow other BSSes to be tried if the BSS with strongest signal strength
> > fails association/authentication (either due to timeout or
> > authentication failure).
> >
> > --
> > Jouni Malinen                                            PGP id EFC895FA
> > _______________________________________________
> > HostAP mailing list
> > HostAP at lists.shmoo.com
> > http://lists.shmoo.com/mailman/listinfo/hostap
> _______________________________________________
> HostAP mailing list
> HostAP at lists.shmoo.com
> http://lists.shmoo.com/mailman/listinfo/hostap