All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Greear <greearb@candelatech.com>
To: "Peer, Ilan" <ilan.peer@intel.com>, Luca Coelho <luca@coelho.fi>,
	"kvalo@codeaurora.org" <kvalo@codeaurora.org>
Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: Re: [PATCH 06/12] iwlwifi: mvm: Add support for 6GHz passive scan
Date: Sun, 11 Apr 2021 04:16:58 -0700	[thread overview]
Message-ID: <eb60c152-81ac-2977-87fc-f724d4d6ccf0@candelatech.com> (raw)
In-Reply-To: <BN7PR11MB2610D9C80C698F837C3A2A55E9719@BN7PR11MB2610.namprd11.prod.outlook.com>

On 4/11/21 3:14 AM, Peer, Ilan wrote:
> Hi Ben,
> 
>> -----Original Message-----
>> From: Ben Greear <greearb@candelatech.com>
>> Sent: Wednesday, March 31, 2021 15:04
>> To: Luca Coelho <luca@coelho.fi>; kvalo@codeaurora.org
>> Cc: linux-wireless@vger.kernel.org
>> Subject: Re: [PATCH 06/12] iwlwifi: mvm: Add support for 6GHz passive scan
>>
>> On 3/31/21 2:14 AM, Luca Coelho wrote:
>>> From: Ilan Peer <ilan.peer@intel.com>
>>>
>>> When doing scan while 6GHz channels are not enabled, the 6GHz band is
>>> not scanned. Thus, if there are no APs on the 2GHz and 5GHz bands
>>> (that will allow discovery of geographic location etc. that would
>>> allow enabling the 6GHz channels) but there are non collocated APs on
>>> 6GHz PSC channels these would never be discovered.
>>>
>>> To overcome this, FW added support for performing passive UHB scan in
>>> case no APs were discovered during scan on the 2GHz and 5GHz channels.
>>>
>>> Add support for enabling such scan when the following conditions are
>>> met:
>>>
>>> - 6GHz channels are supported but not enabled by regulatory.
>>> - Station interface is not associated or less than a defined time
>>>     interval passed from the last resume or HW reset flows.
>>> - At least 4 channels are included in the scan request
>>> - The scan request includes the widlcard SSID.
>>> - At least 50 minutes passed from the last 6GHz passive scan.
>>
>> Why are you trying so hard to not do passive scans?  This seems like it is set
>> up for all sorts of frustration.
>>
> 
> This logic enables a special 'passive' scan which is not directly intended for discovery of APs for connection etc. but
> for discovery of APs with country information in the beacons/probe responses, so the fw could use this information
> as an input that might allow it to enable 6GHz channels (which are supported but are disabled). This special scan
> is intended for cases that the device does not have any other regulatory information that allows it to enable the 6GHz channels.
> Once these channels are enabled, we use passive scan as needed.
> 
> We generally try to avoid passive scan on all the 6GHz channels as this is a long flow that takes at least 6 seconds (as there are
> such 64 channels) and with the discovery mechanisms defined for the 6GHz is not really needed.

If the station comes up and does a 6E passive scan and does not find any AP, perhaps because 6Ghz AP was turned on 1 minute after the station
tried to initially scan, this means that it will take 50 minutes before it can have a chance to scan
the AP and connect to the Internet?  If station cannot connect after a relatively short time,
then I think it should scan as widely as it can in order find some possible way to connect.

And why care about 'at least 4 channels'.  If we know the AP channel, and can scan exactly there, then your
concern about taking a long time is resolved.

How else can we tell the radio that 6E is allowed?  I previously tried all sorts of things
to enable 6E channels so that I could more easily set the radio to sniff one of those channels
in monitor mode, and I had no luck.

If all of the 6E channels are marked as passive, what harm is it to enable the channels
in the regdom from the beginning?

Thanks,
Ben

> 
> Hope this clarifies things.
> 
> Regards,
> 
> Ilan.
> 


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

  reply	other threads:[~2021-04-11 11:26 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-31  9:14 [PATCH 00/12] iwlwifi: updates intended for v5.13 2021-03-31 Luca Coelho
2021-03-31  9:14 ` [PATCH 01/12] iwlwifi: mvm: write queue_sync_state only for sync Luca Coelho
2021-04-12 10:24   ` Luca Coelho
2021-03-31  9:14 ` [PATCH 02/12] iwlwifi: mvm: clean up queue sync implementation Luca Coelho
2021-03-31  9:14 ` [PATCH 03/12] iwlwifi: mvm: when associated with PMF, use protected NDP ranging negotiation Luca Coelho
2021-03-31  9:14 ` [PATCH 04/12] iwlwifi: add ax201 killer device Luca Coelho
2021-03-31  9:14 ` [PATCH 05/12] iwlwifi: pcie: try to grab NIC access early Luca Coelho
2021-04-12 10:22   ` Luca Coelho
2021-03-31  9:14 ` [PATCH 06/12] iwlwifi: mvm: Add support for 6GHz passive scan Luca Coelho
2021-03-31 12:03   ` Ben Greear
2021-04-11  9:41     ` Luca Coelho
2021-04-11 10:14     ` Peer, Ilan
2021-04-11 11:16       ` Ben Greear [this message]
2021-04-11 12:14         ` Peer, Ilan
2021-04-11 16:15           ` Ben Greear
2021-04-13 12:49             ` Peer, Ilan
2021-03-31  9:14 ` [PATCH 07/12] iwlwifi: mvm: enable PPAG in China Luca Coelho
2021-03-31  9:14 ` [PATCH 08/12] iwlwifi: add new so-gf device Luca Coelho
2021-03-31  9:14 ` [PATCH 09/12] iwlwifi: move iwl_configure_rxq to be used by other op_modes Luca Coelho
2021-03-31  9:14 ` [PATCH 10/12] iwlwifi: mvm: support BIOS enable/disable for 11ax in Ukraine Luca Coelho
2021-03-31  9:14 ` [PATCH 11/12] iwlwifi: mvm: refactor ACPI DSM evaluation function Luca Coelho
2021-03-31  9:14 ` [PATCH 12/12] iwlwifi: mvm: Use IWL_INFO in fw_reset_handshake() Luca Coelho

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=eb60c152-81ac-2977-87fc-f724d4d6ccf0@candelatech.com \
    --to=greearb@candelatech.com \
    --cc=ilan.peer@intel.com \
    --cc=kvalo@codeaurora.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=luca@coelho.fi \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.