Modify

Opened 5 years ago

Closed 17 months ago

Last modified 11 months ago

#9678 closed defect (fixed)

ar71xx: DE locate, but channel 12 and 13 are disabled

Reported by: anonymous Owned by: developers
Priority: normal Milestone: Barrier Breaker 14.07
Component: kernel Version: Trunk
Keywords: atheros DE channel disable Cc:

Description

openwrt trunk on tp1043:

cat /etc/config/wireless
[...]

option country DE

[...]

but i have:

# iw list
Wiphy phy0

Band 1:

Capabilities: 0x104e

HT20/HT40
SM Power Save disabled
RX HT40 SGI
No RX STBC
Max AMSDU length: 3839 bytes
DSSS/CCK HT40

Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
Minimum RX AMPDU time spacing: 8 usec (0x06)
HT TX/RX MCS rate indexes supported: 0-15
Frequencies:

  • 2412 MHz [1] (20.0 dBm)
  • 2417 MHz [2] (20.0 dBm)
  • 2422 MHz [3] (20.0 dBm)
  • 2427 MHz [4] (20.0 dBm)
  • 2432 MHz [5] (20.0 dBm)
  • 2437 MHz [6] (20.0 dBm)
  • 2442 MHz [7] (20.0 dBm)
  • 2447 MHz [8] (20.0 dBm)
  • 2452 MHz [9] (20.0 dBm)
  • 2457 MHz [10] (20.0 dBm)
  • 2462 MHz [11] (20.0 dBm)
  • 2467 MHz [12] (disabled)
  • 2472 MHz [13] (disabled)
  • 2484 MHz [14] (disabled)

12 and 13 should work in DE like in the whole EU

Attachments (0)

Change History (75)

comment:1 Changed 5 years ago by anonymous

this is ok:

# iw reg get
country DE:

(2400 - 2483 @ 40), (N/A, 20)
(5150 - 5250 @ 40), (N/A, 20), NO-OUTDOOR
(5250 - 5350 @ 40), (N/A, 20), NO-OUTDOOR, DFS
(5470 - 5725 @ 40), (N/A, 26), DFS

iw list reports wrong channel support

comment:2 Changed 5 years ago by anonymous

Could it be related to this?
http://wiki.openwrt.org/toh/netgear/wndr3700?s#wireless.regulatory.issues
http://smorgasbord.gavagai.nl/2010/09/wifi-regulatory-compliance-and-how-to-fix-it/
I the same issue with my WNDR3700v2. Replacing '/usr/lib/crda/regulatory.bin' solved the problem.

comment:3 Changed 5 years ago by anonymous

for me the suggested fix did not work, no errors but just fell back to using the 00 defaults - despite the fact I'd also set them liberally as per the article! - perhaps it did not like the output file, but no error was present in dmesg.

Shouldn't the correct fix be to compile the binary for OpenWRT image with the CONFIG_ATH_USER_REGD option?

comment:4 Changed 5 years ago by ew-tech@…

Affected by this too, set DE in LuCi but only get channels up to 11. If 12 or 13 was set by hand, the wifi completely turns off.

Modus: Master | SSID: XXXXXX
BSSID: XX:XX:XX:XX:XX:XX | Verschlüsselung: WPA2 PSK (CCMP)
Kanal: 11 (2.462 GHz) | Sendestärke: 15 dBm
Signal: -41 dBm | Rauschen: -95 dBm
Bitrate: 54.0 MBit/s | Land: DE

This is backfire rc5 on wr1043nd 1.6 and crda 1.1.1-1

Please offer replacement packages to fix this.

comment:5 Changed 5 years ago by anonymous

please provide a fix for this issue

every 1043nd user in !usa is affected

comment:6 Changed 5 years ago by anonymous

it is still in trunk from today...

channel 12 and 13 are not available

comment:7 Changed 5 years ago by anonymous

no news here?

comment:8 Changed 5 years ago by anonymous

