wireless-regdb: Allow 6ghz in the US

wireless-regdb: Allow 6ghz in the US

[rmandrad]

Allow 6ghz in the US

https://www.federalregister.gov/documents/2020/05/26/2020-11236/unlicensed-u
se-of-the-6-ghz-band allows the use of 6ghz in the US namely section
59 https://www.federalregister.gov/d/2020-11236/p-66 with absolute radiated
power of 30 dBm for the 320 megahertz channel

based on this remove NO-IR flag and allow 30 dBm max power

Signed-off-by: Rudy Andram <rmandrad@gmail.com>

diff --git a/db.txt b/db.txt
index 803f1bc..bc2b4fe 100644
--- a/db.txt
+++ b/db.txt
@@ -1953,7 +1953,8 @@ country US: DFS-FCC
 	(5850 - 5895 @ 40), (27), NO-OUTDOOR, AUTO-BW, NO-IR
 	# 6g band
 	#
https://www.federalregister.gov/documents/2020/05/26/2020-11236/unlicensed-u
se-of-the-6ghz-band
-	(5925 - 7125 @ 320), (12), NO-OUTDOOR, NO-IR
+	(5925 - 6425 @ 320), (30), NO-OUTDOOR
+	(6525 - 6875 @ 320), (30), NO-OUTDOOR
 	# 60g band
 	# reference: section IV-D
https://docs.fcc.gov/public/attachments/FCC-16-89A1.pdf
 	# channels 1-6 EIRP=40dBm(43dBm peak)

Re: wireless-regdb: Allow 6ghz in the US

[Chen-Yu Tsai]

CC-ing Dennis, the original submitter, and also Ping-Ke, who has done
a lot of 6 GHz updates, for more information.

On Wed, Feb 26, 2025 at 4:03 PM <rmandrad@gmail.com> wrote:
>
> Allow 6ghz in the US
>
> https://www.federalregister.gov/documents/2020/05/26/2020-11236/unlicensed-u
> se-of-the-6-ghz-band allows the use of 6ghz in the US namely section
> 59 https://www.federalregister.gov/d/2020-11236/p-66 with absolute radiated
> power of 30 dBm for the 320 megahertz channel

Please don't wrap URLs.

Please see the original submission [1], which explains why the power limit
is so low. Basically, neither the database nor the kernel supports
specifying power spectral density limits, so we can only take the
narrowest bandwidth to calculate the applicable power limit.

[1] https://lore.kernel.org/wireless-regdb/CAPRryQp6j4UKvLZCkMAuQdaxepMBETQUJ1eNULJSh3ZWXC0f5Q@mail.gmail.com/

> based on this remove NO-IR flag and allow 30 dBm max power

The original submission mentioned NO-IR requirements, though I did not
find such wording. Dennis, do you have any ideas?

> Signed-off-by: Rudy Andram <rmandrad@gmail.com>
>
> diff --git a/db.txt b/db.txt
> index 803f1bc..bc2b4fe 100644
> --- a/db.txt
> +++ b/db.txt
> @@ -1953,7 +1953,8 @@ country US: DFS-FCC
>         (5850 - 5895 @ 40), (27), NO-OUTDOOR, AUTO-BW, NO-IR
>         # 6g band
>         #
> https://www.federalregister.gov/documents/2020/05/26/2020-11236/unlicensed-u
> se-of-the-6ghz-band
> -       (5925 - 7125 @ 320), (12), NO-OUTDOOR, NO-IR
> +       (5925 - 6425 @ 320), (30), NO-OUTDOOR
> +       (6525 - 6875 @ 320), (30), NO-OUTDOOR

The database entry targets LPI usage instead of standard usage, which
requires the presence of AFC, which is also a requirement that the
database is unable to represent. And under LPI usage, the full 6GHz
band (U-NII-5, 6, 7) is available.


Thanks
ChenYu

>         # 60g band
>         # reference: section IV-D
> https://docs.fcc.gov/public/attachments/FCC-16-89A1.pdf
>         # channels 1-6 EIRP=40dBm(43dBm peak)
>
>
>

RE: wireless-regdb: Allow 6ghz in the US

[Ping-Ke Shih]

Chen-Yu Tsai <wens@kernel.org> wrote:
> 
> > based on this remove NO-IR flag and allow 30 dBm max power
> 
> The original submission mentioned NO-IR requirements, though I did not
> find such wording. Dennis, do you have any ideas?
> 

FYI. The description below in [1]

In all cases, an exception exists for transmitting brief messages to an
access point when attempting to join its network after detecting a signal
that confirms that an access point is operating on a particular channel.

