On Thu, 2011-09-29 at 17:00 +0200, Stanislaw Gruszka wrote: > On Tue, Sep 27, 2011 at 01:34:49PM +0200, Johannes Berg wrote: > > On Tue, 2011-09-27 at 13:12 +0200, Stanislaw Gruszka wrote: > > > It is not possible to connect to remote station on two bands > > > at once, or I'm wrong? > > > > I don't think it is, but there could be channel switches maybe? > > If AP would like to change to different band, it will need provide new > Supported Rates element, or operate on older one. > > So this could be simplified, but from other hand this helps to catch > bugs, so maybe would be better to keep it. As long some other warning > would be added to check that we send on proper channel. 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) ... > > > Which may happen when we are just after disassociation and changed > > > channel/band, but still want send some frames (namely delBA) to old > > > sta. Right fix should prevent to change channel before we fully > > > dissassocate, or prevent to send frames after connection is lost, > > > or both, but I don't know how to correctly do this so far. > > > > Well, either we should simply not send the frame, or send it before > > disassoc, no? > > I think I can fix this that way, but I'm not sure if that would be right > fix either. We have few instances of warning: I think that would be the right fix. In some cases, we may want to reorder things instead of just not sending frames. > 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? > 2) started at ieee80211_tx_status() > https://bugzilla.redhat.com/show_bug.cgi?id=731365#c11 > could be fixed by adding association check before > ieee80211_send_bar() That seems reasonable. No use in trying to tear down BA sessions when we're already disconnected. > 3) started at ieee80211_offchannel_return() > https://bugzilla.redhat.com/show_bug.cgi?id=737993#c0 > no idea how to fix Hm, seems like maybe offchannel return is telling the AP that we woke up, but maybe the offchannel work disconnected or something? > All these problems looks like channel switching issue - > - we changed channel, whereas we should still operate on old one. > Fedora 15 users start to report that WARNING after update to 3.0 > from 2.6.38, so this could be related to Ben offchannel work. That's very well possible. Thanks for looking into all this! 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
