Re: [PATCH 3/4] mac80211: Improve error handling for off-channel operation

[Seth Forshee <seth.forshee@canonical.com>]

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