[1] https://www.federalregister.gov/documents/2020/05/26/2020-11236/unlicensed-use-of-the-6-ghz-band

RE: wireless-regdb: Allow 6ghz in the US

[rmandrad]

Hi Dennis, et all

122. is not specifying NO-IR which basically is denying any 6Ghz in the US what it means in my opinion is 

Client devices (like phones, tablets, laptops) need to find Wi-Fi networks before they can join them.
One-way devices do this is by sending out probe requests. These are little "Are you there?" signals that ask nearby access points (routers) to respond, so the device knows which networks are available.  This is why drivers use the non 6Ghz for allowing clients to identify the router has 6ghz capabilities… I don’t think is for wireless-regdb to take over the HW router compliance and certification which is  what 122.  is about

Thank you
Best Regards,
Rudy

From: Dennis Bland <dennis@dbperformance.com> 
Sent: 05 March 2025 05:49
To: Ping-Ke Shih <pkshih@realtek.com>; wens@kernel.org
Cc: rmandrad@gmail.com; linux-wireless@vger.kernel.org; wireless-regdb@lists.infradead.org
Subject: Re: wireless-regdb: Allow 6ghz in the US

Hi everyone:

Section 122 of Document 2020-11236 (Unlicensed Use of the 6 GHz Band) mentions the following, which formed the basis of the NO-IR requirement:

  122. The Commission recognizes the utility of permitting probe requests to enable client devices to join an access point's network. However, these probe requests have the potential to cause harmful interference to licensed operations. The Commission therefore only permits a client device to send a probe request to an access point after it has detected a transmission from the access point.

Best regards,

Dennis


On Wed, Feb 26, 2025 at 2:09 AM Ping-Ke Shih <mailto:pkshih@realtek.com> wrote:
Chen-Yu Tsai <mailto:wens@kernel.org> wrote:
> 
> > based on this remove NO-IR flag and allow 30 dBm max power
> 
> The original submission mentioned NO-IR requirements, though I did not
> find such wording. Dennis, do you have any ideas?
> 

FYI. The description below in [1]

In all cases, an exception exists for transmitting brief messages to an
access point when attempting to join its network after detecting a signal
that confirms that an access point is operating on a particular channel.

[1] https://www.federalregister.gov/documents/2020/05/26/2020-11236/unlicensed-use-of-the-6-ghz-band

Re: wireless-regdb: Allow 6ghz in the US

[Chen-Yu Tsai]

On Wed, Mar 5, 2025 at 4:23 PM <rmandrad@gmail.com> wrote:
>
> That is not specifying NO-IR which basically is denying any 6Ghz in the US what it means in my opinion is
>
>
>
> Client devices (like phones, tablets, laptops) need to find Wi-Fi networks before they can join them.
>
> One-way devices do this is by sending out probe requests. These are little "Are you there?" signals that ask nearby access points (routers) to respond, so the device knows which networks are available.

Section 122 says: The Commission therefore only permits a client
device to send a probe request to an access point after it has
detected a transmission from the access point. The client device
will be required to send the probe request on the same frequency
as the access point's transmission.

I think this translates to "passive scanning only", which is what
NO_IR is meant to specify. NO-IR was previously called PASSIVE-SCAN,
and was renamed when it was merged with NO-IBSS.

Maybe the kernel's implementation needs work? I'm not a WiFi person so
I really don't know all the details.

> That is why drivers use the non 6Ghz for allowing clients to identify the router has 6ghz capabilities… I don’t think is for wireless-regdb to take over the HW router compliance and certification which is  what 122.  is about

No, section 122 is definitely about client devices, which is what Linux
devices are.


Thanks
ChenYu

> From: Dennis Bland <dennis@dbperformance.com>
> Sent: 05 March 2025 05:49
> To: Ping-Ke Shih <pkshih@realtek.com>; wens@kernel.org
> Cc: rmandrad@gmail.com; linux-wireless@vger.kernel.org; wireless-regdb@lists.infradead.org
> Subject: Re: wireless-regdb: Allow 6ghz in the US
>
>
>
> Hi everyone:
>
>
>
> Section 122 of Document 2020-11236 (Unlicensed Use of the 6 GHz Band) mentions the following, which formed the basis of the NO-IR requirement:
>
>
>
>   122. The Commission recognizes the utility of permitting probe requests to enable client devices to join an access point's network. However, these probe requests have the potential to cause harmful interference to licensed operations. The Commission therefore only permits a client device to send a probe request to an access point after it has detected a transmission from the access point.
>
>
>
> Best regards,
>
>
>
> Dennis
>
>
>
>
>
> On Wed, Feb 26, 2025 at 2:09 AM Ping-Ke Shih <pkshih@realtek.com> wrote:
>
> Chen-Yu Tsai <wens@kernel.org> wrote:
> >
> > > based on this remove NO-IR flag and allow 30 dBm max power
> >
> > The original submission mentioned NO-IR requirements, though I did not
> > find such wording. Dennis, do you have any ideas?
> >
>
> FYI. The description below in [1]
>
> In all cases, an exception exists for transmitting brief messages to an
> access point when attempting to join its network after detecting a signal
> that confirms that an access point is operating on a particular channel.
>
> [1] https://www.federalregister.gov/documents/2020/05/26/2020-11236/unlicensed-use-of-the-6-ghz-band
>

