Madwifi is too restrictive in Denmark

It is similar here in Czech Republic, here also channels 149-165 are allowed even for outdoor use - althrought within some special conditions, like very restrictive EIRP and etc. - and lower channels - 5,2-5,4 are allowed too but only for indoor use. Channels between 5,4-5,7 are allowed on less restrictive basis. So, following table is broken, or i could say BROKEN. And I am afraid that many "countrycodes" are broken like this ...

CZECH REPUBLIC (CZ, 0xcb, 203) ETSI3_WORLD (0x36, 54)
2412B 18.0 2417B 18.0 2422B 18.0 2427B 18.0 2432B 18.0 2437B 18.0
2442B 18.0 2447B 18.0 2452B 18.0 2457B 18.0 2462B 18.0 2467B 18.0
2472B 18.0 5180A 16.0 5200A 16.0 5220A 16.0 5240A 16.0 5260A 16.0
5280A 16.0 5300A 16.0 5320A 16.0

My solution is either use other - Uzbekistan :) - countrycode, or edit eeprom to regdomain 96 and don't set countrycode, then i got following channel list, which is far from ideal but at least let us use allowed channels :

Channel   1 : 2412  Mhz 11g          Channel  52 : 5260* Mhz 11a
Channel   2 : 2417  Mhz 11g          Channel  56 : 5280* Mhz 11a
Channel   3 : 2422  Mhz 11g          Channel  58 : 5290* Mhz 11a Static
Channel   4 : 2427  Mhz 11g          Channel  60 : 5300* Mhz 11a
Channel   5 : 2432  Mhz 11g          Channel  64 : 5320* Mhz 11a
Channel   6 : 2437* Mhz 11g Dynamic  Channel 100 : 5500* Mhz 11a
Channel   7 : 2442  Mhz 11g          Channel 104 : 5520* Mhz 11a
Channel   8 : 2447  Mhz 11g          Channel 108 : 5540* Mhz 11a
Channel   9 : 2452  Mhz 11g          Channel 112 : 5560* Mhz 11a
Channel  10 : 2457  Mhz 11g          Channel 116 : 5580* Mhz 11a
Channel  11 : 2462  Mhz 11g          Channel 120 : 5600* Mhz 11a
Channel  12 : 2467* Mhz 11g          Channel 124 : 5620* Mhz 11a
Channel  13 : 2472* Mhz 11g          Channel 128 : 5640* Mhz 11a
Channel  14 : 2484* Mhz 11b          Channel 132 : 5660* Mhz 11a
Channel  34 : 5170* Mhz 11a          Channel 136 : 5680* Mhz 11a
Channel  36 : 5180* Mhz 11a          Channel 140 : 5700* Mhz 11a
Channel  38 : 5190* Mhz 11a          Channel 149 : 5745* Mhz 11a
Channel  40 : 5200* Mhz 11a          Channel 152 : 5760* Mhz 11a Static
Channel  42 : 5210* Mhz 11a Static   Channel 153 : 5765* Mhz 11a
Channel  44 : 5220* Mhz 11a          Channel 157 : 5785* Mhz 11a
Channel  46 : 5230* Mhz 11a          Channel 160 : 5800* Mhz 11a Static
Channel  48 : 5240* Mhz 11a          Channel 161 : 5805* Mhz 11a
Channel  50 : 5250* Mhz 11a Static   Channel 165 : 5825* Mhz 11a

That still doesn't solve turbo problem - turbo is only available within 5,745-5,825Ghz range and not within 5,4-5,7Ghz, but man cannot have all... . I think we should just ignore all this till it is sorted, haven't tried OpenHAL recently but there should be able to ignore this, on trunk - we would need access to HAL source to sort this out i am afraid of, but maybe i am just plain wrong ...

I've just "upgraded" to the trunk version straight out of svn:

ath_hal: 0.9.30.13 (AR5210, AR5211, AR5212, AR5416, RF5111, RF5112, RF2413, RF54
13, RF2133)
wlan: 0.8.4.2 (svn r2377)
ath_pci: 0.9.4.5 (svn r2377)
ath_rate_sample: 1.2 (svn r2377)                                                

... and it still suffers from this.

Guys,

I hate to say this but the regulatory information is maintained in the binary HAL (which is outside the direct control of the MadWifi team). The latest build has HAL 0.9.30.13. Until you see an updated HAL, you should not expect any difference in behavior regarding regulator behavior. All we can do is pass the info upstream.

- M