Re: AP + P2P_GO multichan tests with intel7260 as a P2P_CLIENT - direct probe issue

[Johannes Berg <johannes@sipsolutions.net>]

On Thu, 2015-07-02 at 17:43 +0530, Krishna Chaitanya wrote:
> 
> Thismight still be relevant, if you remember our discussion
> (
> http://permalink.gmane.org/gmane.linux.kernel.wireless.general/135533
> )
> a while ago, in a passive scan environment beacon might have
> the latest information than probe response but we end up using
> probe response, so in those cases direct probe helps to
> get the right capabilities.
> 
> But i remember your argument about changing AP config is not
> much of a use case :-)

Yeah I still don't think this is much of an issue.

> In an environment where AP config is changed this might be helpful
> else not needed. Given the enterprise wifi deployments using 
> controllers auto-changing of AP config based on the environemnt may 
> not be far away

I can see the HT/VHT operation changing, and perhaps even channel
jumping, but staying on the channel and changing parameters that can't
actually be updated on the fly seems a bit strange. I'm not even sure
what parameters those would be.

That said, I found at least one issue with removing the direct probe:
If the beacon only has WMM info and not WMM parameters (as permitted by
the WMM spec) then we would disable WMM in ieee80211_mgd_assoc() if we
don't have a probe response. We'd thus have to move validation to after
having received the association response, but at that point it's not
clear to me what we should do if we don't receive good WMM parameters,
then we can't connect without WMM any more.

johannes