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
