Linux Unlocked channels+TX power+other mods for Atheros, Intel, Realtek

Hello everybody,


My first post here. Maybe somebody recognises me from the Frequency Hell project :O
I've been hacking around the drivers and firmware of various cards in Linux (at this writing running kernel 3.13-rc7).
I am looking for other Linux/firmware hackers for co-operation in completely 'freeing' contemporary WLAN cards.

So far, I've managed to do the following:

-802.11d completely disabled
-Radar detection removed (in hostapd too)
-Active scanning always allowed
-OFDM always allowed
-40MHz channel pairing restrictions removed both in the card and hostapd. No more "20/40 MHz operation not permitted on x and y based on overlapping BSSes" BS.
-Force card to use the highest available TX power even if the signal strength is good
-Unlocked all the channels both on 2GHz and 5GHz bands
-All channels also available for AP mode use
-Unlocked TX power settings. Max available TX power depends on the card, but my cards are as follows (MCS0 peak, measured at the antenna port(s)):
--Intel 6235 ETSI: 22,5dBm @2GHz; 19dBm @5GHz (both 2 chain. This card really sucks at default and the range still sucks after modding when compared to the others)
--Atheros 9287 FCC: 24dBm 1 chain, 26dBm 2 chains (nice but loses to the Realtek)
--Realtek 8192DE ETSI: 25,5dBm 1 chain, 28dBm 2 chains @2GHz; 21,5dBm @5GHz (card runs hot after 100GB transfer but works fine, great range. Tested only 1 chain @5GHz since I fried my 2-chain dual band AP.. -.-)

-Atheros and Realtek only: permanently change channel restrictions and TX power limits in EEPROM so even Windows users can enjoy some freedom Tested on Win7 x64.


I need help modifying the Intel firmware. Has anyone figured out how to patch the TX power at 5GHz mid-band without affecting the other bands? If I change anything there the whole 5GHz band drops to ~5dBm TX power even though the card seems to accept the modified EEPROM just fine!

In addition, I'm working on enabling custom channels; e.g. "channel 16" at 2494MHz. So far I have liberated 2.34...2.6GHz area with the Realtek card, but no progress with the other cards even after days (and nights..) of debugging and coding. I know for certain that there are custom Atheros cards with unlocked tuning capabilities, so I would be grateful if somebody with an EEPROM burner and an ath9k-supported card could help me debug.
Even better would be if you happen to own such an unlocked card and could send me a dump


Peace,


Syysvalo

 

Here's how to change the regulatory domain on Atheros 9287 EEPROM.

The regulatory domain is stored at 0x8 as a simple 1-byte hex value.
The card itself doesn't know how to interpret this value, the drivers do all the dirty work. Setting the value to 0x65 enables all channels (if you have CRDA patched out).

Note that 0x0 is USA in most Atheros cards (all of them?). The world domains start at 0x60.
Next you'll need to fix the checksum at 0x3. It is a simple 1-byte value and no need to do complicated calculations - just make the same change as you did with the regulatory domain value.

For example, if the values were:
0x3=3A, 0x8=00
and you changed your regulatory domain to 0x65
-> 0x3=3A, 0x8=65
add 0x65 to 0x3
-> 0x3=9F, 0x8=65.

All done. Flash and enjoy.
TX power settings start at 0x216, but there is really no need to change them if you use patched drivers/CRDA.


Next we do the same but on Intel 6235.
First I must say that Intel's NVM is just absurdly huge when compared to all others. Entire operating systems could fit in and if you're paranoid enough, maybe there is one already
Anyways, Intel uses a detailed allowed channel mapping area instead of a single regulatory domain byte.
The area starts at 0xCC and has the following structure:
1 byte max allowed TX power of channel #1
1 byte other restrictions of channel #1
1 byte max allowed TX power of channel #2
...and so on.

Setting the values to 0x0000 means the channel is disabled.
The TX power is stored as dBm so the default is 0x0F = 15dBm and the maximum is 0xFF = 255dBm. Unfortunately above 23dBm (actual measured power 22,5dBm) my card can't connect to any AP anymore.. guess the amp is clipping/crapping out.
I recommend staying at 0xA6 or less.
The next value should be set to 0x6F, which means "no restrictions".

After the 2GHz channels there is what looks like a 2-byte checksum, but I'm not changing it and the card still accepts the new values just fine?!
Maybe it's the Evil Bit so I'm leaving it alone for now.

After channels 1-14 come 183-196, then 7-16 (5GHz band!), checksum(CS), 34-64, CS, 100-140, CS, 145-165, CS, and then 40MHz channels starting from 1-7.

