On Thu, 2012-02-23 at 17:59 -0800, Paul Stewart wrote: > mac80211 is lenient with respect to reception of corrupted beacons. > Even if the frame is corrupted as a whole, the available IE elements > are still passed back and accepted, sometimes replacing legitimate > data. It is unknown to what extent this "feature" is made use of, > but it is clear that in some cases, this is detrimental. One such > case is reported in http://crosbug.com/26832 where an AP corrupts > its beacons but not its probe responses. > > One approach would be to completely reject frames with invaid data > (for example, if the last tag extends beyond the end of the enclosing > PDU). The enclosed approach is much more conservative: we simply > prevent later IEs from overwriting the state from previous ones. > This approach hopes that there might be some salient data in the > IE stream before the corruption, and seeks to at least prevent that > data from being overwritten. This approach will fix the case above. > > Further, we flag element structures that contain data we think might > be corrupted, so that as we fill the mac80211 BSS structure, we try > not to replace data from an un-corrupted probe response with that > of a corrupted beacon, for example. > > Short of any statistics gathering in the various forms of AP breakage, > it's not possible to ascertain the side effects of more stringent > discarding of data. Acked-by: Johannes Berg <johannes@xxxxxxxxxxxxxxxx> -- 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