Updated from rc5 to rc6 yesterday, but there is no change. Channel 12 and 13 are out of order, there is no signal from the chipset if choosen.
tl1043nd

comment:9 Changed 4 years ago by anonymous

Same issue, 1043ND

comment:10 Changed 4 years ago by anonymous

Same issue on BARRIER BREAKER (Bleeding Edge, r34253) on TL-WDR4300 v1.3

Wireless chipsets:
[29.690000] ieee80211 phy0: Atheros AR9340 Rev: 0 mem = 0xb8100000, irq = 47
[29.710000] ieee80211 phy1: Atheros AR9300 Rev: 4 mem = 0xB0000000, irq = 40

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

Its simple to fix. Just build same image and turn just CONFIG_ATH_USER_REGD on. Then it would work. TP-Link programm in the EEPROM the world-settings. The ath9k driver uses them also when you set something else. The CONFIG_ATH_USER_REGD is an patch for the ath9k driver, that let you change the regulatory domain. But it wont let you get higher TX-Power then allowed from the EEPROM.

comment:12 in reply to: ↑ 11 ; follow-up: Changed 4 years ago by anonymous

Replying to anonymous:

Its simple to fix. Just build same image and turn just CONFIG_ATH_USER_REGD on. Then it would work. TP-Link programm in the EEPROM the world-settings. The ath9k driver uses them also when you set something else. The CONFIG_ATH_USER_REGD is an patch for the ath9k driver, that let you change the regulatory domain. But it wont let you get higher TX-Power then allowed from the EEPROM.

Thanks for your help.
May by there is some "workaround", I add following commands in /etc/rc.local:
wifi down
iw reg set PL
wifi up
and iwconfig wlan0 show the Tx-Power=27 dBm but I am not sure whether the value displayed is reliable, please see https://dev.openwrt.org/ticket/12462 .
Do you know what is the maximum tx power of the Atheros AR9340 and AR9580 and how to check the limit in the EEPROM?

comment:13 in reply to: ↑ 12 Changed 4 years ago by anonymous

I found this thread when I try to solve problem on different HW but also Atheros (in my case Atheros 5413)

It is possible change regulatory domain on EEPROM.
package kmod-madwifi contain nice tool ath_info :-)

comment:14 Changed 4 years ago by Nilfred <nilfred@…>

After r31954 (mac80211: use built-in regulatory database instead of crda to avoid various race conditions) there is no /usr/lib/crda/regulatory.bin file to replace. So previous workaround aren't working anymore in AA-rc1.
This is what I "find" @r34185:

find . -name db.txt
./build_dir/toolchain-mips_r2_gcc-4.6-linaro_uClibc-0.9.33.2/linux-3.3.8/net/wireless/db.txt
./build_dir/linux-ar71xx_generic/compat-wireless-2012-09-07/net/wireless/db.txt
./build_dir/linux-ar71xx_generic/linux-3.3.8/net/wireless/db.txt
find . -name regdb.txt
./package/mac80211/files/regdb.txt

So, patch'em and re-compile may solve it now.

comment:15 Changed 4 years ago by anonymous

Just tested setting channel 13 on Attitude Adjustment 12.09 RC1 on a WR1043ND HW V1.8 and it still doesn't work.
Manually setting iw reg set NL doesn't help either and regdb.txt is no longer there.

Any workaround or fix would be appreciated, especially since this bug already exists so long.

comment:16 Changed 4 years ago by Michael Markstaller <mm@…>

This is really a showstopper in AA - is it so hard to fix and give us back channels 12/13 ?
I'd be happy to test with trunk or AA

comment:17 Changed 4 years ago by jow

Yes it is.

comment:18 Changed 4 years ago by anonymous

This is already fixed for a loooooong time!
You just have to compile own image with CONFIG_ATH_USER_REGD
Setting some regions with iw luci or anything else DONT work! Driver ignores it! Driver only uses the region set in the Atheros eeprom. This can only be changed on old ath5k devices with ath_info. On all modern ath9k the tool dont work. But its possible too. Just missing tool.
But simply use the config above! It does not matter what region is set in eeprom.

