Message-ID: <742e0bdf-8208-3190-f5cc-a2438aeaf813@quicinc.com>
Date:   Thu, 2 Mar 2023 12:43:42 -0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.8.0
Subject: Re: [PATCH v2 07/23] wifi: wireless: correct validation 6G Band for
 primary channel
Content-Language: en-US
To:     <gregory.greenman@intel.com>, <johannes@sipsolutions.net>
CC:     <linux-wireless@vger.kernel.org>,
        Mordechay Goodstein <mordechay.goodstein@intel.com>
References: <20230301100935.170922-1-gregory.greenman@intel.com>
 <20230301115906.314faf725255.I5e27251ac558297553b590d3917a7b6d1aae0e74@changeid>
From:   Jeff Johnson <quic_jjohnson@quicinc.com>
In-Reply-To: <20230301115906.314faf725255.I5e27251ac558297553b590d3917a7b6d1aae0e74@changeid>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 3/1/2023 2:09 AM, gregory.greenman@intel.com wrote:
> From: Mordechay Goodstein <mordechay.goodstein@intel.com>
> 
> Current check that beacon primary channel is in the range of 80Mhz
> (abs < 80) is invalid for EHT 320Mhz due to 6G DUP beacon means that

s/Mhz/MHz/g

also suggest separating the magnitude from the units to align with SI 
nomenclature.

> AP transmits on all the sub 20Mhz channels the beacon.
> 
> 9.4.2.249 HE Operation element - ... AP transmits Beacon frames in
> non-HT duplicate PPDU with a TXVECTOR parameter CH_BANDWIDTH value
> that is up to the BSS bandwidth.
> 
> So in case of 320Mhz the DUP beacon can be in upper 160 for primary
> channel in the lower 160 giving possibly a absolute range of over

s/a absolute/an absolute/

> 80Mhz.
> 
> Also this check is redundant all together, if AP has a wrong primary
> channel in the beacon it's a fluty AP, and we would fail in next
> steps to connect.
> 
> Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com>
> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
> ---
>   net/wireless/scan.c | 14 ++++++--------
>   1 file changed, 6 insertions(+), 8 deletions(-)
> 
> diff --git a/net/wireless/scan.c b/net/wireless/scan.c
> index 72e9af6158ef..0cdfbb104b80 100644
> --- a/net/wireless/scan.c
> +++ b/net/wireless/scan.c
> @@ -1885,23 +1885,21 @@ cfg80211_get_bss_channel(struct wiphy *wiphy, const u8 *ie, size_t ielen,
>   
>   	freq = ieee80211_channel_to_freq_khz(channel_number, channel->band);
>   
> -	/*
> -	 * In 6GHz, duplicated beacon indication is relevant for
> -	 * beacons only.
> +	/* Frame info (beacon/prob res) is the same as resieved channel, no need

s/resieved/received/

> +	 * for forther process.

s/forther/further/

>   	 */
> -	if (channel->band == NL80211_BAND_6GHZ &&
> -	    (freq == channel->center_freq ||
> -	     abs(freq - channel->center_freq) > 80))
> +	if (freq == channel->center_freq)
>   		return channel;
>   
>   	alt_channel = ieee80211_get_channel_khz(wiphy, freq);
>   	if (!alt_channel) {
> -		if (channel->band == NL80211_BAND_2GHZ) {
> +		if (channel->band == NL80211_BAND_2GHZ ||
> +		    channel->band == NL80211_BAND_60GHZ) {
>   			/*
>   			 * Better not allow unexpected channels when that could
>   			 * be going beyond the 1-11 range (e.g., discovering
>   			 * BSS on channel 12 when radio is configured for
> -			 * channel 11.
> +			 * channel 11) or beyond the 6G channel range.

both in subject and here can we change 6G to 6 GHz to avoid confusion 
with cellular use of "6G" and potentially WFA use of "Wi-Fi 6" where 6 
is a generation and not a frequency?


>   			 */
>   			return NULL;
>   		}