On Mon, Nov 29, 2010 at 08:53:23PM +0100, Christian Lamparter wrote: > This patch fixes an curious issue due to insufficient > rx frame filtering. Well.. In theory, there is nothing saying that Deauthentication / Disassociation frames could not be used with multicast addresses.. Not that I would expect anyone to really use this option ever. > [ 2352.453804] Ignore 0d:1f:31:f8:64:ff > [ 2352.453808] Ignore 0d:1f:31:f8:64:ff > ^^ the group-address flag is set! > (the correct SA/TA would be: 00:1f:31:f8:64:ff) > > Since the AP does not know from where the frames come, it > generates a DEAUTH response for the (invalid) mcast address. > This mcast deauth frame then passes through all filters and > tricks the stack into thinking that the AP brutally kicked > us! This is an interesting frame for from the AP view point, too.. I don't remember whether there is any explicit statement about the SA being individual address, but it would sounds reasonable to avoid sending out Deauth/Disassoc frames based on this type of bogus addresses if the result would go out as a multicast frame. > This patch fixes the problem by simply ignoring > non-broadcast, group-addressed deauth/disassoc frames. While this is not strictly speaking correct (i.e., we would need to check whether we are part of the multicast group group), this sounds like a reasonable thing to do in case of Deauthentication and Disassociation frames. I don't really see any reasonable use cases for non-broadcast multicast with them. Action frames may actually get such use, so the v2 is a good update. -- Jouni Malinen PGP id EFC895FA -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