comment:19 Changed 4 years ago by anonymous

http://luci.subsignal.org/~jow/reghack/

Works very well check readme.txt

comment:20 Changed 4 years ago by Michael Markstaller <mm@…>

Looks "amazing" but well if thats the way ;) It works.. (Any hint to a statement why this is - like it is? would be IMHO enough - I understand the problem absolutely..)

comment:21 Changed 4 years ago by anonymous

That reghack tool works fine. Channels 12,13 are back.

comment:22 Changed 3 years ago by pedro@…

Just ran into this today trying to enable HT40 in a 1043nd. I set the locale to PT and could still only select channels up to 11 for the primary channel. When I enabled HT40 with the channel above the router lost all wifi and I had to go in with ethernet to fix it. I had selected channel 9 so it failed trying to use 13. It would be nice to either fix this for good or disallow setting channel 9 and HT40 with the second channel above as that's not a supported configuration.

comment:23 Changed 3 years ago by spam.dump.one@…

Reghack enables channels 12 and 13 but, when I try to use them, they don't.

Using Attitude Adjustment stable on WNDR3800.

comment:24 Changed 3 years ago by anonymous

Honestly! open for 2 years?

I was burned by this today... TL-WR1043ND - ATTITUDE ADJUSTMENT (12.09-rc1, r34185)

Workarounds don't work for me.

channel [12] (13) is disabled for use in AP mode, flags: 0x61
wlan0: IEEE 802.11 Configured channel (13) not found from the channel list of current mode (1) IEEE 802.11g

comment:25 follow-ups: Changed 3 years ago by jow

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

reghack works to get the additional channels. This problem cannot be fixed in OpenWrt due to various obligations and agreements with vendors.

comment:26 in reply to: ↑ 25 Changed 3 years ago by anonymous

Replying to jow:

reghack works to get the additional channels. This problem cannot be fixed in OpenWrt due to various obligations and agreements with vendors.

Reghack does not work on stable.

comment:27 in reply to: ↑ 25 ; follow-up: Changed 3 years ago by anonymous

Replying to jow:

reghack works to get the additional channels. This problem cannot be fixed in OpenWrt due to various obligations and agreements with vendors.

Could you please direct me to a page where these obligations and agreements with vendors are detailed or could you please provide a description of the obligations and agreements with vendors that OpenWRT subscribes to?

I searched the wiki & forum and did not find any information.

Although the source is open, have OpenWRT devs have signed NDA agreements with vendors?

comment:28 in reply to: ↑ 27 Changed 3 years ago by anonymous

Replying to anonymous:

Replying to jow:

reghack works to get the additional channels. This problem cannot be fixed in OpenWrt due to various obligations and agreements with vendors.

Could you please direct me to a page where these obligations and agreements with vendors are detailed or could you please provide a description of the obligations and agreements with vendors that OpenWRT subscribes to?

I searched the wiki & forum and did not find any information.

Although the source is open, have OpenWRT devs have signed NDA agreements with vendors?

*Although the source is open, have OpenWRT devs signed NDA agreements with vendors?

comment:29 Changed 3 years ago by anonymous

  • Resolution wontfix deleted
  • Status changed from closed to reopened

Reopen: I faced this crap too. I think this hilarious idiocy *should* be fixed - it took me nearly 2 days to get idea why the very same settings are working on old router but fail for new one.

Releasing BROKEN firmwares warrants poor reputation for project. And recommending some blatant regulatory hacks as solution? Someone is clearly out of their minds. This hilarious idiocy is well beyond my wildest imaginations. Hacking regulations to ... comply with local regulations? This is just insane! Not to mention hack is far more nasty in relaxing regulations than I would like to see to just comply with local regulations. And at the end of day, treating "world" regdomain 00 as USA _is_ a bug, no matter what. World != USA.

comment:30 Changed 3 years ago by anonymous

