#16862: faulty regdomains: Follup to #16818, #9678
-------------------------------------------------+-------------------------
Reporter: anonymous | Owner: developers
Type: defect | Status: new
Priority: high | Milestone: Barrier
Component: base system | Breaker (trunk)
Keywords: ETSI WORLD US AT DE EU channel 12 | Version: Trunk
13 14 |
-------------------------------------------------+-------------------------
In r41293 the ETSI and the WORLD/US and JP regdomains are faulty:
a) US has an additional illegal channel 12.
b) ETSI/Europe is missing legal channel 13. (and 12, if a was repaired)
c) JP is missing legal channel 13 and 14 (and 12, if a was repaired)
The design of channel lists in OpenWRT is inappropriate.
A possilble solution (pseudocode) could look like this:
if empty(uci.country)
then uci.wireless.disabled
(or uci.wireless.transmit.disable; receiving would not break anything)
else
channellist_2400MHz=1,2,3,4,5,6,7,8,9,10,11
switch (uci.country)
case ETSI
channellist+=12,13;
case JP
channellist+=12,13,14;
case US
;;
...
the whole thing, if it's really necessary to be supported by a kernel
module, could be assisted by a (kernel parameter) country variable
mac80211.ko, that is to be set in /etc/modules.d/mac80211.conf
With the parameter unset, the wireless radio device should not be set up
in the first place or could fallback to WORLD.
The mechanismn could be accompanied by IEEE 802.11d detection.
The current approach is faulty, in the presence of 3G-Routers and mobile
phones/tablets:
You could travel around the world with a US-device, without breaking the
regulatory rules, but as a Japanese your settings would be illegal
elsewhere, as a european user your settings would be "illegal" in the US.
With a statically set up router - which are still the majority - the
snapshots don't make sense.
The current approach is discouraging users in Europe and Japan. Even
experts need to invest a lot of time in this issue. Time: that could be
spent better.
The point, that it was a legal/licensing issue can not stand. Even if it
was, a proprietary driver or a direct licensing by the user could
circumvent the problem better, than annoying users.
The current OpenWRT solution does not correspond to IEEE 802.11d in this
scenario.
It should be considered that changes at runtime are a more compliant
solution than a rather moronic "WORLD=US"-approach, that would stamp US-
regulations on all "wireless world citizens" - even those not travelling.
--
Ticket URL: <https://dev.openwrt.org/ticket/16862>
OpenWrt <http://openwrt.org>
Opensource Wireless Router Technology
_______________________________________________
openwrt-tickets mailing list
[email protected]
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-tickets
