[PATCH 16/16] P2P: Don't switch channel during group formation

[Peer, Ilan]

> -----Original Message-----
> From: Jouni Malinen [mailto:j at w1.fi]
> Sent: Friday, June 19, 2015 11:37
> To: Peer, Ilan
> Cc: hostap at lists.shmoo.com; Stern, Avraham
> Subject: Re: [PATCH 16/16] P2P: Don't switch channel during group formation
> 
> On Wed, Jun 17, 2015 at 04:25:02PM +0300, Ilan Peer wrote:
> > On 40Mhz channels, primary and secondary channels are sometimes
> > switched to get secondary channel with no beacons from other BSSes.
> > However, when starting a P2P GO after GoN, this may fail the group
> > formation since the client will search the GO on the original primary
> > channel.
> 
> This does not sound correct. P2P GO is always allowed to change channels,
> even between GO Negotiation and the start of beaconing. P2P Client must be
> capable of finding the GO even if it has changed channels. This may add some
> small delay due to having to run full scans, but that sounds acceptable to me
> when it allows following the 20/40 MHz co-existence requirements.
> 

This is the case. I guess that the increased discovery time is preferable in this case, as better performance can be achieved.

> > Fix this by not switching the primary and secondary channel during P2P
> > group formation. This also fixes failures seen with hwsim test
> > "go_neg_forced_freq_diff_than_bss_freq".
> 
> Could you please provide more details on how that test case is failing?
> I don't see it in my test setup.. wpa_supplicant does search the GO from other
> channels than only the one indicated during GO Negotiation.
> 

This failure happens when HT/VHT are enabled by default for P2P GO (this is the case in our testing setups, but not in the master branch). In such a case, a PRI/SEC switch done in the AP layer is not transparent to the containing wpa_supplicant interface that reports the original frequency over the control interface, although it started beaconing on the adjacent frequency. However, the client reports the frequency on which it associated which is different, so the test fails on a the frequency verification.

Maybe the real fix in this case would be to fix the reporting of the frequency on the P2P GO + fix the test to verify the P2P GO and Client report the same freq.

Regards,

Ilan.