Don't use openwrt, they don't owe you anything, you don't owe anyone anything.

comment:31 Changed 3 years ago by jow

  • Resolution set to wontfix
  • Status changed from reopened to closed

Technically speaking, only supporting channels 1-11 while 1-13 are allowed is in compliance with the regulatory. You make it sound as if you'd need to hack something to not be able to use disallowed frequencies.

comment:32 Changed 3 years ago by anonymous

  • Resolution wontfix deleted
  • Status changed from closed to reopened

You make it sound as if you'd need to hack something to not be able to use disallowed frequencies.

Wrong, you've got really perverted view, jow.
1) Its 100% legal to use channels 12/13 in my country (in fact it's also legal in EU/CN IIRC, so USA haves crippled wireless compared to many other places in the world). That what makes need to resort to hacks really silly. I just want to have my country regulations in effect (since hack also affects some other limits, well beyond changes needed for proper device operation in RU). All wireless equipment which is being sold here in Russia supports channels 12/13. This includes TL-1043ND, which haves 00 in it EEPROM, stock firmware is fine with it. OpenWRT on same hardware loses channels 12/13 and then refuses to use them even after explicit hint via web interface. This is silly and causes load of really moron problems.

2) While I can configure which channel to use in AP mode (though inability to select chan 12/13 cripples my ability to select channels with least interference in some cases), EPIC FAIL hits you if you setting up wireless client. If you haven't got it: wireless client FAILS TO SEE APs on channels 12/13! So openwrt users would be unable to connect to APs on channel 12/13. EPIC FAIL! Those who sets up APs here are not aware of this particular openwrt idiocy, and their equipment obviously allows to use chan 12/13 or even automatically selects these channels. So some APs are doomed to be unavailable for OpenWRT clients. Don't you think it's rather heavy issue and firmware with such flaws is really borked thing?

3) If I would want to do something to exceed regulatory limits, the best idea around seems to be mentioned reghack patcher, as it allows far more than just using correct settings for my country. That's why I'm not really happy with such solution. It's really overkill, IMO such tool should be last resort solution and just uploading firmware while living in Russia hardly should require "last resort" solutions by default.

4) If you're refusing to fix that, please put big fat red warning your default firmware image is borked and unusable outside of USA, it will save heck a lot of time for people trying to get idea what's wrong with their wireless. I've spent about 2 days trying to understand why I can't see some APs and why my usual openwrt settings fail on TL-1043 in really obscure way.

comment:33 Changed 3 years ago by bittorf@…

maybe a proper way would be to check that if user logins/SSH via /etc/profile and print an appropiate warnung? e.g.

your WiFi is bound from manufacturer to regdomain '$REGDOMAIN',
which limits your e.g. channels/txpower to $(iw phy0 info|magic)

e.g.

your WiFi is bound from manufacturer to regdomain '00',
which limits your e.g. channels/txpower to:

Frequencies:
* 2412 MHz [channel 1] (11.0 dBm = 12 mW)
* 2417 MHz [channel 2] (12.0 dBm = 15 mW)
* 2422 MHz [channel 3] (12.0 dBm = 15 mW)
* 2427 MHz [channel 4] (15.0 dBm = 31 mW)
* 2432 MHz [channel 5] (15.0 dBm = 31 mW)
* 2437 MHz [channel 6] (15.0 dBm = 31 mW)
* 2442 MHz [channel 7] (15.0 dBm = 31 mW)
* 2447 MHz [channel 8] (15.0 dBm = 31 mW)
* 2452 MHz [channel 9] (12.0 dBm = 15 mW)
* 2457 MHz [channel 10] (11.0 dBm = 15 mW)
* 2462 MHz [channel 11] (11.0 dBm = 12 mW)

comment:34 Changed 3 years ago by jow

  • Resolution set to wontfix
  • Status changed from reopened to closed

comment:35 Changed 3 years ago by anonymous

This is already fixed for a loooooong time!
You just have to compile "OWN" image with CONFIG_ATH_USER_REGD=y

