On Wed, 2011-10-05 at 13:15 +0200, Stanislaw Gruszka wrote: > > Yeah I was going to say ... the main purpose of this these days seems to > > be catching this tx-on-wrong-band (which should be channel) ... > > There is a old patch from Luis, which add channel to sta_info, > http://www.spinics.net/lists/linux-wireless/msg56399.html > I could incorporate it into my sta->supp_rates[BAND] removal patch, > so we will not loose debuggability, but event extend it. That seems tricky with CSA, I'm not sure I'd want to go there? > > > 1) started at ieee80211_sta_connection_lost() > > > https://bugzilla.redhat.com/show_bug.cgi?id=731365#c0 > > > could be fixed by: > > > ieee80211_set_disassoc(..., false); > > > ieee80211_send_deauth_disassoc(, false); > > > > Why would this trigger the problem? Can we somehow lose connection while > > already trying to connect to a new AP? > > Not sure if I understand. I think that change should not influence > new AP connection. Also if we really loose connection to old AP, not > sending deauth/disassoc frames does not matter. It can have matter if > for some reason old AP start to become available again, so we properly > disassociate. But for such corner case we should rather not care. True, but I'm not sure I understand how we can even run into the problem in this scenario. How can we be on a different band when detecting that the AP went away? No wonder it went away then ... we're on the wrong band?! 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
