On Fri, Feb 24, 2012 at 3:59 AM, Paul Stewart <pstew@xxxxxxxxxxxx> 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. > [...] > @@ -705,7 +730,8 @@ u32 ieee802_11_parse_elems_crc(u8 *start, size_t len, > if (!elems->quiet_elem) { > elems->quiet_elem = pos; > elems->quiet_elem_len = elen; > - } > + } else > + elem_parse_failed = true; > elems->num_of_quiet_elem++; i'm not familiar with this IE, but num_of_quiet_elem, which defined as: u8 num_of_quiet_elem; /* can be more the one */ suggests we should treat it differently. Eliad. -- 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