https://forum.openwrt.org/viewtopic.php?id=35828

Read some and you will understand.
If you dont know how to do that, its not the firmware problem ...

comment:36 Changed 3 years ago by anonymous

I think the Russian feels entitled to download a workable firmware that served his needs. In his warped, sick or lazy view, not having that convenient download available equals failure on the developers.

This is going to be one of those tickets where the self-entitled user will play the re-open ticket tantrum game.

comment:37 Changed 3 years ago by anonymous

You just have to compile "OWN" image with CONFIG_ATH_USER_REGD=y

Yes. But releasing borked firmware images which are breaking proper wi-fi operation without even bothering self to put any warning is irresponsible, to say the least. But okay, now I can see why some local firmware developers called openwrt devs "f*cking morons". Looks like they weren't so untrue, looking on such a hilarious firmware images releases and bugs handling.

comment:38 Changed 3 years ago by anonymous

You just have to compile "OWN" image with CONFIG_ATH_USER_REGD=y

Yes. But releasing borked firmware images which are breaking proper wi-fi operation without even bothering self to put any warning is irresponsible, to say the least. But okay, now I can see why some local firmware developers called openwrt devs "f*cking morons". Looks like they weren't so untrue, looking on such a hilarious firmware images releases and bugs handling.

comment:39 Changed 3 years ago by anonymous

Doh, and bug tracker also screwed up, giving away "gateway timeout". How pathetic.

comment:40 follow-up: Changed 3 years ago by jow

As "pathetic fucking moron" I kindly ask you to stop posting insults here and wish you all the best in finding a more appropriate firmware for your device. Thank you.

comment:41 follow-up: Changed 3 years ago by anonymous

To have such wish respected you should at least save time of people outside of USA by clearly stating you release usa-only firmware which is unable to operate properly in other countries with different regulations. As you can imagine, wasting 2 days on trying to figure out why it fails to work properly is not fun at all. So I do think I have valid reasons to be "rather angry" on current state of things. Seriosly, this is most hilarious bug handling I faced in last 5 years.

comment:42 in reply to: ↑ 40 Changed 3 years ago by spam.dump.one@…

  • Resolution wontfix deleted
  • Status changed from closed to reopened

Replying to jow:

As "pathetic fucking moron" I kindly ask you to stop posting insults here and wish you all the best in finding a more appropriate firmware for your device. Thank you.

Jow, thanks for your work.

I'd just like to point out that this reghack does not work on stable (for me, and other people reported that too).

It would be really nice to see a little update here. One that does not need a recompile.
Thank you.

comment:43 Changed 3 years ago by jow

  • Resolution set to wontfix
  • Status changed from reopened to closed

It works fine here with the default wifi settings on 12.09 - tested on ar71xx and tl-wr1043nd.

comment:44 Changed 3 years ago by j.lancett@…

  • Resolution wontfix deleted
  • Status changed from closed to reopened

Hi i live in the UK and wood like to use channels 12 and 13. Im not a openwrt master so i don't no how to make it work. If you are not in the US it should just work.

comment:45 Changed 3 years ago by jow

  • Resolution set to wontfix
  • Status changed from reopened to closed

comment:46 Changed 3 years ago by mm@…

Still, just to second: this is a real big annoyance.
The one who knows just avoids Ch12/13 but if one doesn't know about this bug could loose many hours in useless troubleshooting (I still call it bug for a thing that doesn't work on such a popular and wide-spread box like WR1043!)
Also don't understand whats the real problem with just setting the CONFIG_ATH_USER_REGD option? A default of 0 (world) and the remainder is up to the user where he/she currently is..

comment:47 Changed 3 years ago by anonymous

OpenWRT is open source. Devs earns nothing tangible regardless if you use the firmware or not. It's take it or leave it.

comment:48 in reply to: ↑ 41 Changed 3 years ago by anonymous

my vision of the problem :