Re: wireless-regdb: Allow 6ghz in the US

[Nicolas Cavallari]

On 05/03/2025 09:58, Chen-Yu Tsai wrote:
> On Wed, Mar 5, 2025 at 4:23 PM <rmandrad@gmail.com> wrote:
>>
>> That is not specifying NO-IR which basically is denying any 6Ghz in the US what it means in my opinion is
>>
>>
>>
>> Client devices (like phones, tablets, laptops) need to find Wi-Fi networks before they can join them.
>>
>> One-way devices do this is by sending out probe requests. These are little "Are you there?" signals that ask nearby access points (routers) to respond, so the device knows which networks are available.
> 
> Section 122 says: The Commission therefore only permits a client
> device to send a probe request to an access point after it has
> detected a transmission from the access point. The client device
> will be required to send the probe request on the same frequency
> as the access point's transmission.
> 
> I think this translates to "passive scanning only", which is what
> NO_IR is meant to specify. NO-IR was previously called PASSIVE-SCAN,
> and was renamed when it was merged with NO-IBSS.
> 
> Maybe the kernel's implementation needs work? I'm not a WiFi person so
> I really don't know all the details.
> 
>> That is why drivers use the non 6Ghz for allowing clients to identify the router has 6ghz capabilities… I don’t think is for wireless-regdb to take over the HW router compliance and certification which is  what 122.  is about
> 
> No, section 122 is definitely about client devices, which is what Linux
> devices are.

No, Linux also supports access point, IBSS, OBSS and mesh, not to 
mention monitor injection.

If you remove NO-IR, you are allowing Linux to create access points, 
ad-hoc and mesh networks on the channel without conditions.

RE: wireless-regdb: Allow 6ghz in the US

[rmandrad]

See below


[1] Beacon Hints
" cfg80211 has a feature called beacon hinting to assist cfg80211 in allowing a card to lift passive-scan and no-beaconing flags. Passive-scan flags are used on channels to ensure that an interface will not issue a probe request out. The no-ir flag exists to allow regulatory domain definitions to disallow a device from initiating radiation of any kind and that includes using beacons, so for example AP/IBSS/Mesh/GO interfaces would not be able to initiate communication on these channels unless the channel does not have this flag. If either of these flags are present on a channel a device is prohibited from initiating communication on cfg80211."

...

" It is also important to note that the Linux kernel beacon hint mechanism only trusts beacons from 802.11 APs, not Mesh or IBSS."

