Could not set station flag for kernel driver

[Jouni Malinen]

On Fri, Sep 02, 2011 at 04:42:42PM +0530, Yogesh Ashok Powar wrote:
>  We have seen following errors when station dissassociates & deauths.
> 
> >wlan0: AP-STA-DISCONNECTED 0c:74:c2:9a:4c:59
> >wlan0: STA 0c:74:c2:9a:4c:59 IEEE 802.11: disassociated
> >wlan0: AP-STA-DISCONNECTED 0c:74:c2:9a:4c:59
> >Could not set station 0c:74:c2:9a:4c:59 flags for kernel driver (errno=97).

Does this cause any noticeable misbehavior apart from that message in
hostapd output?

> It seems like hostapd tries to set station flags even after the station
> deletion. Following is the patch which avoid removing station entries
> from disassoc handler; this will defer station removal to deauth
> handler through 'ap_free_sta' call.

This could potentially cause some problems unless the station entry in
kernel is move to disassociated state. Since the assumption is more or
less that the kernel driver maintains a STA entry only when the STA is
associated, this could leave a window open to enable some frames to be
accepted when they should not be.

It looks like the encryption keys get removed, so the STA entry in
kernel could potentially even accept unencrypted frames. At minimum, the
STA entry needs to be unauthorized with ap_sta_set_authorized(hapd, sta,
0). This is actually pretty similar to what I did recently to allow
Deauthentication/Disassociation frames to be PS buffered:
http://w1.fi/gitweb/gitweb.cgi?p=hostap.git;a=commitdiff;h=4dc03726de072b127ba4f219cdf50df8f9b7c9be

Doing this type of changes comes with a risk and I would rather not do
this unless there is a real issue that gets fixed by leaving the STA
entry in kernel for longer time (like there was in the case of
transmitting Deauth/Disassoc; but I do not see similar reason in the
receiving Deauth/Disassoc case).

-- 
Jouni Malinen                                            PGP id EFC895FA