to many people that dont have the minimun knowledge to use openwrt, and dont want to spend time studing this. Where is writen that openwrt have to work flawless the way you want ? its a customizable firmware, its up to you modify it to the way you want, if you dont have the knowledge to do this, go and learn how to do it and STOP CRYING .

comment:49 Changed 3 years ago by anonymous

I have compiled my own image with imagebuilder via "make image PROFILE=WNDR3700" and edited .config file to include "CONFIG_ATH_USER_REGD=y" but I still have no channel 12-14. What did I do wrong?

comment:50 Changed 2 years ago by anonymous

Here, wndr3700 V2 user in China, with factoy img I get 27dbm TX power, I measure the TX power with a field strength meter it's 30mV/m, but after flash the 12.09, I got the max 17dm and about 15mV/m readings from meter, I install the reghack according to the jow's patch, but it really does not work, seems very long time this issues does not be cared of...any suggestion?

comment:51 Changed 2 years ago by anonymous

  • Resolution wontfix deleted
  • Status changed from closed to reopened

comment:52 Changed 2 years ago by anonymous

Maybe this is a related but different issue. I have three WR841n's that default to US (as expected). The problem is that all three are stuck at 18dbm, no matter what tx-power I set (r39729). They worked properly on earlier versions (r39100ish) and AA.

comment:53 follow-up: Changed 2 years ago by moverisk

For the record. Today (Mar.11th) I've successfully applied the reghack (built 07-Feb-2014 22:47) to Gargoyle 1.6.0 on TP-LINK WR1043ND. After reboot it showed 9 channels only but loading config file helped and now 12&13 are accessible.

Frequencies:

  • 2412 MHz [1] (20.0 dBm)
  • 2417 MHz [2] (20.0 dBm)
  • 2422 MHz [3] (20.0 dBm)
  • 2427 MHz [4] (20.0 dBm)
  • 2432 MHz [5] (20.0 dBm)
  • 2437 MHz [6] (20.0 dBm)
  • 2442 MHz [7] (20.0 dBm)
  • 2447 MHz [8] (20.0 dBm)
  • 2452 MHz [9] (20.0 dBm)
  • 2457 MHz [10] (20.0 dBm)
  • 2462 MHz [11] (20.0 dBm)
  • 2467 MHz [12] (20.0 dBm)
  • 2472 MHz [13] (20.0 dBm)
  • 2484 MHz [14] (disabled)

comment:54 Changed 2 years ago by max

reghack doestn't seem to work for me (Netgear WNDR3700, OpenWRT 12.09 r36088).
I have successfully patched the 2 files and rebooted, but still can't activate channel 12.

Region is set to Austria (AT), iw reg get:

country AT:
        (2402 - 2482 @ 40), (N/A, 20)
        (5170 - 5250 @ 40), (N/A, 20)
        (5250 - 5330 @ 40), (N/A, 20), DFS
        (5490 - 5710 @ 40), (N/A, 27), DFS

Error:

Apr  3 00:09:33 OpenWrt daemon.warn hostapd: wlan0: IEEE 802.11 Configured channel (12) not found from the channel list of current mode (1) IEEE 802.11g
Apr  3 00:09:33 OpenWrt daemon.warn hostapd: wlan0: IEEE 802.11 Hardware does not support configured channel

iw phy0 info:

                Frequencies:
                        * 2412 MHz [1] (17.0 dBm)
                        * 2417 MHz [2] (17.0 dBm)
                        * 2422 MHz [3] (17.0 dBm)
                        * 2427 MHz [4] (17.0 dBm)
                        * 2432 MHz [5] (17.0 dBm)
                        * 2437 MHz [6] (17.0 dBm)
                        * 2442 MHz [7] (17.0 dBm)
                        * 2447 MHz [8] (17.0 dBm)
                        * 2452 MHz [9] (17.0 dBm)
                        * 2457 MHz [10] (17.0 dBm)
                        * 2462 MHz [11] (17.0 dBm)
                        * 2467 MHz [12] (17.0 dBm) (passive scanning)
                        * 2472 MHz [13] (17.0 dBm) (passive scanning)
                        * 2484 MHz [14] (27.0 dBm) (passive scanning)

