| Message ID | 000201db8822$98f28da0$cad7a8e0$@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | wireless-regdb: Allow 6ghz in the US | expand |
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) > > >
(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) > > > > > > >
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) > > > > > > >
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
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 >
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.
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.
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. >
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. >
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
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
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> # reference: section IV-D https://docs.fcc.gov/public/attachments/FCC-16-89A1.pdf # channels 1-6 EIRP=40dBm(43dBm peak)