Channels 169-177 are not usable with US country code due to NO-IR flag from regdb - why the NO-IR flag?

For Developers
1

Hi all, I'm not sure whether or not I'm understanding this properly from a legal standpoint, so I wanted to run it past people a bit informally before submitting the necessary regdb patch.

I have recently observed that despite the 'indoor only' channels 169-177 being listed in the options for 5GHz channel selection on LuCI, those channels are effectively unusable for an AP, even though they should be, due to improper regdb settings that are more narrow than is legally required, at least by my reading.

When one attempts to set up an access point inclusive of those channels with the regulatory domain set to US, the access point fails to come up:

Sat May 31 04:54:19 2025 daemon.notice hostapd: phy0-ap0: interface state UNINITIALIZED->COUNTRY_UPDATE
Sat May 31 04:54:19 2025 daemon.notice hostapd: Frequency 5865 (primary) not allowed for AP mode, flags: 0x10053 NO-IR
Sat May 31 04:54:19 2025 daemon.err hostapd: Primary frequency not allowed
Sat May 31 04:54:19 2025 daemon.warn hostapd: phy0-ap0: IEEE 802.11 Configured channel (173) or frequency (5865) (secondary_channel=1) not found from the channel list of the current mode (2) IEEE 802.11a
Sat May 31 04:54:19 2025 daemon.warn hostapd: phy0-ap0: IEEE 802.11 Hardware does not support configured channel
Sat May 31 04:54:19 2025 daemon.err hostapd: Could not select hw_mode and channel. (-3)
Sat May 31 04:54:19 2025 daemon.notice hostapd: phy0-ap0: interface state COUNTRY_UPDATE->DISABLED
Sat May 31 04:54:19 2025 daemon.notice hostapd: phy0-ap0: AP-DISABLED
Sat May 31 04:54:19 2025 daemon.err hostapd: phy0-ap0: Unable to setup interface.

As these logs say, this is because the channel group is listed in wireless regdb as NO-IR (db.txt from wireless-regdb on kernel.org ):

country US: DFS-FCC
[...]
	# https://www.federalregister.gov/documents/2021/05/03/2021-08802/use-of-the-5850-5925-ghz-band
	# max. 33 dBm AP @ 20MHz, 36 dBm AP @ 40Mhz+, 6 dB less for clients
	(5850 - 5895 @ 40), (27), NO-OUTDOOR, AUTO-BW, NO-IR
[...]

This issue prevents using 160mhz and 80mhz centered near/within these channels, which is seemingly something that is touched upon at least in passing in the FCC's discussion of freeing this high 5GHz spectrum, both here (see page 9/point 18 for one mention) and in the document linked in the wireless-regdb comment above:

The Commission determined that when the U-NII-4 [channels 169-177/5.850-5.925ghz] band was combined with U-NII-3 [channels 149-165/5.725-5.850ghz] band spectrum, indoor access point EIRP can scale to 36 dBm for 80 and 160 megahertz channels.

so I believe (unless I have misinterpreted the FCC rules) that this possibly is an issue with wireless-regdb, and this band should not be marked as NO-IR when the country code is set to US. I'm no RF lawyer, however - is my reasoning correct, and is there some other reason that this channel range is marked as NO_IR?

2

Read the references and contact regdb mailing lists IF something is wrong.

1 Like
3

I was kind of hoping to get kind of a first-pass look before sending it upstream, but okay.

4

Or just look in the archives... Passing such an opportunity when it's low hanging fruit appears like an unlikely oversight.

We also discussed using NO-IR for 5850-5895. The regulations forbid active scans, and PMTP-ONLY does not prevent them. NO-IR appears to be the only option which conforms to this restriction, though that will also block running an AP in this range.

So we would not be able to operate an OpenWrt or other Linux-based AP, while other vendors would be allowed to do this? How is this acceptable? How does this help in liberating the band?

We're allowing clients which use the rules in the db to connect to APs in the band. We may be able to get APs supported later on by getting changes to break up passive-scan and no-IR. But with what we have to work with right now, and based on my interpretation of the rules, I think this is the best we can do currently.

Source: https://lists.infradead.org/pipermail/wireless-regdb/2021-July/001252.html

After glancing at the thread it looks like someone needs to

  • break up one flag into two
  • get it supported in the kernel
  • and hostapd
  • then update regdb
  • and wait until everything ends up in a released firmware

So it looks like you're right. But since it hasn't been needed yet, someone still has to “just do it”.

3 Likes
5

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.