Finally as a bonus, if your card has 802.11n disabled, change the 16-bit value at 0x8A to 0x0040. Enjoy your hard-deserved 802.11n.


Realtek comes last. You'll only need to change a couple of driver files (hint: regd*.* and wifi.h for TX power) and patch CRDA - done. I <3 Realtek.


Peace,


Syysvalo

--- Double Post Merged, 24 Jan 2014 ---

Mini-how-to: create your own digitally signed regulatory database for CRDA.

This is actually quite straightforward.

0. First, check that you don't have CONFIG_WIRELESS_OLD_REGULATORY enabled in your kernel. If you don't know the answer, it very likely is not enabled.
If it IS enabled, you'll need to disable it and recompile your kernel. This step is needed since some cards, like Atheros, apply extra restrictions if it's enabled.

1. Clone the regulatory database git repo: git clone git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-regdb.git

2. cd wireless-regdb

3. Edit db.txt with your favourite text editor to your liking. Unfortunately, I could not attach a pre-modded db.txt (Error: The uploaded file does not have an allowed extension.).

4. Run make

5. Copy <username>.key.pub.pem to /lib/crda/pubkey

6. Copy regulatory.bin to /lib/crda

7. Restart CRDA and your WLAN card or simply reboot

If you want to share the database with your friends, remember to include the *.key.pub too or it won't work!

After reboot you should see lines like this on dmesg:
cfg80211: World regulatory domain updated:
cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
2402000 KHz - 2494000 KHz @ 40000 KHz), (N/A mBi, 3000 mBm)
4915000 KHz - 5835000 KHz @ 80000 KHz), (N/A mBi, 3000 mBm)

3000 mBm = 30dBm =)

If your card's channels and/or TX power are not fully unlocked now, you'll need to patch the drivers and/or EEPROM too.
Generally: Realtek=very easy, Ralink=easy, Atheros=hard, Intel=nightmarish.
More to follow..

Peace,


Syysvalo

 

Unfortunately I don't have a flasher for Atheros that would work over USB - if you need to use your adapter in Windows I'm afraid the only solution is to desolder the EEPROM chip (usually it's the smallest 8-pin DIP) and read/write it with any of the <$15 EEPROM flashers. For changing the EEPROM images I use Hexer/Winhex, but any hex editor would do. The EEPROM is just 727 bytes long in this case.
It might be possible to flash it in place without unsoldering, but that might brick your adapter too.
One could always patch the Windows driver; RING0 binary with no source = no fun and beyond my skills.. I should not have stopped studying x86 asm ~10 years ago

In Linux it is possible to bypass the region checks completely with software patches only. You'll need to patch both the CRDA daemon and the ath9k driver, most changes are in regd.c, regd.h and eeprom*.c. In your case it is easier because your domain is not a world roaming domain - the bloody drivers have special checks (and additional restrictions) for world domains.


Only with TPC, 802.11h and 802.11d disabled, I can be sure that the card won't decide to change the channel and/or TX power by its own.
I mostly just NOP them out, for example I patched a function is_radar_detected_on_channel to immediately return false to the caller.
In similar style, when the driver calls the EEPROM read routine for get_max_tx_power I don't touch the read routine but add 13dBm to the return value

Could you please elaborate a bit about the connection problems in the ETSI domain? If I understood correctly, only APs set the region code in their probe packets and the clients passively either obey it or not, and therefore the AP can't detect how the client acted. Please correct me if I have missed something important =)

 

Ah, OK, it seems that we both are correct.

When 802.11d is enabled, the AP adds a country code to every probe packet it sends. In Linux, when the client adapter sees such a packet, it will call CRDA and ask it to change the regulatory domain accordingly. Then CRDA checks its regulatory database and assigns new rules accordingly (it can both add and remove restrictions). When this happens, you'll see a notice in dmesg output.
In Windows the driver has to do all the dirty work by itself, but thankfully at least Realtek drivers ship with 802.11d disabled by default and one can toggle it at adapter properties.
The important thing is that 802.11d is completely software-based. If the client simply decides to ignore any country codes found in probes, the AP will never know and the client will be left at default settings.

So, when using unpatched drivers and for example an FCC card, one needs to keep 802.11d enabled in order to use channels 12 & 13 with an ETSI AP. Of course, channels 1-13 will then be limited to 20dBm.
With patched drivers and/or firmware, one can both have the cake and eat it. The card is set for example to FCC domain, but with channels 1-14 and 27dBm TX enabled. Probe packet comes with lets say UK country code and goes straight to trash, operation at channel 14 @27dBm will continue as before and the AP has no idea. This is why I disable it in my driver mod set.