On Fri, 2012-02-24 at 06:24 -0800, Paul Stewart wrote: > On Thu, Feb 23, 2012 at 11:34 PM, Johannes Berg > <johannes@xxxxxxxxxxxxxxxx> wrote: > > 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. > >> > >> 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. > > > > Hmmm. This seems reasonable, but in the given example (in the bug > > report) it will at least lose the WMM info (since it's corrupt) and the > > HT info, as well as WPS (which is probably not relevant.) > > As you can see from the association request, the STA appears to hold > an amalgamation of the broken rate information in the beacon and the > correct HT/WMM information from the probe response. In the > association request there's both HT and WMM info, as it was able to > get it from the probe response. Ah, indeed, I hadn't even looked at that. > > I suppose better to accept such service degradation than not connect, > > but I wonder if we should log a warning when we actually try to use such > > an AP? > > Let me know where you'd like it. How about having a flag in the BSS struct (ieee80211_bss) and printing a message when we use that BSS struct for assoc? E.g. in ieee80211_mgd_assoc()? I'm not sure I fully understand where this actually has any effect. johannes -- 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
