Disassociation notification received - possible foul play?

Dan Williams dcbw at redhat.com
Wed Jun 6 12:15:08 EDT 2012


On Wed, 2012-06-06 at 13:31 +0100, Michael Zintakis wrote:
> > You would need to take a look at the driver you are using to figure out
> > why it indicated disconnection.
> >   
> Well, I thought the log excerpts I attached show the reason for that, 
> no? Here it is again:
> 
> Wireless event: cmd=0x8b15 len=24
> Wireless event: new AP: 00:00:00:00:00:00
> wlan0: Event DISASSOC (1) received
> wlan0: Disassociation notification
> 
> Wouldn't that indicate that "Disassociation notification" was received 
> from "new" AP with MAC address 00:00:00:00:00:00 and that was the reason 
> for the disconnection?

WEXT simply cannot convey a disconnect reason.  It's a hard limitation
of the WEXT API.  Which is one reason cfg80211/nl80211 was developed.
In your case, you simply have to enable driver debugging and figure out
why the driver decided to emit the disassociation event.  The WEXT
command you're seeing is actually "new association" (*not*
disassociated) but the BSSID of 00:00:00:00:00:00 means "disassociated"
since it's not a legal MAC address.  That's just how WEXT does things,
and that's why we try as hard as we can to kill it.

Dan

> > You seemed to be using the old WEXT driver interface which
> > does not provide enough details to wpa_supplicant to know what happened
> > and as such, 
> I have no choice in the matter as the underlying device only supports wext.
> 
> I am open to suggestions though - if you (or anybody else) know of 
> either a USB (ideally, "nano" class, but a regular USB would do too) 
> device or a smartphone with a wireless chip which supports both the new 
> netlink standard as well as 802.11i and 802.11w then I'll be glad to 
> hear it. So far, my own (re)search proved to be completely fruitless - 
> it seems that chips supporting that set of standards (the latter of 
> which which was finalised 3 years ago!) are like gold dust!
> 
> I know it is unlikely that I'd have the same problem with my AP - it is 
> based on atheros chip and as far as I know these standards are supported 
> there, so I think that it is unlikely that I will experience that sort 
> of difficulties on the AP side. The problem for me is the client side.
> 
> _______________________________________________
> HostAP mailing list
> HostAP at lists.shmoo.com
> http://lists.shmoo.com/mailman/listinfo/hostap




More information about the HostAP mailing list