dmesg | grep ath:

[    0.070000] gpiochip_add: registered GPIOs 0 to 15 on device: ath79
[   10.450000] ath: EEPROM regdomain: 0x60
[   10.450000] ath: EEPROM indicates we should expect a direct regpair map
[   10.450000] ath: Country alpha2 being used: 00
[   10.450000] ath: Regpair used: 0x60
[   10.460000] Registered led device: ath9k-phy0
[   10.480000] ath: EEPROM regdomain: 0x60
[   10.480000] ath: EEPROM indicates we should expect a direct regpair map
[   10.480000] ath: Country alpha2 being used: 00
[   10.480000] ath: Regpair used: 0x60
[   10.480000] Registered led device: ath9k-phy1

comment:55 Changed 2 years ago by anonymous

Don't change the regdomain after patching. Leave everything at defaults.

comment:56 Changed 2 years ago by max

I tried setting the region to World (00), which i assume is the default, and restarted the device.
Still the same results, cannot use channel 12/13.

comment:57 Changed 2 years ago by anonymous

I have the same problem as max, I cannot use channel 12/13 in the latest trunk after using reghack. I updated from a february build in which reghack was working.

Device: tl-wdr3600

comment:58 in reply to: ↑ 53 Changed 2 years ago by tecnicoedilson@…

Replying to moverisk:

For the record. Today (Mar.11th) I've successfully applied the reghack (built 07-Feb-2014 22:47) to Gargoyle 1.6.0 on TP-LINK WR1043ND. After reboot it showed 9 channels only but loading config file helped and now 12&13 are accessible.

Frequencies:

  • 2412 MHz [1] (20.0 dBm)
  • 2417 MHz [2] (20.0 dBm)
  • 2422 MHz [3] (20.0 dBm)
  • 2427 MHz [4] (20.0 dBm)
  • 2432 MHz [5] (20.0 dBm)
  • 2437 MHz [6] (20.0 dBm)
  • 2442 MHz [7] (20.0 dBm)
  • 2447 MHz [8] (20.0 dBm)
  • 2452 MHz [9] (20.0 dBm)
  • 2457 MHz [10] (20.0 dBm)
  • 2462 MHz [11] (20.0 dBm)
  • 2467 MHz [12] (20.0 dBm)
  • 2472 MHz [13] (20.0 dBm)
  • 2484 MHz [14] (disabled)

Hey man,

I tried to load the reghack on my 1043 v1.8. After reboot I could see channels 12 and 13 as available options but wifi refuse to turn on. On main Gargoyle status screen I see Wireless disabled even having wifi option tuned on on "Connection".
So, did you performed any extra steps besides those ones present on:

http://luci.subsignal.org/~jow/reghack/README.txt

How to use:

ssh root@openwrt

On ar71xx:

cd /tmp/
wget http://luci.subsignal.org/~jow/reghack/reghack.mips.elf
chmod +x reghack.mips.elf
./reghack.mips.elf /lib/modules/*/ath.ko
./reghack.mips.elf /lib/modules/*/cfg80211.ko
reboot

Thanks!

comment:59 Changed 2 years ago by anonymous

A possilble solution (pseudocode) could be:

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.

BTW: The whole discussion is nonsense, since portable 3G-Routers and mobile phones exist...
You could travel around the world with a US-device, without breaking the regulatory rules, but as a Japanese you would be illegal elsewhere, as a european user you would be "illegal" in the US.

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.

comment:61 Changed 2 years ago by jow

  • Milestone changed from Attitude Adjustment 12.09 to Barrier Breaker 14.07

Milestone Attitude Adjustment 12.09 deleted

comment:62 Changed 22 months ago by soern

I just found this defect after wasting nearly an entire day of my life. I had suspected broken configuration, tried to install wpa_supplicant for wpad-mini, set the regulatory domain to DE, etc. and began to think that it must be my fault.

