Date: Wed, 6 Feb 2013 16:20:51 -0600
From: Seth Forshee <seth.forshee@canonical.com>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: linux-wireless@vger.kernel.org,
	Stanislaw Gruszka <sgruszka@redhat.com>
Subject: Re: [PATCH 3/4] mac80211: Improve error handling for off-channel
 operation
Message-ID: <20130206222051.GD6280@thinkpad-t410> (sfid-20130206_232058_584130_FF8E40E9)
References: <1360162873-17240-1-git-send-email-seth.forshee@canonical.com>
 <1360162873-17240-4-git-send-email-seth.forshee@canonical.com>
 <1360187077.7910.78.camel@jlt4.sipsolutions.net>
 <20130206220517.GC6280@thinkpad-t410>
 <1360188651.7910.80.camel@jlt4.sipsolutions.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <1360188651.7910.80.camel@jlt4.sipsolutions.net>
Sender: linux-wireless-owner@vger.kernel.org

On Wed, Feb 06, 2013 at 11:10:51PM +0100, Johannes Berg wrote:
> On Wed, 2013-02-06 at 16:05 -0600, Seth Forshee wrote:
> > On Wed, Feb 06, 2013 at 10:44:37PM +0100, Johannes Berg wrote:
> > > On Wed, 2013-02-06 at 09:01 -0600, Seth Forshee wrote:
> > > > Errors in sending the nullfunc frame to set powersave at the AP for
> > > > off-channel operation can lead to high packet loss. Add error handling
> > > > to fail going off-channel when this happens, and return an error to
> > > > userspace.
> > > 
> > > With the flushes in place, have you ever seen this fail? This and patch
> > > ones seems like a lot of churn for only half of what you'd want -- what
> > > you really want is to know if the AP ACKed the frame...
> > 
> > That's a good point. I've seen iw fail to initiate scans, but I can't
> > say whether or not any of them was due to the queues being stopped for
> > some reason. When I was testing NetworkManager was still managing the
> > interface, so at least some failures were undobtedly because another
> > scan was ongoing.
> 
> Yeah you'd expect that. I think you could tell the difference -- EBUSY
> vs. whatever other error code you chose?

Sure. I _can_ test for that, just saying that I haven't.

> > I'd considered trying to expand this to check whether or not the frame
> > was acked -- in fact just today I captured a trace where the AP didn't
> > ack the frame but the STA went off-channel anyway. I'm not sure how to
> > implement that yet, and haven't found time to look into it.
> 
> It means waiting for the TX status from the driver, which might not
> really come with all drivers at all, making it somewhat tricky in
> general.
> 
> Anyway my point is that this doesn't really help all that much, and
> patch 1 and 3 together is a lot of churn ...

Fair enough. If you want I can drop those and resend 2 and 4, because
they do fix real problems.

Seth