ALFA AWUS036NHA hacking EEPROM via UART/JTAG

[mokba]

Hi

Got one of the GB region EEPROM locked NHA cards, any attempt to raise power to at least 27dBm fails. Tried several driver hacks, including hardcoding txpower in driver, regulatory gameplays, and even openwrt the results is always the same:

I can set whatever power I want, 15,27,30 dBm etc. but values over 20dBm simply have no effect. I know there are hundreds of regulatory/crda tutorials around the web that make me sick where people report success not knowing it is false success because the actual power is not raised.

I've also tried the same with TL-WN722N adapter and there is situation even worse: Any txpower value larger than 16dBm (possibly 15 or even 14, I didn't do precise test due to lack of RF measuring equipment) won't make any difference on the remote access point.

From a very quick comparison I can tell AWUS036NHA has about 3-5 db stronger txpower and about 5-7 db better reception sensitivity than TL-WN722N which has CN region burned in.

Further I have tried to run both cards on Win XP where Ubiquiti client utility can be used. This utility displays adapter's txpower in windows and for TL-WN722N it was set to 630mW while for AWUS036NHA it was set to 1000mW. Hoping it might give some boost I tried connecting to an access point and checking the RSSI there but unfortunately RSSI is the same as it was on ubuntu with default 20dBm. Even though the card reports 1W in utility it doesn't look like it is really transmitting at 1W.

So it seems there is only one approach left: EEPROM hacking

I knew this card has an UART that can be easily accessed so I did a bit googling and found someone who has already managed to get UART output

http://bobcopeland.com/blog/2015/05/reserialized/

But there's not much info on what can be done from serial console and even basic info is missing like baudrate so I got an idea to register here and start this thread in a hope there will be more people interested in doing this.

There are also JTAG leads on PCB pulled from AR9271L chip going down left to the EEPROM chip, you can see it on a picture and find out more if you look at the AR9271L datasheet so in case UART is not much of a help maybe EEPROM could be dumped via JTAG and flashed back after it's modifed.



I'd prefer any of the two methods since I have both serial and JTAG adapter rather than unsoldering and buying an EEPROM programmer. Even better would be if we could add it's support to some of the EEPROM modding tools so everyone can use it without opening the case.

Let's get this thing unlocked to it's full power.

[frafri]

i have this card and it has work for me but I have not been able to raise the power. also having issues with it on windows 10

[mokba]

update: got something mixed up, after checking again JTAG pins are not connected anywhere so it's required to solder wires directly on chip.

anyone have an EEPROM dump from US region locked card?

[brunoaduarte]

Hi mokba, i thought that only the regulatory domain setting (cfg80211: DFS Master region), was written to the EEPROM.

My new AWUS036NHA should arrive next monday (bought from US). I'll make an EEPROM dump and send to you.

[mokba]

that's great news. I had no luck so far with increasing the power of ath chipsets, so swapping an EEPROM might be the best thing to start with. If that does not make any difference then I'll know for sure there's something with the driver code I'm missing.

[brunoaduarte]

that's great news. I had no luck so far with increasing the power of ath chipsets, so swapping an EEPROM might be the best thing to start with. If that does not make any difference then I'll know for sure there's something with the driver code I'm missing.

