On Fri, 2012-02-24 at 07:25 -0800, Paul Stewart wrote: > >> > 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. > > How do we clear this flag? Let's say we got one corrupted beacon and > from then on, everything was ducky. We set the flag flag on the > corrupted beacon. Do we clear it on an unblemished probe response? > Are these really two flags, since beacons and probe responses > sometimes have different subsets of info, or does a valid probe > response clear both flags? Huh, good questions. Which info do we end up using? Just the one that was not corrupted? I think we always use the last IEs, no? Hmm. You said in the bug that supported rates were really only affected, and this caused an issue with the supported rates that we send, because we restrict ourselves to the rates the AP advertises (due to other buggy APs ...) Maybe then it doesn't matter all that much. OTOH, why should we ever reset the flag? Eventually the BSS entry will be deleted anyway? And if we keep reconnecting to it, maybe there's some other bug? I'm not really sure -- open to suggestions. I just think that in order to actually notice such things in the future we should print something so we don't get confused. 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