I understand that some people see the majority of OpenWRT's users in the US and it's understandable that the default regulatory domain is set to USA (alias "World").

On the other hand: When setting the regulatory domain using iw reg, I'd at least expect *some* error message pointing me here or to the Wiki. In the current state, OpenWRT or more percisely, iw, wifi and/or uci, just quietly ignore the regulatory domain, leaving possibly thousands of people wondering why their setup just isn't working the way it should be.

To me, this clearly is a defect that has already wasted so many people's lifetime.

Please, if you can't distribute images with other regulatory domains, *at least* add some error message telling the users what's going on.

comment:63 Changed 21 months ago by anonymous

I think Russia should launch couple of nukes on fuckin' USA heads so they learn USA != world hard way. Its just unimaginable how wretched some people could be. Ath9k devs are bunch of fucking idiots and openwrt devs follow same way.

comment:64 Changed 21 months ago by anonymous

This is clearly a defect. Perhaps we should fork the project and not bother the yankee devs, let them remain with their delusions of grandeur...

comment:65 Changed 21 months ago by anonymous

Instead of forking, maybe you can just compile with the right option... or send patches ...

comment:66 Changed 21 months ago by anonymous

EVERY device vendor ships their devices with respective channels enabled (when the correct country is set), so why can't OpenWRT?

I really doubt that there is a real legal issue but rather a myth...

comment:67 follow-up: Changed 21 months ago by bngtlrs

+1 I am affected by this, too. It is definately a papercut for experienced users and possibly a show stopper for novice users.

Wouldn't it solve the legal issues if someone in a different legislative region hosted "real" world (not just USA) images of OpenWRT? OpenWRT.org could clearly state that while country selection is implemented in all images, it always complies at least with US regulations and refer to that second download site. That way novice users would have a chance to select the image appropriate for them and no one would complain here.

comment:68 Changed 20 months ago by christof@…

ok. there is a way when compiling your own image. Great!

Is there also a way when using the image-builder? If so, it should be documented here.

comment:69 Changed 20 months ago by christof@…

... well, I found this - thank you jow - : http://luci.subsignal.org/~jow/reghack/
This works on a Barrier Breaker Image I created today. The patch consumes a little over 100kb space but it makes the channels 12 and 13 available.
unfortunately the driver is not being compiled by the image builder so it is either
a) reserving some space to execute the hack after flashing or
b) compiling the firmware

comment:70 in reply to: ↑ 67 Changed 20 months ago by anonymous

Replying to bngtlrs:

+1 I am affected by this, too. It is definately a papercut for experienced users and possibly a show stopper for novice users.

Wouldn't it solve the legal issues if someone in a different legislative region hosted "real" world (not just USA) images of OpenWRT? OpenWRT.org could clearly state that while country selection is implemented in all images, it always complies at least with US regulations and refer to that second download site. That way novice users would have a chance to select the image appropriate for them and no one would complain here.

Downloads are hosted in Europe.

comment:71 Changed 19 months ago by anonymous

tplink wr1043nd in AT also affected by this. patch is working - f*ing brave new world

comment:72 Changed 17 months ago by nbd

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

fixed in r45252

comment:73 Changed 15 months ago by anonymous

Working for AA !???

comment:74 follow-up: Changed 11 months ago by anonymous

Still on BB 14.07, have "TP-Link TL-WDR3600 v1". After reghack 12-13 i available on 2,4GHz radio, but 5GHz is not unlocked. Anyone? :)

comment:75 in reply to: ↑ 74 Changed 11 months ago by anonymous

Replying to anonymous:

Still on BB 14.07, have "TP-Link TL-WDR3600 v1". After reghack 12-13 i available on 2,4GHz radio, but 5GHz is not unlocked. Anyone? :)

Figured it out. "Worked" when setting country to worldwide (00) since my country NO uses DFS on most channels in the 5GHz spectrum. Is DFS enabled in CC? I have as I said BB 14.07

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.