Return-path: Received: from mail-gw0-f46.google.com ([74.125.83.46]:56025 "EHLO mail-gw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751089Ab0I2RLA (ORCPT ); Wed, 29 Sep 2010 13:11:00 -0400 Received: by gwj17 with SMTP id 17so348145gwj.19 for ; Wed, 29 Sep 2010 10:11:00 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <1285748303.3756.19.camel@jlt3.sipsolutions.net> References: <20100928222945.GB10932@tux> <1285748303.3756.19.camel@jlt3.sipsolutions.net> From: "Luis R. Rodriguez" Date: Wed, 29 Sep 2010 10:10:38 -0700 Message-ID: Subject: Re: [PATCH] mac80211: fix rate_control_send_low warnings for delbas To: Johannes Berg Cc: linville@tuxdriver.com, stable@kernel.org, linux-wireless@vger.kernel.org, Paul Stewart , Amod Bodas , Vasanthakumar Thiagarajan , Jouni Malinen Content-Type: text/plain; charset=UTF-8 Sender: linux-wireless-owner@vger.kernel.org List-ID: On Wed, Sep 29, 2010 at 1:18 AM, Johannes Berg wrote: > On Tue, 2010-09-28 at 15:29 -0700, Luis R. Rodriguez wrote: > >> Since we end up associated to two different APs at the same >> time to transmit to either AP consists of an offchannel >> operation but today we just lack the state machine to be able >> to do this properly so for now just drop those frames. > > 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? Luis