On Wed, Sep 29, 2010 at 10:25 AM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Wed, 2010-09-29 at 10:10 -0700, Luis R. Rodriguez wrote: > >> > I really think that can be done more easily though. For one, clearly we >> > already have the warning, so we don't need more infrastructure to catch >> > such errors?! >> >> This is true, I just added that to ensure I hit these when testing >> really, I can nuke the counter, but it can help if eventually believe >> we have a proper fix to allow these frames through somehow too. >> >> > Also, this may end up hiding issues that we don't yet >> > understand, like the nullfunc one you were talking about. >> >> Yeah, good point, although I am under the impression this is a similar >> situation, we probably try to send a nullfunc to notify the old AP we >> are going to go awake if we are transmitting data while roaming. But >> yeah, its not easily triggerable yet. >> >> > The delBA one >> > we now understand fully, so it makes more sense to simply suppress >> > sending delBA when we are going to disassociate by way of associating >> > with a new AP, no? >> >> That's reasonable but we will still need the channel, otherwise how >> would we know its this issue? > > Why do we care? We can just always suppress sending the delba when we > get into _set_disassoc() from mgd_assoc(), no? Yeah, and I actually think I found another race with this code, I'm going to try something a bit different now. Luis -- 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
