Re: [PATCH] mac80211: stop scan before connection

On Wed, 2015-03-18 at 12:11 +0200, Eliad Peller wrote:

i'm not sure. the AP will probably have some retransmissions, 

It hopefully will, but they'll be real retransmissions (with retry bit),
usually occurring within a very short period of time.

so the
station should have good chances to get the frames (assuming the
hardware will give this interface some airtime during the scan).

So the normal dwell time during even an active scan (say 30ms) will mean
that all of those retries will not be heard once you miss the first one.

quoted

So in a sense you could say deferring the handling doesn't make sense,
but I'd still argue you shouldn't start this process while you're in the
middle of scanning, hence this patch.

i agree the patch makes sense anyway, i just noted that mac80211
behavior seems wrong.
you should avoid scanning while connecting in first place, not defer
the handling.

Yeah, agree.

btw, note that both this patch and ieee80211_iface_work() don't count
for the sched scan case, which is basically the same.

True, except we can't really cover that case since we don't even know
when we're really scanning while sched scan is enabled.

I'd expect drivers to either abort the scheduled scan in that case, or
protected the authentication/association in some way (like iwlwifi does,
for example, by giving a few hundred ms of guaranteed channel time in
the mgd_prepare_tx method)

quoted

We may have to do more exclusions (e.g. don't start a scan while
authenticating or associating) here though, and ultimately not
*processing* the frames will be irrelevant as they shouldn't be coming
in anyway.

that's true for auth/assoc frames. but some other frames (e.g. deauth)
can come anytime, and i don't see why we should defer processing in
this case.

Yeah, true. This seems like something we should take a closer look at,
think about the design more and document the expectations better.

Still, I think this patch is one step along that way.

johannes