Please note: This project is no longer active. The website is kept online for historic purposes only.
If you´re looking for a Linux driver for your Atheros WLAN device, you should continue here .

Ticket #1348 (new defect)

Opened 15 years ago

Last modified 15 years ago

Madwifi is too restrictive in Denmark

Reported by: ff-madwifi@partyticket.net Assigned to:
Priority: minor Milestone:
Component: madwifi: HAL Version: v0.9.3
Keywords: Cc:
Patch is attached: 0 Pending:

Description

Although Denmark has adopted ETSI we allow more frequencies than what ETSI suggests.

The relavant rlan (aka 802.11) frequencies allowed in Denmark as of November 7 2006 are:

  • 2400,0-2483,5 MHz (Channel 1-11)
  • 5150,0-5350,0 MHz (Channel 36-64)
  • 5470,0-5725,0 MHz (Channel 100-140)
  • 5725,0-5925,0 MHz (Channel 136-165)

The law also states that there is no requirement for channel separation and that the entire band can be used at will, so shouldn't that indicate that there are no limitations on turbo mode?

The problem with madwifi is that it disallows channel 149 to 165, which clearly should be allowed according the the proclamation: "Bekendtgørelse nr. 1140 af 7. november 2006", which is available here:
http: //itst.dk/static/pressemeddelelse/BEK._om_anvendelse_uden_tilladelse.pdf
See Section 10 on page 20.

The proclamation only went into effect on november 7 2006, so it's understandable that the madwifi international legal department hasn't noticed yet, but could we please have those channels enabled so we don't need to lie about the country code to use them?

What can I do to help this matter? Is it even in the hands of the madwifi developers to fix this oversight?

I'm using pyramid-1.0b5 which updated their madwifi driver 4 months ago, ath_pci reports version: 0.9.4.5 (0.9.3) so I might be terribly outdated, has this been fixed in 0.9.3.1?

Change History

05/26/07 11:45:34 changed by strasak@bubakov.net

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 ...

05/26/07 18:26:04 changed by anonymous

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.

05/26/07 23:08:56 changed by mtaylor

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