Modify

Opened 4 years ago

Closed 3 years ago

#16862 closed defect (fixed)

faulty regdomains: Follup to #16818, #9678

Reported by: anonymous Owned by: developers
Priority: high Milestone: Chaos Calmer 15.05
Component: base system Version: Trunk
Keywords: ETSI WORLD US AT DE EU channel 12 13 14 Cc:

Description

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.

Attachments (0)

Change History (14)

comment:1 Changed 4 years ago by nbd

the channel 12 thing has been fixed in r41298

comment:3 Changed 4 years ago 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?

comment:4 follow-up: Changed 4 years ago by anonymous

Opinions? My 5ct: the whole thing is "broken" already upstream, not only in OpenWRT.

An example: I get a TP-Link in Germany, the vendor-FW just overides the allowed channels, with any Linux I know, I have to apply (again and again!) crude "patches" to get ch12/13.
As otherwise it falls back to US, "World" (or in this case CN) which is programmed in some eeprom and simply wrong..

I know, this is (regulatory/legal issues) pretty tricky (as DFS is) but when I'm compiling an image as "root" I should have the choice to decide wether I know what I'm doing here and which frequencies I'm allowed to use.
I'd compare anybody building OpenWRT with an amateur radio-operator: you can do anything, your just liable for the results.

So please give us an option, to "just fix it", dont make it default but the current behavior is very, very annoying.

Michael

comment:5 Changed 4 years ago by nbd

Actually, there is a "just fix it" option, which has been there for years now.
You simply enable "CONFIG_ATH_USER_REGD" in your .config, and afterwards you can select the proper regulatory domain in the config.

comment:6 in reply to: ↑ 4 Changed 4 years ago by jogo

Replying to anonymous:

Opinions? My 5ct: the whole thing is "broken" already upstream, not only in OpenWRT.

An example: I get a TP-Link in Germany, the vendor-FW just overides the allowed channels, with any Linux I know, I have to apply (again and again!) crude "patches" to get ch12/13.
As otherwise it falls back to US, "World" (or in this case CN) which is programmed in some eeprom and simply wrong..

Correct, this is the main cause for channels 12/13 being unavailable for many non US devices with OpenWrt.

I know, this is (regulatory/legal issues) pretty tricky (as DFS is) but when I'm compiling an image as "root" I should have the choice to decide wether I know what I'm doing here and which frequencies I'm allowed to use.
I'd compare anybody building OpenWRT with an amateur radio-operator: you can do anything, your just liable for the results.

So please give us an option, to "just fix it", dont make it default but the current behavior is very, very annoying.

This option already exists, CONFIG_ATH_USER_REGD - "Force Atheros drivers to respect the user's regdomain settings". If you build your own image you can enable it and force a country then.

But for regulatory reasons this is not enabled for OpenWrt provided images (snapshots and releases), which is what most complaints are about.

comment:7 Changed 4 years ago by anonymous

http://apps.fcc.gov/ecfs/document/view?id=7521096518

Because 5 GHz U-NII devices are able to operate across such a wide swath of spectrum as described
above, any device could potentially be reprogrammed to operate outside of its certified frequency
range. Accordingly, we are adopting the proposal in the NPRM that manufacturers must take steps to
prevent unauthorized software changes to their equipment in all of the U-NII bands.
93 We leave the precise methods of ensuring the integrity of the software in a radio to the
manufacturer, but require the manufacturer to document those methods in its application for
equipment authorization. We decline to set specific security protocol or authentication
requirements at this time because they could hinder the development of the technology used to
provide such security, and be unduly burdensome on manufacturers.

I guess this puts the "let me use my channels" disucssion in a new light and explains the cautious behaviour of the OpenWrt developers. Regulatory violations in the past might lead to cryptographically signed firmwares in the future...

Since the north america region is a too huge market to ignore, vendors will need to cater to the rules set by the FCC.

comment:8 Changed 4 years ago by anonymous

Still the discussion leaves out the usability.
OpenWRT may be the code base for some commercial routers. DD-WRT even has a commercial license, providing for additional functions. I understand that some points of the discussion are depending on support for this business models - it's hard cash, that flows back into development.

Now that you bring cryptographically signed information into this discussion, let's consider the following:
Instead of letting users - even advanced users - self-compile images, that probably just won't work or -at worst- lead to destroyed/bricked or otherwise crippled devices, make snapshots/images with a change in UCI: It looks for a cryptographically signed or even encrypted regdomain information and sets information accordingly. The signed regdomain is interchangeable but bound to the Wifi MAC.
You could provide a web based tool creating this information.

In order to make this approach fair and equal, there must not be a fallback regdomain. Otherwise non-US users would be discriminated.

The regdomain information should also exist on hardware with a firmware based on OpenWRT an could reside in a flash partition, that is not overwritten during flash (like the ART). Therefore users would not need to buy another regdomain license - it's bound to the region the device was sold unless a user "buys"/"registers for" a new one an exchanges it.

This is a similar approach to the faulty eeprom routines, but would work less invasive.

It also could reduce the problem, since monetary compensation for a more user friendly change of regdomains is possible that way, without "reghacking".

comment:9 Changed 4 years ago by anonymous

Can you implement such a mechanism?

comment:10 Changed 4 years ago by anonymous

Silence?

comment:11 Changed 4 years ago by anonymous

ping -c2 developers.openwrt
PING 172.18.1.100 (172.18.1.100) 56(84) bytes of data.
From 172.18.1.1 icmp_seq=1 Destination Host Unreachable
From 172.18.1.1 icmp_seq=2 Destination Host Unreachable
--- 172.18.1.100 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1001ms

comment:12 Changed 3 years ago by anonymous

Currently broken:
http://downloads.openwrt.org/barrier_breaker/14.07-rc3/ar71xx/generic/config.ar71xx_generic

# CONFIG_ATH_USER_REGD is not set
...
# CONFIG_PACKAGE_ATH_DFS is not set

This means, this firmware will violate the regulatory in most European countries for 5GHz-Devices, while being compliant to the US markets.
Furthermore channels valid in the EU markets are not working by default.

For those users in the EU, that are not capable of compiling images oder using the image generator, using current snapshots would be illegal.

Those users in the EU trying the lift the problems with jow reghack will need smaller firmware images, as the reghack consumes additional flash memory in rootfs_data.

A possible and quick solution would be to separate build (rc and stable release) snapshots for EU, US and JP.
Some hardware manufactureres do it alike: they offer various firmwares for different markets.

Another solution could be to enhance the image builder, not to include the precompiled wireless drivers from kernel but to compile them -and only them- separately at image builders's runtime for a given regulatory; this would also save compile time and would allow for a combination with the previous proposal.

e.g.:
make image PROFILE="TLWR1043" DEFAULT_REGDOMAIN="DE"

comment:13 Changed 3 years ago by jow

The default regdomain does not allow channels which require DFS.

comment:14 Changed 3 years ago by nbd

  • Resolution set to fixed
  • Status changed from new to closed

fixed in r45252

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.