#16862: faulty regdomains: Follup to #16818, #9678
-------------------------+-------------------------------------------------
Reporter: anonymous | Owner: developers
Type: defect | Status: new
Priority: high | Milestone: Barrier Breaker (trunk)
Component: base | Version: Trunk
system | Keywords: ETSI WORLD US AT DE EU channel 12
Resolution: | 13 14
-------------------------+-------------------------------------------------
Comment (by anonymous):
@nbd:
http://wireless.kernel.org/en/developers/Documentation/mac80211
http://wireless.kernel.org/en/developers/Documentation/mac80211/#mac80211_802.11d_support
http://wireless.kernel.org/en/developers/Documentation/cfg80211#Regulatorysupport
is this still the way the mainline kernel handles regulatory domain
settings
This sound like a valid approach to me, assuming, that the majority of
travellers will be clients, not APs, while static APs will be setup once.
Another approach for the "travelling AP problem" could be to first
initialize only the device's rx path(s) with WORLD regdomain (meaning all
available channels) and it MUST first listen for /*any*/ 802.11d
information in the surrounding and acquire channel usage statistics
originating from passive scans before initializing the tx path(s). If any
packets indicate, that the country settings in our device do not correlate
with the majority of beacons in our surrounding, it MUST limit the channel
list before initializing the tx path(s) and/or adapt the regdomain at
runtime, if necessary. This mechanism SHOULD be a default, that CAN be
overridden by an additional kernel parameter or a compile option or a uCI
setting at the users responsibility, if his device is undoubtedly location
bound and/or will never be moved in between regulatory borders. Vice versa
the device should passively scan those (now) off limit channels for
beacons and, if statistically indicated, adapt the tx regdomain.
Of course using this mechanism, a fixed channel 12 and 13 needs to depend
on a location bound AP (as described above), whereas the mechanism should
not be active.
The usage of 80211d information on OpenWRT APs should therefore be the
default. It may be necessary to differentiate between a probably limited
"runtime regdomain" and the "set up regdomain", but I guess, that setting
the regdomain to a country surely indicates a location bound AP, while
World triggers that mechanism.
Of course this could be achieved by uci/netfid instead of kernel
parameters too, but some devs are sceptical as far as I know.
This is a quite similar approach to the way DFS is implemented, therefore
it should not be to hard to do.
On mobile systems (mobile mesh nodes) it will allow for a hassle free
automatic adaption at runtime using the world domain, while fixed APs will
not be bothered.
In case both client and AP (e.g. WDS and/or universal repeater mode) the
setting of the client MUST prevail.
Opinions?
--
Ticket URL: <https://dev.openwrt.org/ticket/16862#comment:3>
OpenWrt <http://openwrt.org>
Opensource Wireless Router Technology
_______________________________________________
openwrt-tickets mailing list
[email protected]
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-tickets
