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