Hi, my AWUS036NHA arrived today, but unfortunately it seems to be the same region of yours (even though i've bought it from USA).

Jan  4 21:37:00 android kernel: [  294.112057] usb 2-5: new high-speed USB device number 2 using ehci-pci
Jan  4 21:37:00 android kernel: [  294.260933] usb 2-5: New USB device found, idVendor=0cf3, idProduct=9271
Jan  4 21:37:00 android kernel: [  294.260938] usb 2-5: New USB device strings: Mfr=16, Product=32, SerialNumber=48
Jan  4 21:37:00 android kernel: [  294.260941] usb 2-5: Product: UB91C
Jan  4 21:37:00 android kernel: [  294.260944] usb 2-5: Manufacturer: ATHEROS
Jan  4 21:37:00 android kernel: [  294.260946] usb 2-5: SerialNumber: 12345
Jan  4 21:37:02 android kernel: [  296.086203] usb 2-5: ath9k_htc: Firmware htc_9271.fw requested
Jan  4 21:37:02 android kernel: [  296.086673] usbcore: registered new interface driver ath9k_htc
Jan  4 21:37:02 android kernel: [  296.099289] usb 2-5: firmware: direct-loading firmware htc_9271.fw
Jan  4 21:37:02 android kernel: [  296.381062] usb 2-5: ath9k_htc: Transferred FW: htc_9271.fw, size: 50980
Jan  4 21:37:02 android kernel: [  296.621578] ath9k_htc 2-5:1.0: ath9k_htc: HTC initialized with 33 credits
Jan  4 21:37:02 android kernel: [  296.899956] ath9k_htc 2-5:1.0: ath9k_htc: FW Version: 1.3
Jan  4 21:37:02 android kernel: [  296.913129] ieee80211 phy1: Atheros AR9271 Rev:1
Jan  4 21:37:02 android kernel: [  296.913167] cfg80211: Calling CRDA for country: GB
Jan  4 21:37:02 android kernel: [  296.931385] cfg80211: Regulatory domain changed to country: GB
Jan  4 21:37:02 android kernel: [  296.931391] cfg80211:  DFS Master region: ETSI
Jan  4 21:37:02 android kernel: [  296.931393] cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
Jan  4 21:37:02 android kernel: [  296.931397] cfg80211:   (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
Jan  4 21:37:02 android kernel: [  296.931400] cfg80211:   (5170000 KHz - 5250000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (N/A)
Jan  4 21:37:02 android kernel: [  296.931404] cfg80211:   (5250000 KHz - 5330000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (0 s)
Jan  4 21:37:02 android kernel: [  296.931406] cfg80211:   (5490000 KHz - 5710000 KHz @ 160000 KHz), (N/A, 2700 mBm), (0 s)
Jan  4 21:37:02 android kernel: [  296.931409] cfg80211:   (57000000 KHz - 66000000 KHz @ 2160000 KHz), (N/A, 4000 mBm), (N/A)

[mokba]

well, i wasn't giving much hope to be honest. if you have programmer please dump it anyway so we can compare if the content is the same. i'll have to buy one as it looks like even if i make some kind of jtag connection the jtag adapter i got is not much of a use. i wasn't even able to unbrick an ordinary router with it.

maybe somebody else will have US version so we'll have to wait or we can attempt to write custom values into eeprom. do you know is there any relation between CPU revision / reg domain?

i know they claim older versions of the card have AR9271 vs. newer AR9271L which apparently stands for Low cost but i don't trust them. more likely it means Low power.

[brunoaduarte]

well, i wasn't giving much hope to be honest. if you have programmer please dump it anyway so we can compare if the content is the same. i'll have to buy one as it looks like even if i make some kind of jtag connection the jtag adapter i got is not much of a use. i wasn't even able to unbrick an ordinary router with it.

maybe somebody else will have US version so we'll have to wait or we can attempt to write custom values into eeprom. do you know is there any relation between CPU revision / reg domain?

i know they claim older versions of the card have AR9271 vs. newer AR9271L which apparently stands for Low cost but i don't trust them. more likely it means Low power.

mokba, i've found 4 devices on the I2C line, so i dumped them all

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: 50 51 52 53 -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

here is the dump

AWUS036NHA - ATMLH440.zip

I've replaced my mac address with AABBCCDDEEFF.

[mokba]

until i manage to read mine here's one i found online from TL-WN721NC that use same chipset.

TL-WN721NC.bin.zip

[brunoaduarte]

Nice, if you've got a RaspberryPi you could read it very easily just by connecting wires to I2C SDA and SCK lines (don't need to remove the EEPROM from PCB)...

So,

Here's the EEPROM Map.jpg (taken from AR9271 datasheet).



And some EEPROM comparison



Interesting info about the Atheros regulatory settings

https://wireless.wiki.kernel.org/en/users/drivers/ath

[brunoaduarte]

Hi mokba, have you tried editing the ath9k driver source code "max_power" property ?

ath9k/common-init.c

#define CHAN2G(_freq, _idx)  { \
	.band = IEEE80211_BAND_2GHZ, \
	.center_freq = (_freq), \
	.hw_value = (_idx), \
	.max_power = 20, \
}

I got this quote from another forum

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 ****** drivers have special checks (and additional restrictions) for world domains.

[pedropt]

Nice work Bruno , you just gave me an idea here to extract the firmware from my most powerful cards .
You should make this thread in aircrack-ng forum too .
Maybe with help we could find a way to build a new firmware for some wifi cards that are not yet compatible .
examples : realtek 8192usb and realtek 8188 (some models) , i have both cards with those chipsets here , i will give a look if i am able to extract the firmware of it wit my blackcat or with my tiao .
Anyway , thanks for the idea .

[mokba]

Hi

Yes I've tried that setting to 30, and iw list displays max power 30 but no actual effect on txpower.

What I'm wondering if the driver code by default doesn't allow more than 20 how the US region cards get higher txpower?

[mrflash]

Hi
I just removed my eeprom from the PCB and read it out to see that it's locked to 0x33A. (0x833A) (at offset 0x88 in the rom file)
Now I can write a different region code to it but wonder what code to write. Should I just go with the US code or the BO code?
Any suggestions?

Oh and thanks for all this good info regarding this rom mod. Would never have come up with this mod if it was't for this thread

[mokba]

try TW if it will work

country TW: DFS-FCC
(2400 - 2483.5 @ 40), (30)
# Follow US 5.15 ~ 5.25 GHz: 30 dBm for master mode, 23 dBm for clients
(5150 - 5250 @ 80), (23), AUTO-BW
(5250 - 5350 @ 80), (23), DFS, AUTO-BW
(5470 - 5725 @ 160), (23), DFS
(5725 - 5850 @ 80), (30)

these are all GB cards we have

[   15.930000] ieee80211 phy1: rt2x00_set_rt: Info - RT chipset 5390, rev 0500 detected
[   15.930000] ieee80211 phy1: rt2x00_set_rf: Info - RF chipset 7620 detected
[   15.940000] ieee80211 phy1: Selected rate control algorithm 'minstrel_ht'
[   15.960000] usbcore: registered new interface driver rt2800usb
[   15.970000] l2tp_ppp: PPPoL2TP kernel driver, V2.0
[   16.130000] usb 1-1: ath9k_htc: Transferred FW: htc_9271.fw, size: 50980
[   16.360000] ath9k_htc 1-1:1.0: ath9k_htc: HTC initialized with 33 credits
[   19.100000] ath9k_htc 1-1:1.0: ath9k_htc: FW Version: 1.3
[   19.100000] ath9k_htc 1-1:1.0: FW RMW support: Off
[   19.110000] ath: EEPROM regdomain: 0x833a
[   19.110000] ath: EEPROM indicates we should expect a country code
[   19.120000] ath: doing EEPROM country->regdmn map search
[   19.120000] ath: country maps to regdmn code: 0x37
[   19.130000] ath: Country alpha2 being used: GB
[   19.130000] ath: Regpair used: 0x37
[   19.150000] ieee80211 phy2: Atheros AR9271 Rev:1
[   19.160000] cfg80211: Regulatory domain changed to country: GB
[   19.170000] cfg80211:  DFS Master region: ETSI
[   19.170000] cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
[   19.180000] cfg80211:   (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
[   19.190000] cfg80211:   (5170000 KHz - 5250000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (N/A)
[   19.200000] cfg80211:   (5250000 KHz - 5330000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (0 s)
[   19.210000] cfg80211:   (5490000 KHz - 5710000 KHz @ 160000 KHz), (N/A, 2700 mBm), (0 s)
[   19.220000] cfg80211:   (57000000 KHz - 66000000 KHz @ 2160000 KHz), (N/A, 4000 mBm), (N/A)

[mrflash]

Gah!
There is a checksum in there.

Jan 21 23:18:06 OpenWrt kern.info kernel: [   34.460000] usb 1-1: ath9k_htc: Transferred FW: htc_9271.fw, size: 51272
Jan 21 23:18:06 OpenWrt kern.info kernel: [   34.710000] ath9k_htc 1-1:1.0: ath9k_htc: HTC initialized with 33 credits
Jan 21 23:18:06 OpenWrt kern.err kernel: [   34.880000] ath: phy1: Bad EEPROM checksum 0x81fc or revision 0x000e
Jan 21 23:18:06 OpenWrt kern.err kernel: [   34.890000] ath: phy1: Unable to initialize hardware; initialization status: -22
Jan 21 23:18:06 OpenWrt kern.err kernel: [   34.900000] ath: phy1: Unable to initialize hardware; initialization status: -22
Jan 21 23:18:06 OpenWrt kern.err kernel: [   34.900000] ath9k_htc: Failed to initialize the device
Jan 21 23:18:06 OpenWrt kern.info kernel: [   34.910000] usb 1-1: ath9k_htc: USB layer deinitialized

[mrflash]

Found some info about the checksum here:
http://lxr.free-electrons.com/source.../eeprom_9287.c
At line 231 they calc the checksum.

So it looks like the eeprom struct

struct base_eep_ar9287_header {
442         u16 length;
443         u16 checksum;
444         u16 version;
445         u8 opCapFlags;
446         u8 eepMisc;
447         u16 regDmn[2];
448         u8 macAddr[6];
449         u8 rxMask;
450         u8 txMask;
451         u16 rfSilent;
452         u16 blueToothOptions;
453         u16 deviceCap;
454         u32 binBuildNumber;
455         u8 deviceType;
456         u8 openLoopPwrCntl;
457         int8_t pwrTableOffset;
458         int8_t tempSensSlope;
459         int8_t tempSensSlopePalOn;
460         u8 futureBase[29];
461 } __packed;

Starts at offset 0x80 in the 24c08 eeprom and are 0x178 bytes long.

So when I take my original data from offset 0x80 and xor it like they do I get 0xFFFF as result.
Will have to remove the chip again and calc new checksum.
Also I notice some interesting in the struct.
There are two bytes there called rxMask and txMask. They are set to 01 in my eeprom. Wonder if they have anything to do with tx power??

Anyway. Here is the code I made to verify the checksum.

	DWORD i;
	WORD *w = (WORD*)eeprom; //eeprom point to offset 0x80 and sizeof(eeprom) is 0x178
	WORD sum = 0;

	for(i = 0; i < sizeof(eeprom)/2; i++)
	{
		sum ^= w[i];
	}

	printf("%04X\n", sum); //If sum == 0xFFFF then all is good

[mokba]

let me know if you manage to fix the checksum, otherwise I'll take a look around to see what has to be done.

maybe you can use something like this so no need to remove chip http://www.aliexpress.com/item/1Pcs-...251460158.html

[mrflash]

let me know if you manage to fix the checksum, otherwise I'll take a look around to see what has to be done.

maybe you can use something like this so no need to remove chip http://www.aliexpress.com/item/1Pcs-...251460158.html

I ordered the "new" FlashCat USB that comes with the PCB v2.x and with it I also ordered this test clip. With PCB 2.x it can now also do i2c.
But I did not get it yet and I just cant wait to test this so it will be the hard way again
Anyway. Thanks for this link. The one I ordered was much more expensive.
I have hi hopes to fix the checksum coz when i calc the sum on my modified data I get the exact value as I see in my log.

[brunoaduarte]

Hi,

@mrflash:

- There's no need to remove the EEPROM from the card. It's a I2C memory, so you could just solder 2 thin wires (SDA and SCK) if you've got a i2c programmer.
(I'm using a raspberry pi as i2c programmer)

- AWUS036NHA (AR9271 chipset), do not uses the "eeprom_9287.c", if you look at "ath9k/eeprom.c" code you'll see that it uses "ath9k/eeprom_4k.c" instead.

int ath9k_hw_eeprom_init(struct ath_hw *ah)
{
	int status;

	if (AR_SREV_9300_20_OR_LATER(ah))
		ah->eep_ops = &eep_ar9300_ops;
	else if (AR_SREV_9287(ah)) {
		ah->eep_ops = &eep_ar9287_ops;
	} else if (AR_SREV_9285(ah) || AR_SREV_9271(ah)) {
		ah->eep_ops = &eep_4k_ops;
	} else {
		ah->eep_ops = &eep_def_ops;
	}

	if (!ah->eep_ops->fill_eeprom(ah))
		return -EIO;

	status = ah->eep_ops->check_eeprom(ah);

	return status;
}

BTW @mokba: EEPROM address 0x147 to 0x18A seems to hold the power table

AWUS036NHA -> 0x147 = 2Eh = 46d (half dBm) / 2 = 23 dBm (maximum)

TL-WN721NC -> 0x147 = 24h = 36d (half dBm) / 2 = 18 dBm (maximum)

So...

i've spent the last days looking at the ath9k_htc backports driver + the open-ath9k-htc-firmware source codes.
And now i'm not sure if we should waste time messing with the EEPROM if our goal is to reach maximum output power.

Everything we need is in the driver + firmware, so we just have to find out where in the code, it loads the data from the EEPROM, intercept it and change it.
(unless you want to do a permanent region change of course, or maybe in the future save the max tx power settings to it).

From my tests i can tell (with original backports driver + open ath9k_htc firmware):

- iwconfig txpower 18 sets the maximum practical output power for the AR9271.
There seems to be a bug where values over 18 simply have no effect, even though the driver still sets higher half-dbm values in the firmware.

- iwconfig txpower 18 to 23 dBm
Causes changes in the driver (half dbm values are reported to the firmware), but as i said, have no practical effects (no power increase occurs).

- iwconfig txpower 23 to 33 dBm
Is capped by the driver, that will always report 23 dBm to the firmware (28 dBm considering the +5 dBm internal driver offset)

So before worrying about the driver 23 dBm cap (that is very easy to bypass, just by adding +10dBm to the driver routine that sets the firmware power), we must find this firmware bug that make 18-23 dBm settings ineffective.

Also, the firmware itself is capped at 31.5 dBm (MAX_RATE_POWER = 63 // half dBm value) (this one is a little more complicated, as there are a lot of parts of the code that cap it, so we must search for all hexadecimals 0x3F and decimals 63 and try to increase it)

Here's some more info about my tests
https://docs.google.com/spreadsheets...it?usp=sharing

Any help on debugging the driver+firmware are welcome.

Here's where i'm focused/stuck now: https://github.com/qca/open-ath9k-ht...ware/issues/82

[mrflash]

I have now updated the checksum on my chip and now it seems to work fine. No error messages under boot etc.
Here are som log data:

(Oh and I used BO as the new region)

[   34.780000] ieee80211 phy1: Atheros AR9271 Rev:1
[   34.790000] cfg80211: Calling CRDA for country: BO
[   34.790000] cfg80211: Current regulatory domain intersected:
[   34.790000] cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[   34.800000] cfg80211:   (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 3000 mBm)
[   34.810000] cfg80211:   (5735000 KHz - 5835000 KHz @ 40000 KHz), (N/A, 3000 mBm)
[   34.820000] Registered led device: ath9k_htc-phy1


iwconfig wlan1
wlan1     IEEE 802.11bgn  ESSID:"SSID"
          Mode:Managed  Frequency:2.452 GHz  Access Point: AA:BB:CC:DD:EE:FF
          Bit Rate=7.2 Mb/s   Tx-Power=27 dBm
          RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:off
          Link Quality=64/70  Signal level=-46 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:4   Missed beacon:0

		  
iw list
Wiphy phy1
        Band 1:
                Capabilities: 0x116e
                        HT20/HT40
                        SM Power Save disabled
                        RX HT20 SGI
                        RX HT40 SGI
                        RX STBC 1-stream
                        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-7
                Frequencies:
                        * 2412 MHz [1] (30.0 dBm)
                        * 2417 MHz [2] (30.0 dBm)
                        * 2422 MHz [3] (30.0 dBm)
                        * 2427 MHz [4] (30.0 dBm)
                        * 2432 MHz [5] (30.0 dBm)
                        * 2437 MHz [6] (30.0 dBm)
                        * 2442 MHz [7] (30.0 dBm)
                        * 2447 MHz [8] (30.0 dBm)
                        * 2452 MHz [9] (30.0 dBm)
                        * 2457 MHz [10] (30.0 dBm)
                        * 2462 MHz [11] (30.0 dBm)
                        * 2467 MHz [12] (30.0 dBm)
                        * 2472 MHz [13] (30.0 dBm)
                        * 2484 MHz [14] (disabled)

I dont have any equipment to measure output power so I don't know if I actually got 27dbm tx power.
Anyone know a good way of testing tx power?
Before the eeprom mod I got an error message when I tried to do a "iwconfig wlan1 txpower <pow>" using a pow greater then 20.
Now I can set it to everything above 20 without any error messages.
I can also go beyond 27 if I want but I guess the awus036nha have a max tx set to 27?

[aanarchyy]

well one way you can try that i have kinda done a bit myself, measure the current being drawn by the card itself. (with a multi-meter or such, or plug the card into a usb hub plugged into some type of current measuring device like a kil a watt and just subtract the overhead of the hub.)
It wont give you an exact figure of tx power, but it will give you an idea at significantly cheaper than radio equipment.

[mokba]

excellent news @mrflash

it should go to 30 without problems as it is detected as 1W in win xp

if it can work at 30 and deliver 1W output the card should start resetting itself at 30 dBm when connected to a regular USB2.0 port because port should not deliver more than 500mA of current and the card needs more to output 1W

[brunoaduarte]

excellent news @mrflash

it should go to 30 without problems as it is detected as 1W in win xp

if it can work at 30 and deliver 1W output the card should start resetting itself at 30 dBm when connected to a regular USB2.0 port because port should not deliver more than 500mA of current and the card needs more to output 1W

500 mA x 5V = 2500 mW (33.97 dBm)

I think a regular usb 2.0 port should provide 1W (30 dBm) (200 mA) easily. Shouldn't it ?

[mokba]

500 mA x 5V = 2500 mW (33.97 dBm)

I think a regular usb 2.0 port should provide 1W (30 dBm) (200 mA) easily. Shouldn't it ?

is that correct formula? I saw different info

EDIT:

it is power input 2.5W into USB device

http://www.backtrack-linux.org/forum...ull=1#post2867

[mokba]

well one way you can try that i have kinda done a bit myself, measure the current being drawn by the card itself. (with a multi-meter or such, or plug the card into a usb hub plugged into some type of current measuring device like a kil a watt and just subtract the overhead of the hub.)
It wont give you an exact figure of tx power, but it will give you an idea at significantly cheaper than radio equipment.

Hi

thanks for info, could you explain how to do with multimeter?

[mrflash]

I ordered this from ebay:
http://www.ebay.com/itm/331717106581...%3AMEBIDX%3AIT

[aanarchyy]

On a quick test, here are some results i have... Keep in mind this is current drawn by the CARD, _NOT_ actual transmit power, there will be some overhead
This test was perfomed by placing an ammeter in line with the 5v+ wire of the USB2 port.
Both tests were performed using an AWUS036NH card.
All results are nominal averaged readings.

These results are using my main debian machine with a custom reg.db up to 33db(1995mw):
device down and idle: 71ma = 355mw
device up and idle: 309ma = 1545mw
full force mdk3: 527ma = 2635mw

These results are using an unpatched Arch linux box using a stock reg.db up to 20db(100mw):
device down and idle: 70ma = 350mw
device up and idle:297ma = 1485mw
full force mdk3: 341ma = 1705mw

Well, that tells me there is a CLEAR difference in power draw by the card when using a modified reg.db, and i would attribute that to increased transmit power.
If there is any interest in this, i can do a more concise write-up using a more diverse range of cards i have at my disposal.

[brunoaduarte]

I ordered this from ebay:
http://www.ebay.com/itm/331717106581...%3AMEBIDX%3AIT

Cool device ! I've just bought one for me too...

On a quick test, here are some results i have... Keep in mind this is current drawn by the CARD, _NOT_ actual transmit power, there will be some overhead
This test was perfomed by placing an ammeter in line with the 5v+ wire of the USB2 port.
Both tests were performed using an AWUS036NH card.
All results are nominal averaged readings.

These results are using my main debian machine with a custom reg.db up to 33db(1995mw):
device down and idle: 71ma = 355mw
device up and idle: 309ma = 1545mw
full force mdk3: 527ma = 2635mw

These results are using an unpatched Arch linux box using a stock reg.db up to 20db(100mw):
device down and idle: 70ma = 350mw
device up and idle:297ma = 1485mw
full force mdk3: 341ma = 1705mw

Well, that tells me there is a CLEAR difference in power draw by the card when using a modified reg.db, and i would attribute that to increased transmit power.
If there is any interest in this, i can do a more concise write-up using a more diverse range of cards i have at my disposal.

Nice tests... I'll wait for my usb power measurer to arrive and i'll do similar tests with the AWUS036NHA

So... yesterday i did some EEPROM testing here...

If you look at region 0x139 - 0x18A (rates power table)

AWUS036NHA vs TL-WN721NC EEPROM comparison

You'll see that TL-WN721NC power for most rates is 0x24 (36d) -> 18 dBm, and for AWUS036NHA it is 0x2E (46d -> 23 dBm), 0x2C, 0x2A and 0x28.

So my first test was to see if it really works to change this power table... i replaced all 2E, 2C, 2A and 28 by 0x14 (20 -> 10 dBm).
And it worked, TX power limit was decreased, i could not go any higher than the specified value, and RX LEVEL on receiver was very low all the time.

Then i did another EEPROM write, and instead of 0x14, i've wrote 0x35 (53d -> 26 dBm), but now, although i can set higher values with iwconfig, RX level on receiver was never higher than with the original 2E, 2C, 2A and 28 bytes...
So it did not work ! (i also tried higher values than 0x35)

So, we have 2 scenarios:
- the card is already in it's physical full power with original EEPROM data
- there are another eeprom bytes that limit this output power (which i'm not able to identify)

BTW: i can confirm now, the power gap i related when changing iwconfig 17 -> iwconfig 18, was caused by the onboard power amplifier being turned on.

I can also manually turn on power amplifier by probing the SE2576L EN pin with 3.3V (if it's not already turned on of course) (again, it's automatically turned on at iwconfig 18)

Here are the EEPROM changes i've tested (left is the original dump)

this is 0x100 to 0x1FF

[mokba]

@brunoaduarte did you try:

1. set the different region in eeprom (US, BO?)
2. set the US/BO country code on AP you're connecting to?
3. try on windows to eliminate ath9k as cause?

[mrflash]

On a quick test, here are some results i have... Keep in mind this is current drawn by the CARD, _NOT_ actual transmit power, there will be some overhead
This test was perfomed by placing an ammeter in line with the 5v+ wire of the USB2 port.
Both tests were performed using an AWUS036NH card.
All results are nominal averaged readings.

These results are using my main debian machine with a custom reg.db up to 33db(1995mw):
device down and idle: 71ma = 355mw
device up and idle: 309ma = 1545mw
full force mdk3: 527ma = 2635mw

These results are using an unpatched Arch linux box using a stock reg.db up to 20db(100mw):
device down and idle: 70ma = 350mw
device up and idle:297ma = 1485mw
full force mdk3: 341ma = 1705mw

Well, that tells me there is a CLEAR difference in power draw by the card when using a modified reg.db, and i would attribute that to increased transmit power.
If there is any interest in this, i can do a more concise write-up using a more diverse range of cards i have at my disposal.

Hi
Can you specify what options you used with mdk3 so I can try the same test on my adapter?

[mrflash]

I measured my power consummation at the 230v side (so not to accurate) but I notice that when changing txpower from 0 up to 23 I could see and increase in power usage.
However going higher that 23 did not give and power increase so it kind of looks like that 23dbm is max on my card atm.
Will try to do same test again when I get my usb measuring device.
For testing I used "mdk3 mon0 a -a <mac>" (my own wifi mac)
txpower 0 gave 2.2w
txpower 20 gave 3.2w
txpower 23 gave 3.6w
txpower 26 gave 3.6w
txpower 27 gave 3.6w
txpower 30 gave 3.6w

[aanarchyy]

Hi
Can you specify what options you used with mdk3 so I can try the same test on my adapter?

as far as i remember, it was the auth flood attack, which it looks like is the same one you used in the below example.

I measured my power consummation at the 230v side (so not to accurate) but I notice that when changing txpower from 0 up to 23 I could see and increase in power usage.
However going higher that 23 did not give and power increase so it kind of looks like that 23dbm is max on my card atm.
Will try to do same test again when I get my usb measuring device.
For testing I used "mdk3 mon0 a -a <mac>" (my own wifi mac)
txpower 0 gave 2.2w
txpower 20 gave 3.2w
txpower 23 gave 3.6w
txpower 26 gave 3.6w
txpower 27 gave 3.6w
txpower 30 gave 3.6w

That sounds like you may be going through a usb HUB, and the overhead of the hub itself will skew the results.

I'm curious about the results with that little device, i've been tempted to get one of those myself.

[brunoaduarte]

@brunoaduarte did you try:

1. set the different region in eeprom (US, BO?)
2. set the US/BO country code on AP you're connecting to?
3. try on windows to eliminate ath9k as cause?

Hi, i think setting region in EEPROM won't make any difference for the Linux tests, as i've already tampered the regulatory files in my Kali Linux to make country GB allow 33 dBm.

Anyway, i've set country US (0x8348) in my EEPROM and tested it with WindowsXP.
Nothing happened. Before with country GB, max allowed power was 100 mW. Now with country US, it's also 100 mW.

country US: DFS-FCC
	(2402 - 2472 @ 40), (30)

country BO is not good on newer regulatory files...

country BO: DFS-JP
	(2402 - 2482 @ 40), (20)

[mokba]

Hi, i think setting region in EEPROM won't make any difference for the Linux tests, as i've already tampered the regulatory files in my Kali Linux to make country GB allow 33 dBm.

this might make it fail again. the best way to test eeprom mods would be on a clean OS without patches/backports (live kali/ubuntu) because i read somewhere that ath cards when detect txpower tampering silently drop to 10dBm output.

[brunoaduarte]

this might make it fail again. the best way to test eeprom mods would be on a clean OS without patches/backports (live kali/ubuntu) because i read somewhere that ath cards when detect txpower tampering silently drop to 10dBm output.

@mokba, sorry, but i guess that's bulls**t... Maybe the Windows/Mac drivers provided by Alfa could theoretically do that (very hard to believe they would do it though).

But Linux uses open sources driver + firmware, so everything is managed by the linux open source stuff.

The Alfa card doesn't have any kind of code running by itself that would be able to detect that. There's no onboard MCU to control the AR9271.

So i guess we can discard that possibility.

Now, unless we can understand the open source firmware or find another region EEPROM dump, we're stuck.

For now, i'm stopping these tests and buying an external power amplifier. lol

[kalifornia]

Lol bruno. I just got my 036nha in the mail today and same deal max 20 even though in canafa here i can go 27. Im going to buy an external power amp also. You have any suggestions on one thats good? Btw this awus036nha card is amazing. Very solid connection on low signal.

[mokba]

yeah it drops to 10 mW on AR9280, but no info yet on AR9271 so i just mentioned that as a possibility. read here on ubiquiti card review http://xiaopan.co/forums/threads/alf...ards-too.5378/

if you need high throughput don't buy any of these 30USD amps that ebay/ali are crowded with.

[brunoaduarte]

yeah it drops to 10 mW on AR9280, but no info yet on AR9271 so i just mentioned that as a possibility. read here on ubiquiti card review http://xiaopan.co/forums/threads/alf...ards-too.5378/

if you need high throughput don't buy any of these 30USD amps that ebay/ali are crowded with.

Yeah, i imagine that buying one of these 30$ amplifiers would not be worth it. Do you recommend any power amplifier ? Something like 2~3 W is enough.

Thanks

[aanarchyy]

Did you try building a customized reg.db?
I wrote a little script that will download, compile, and install a reg.db that will allow up to 33dbm(about 2W)

If it's useful to anyone else, here ya go.

http://s000.tinyupload.com/index.php...16042330344398

[kalifornia]

Been doing a bunch of testing with the 036nha and it supports all modes injects and captures handshakes like a champ. It the best card i have used by far. Better then the 036h or def on par in my tests. Only downfall i can see with the 036nha is low tx power. To get this to pump out 1w would be awesome. Even 27 dbm would be nice. The 036 nha connection is amazing. my 14dbi panel and 24dbi para grid antennaS need the nha to transmit more power.

[paulik]

so, conclusion is that get more output power as 23dB is impossible from this card, and other region tries are only cosmetics ?

[brunoaduarte]

so, conclusion is that get more output power as 23dB is impossible from this card, and other region tries are only cosmetics ?

Pretty much... As setting "iwconfig wlan0 txpower 18" in reality sets 23 dBm of power inside the driver, and the card can't go any further (at least with atheros drivers + firmware), it's not even needed to hack crda, because most countries allows up to 20 dBm by default. So in resume, use stock driver + settings, and you're at maximum power settings.

[mokba]

I would still wait for mrflash's precise measurements (would do it myself but got no time currently). He said power usage increases up to setting 23dBm which reminds me of a discussion at openwrt forums about newer tp-link routers that have 23dBm limit which is mainly cosmetical change only since the driver adds those 5dB as offset so I guess 28 would be the max atm?

Another thing there is an interesting tutorial: http://yo3iiu.ro/blog/?p=1301
If you manage to get all channels working txpower should be higher on these channels that have no calibration data in EEPROM. At least that was the case when I tested this.

[kakali]

Any news on this?

[kalifornia]

I'd like to know also how the testing is going. Either way the awus036nha rocks!!

[kalifornia]

btw Im in canada and my 036nha is burned to GB also. What a joke. lol

[ 7115.492921] usb 5-6: Product: UB91C
[ 7115.492923] usb 5-6: Manufacturer: ATHEROS
[ 7115.492926] usb 5-6: SerialNumber: 12345
[ 7116.737140] usb 5-6: ath9k_htc: Firmware htc_9271.fw requested
[ 7116.737905] usbcore: registered new interface driver ath9k_htc
[ 7116.746738] usb 5-6: firmware: direct-loading firmware htc_9271.fw
[ 7117.025484] usb 5-6: ath9k_htc: Transferred FW: htc_9271.fw, size: 50980
[ 7117.265974] ath9k_htc 5-6:1.0: ath9k_htc: HTC initialized with 33 credits
[ 7118.343382] ath9k_htc 5-6:1.0: ath9k_htc: FW Version: 1.3
[ 7118.343388] ath9k_htc 5-6:1.0: FW RMW support: Off
[ 7118.343391] ath: EEPROM regdomain: 0x833a
[ 7118.343392] ath: EEPROM indicates we should expect a country code
[ 7118.343395] ath: doing EEPROM country->regdmn map search
[ 7118.343397] ath: country maps to regdmn code: 0x37
[ 7118.343398] ath: Country alpha2 being used: GB
[ 7118.343400] ath: Regpair used: 0x37
[ 7118.352515] ieee80211 phy3: Atheros AR9271 Rev:1
[ 7118.672816] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 7118.674420] cfg80211: Current regulatory domain intersected:
[ 7118.674427] cfg80211: DFS Master region: unset
[ 7118.674429] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
[ 7118.674432] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
[ 7118.674436] cfg80211: (5170000 KHz - 5250000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 1700 mBm), (N/A)
[ 7118.674439] cfg80211: (5250000 KHz - 5330000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (0 s)
[ 7118.674442] cfg80211: (5490000 KHz - 5600000 KHz @ 80000 KHz), (N/A, 2400 mBm), (0 s)
[ 7118.674444] cfg80211: (5650000 KHz - 5710000 KHz @ 60000 KHz), (N/A, 2400 mBm), (0 s)

[kalifornia]

I got some install errors when running your script bro but i fixed it with running apt-get install libnl-3-dev libgcrypt11-dev libnl-genl-3-dev then it installed fine. thx

Did you try building a customized reg.db?
I wrote a little script that will download, compile, and install a reg.db that will allow up to 33dbm(about 2W)

If it's useful to anyone else, here ya go.

http://s000.tinyupload.com/index.php...16042330344398

[aanarchyy]

I got some install errors when running your script bro but i fixed it with running apt-get install libnl-3-dev libgcrypt11-dev libnl-genl-3-dev then it installed fine. thx

oops, typo in the script., sorry 'bout that...
it's the libnl-3-dev one that i screwed up, just change it in the first line and it will work

[dustyboner]

I was looking at the AR9271 datasheet and found this:

To ensure that the
FCC limits are observed and the output power
stays close to the maximum allowed, the
transmit output power is adjusted by a closed
loop, digitally programmed, control loop at the
start of each packet. The ARXXXX provides a
closed loop power control based on an on-chip
power detector.

so does that mean that a modified Reg.db won't work to increase the Tx power on anything with the AR9271 chipset?