[1[  https://wireless.docs.kernel.org/en/latest/en/developers/regulatory/processing_rules.html

My experience is with Openwrt and APs. We have users in the US complaining that they can't use 6GHz due to NO-IR


-----Original Message-----
From: Nicolas Cavallari <nicolas.cavallari@green-communications.fr> 
Sent: 05 March 2025 12:19
To: wens@kernel.org; rmandrad@gmail.com
Cc: Dennis Bland <dennis@dbperformance.com>; Ping-Ke Shih <pkshih@realtek.com>; linux-wireless@vger.kernel.org; wireless-regdb@lists.infradead.org
Subject: Re: wireless-regdb: Allow 6ghz in the US

On 05/03/2025 09:58, Chen-Yu Tsai wrote:
> On Wed, Mar 5, 2025 at 4:23 PM <rmandrad@gmail.com> wrote:
>>
>> That is not specifying NO-IR which basically is denying any 6Ghz in 
>> the US what it means in my opinion is
>>
>>
>>
>> Client devices (like phones, tablets, laptops) need to find Wi-Fi networks before they can join them.
>>
>> One-way devices do this is by sending out probe requests. These are little "Are you there?" signals that ask nearby access points (routers) to respond, so the device knows which networks are available.
> 
> Section 122 says: The Commission therefore only permits a client 
> device to send a probe request to an access point after it has 
> detected a transmission from the access point. The client device will 
> be required to send the probe request on the same frequency as the 
> access point's transmission.
> 
> I think this translates to "passive scanning only", which is what 
> NO_IR is meant to specify. NO-IR was previously called PASSIVE-SCAN, 
> and was renamed when it was merged with NO-IBSS.
> 
> Maybe the kernel's implementation needs work? I'm not a WiFi person so 
> I really don't know all the details.
> 
>> That is why drivers use the non 6Ghz for allowing clients to identify 
>> the router has 6ghz capabilities… I don’t think is for wireless-regdb 
>> to take over the HW router compliance and certification which is  
>> what 122.  is about
> 
> No, section 122 is definitely about client devices, which is what 
> Linux devices are.

No, Linux also supports access point, IBSS, OBSS and mesh, not to mention monitor injection.

If you remove NO-IR, you are allowing Linux to create access points, ad-hoc and mesh networks on the channel without conditions.

Re: wireless-regdb: Allow 6ghz in the US

[Chen-Yu Tsai]

Cc-ing Johannes since I think this discussion also involves what cfg80211
does.

On Wed, Mar 5, 2025 at 10:36 PM <rmandrad@gmail.com> wrote:
>
> See below
>
>
> [1] Beacon Hints
> " cfg80211 has a feature called beacon hinting to assist cfg80211 in allowing a card to lift passive-scan and no-beaconing flags. Passive-scan flags are used on channels to ensure that an interface will not issue a probe request out. The no-ir flag exists to allow regulatory domain definitions to disallow a device from initiating radiation of any kind and that includes using beacons, so for example AP/IBSS/Mesh/GO interfaces would not be able to initiate communication on these channels unless the channel does not have this flag. If either of these flags are present on a channel a device is prohibited from initiating communication on cfg80211."

Doesn't this do what the FCC rules say? No initiating communications
unless prior traffic has been seen on the channel for client devices.

> ...
>
> " It is also important to note that the Linux kernel beacon hint mechanism only trusts beacons from 802.11 APs, not Mesh or IBSS."
>
> [1[  https://wireless.docs.kernel.org/en/latest/en/developers/regulatory/processing_rules.html
>
> My experience is with Openwrt and APs. We have users in the US complaining that they can't use 6GHz due to NO-IR

OK. It would have helped if you explained that it is the AP side that
is not working.

Regarding that, AFAIK we don't really have a way to specify different
rules for APs vs client devices. AFAIK all the power limits written in
the database are for client devices, because clients seem to have more
restrictions.

ChenYu

> -----Original Message-----
> From: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
> Sent: 05 March 2025 12:19
> To: wens@kernel.org; rmandrad@gmail.com
> Cc: Dennis Bland <dennis@dbperformance.com>; Ping-Ke Shih <pkshih@realtek.com>; linux-wireless@vger.kernel.org; wireless-regdb@lists.infradead.org
> Subject: Re: wireless-regdb: Allow 6ghz in the US
>
> On 05/03/2025 09:58, Chen-Yu Tsai wrote:
> > On Wed, Mar 5, 2025 at 4:23 PM <rmandrad@gmail.com> wrote:
> >>
> >> That is not specifying NO-IR which basically is denying any 6Ghz in
> >> the US what it means in my opinion is
> >>
> >>
> >>
> >> Client devices (like phones, tablets, laptops) need to find Wi-Fi networks before they can join them.
> >>
> >> One-way devices do this is by sending out probe requests. These are little "Are you there?" signals that ask nearby access points (routers) to respond, so the device knows which networks are available.
> >
> > Section 122 says: The Commission therefore only permits a client
> > device to send a probe request to an access point after it has
> > detected a transmission from the access point. The client device will
> > be required to send the probe request on the same frequency as the
> > access point's transmission.
> >
> > I think this translates to "passive scanning only", which is what
> > NO_IR is meant to specify. NO-IR was previously called PASSIVE-SCAN,
> > and was renamed when it was merged with NO-IBSS.
> >
> > Maybe the kernel's implementation needs work? I'm not a WiFi person so
> > I really don't know all the details.
> >
> >> That is why drivers use the non 6Ghz for allowing clients to identify
> >> the router has 6ghz capabilities… I don’t think is for wireless-regdb
> >> to take over the HW router compliance and certification which is
> >> what 122.  is about
> >
> > No, section 122 is definitely about client devices, which is what
> > Linux devices are.
>
> No, Linux also supports access point, IBSS, OBSS and mesh, not to mention monitor injection.
>
> If you remove NO-IR, you are allowing Linux to create access points, ad-hoc and mesh networks on the channel without conditions.
>

RE: wireless-regdb: Allow 6ghz in the US

[rmandrad]

Thank you Wens for cc'ing Johannes

One of the issues [1] reported with one the openwrt devices ... my understanding / experience is that if there is NO-IR basically clients will not connect (I can't think of a use case where there's prior traffic)

[1] https://github.com/openwrt/openwrt/issues/18079


-----Original Message-----
From: Chen-Yu Tsai <wens@kernel.org> 
Sent: 05 March 2025 15:11
To: rmandrad@gmail.com
Cc: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>; Dennis Bland <dennis@dbperformance.com>; Ping-Ke Shih <pkshih@realtek.com>; linux-wireless@vger.kernel.org; wireless-regdb@lists.infradead.org; Johannes Berg <johannes@sipsolutions.net>
Subject: Re: wireless-regdb: Allow 6ghz in the US

Cc-ing Johannes since I think this discussion also involves what cfg80211 does.

On Wed, Mar 5, 2025 at 10:36 PM <rmandrad@gmail.com> wrote:
>
> See below
>
>
> [1] Beacon Hints
> " cfg80211 has a feature called beacon hinting to assist cfg80211 in allowing a card to lift passive-scan and no-beaconing flags. Passive-scan flags are used on channels to ensure that an interface will not issue a probe request out. The no-ir flag exists to allow regulatory domain definitions to disallow a device from initiating radiation of any kind and that includes using beacons, so for example AP/IBSS/Mesh/GO interfaces would not be able to initiate communication on these channels unless the channel does not have this flag. If either of these flags are present on a channel a device is prohibited from initiating communication on cfg80211."

Doesn't this do what the FCC rules say? No initiating communications unless prior traffic has been seen on the channel for client devices.

> ...
>
> " It is also important to note that the Linux kernel beacon hint mechanism only trusts beacons from 802.11 APs, not Mesh or IBSS."
>
> [1[  
> https://wireless.docs.kernel.org/en/latest/en/developers/regulatory/pr
> ocessing_rules.html
>
> My experience is with Openwrt and APs. We have users in the US 
> complaining that they can't use 6GHz due to NO-IR

OK. It would have helped if you explained that it is the AP side that is not working.

Regarding that, AFAIK we don't really have a way to specify different rules for APs vs client devices. AFAIK all the power limits written in the database are for client devices, because clients seem to have more restrictions.

ChenYu

> -----Original Message-----
> From: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
> Sent: 05 March 2025 12:19
> To: wens@kernel.org; rmandrad@gmail.com
> Cc: Dennis Bland <dennis@dbperformance.com>; Ping-Ke Shih 
> <pkshih@realtek.com>; linux-wireless@vger.kernel.org; 
> wireless-regdb@lists.infradead.org
> Subject: Re: wireless-regdb: Allow 6ghz in the US
>
> On 05/03/2025 09:58, Chen-Yu Tsai wrote:
> > On Wed, Mar 5, 2025 at 4:23 PM <rmandrad@gmail.com> wrote:
> >>
> >> That is not specifying NO-IR which basically is denying any 6Ghz in 
> >> the US what it means in my opinion is
> >>
> >>
> >>
> >> Client devices (like phones, tablets, laptops) need to find Wi-Fi networks before they can join them.
> >>
> >> One-way devices do this is by sending out probe requests. These are little "Are you there?" signals that ask nearby access points (routers) to respond, so the device knows which networks are available.
> >
> > Section 122 says: The Commission therefore only permits a client 
> > device to send a probe request to an access point after it has 
> > detected a transmission from the access point. The client device 
> > will be required to send the probe request on the same frequency as 
> > the access point's transmission.
> >
> > I think this translates to "passive scanning only", which is what 
> > NO_IR is meant to specify. NO-IR was previously called PASSIVE-SCAN, 
> > and was renamed when it was merged with NO-IBSS.
> >
> > Maybe the kernel's implementation needs work? I'm not a WiFi person 
> > so I really don't know all the details.
> >
> >> That is why drivers use the non 6Ghz for allowing clients to 
> >> identify the router has 6ghz capabilities… I don’t think is for 
> >> wireless-regdb to take over the HW router compliance and 
> >> certification which is what 122.  is about
> >
> > No, section 122 is definitely about client devices, which is what 
> > Linux devices are.
>
> No, Linux also supports access point, IBSS, OBSS and mesh, not to mention monitor injection.
>
> If you remove NO-IR, you are allowing Linux to create access points, ad-hoc and mesh networks on the channel without conditions.
>

Re: wireless-regdb: Allow 6ghz in the US

[Johannes Berg]

Uh, this is a complex discussion. I do believe that we simply do not
have a way to capture the complexity of the rules in the database today.

Skimming the documentation, it seems that:

 * Paragraph 56: For AP operation, it is allowed to operate an LPI AP
   (indoors, obviously) - we could capture that with NO_OUTDOOR and
   that's what the rule has now.
 * Paragraph 122: For client operation, passive scanning is required,
   presumably because clients are assumed to be mobile and thus also
   present outdoors, where they will also scan.
   This can only be captured with NO_IR today.
 * There are additional spectral density power limits in paragraph 59,
   which cannot be captured by the database today.

However, the combination of these really cannot be captured - NO_IR will
also prevent AP operation, which I think is the issue discussed in this
thread, but removing NO_IR will make clients break Paragraph 122.

I'll note that in general scanning on the 6/7 GHz band, by 802.11 spec,
is only active on the few Preferred Scanning Channels (PSCs), however,
that'd _still_ break Paragraph 122.


Unfortunately, it's also hard to fix - we cannot remove NO_IR because
that's used by older kernels, so I think the only way to fix it would be
to add a flag a la NL80211_RRF_ALLOW_6GHZ_VLP_AP (which translates to
IEEE80211_CHAN_ALLOW_6GHZ_VLP_AP) which overrides NO_IR for this
specific case.

We also have reg_rule->psd internally already, I guess we just never
added a way to convey it from userspace? Not sure what it even does
though.

johannes

Re: wireless-regdb: Allow 6ghz in the US

[Chen-Yu Tsai]

Hi,

On Thu, Mar 6, 2025 at 4:02 PM Johannes Berg <johannes@sipsolutions.net> wrote:
>
> Uh, this is a complex discussion. I do believe that we simply do not
> have a way to capture the complexity of the rules in the database today.
>
> Skimming the documentation, it seems that:
>
>  * Paragraph 56: For AP operation, it is allowed to operate an LPI AP
>    (indoors, obviously) - we could capture that with NO_OUTDOOR and
>    that's what the rule has now.
>  * Paragraph 122: For client operation, passive scanning is required,
>    presumably because clients are assumed to be mobile and thus also
>    present outdoors, where they will also scan.
>    This can only be captured with NO_IR today.
>  * There are additional spectral density power limits in paragraph 59,
>    which cannot be captured by the database today.
>
> However, the combination of these really cannot be captured - NO_IR will
> also prevent AP operation, which I think is the issue discussed in this
> thread, but removing NO_IR will make clients break Paragraph 122.
>
> I'll note that in general scanning on the 6/7 GHz band, by 802.11 spec,
> is only active on the few Preferred Scanning Channels (PSCs), however,
> that'd _still_ break Paragraph 122.
>
>
> Unfortunately, it's also hard to fix - we cannot remove NO_IR because
> that's used by older kernels, so I think the only way to fix it would be
> to add a flag a la NL80211_RRF_ALLOW_6GHZ_VLP_AP (which translates to
> IEEE80211_CHAN_ALLOW_6GHZ_VLP_AP) which overrides NO_IR for this
> specific case.
>
> We also have reg_rule->psd internally already, I guess we just never
> added a way to convey it from userspace? Not sure what it even does
> though.

I wonder if it is worth bringing up this topic in the networking track
at Plumbers this year? It would be about the various limitation of
wireless-regdb today, such as:
- lack of PSD
- only one rule per band, preventing things such as
  - AP on 6 GHz in the US, as this thread mentions
  - very low power outdoor usage vs higher power but indoor-only usage

That said, I'm not in a position to implement anything to improve the
status quo.


ChenYu

Re: wireless-regdb: Allow 6ghz in the US

[Johannes Berg]

On Tue, 2025-09-09 at 14:12 +0800, Chen-Yu Tsai wrote:
> I wonder if it is worth bringing up this topic in the networking track
> at Plumbers this year?

I'm not sure who'd be there to discuss it with, I guess? I'm also not
sure who you'd even want to discuss it _with_, since it's mostly an
implementation detail and "just" needs to have something implemented, in
a creatively careful way not to break old stuff.

johannes

Re: wireless-regdb: Allow 6ghz in the US

[Chen-Yu Tsai]

(When replying, please reply to all)

On Wed, Feb 26, 2025 at 5:05 PM <rmandrad@gmail.com> wrote:
>
> Thank you. Apologies this is the first time submitting a kernel patch. The original submission set NO-IR where clearly the document notes it is allowed as section 59 states hence the patch - with increase usage of 6Ghz we have now Openwrt users complaining they can't the band in the US due to NO-IR
>
> Shall I update the patch to only remove NO-IR and increase power to 30 dBm ?

As explained, the limit is lowered from 30 dBm to 12 dBm to comply with
the PSD requirements when using a 20 MHz channel. I suspect no one would
use such a narrow band, but the requirements exist and the database rule
should not be written in a way that allows the user to exceed the limit,
i.e. using 30 dBm on a 20 MHz channel.

So please update the patch to only remove NO-IR. You can look at previous
commits to see how we put URLs in the commit message.

Thanks
ChenYu

> Thank you again
>
> -----Original Message-----
> From: Chen-Yu Tsai <wens@kernel.org>
> Sent: 26 February 2025 08:58
> To: rmandrad@gmail.com
> Cc: linux-wireless@vger.kernel.org; wireless-regdb@lists.infradead.org; Dennis Bland <dennis@dbperformance.com>; Ping-Ke Shih <pkshih@realtek.com>
> Subject: Re: wireless-regdb: Allow 6ghz in the US
>
> CC-ing Dennis, the original submitter, and also Ping-Ke, who has done a lot of 6 GHz updates, for more information.
>
> On Wed, Feb 26, 2025 at 4:03 PM <rmandrad@gmail.com> wrote:
> >
> > Allow 6ghz in the US
> >
> > https://www.federalregister.gov/documents/2020/05/26/2020-11236/unlice
> > nsed-u se-of-the-6-ghz-band allows the use of 6ghz in the US namely
> > section
> > 59 https://www.federalregister.gov/d/2020-11236/p-66 with absolute
> > radiated power of 30 dBm for the 320 megahertz channel
>
> Please don't wrap URLs.
>
> Please see the original submission [1], which explains why the power limit is so low. Basically, neither the database nor the kernel supports specifying power spectral density limits, so we can only take the narrowest bandwidth to calculate the applicable power limit.
>
> [1] https://lore.kernel.org/wireless-regdb/CAPRryQp6j4UKvLZCkMAuQdaxepMBETQUJ1eNULJSh3ZWXC0f5Q@mail.gmail.com/
>
> > based on this remove NO-IR flag and allow 30 dBm max power
>
> The original submission mentioned NO-IR requirements, though I did not find such wording. Dennis, do you have any ideas?
>
> > Signed-off-by: Rudy Andram <rmandrad@gmail.com>
> >
> > diff --git a/db.txt b/db.txt
> > index 803f1bc..bc2b4fe 100644
> > --- a/db.txt
> > +++ b/db.txt
> > @@ -1953,7 +1953,8 @@ country US: DFS-FCC
> >         (5850 - 5895 @ 40), (27), NO-OUTDOOR, AUTO-BW, NO-IR
> >         # 6g band
> >         #
> > https://www.federalregister.gov/documents/2020/05/26/2020-11236/unlice
> > nsed-u
> > se-of-the-6ghz-band
> > -       (5925 - 7125 @ 320), (12), NO-OUTDOOR, NO-IR
> > +       (5925 - 6425 @ 320), (30), NO-OUTDOOR
> > +       (6525 - 6875 @ 320), (30), NO-OUTDOOR
>
> The database entry targets LPI usage instead of standard usage, which requires the presence of AFC, which is also a requirement that the database is unable to represent. And under LPI usage, the full 6GHz band (U-NII-5, 6, 7) is available.
>
>
> Thanks
> ChenYu
>
> >         # 60g band
> >         # reference: section IV-D
> > https://docs.fcc.gov/public/attachments/FCC-16-89A1.pdf
> >         # channels 1-6 EIRP=40dBm(43dBm peak)
> >
> >
> >
>

RE: wireless-regdb: Allow 6ghz in the US

[rmandrad]

wireless-regdb: Allow 6ghz in the US by removing NO-IR

The Federal Communications Commission on 05/26/2020 allowed for the use unlicensed use of the 6GHz band [1]. Currently the settings for US have non-IR. In order to comply with this legislation [1], the patch removes the NO-IR flag

The power limit is not increased from 12 dBm to 30 dBm to comply with the PSD requirements when using a 20 MHz channel

[1] https://www.federalregister.gov/documents/2020/05/26/2020-11236/unlicensed-use-of-the-6-ghz-band#p-66

Signed-off-by: Rudy Andram <rmandrad@gmail.com>

diff --git a/db.txt b/db.txt
index 803f1bc..ffcb0a6 100644
--- a/db.txt
+++ b/db.txt
@@ -1953,7 +1953,7 @@ country US: DFS-FCC
        (5850 - 5895 @ 40), (27), NO-OUTDOOR, AUTO-BW, NO-IR
        # 6g band
        # https://www.federalregister.gov/documents/2020/05/26/2020-11236/unlicensed-use-of-the-6ghz-band
-       (5925 - 7125 @ 320), (12), NO-OUTDOOR, NO-IR
+       (5925 - 7125 @ 320), (12), NO-OUTDOOR
        # 60g band
        # reference: section IV-D https://docs.fcc.gov/public/attachments/FCC-16-89A1.pdf
        # channels 1-6 EIRP=40dBm(43dBm peak)


-----Original Message-----
From: Chen-Yu Tsai <wens@kernel.org> 
Sent: 26 February 2025 09:16
To: rmandrad@gmail.com
Cc: linux-wireless <linux-wireless@vger.kernel.org>; wireless-regdb <wireless-regdb@lists.infradead.org>
Subject: Re: wireless-regdb: Allow 6ghz in the US

(When replying, please reply to all)

On Wed, Feb 26, 2025 at 5:05 PM <rmandrad@gmail.com> wrote:
>
> Thank you. Apologies this is the first time submitting a kernel patch. 
> The original submission set NO-IR where clearly the document notes it 
> is allowed as section 59 states hence the patch - with increase usage 
> of 6Ghz we have now Openwrt users complaining they can't the band in 
> the US due to NO-IR
>
> Shall I update the patch to only remove NO-IR and increase power to 30 dBm ?

As explained, the limit is lowered from 30 dBm to 12 dBm to comply with the PSD requirements when using a 20 MHz channel. I suspect no one would use such a narrow band, but the requirements exist and the database rule should not be written in a way that allows the user to exceed the limit, i.e. using 30 dBm on a 20 MHz channel.

So please update the patch to only remove NO-IR. You can look at previous commits to see how we put URLs in the commit message.

Thanks
ChenYu

> Thank you again
>
> -----Original Message-----
> From: Chen-Yu Tsai <wens@kernel.org>
> Sent: 26 February 2025 08:58
> To: rmandrad@gmail.com
> Cc: linux-wireless@vger.kernel.org; 
> wireless-regdb@lists.infradead.org; Dennis Bland 
> <dennis@dbperformance.com>; Ping-Ke Shih <pkshih@realtek.com>
> Subject: Re: wireless-regdb: Allow 6ghz in the US
>
> CC-ing Dennis, the original submitter, and also Ping-Ke, who has done a lot of 6 GHz updates, for more information.
>
> On Wed, Feb 26, 2025 at 4:03 PM <rmandrad@gmail.com> wrote:
> >
> > Allow 6ghz in the US
> >
> > https://www.federalregister.gov/documents/2020/05/26/2020-11236/unli
> > ce nsed-u se-of-the-6-ghz-band allows the use of 6ghz in the US 
> > namely section
> > 59 https://www.federalregister.gov/d/2020-11236/p-66 with absolute 
> > radiated power of 30 dBm for the 320 megahertz channel
>
> Please don't wrap URLs.
>
> Please see the original submission [1], which explains why the power limit is so low. Basically, neither the database nor the kernel supports specifying power spectral density limits, so we can only take the narrowest bandwidth to calculate the applicable power limit.
>
> [1] 
> https://lore.kernel.org/wireless-regdb/CAPRryQp6j4UKvLZCkMAuQdaxepMBET
> QUJ1eNULJSh3ZWXC0f5Q@mail.gmail.com/
>
> > based on this remove NO-IR flag and allow 30 dBm max power
>
> The original submission mentioned NO-IR requirements, though I did not find such wording. Dennis, do you have any ideas?
>
> > Signed-off-by: Rudy Andram <rmandrad@gmail.com>
> >
> > diff --git a/db.txt b/db.txt
> > index 803f1bc..bc2b4fe 100644
> > --- a/db.txt
> > +++ b/db.txt
> > @@ -1953,7 +1953,8 @@ country US: DFS-FCC
> >         (5850 - 5895 @ 40), (27), NO-OUTDOOR, AUTO-BW, NO-IR
> >         # 6g band
> >         #
> > https://www.federalregister.gov/documents/2020/05/26/2020-11236/unli
> > ce
> > nsed-u
> > se-of-the-6ghz-band
> > -       (5925 - 7125 @ 320), (12), NO-OUTDOOR, NO-IR
> > +       (5925 - 6425 @ 320), (30), NO-OUTDOOR
> > +       (6525 - 6875 @ 320), (30), NO-OUTDOOR
>
> The database entry targets LPI usage instead of standard usage, which requires the presence of AFC, which is also a requirement that the database is unable to represent. And under LPI usage, the full 6GHz band (U-NII-5, 6, 7) is available.
>
>
> Thanks
> ChenYu
>
> >         # 60g band
> >         # reference: section IV-D
> > https://docs.fcc.gov/public/attachments/FCC-16-89A1.pdf
> >         # channels 1-6 EIRP=40dBm(43dBm peak)
> >
> >
> >
>