Re: [PATCH v2 2/2] AP: Set STA's assoc flag in the driver before sending assoc. resp.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Feb 07, 2016 at 03:11:15PM +0000, Peer, Ilan wrote:
> Indeed, we missed that point. However, as the port authorization is still handled
> in the association response callback flow, class 3 frames would be still dropped.

They would not be dropped in the "correct way". I.e., the AP should send
out a Disassociation frame with Reason Code 7 when receiving a Class 3
frame from nonassociated STA. In addition, IEEE 802.1X port applies only
for Data frames and as such, it would not have effect on how other Class
3 frames (mainly, Action frames) would be processed.

> We evaluated this option but preferred to handle this in hostap and not mac80211
> as it requires monitoring assoc req/resp frames in mac80211 (while MLME is handled in
> user space) which did not seem like a clean solution.

That may not seem like a clean solution from implementation view point,
but doing this before the association in hostapd is not a clean solution
from standards compliance view point..

> Does having the port authorization handled in the association callback a valid
> reasoning? If so I can update the commit message.

It is a reason, but not really a complete solution. That said, it may be
justifiable to ignore the exact compliance with the requirement with a
claim that number of other AP implementations do not do this correctly
and there is no significant known issues with accepting other (non-Data)
Class 3 frames during the short window before the TX status information
becomes available (and the STA entry can be removed if no ACK was seen).

> BTW, the issue addressed in the 2nd patch is valid even without the 1st one, as
> we see cases that frames sent from the station immediately after acking the association
> response are not handled on the AP side as the station is not yet added to the kernel.

Yeah, I kind of assumed that it would be fine on its own, but didn't see
any strong need to push it before figuring out what to do with the 2nd
one.

-- 
Jouni Malinen                                            PGP id EFC895FA

_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap



[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux