View Full Version : ALFA AWUS036NHA hacking EEPROM via UART/JTAG
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.
https://wikidevi.com/w/images/c/cd/ALFA_Network_AWUS036NHA_newRevision_%28AR9271L%29_ board_top.jpg
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.
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
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
2015-12-31, 14:12
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.
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
2016-01-04, 23:41
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)
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
2016-01-09, 23:27
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
1143
I've replaced my mac address with AABBCCDDEEFF.
until i manage to read mine here's one i found online from TL-WN721NC that use same chipset.
1142
brunoaduarte
2016-01-10, 15:28
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 1144 (taken from AR9271 datasheet).
https://forums.kali.org/attachment.php?attachmentid=1144&d=1452439117
And some EEPROM comparison
http://i.imgur.com/WpH5yoU.png
Interesting info about the Atheros regulatory settings
https://wireless.wiki.kernel.org/en/users/drivers/ath
brunoaduarte
2016-01-18, 04:42
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.
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 .
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?
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 :)
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)
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
Found some info about the checksum here:
http://lxr.free-electrons.com/source/drivers/net/wireless/ath/ath9k/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
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-SOIC8-SOP8-Flash-Chip-IC-Test-Clips-Socket-Adpter-BIOS-24-25-93-Programmer-Newest/32251460158.html
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-SOIC8-SOP8-Flash-Chip-IC-Test-Clips-Socket-Adpter-BIOS-24-25-93-Programmer-Newest/32251460158.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
2016-01-24, 18:42
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 (http://lxr.free-electrons.com/source/drivers/net/wireless/ath/?v=4.0) + the open-ath9k-htc-firmware (https://github.com/qca/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/d/1Ad3AoFaqREGViFPtKFfQzRQvgilnv9e008ltYJlwHG8/edit?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-htc-firmware/issues/82
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
2016-01-24, 22:25
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.
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
2016-01-25, 03:00
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 ?
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/forums/showthread.php?t=851&p=2867&viewfull=1#post2867
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?
I ordered this from ebay:
http://www.ebay.com/itm/331717106581?_trksid=p2060353.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT
aanarchyy
2016-01-26, 02:56
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
2016-01-27, 14:11
I ordered this from ebay:
http://www.ebay.com/itm/331717106581?_trksid=p2060353.m2749.l2649&ssPageName=STRK%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 (http://i.imgur.com/WpH5yoU.png)
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
http://i.imgur.com/toX6Kpi.png
@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?
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?
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
2016-01-28, 00:45
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
2016-01-28, 02:39
@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)
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
2016-01-28, 03:02
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
2016-01-28, 05:55
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.
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/alfa-tx-power-measurement-results-and-some-other-cards-too.5378/
if you need high throughput don't buy any of these 30USD amps that ebay/ali are crowded with.
brunoaduarte
2016-01-31, 17:31
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/alfa-tx-power-measurement-results-and-some-other-cards-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
2016-02-01, 01:06
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?file_id=00508116042330344398
kalifornia
2016-02-01, 08:59
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. :)
so, conclusion is that get more output power as 23dB is impossible from this card, and other region tries are only cosmetics ?
brunoaduarte
2016-02-06, 22:40
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.
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.
kalifornia
2016-02-20, 01:55
I'd like to know also how the testing is going. Either way the awus036nha rocks!!
kalifornia
2016-02-24, 05:39
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
2016-02-27, 06:31
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?file_id=00508116042330344398
aanarchyy
2016-02-27, 16:08
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
2016-02-27, 21:02
I was looking at the AR9271 datasheet (http://www.cqham.ru/forum/attachment.php?attachmentid=155133&d=1383397504) 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?
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)
I ordered up a new 036NHA that I can use for testing and I also got my FlashCAT I2C reader. I tried to read the eeprom without removing it but that did not work. What I did was just connect all wires to the chip (using the clip that came with the programmer) and started the read program.
I did not connect USB power to the board.
Do you power the board first before you read it?
Also what about WP that is default high. How do you lower it to be able to write to the chip?
brunoaduarte
2016-03-26, 17:17
I ordered up a new 036NHA that I can use for testing and I also got my FlashCAT I2C reader. I tried to read the eeprom without removing it but that did not work. What I did was just connect all wires to the chip (using the clip that came with the programmer) and started the read program.
I did not connect USB power to the board.
Do you power the board first before you read it?
Also what about WP that is default high. How do you lower it to be able to write to the chip?
No, i did not power the board... I just connect SDA, SCK and GND, and i can read the chip.
To write, i manually bridge WP to GND using a tweezer and press the keyboard to execute the write script, then remove the tweezer.
FIY: I'm not able to read the chip when WP is connected to GND, so i only do it when i need to write, and then i remove the tweezer from the pins to verify the written data.
No, i did not power the board... I just connect SDA, SCK and GND, and i can read the chip.
To write, i manually bridge WP to GND using a tweezer and press the keyboard to execute the write script, then remove the tweezer.
FIY: I'm not able to read the chip when WP is connected to GND, so i only do it when i need to write, and then i remove the tweezer from the pins to verify the written data.
How does the chip get power if you don't connect VCC or the USB cable to the pcb?
Is your reader powered with 5v or 3.3v?
I still cant get it to work :)
brunoaduarte
2016-03-28, 13:16
How does the chip get power if you don't connect VCC or the USB cable to the pcb?
Is your reader powered with 5v or 3.3v?
I still cant get it to work :)
My reader is a RaspberryPi, so it's 5V.
It's not needed to power the alfa card. Only those 3 lines connected are enough.
My reader is a RaspberryPi, so it's 5V.
It's not needed to power the alfa card. Only those 3 lines connected are enough.
Ok.
Do you send the bit pattern 1010<3 high bit address>0 followed by 8bit low address and then 1010<3 high bit address>1 followed by 8bit low for then to read 1 byte data?
Something like tihis:
i2c_start();
i2c_write((0xa0|(BYTE)(address>>7))&0xfe);
i2c_write(address);
i2c_start();
i2c_write((0xa0|(BYTE)(address>>7))|1);
data=i2c_read(0);
i2c_stop();
And I guess since you don't mention it you don't use any pullups on SDA/SCL.
No, i did not power the board... I just connect SDA, SCK and GND, and i can read the chip.
To write, i manually bridge WP to GND using a tweezer and press the keyboard to execute the write script, then remove the tweezer.
FIY: I'm not able to read the chip when WP is connected to GND, so i only do it when i need to write, and then i remove the tweezer from the pins to verify the written data.
Hi
I've been struggling with openwrt device trying to read the chip from tplink usb adapter, but i2cdetect does not find any. At first i wasn't sure if my connection is good, but even now following your example with GND wire and 10K pullups between SDA/SCL - 3.3V lines does not return anything.
Can you tell us what should be default state of SDA/SCL gpios when proper connection is made and what is the voltage between these two gpios and GND? I've got about 1.40V between SDA and GND and 1.36V between SCL and GND. Both default to low:
gpio-16 (scl ) in lo
gpio-17 (sda ) in lo
serial output use baudrate 19200
ASIC-ROM_1.8
1. 40Mhz
2. post
3. eep chk
[%s+]
patch.offset: 0x%04x, patch.size : 0x%04x
[%s+]
CheckSum: 0x%08x
size: %d bytes
ld_addr: 0x%08x
fun_addr: 0x%08x
copy %d bytes from 0x%08x to 0x%08x[%s-]
[%s-]
4. cold start
5. usb only!!
6. read usb_conf(0x%04x) to ram(0x%08x)
7. usb_hclk rdy
8. download
- custom usb config
- custom usb config
[cUSB_REQ_DOWNLOAD]: 0x%08x, %02x
[cUSB_REQ_DOWNLOAD]: 0x%08x, %02x
[cUSB_REQ_DOWNLOAD]: 0x%08x, %02x
[cUSB_REQ_DOWNLOAD]: 0x%08x, %02x
[cUSB_REQ_DOWNLOAD]: 0x%08x, %02x
[cUSB_REQ_DOWNLOAD]: 0x%08x, %02x
[cUSB_REQ_DOWNLOAD]: 0x%08x, %02x
[cUSB_REQ_DOWNLOAD]: 0x%08x, %02x
[cUSB_REQ_DOWNLOAD]: 0x%08x, %02x
[cUSB_REQ_DOWNLOAD]: 0x%08x, %02x
[cUSB_REQ_DOWNLOAD]: 0x%08x, %02x
[cUSB_REQ_DOWNLOAD]: 0x%08x, %02x
[cUSB_REQ_DOWNLOAD]: 0x%08x, %02x
==>[cUSB_REQ_COMP]: 0x%08x
VendorCmd: DownloadComplete!
5. usb only!!
A_WDT_INIT()
==>cold start<==
ALLOCRAM start 0x50d80c size 106484
Enable Tx Stream mode: 0x30f
USB mode: 0xf
[+++Magpie_init]
[+++VBUF_init(100)]
[+++VBUF_init(100)]
<wlan_pci_probe>: Attaching the driver
<wlan_pci_probe>: Vendor id 0x168c Dev id 0x24
ath_pci_probe 24
ath_hal = 0x00510928
=>[dnQ] 0x0050f288
[ =>[upQ] 0x0050f264
[ =>[hp dnQ] 0x0050f240
[ =>[mp dnQ] 0x0050f21c
[Tgt running
Hi. I was able to achieve 26dBm out of awus036nha, not sure if it is possible to get more, since inside the driver it adds +5 dBm constantly, so it ends up being 31dBm.
And it is unclear for what setting this alfa card is rated for external 30dBm (iwconfig wlanX txpower 30), or to the internal representation including those +5dBm.
Unfortunately I can not make proper RF measurements, so I use WIFI monitor, and I can clearly see that there is a 5-6 dB difference in power level of RF signal from my AP that uses awus036nha. And it was not like that before, when it was stuck at 20 dBm no-matter what power I set above that value.
So basically you do not need to touch EEPROM at all, just regular RegDB patches plus a change in backports-4.4.2-1/drivers/net/wireless/ath/ath9k/eeprom_4k.c (I am using https://www.kernel.org/pub/linux/kernel/projects/backports/stable/v4.4.2/backports-4.4.2-1.tar.xz).
I was reluctant to create a patch since I was not working under any version control, so here is the source snippet I changed:
682 if (test)
683 return;
684
685 for (i = 0; i < Ar5416RateSize; i++){
686 if (ratesArray[i] && (ratesArray[i] < powerLimit))
687 ratesArray[i] = powerLimit;
688
689 ratesArray[i] -= AR5416_PWR_TABLE_OFFSET_DB * 2;
690 printk("ratesArray[%d]=%d\n", i, ratesArray[i]);
691 }
692
693 ENABLE_REGWRITE_BUFFER(ah);
nice, i'll give this a try.
for +5dBm offset consider it being -5dBm actually, probably because of EIRP calculation with default little antenna. i don't care about EIRP, but am looking to get ERP at nominal value
Yes but I do not understand if alfa card itself rated for 30dBm, it means 26dBm in iwconfig txpower or it needs to be 30 there too?
Anyway i am waiting for my USB power meter to come to see actual power drain for different power levels.
Anyway I tested alfa with USB power meter, apparently this power meter interfere somehow with USB, since alfa can only work through it on 20dBm power, anything more and it just enters some weird state where it consume almost no power, I also tested tw-722 and can confirm that its maximum is 23dBm, and weirdly it works ok through power meter. Need to play with FW sources, maybe I can further raise power from there.
Found some info about the checksum here:
http://lxr.free-electrons.com/source/drivers/net/wireless/ath/ath9k/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
rxMask and txMask might stand for number of antennas, since we know 2 chainz should output more power than single chain you could try to set them to 02 and see if the card will give more output power. if it will work you could probably control tx/rx gain ratio by setting only one of the two to 02.
do you have a bash script for checksum fix?
ericderace
2016-06-22, 13:05
For the guys with the custom regdb (regulatory.bin), did you try aireplay-ng --deauth... ? I've edited my regdb to allow above 20dBm under GB, but anything I put above 20dBm causes the driver to crash when I run aireplay-ng --deauth afterwards. AWUS036NHA on Kali rolling.
crypto-dmtized
2016-07-05, 18:22
I was able to change the txpower to 30 dbm by regulatory.bin and CRDA. I have not had any issues using the card at 30 dbm.
Kernel 3.14.35
Awus036nha
before i start real testing i want to make sure this checksum thing won't slow me down again, so, in case the checksum fix method for ART partitions will work, at which offset in dump the checksum is stored?
alternatively, maybe it would not even be necessary to deal with checksum if its code from eeprom_4k.c is removed? someone can verify this?
if (sum != 0xffff || ah->eep_ops->get_eeprom_ver(ah) != AR5416_EEP_VER ||
ah->eep_ops->get_eeprom_rev(ah) < AR5416_EEP_NO_BACK_VER) {
ath_err(common, "Bad EEPROM checksum 0x%x or revision 0x%04x\n",
sum, ah->eep_ops->get_eeprom_ver(ah));
return -EINVAL;
I was looking at the AR9271 datasheet (http://www.cqham.ru/forum/attachment.php?attachmentid=155133&d=1383397504) 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?
no, it means a modified reg.db only will be insufficient to achieve txpower increase. have you noticed "digitally programmed" ? it means this loop power control mechanism will probably require it's settings re-adjustment too.
quick google search returns some info: http://www.virtualbox.org/svn/vbox/trunk/src/VBox/Devices/PC/ipxe/src/drivers/net/ath/ath9k/ar9003_eeprom.h
/* Delta from which to start power to pdadc table */
/* This offset is used in both open loop and closed loop power control
* schemes. In open loop power control, it is not really needed, but for
* the "sake of consistency" it was kept. For certain AP designs, this
* value is overwritten by the value in the flag "pwrTableOffset" just
* before writing the pdadc vs pwr into the chip registers.
*/
1725
got the dump from TL-WN722N, i had to unsolder one side of the chip because ch341a could not read while it was on board. there is some difference when compared to TL-WN721NC, next i will try to write region 0x1ff as i've found in driver it is debug code. later will try it on alfa too.
UPDATE:
debug country code did not work as the driver expected regpair too but removing checksum code from eeprom_4k.c worked and the driver did not complain about mismatch anymore. this can be helpful between multiple tests since you don't have to calculate checksum every time a bit in eeprom is changed.
Hi
I was able to reach almost? full power with both adapters after changing driver property
alfa would connect to network and drop, looked at dmesg to see that the usb resets so i used y-usb cable. The sound coming from the card was also louder.
tl-wn722n worked with single port supply but the wifi rates dropped to 18-36 Mbps and throughput very low at ~2km distance
There should be a way to manually change fixed rate like it is possible with ath9k
CryptoMeth
2016-08-26, 23:24
Any conclusions yet on how to raise the tx power of the locked down AWUS036NHA?
sure there are any conclusions..
in eeprom.h look for AR5416_PWR_TABLE_OFFSET_DB and set it to -11 if your card is locked to 20dBm
Hi,
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)
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.
maybe because driver checks the EEPROM content and find this value as it's limit (firmware limit)?
- 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.
are you sure it is a firmware bug? maybe the card EEPROM allows the driver to set half dbm values up to 23dBm to the firmware but caps the firmware from setting the actual txpower.
take a look at these addresses
18B -> 11 -> 17 (offset at which PA turns off?)
18C -> 12 -> 18 (offset at which PA turns on or offset at which firmware caps further power increase?)
18D -> 15 -> 21 (min power required to enable high power mode?)
18E -> 17 -> 23 (driver limit/max power allowed to be reported to the firmware?)
what do you think?
update:
i've checked with tplink adapter, and if i change 0x147 to 0x18A values to the alfa style ones (30 29 28 27 rather than 30 30 30 30) i get some different reading of txpower in ubiquity utility:
G mode
CH1 600mW
CH2-CH10 1000mw
CH11 800mw
N mode HT20
CH1 600mW
CH2-CH10 1000mW
CH11 600mW
N mode HT40
CH1 126mW
CH2-CH10 300mW
CH11 126mW
next i tried this same EEPROM bin with 18D changed to 16 (22) and 18E changed to 19 (25) and got these results:
G mode
CH1 600mW
CH2-CH10 1000mw
CH11 800mw
N mode HT20
CH1 600mW
CH2-CH10 1000mW
CH11 800mW
N mode HT40
CH1 1000mW
CH2-CH10 1000mW
CH11 1000mW
so maybe these two offsets are only related to lowest/highest channel HT power settings in FCC domain (these power limits were not present with CN country code), but they could also have double meaning as they look convenient for well-known power limit
values starting at 138 also look interesting to change
cameronkali
2016-11-08, 23:32
maybe because driver checks the EEPROM content and find this value as it's limit (firmware limit)?
are you sure it is a firmware bug? maybe the card EEPROM allows the driver to set half dbm values up to 23dBm to the firmware but caps the firmware from setting the actual txpower.
take a look at these addresses
18B -> 11 -> 17 (offset at which PA turns off?)
18C -> 12 -> 18 (offset at which PA turns on or offset at which firmware caps further power increase?)
18D -> 15 -> 21 (min power required to enable high power mode?)
18E -> 17 -> 23 (driver limit/max power allowed to be reported to the firmware?)
what do you think?
update:
i've checked with tplink adapter, and if i change 0x147 to 0x18A values to the alfa style ones (30 29 28 27 rather than 30 30 30 30) i get some different reading of txpower in ubiquity utility:
G mode
CH1 600mW
CH2-CH10 1000mw
CH11 800mw
N mode HT20
CH1 600mW
CH2-CH10 1000mW
CH11 600mW
N mode HT40
CH1 126mW
CH2-CH10 300mW
CH11 126mW
next i tried this same EEPROM bin with 18D changed to 16 (22) and 18E changed to 19 (25) and got these results:
G mode
CH1 600mW
CH2-CH10 1000mw
CH11 800mw
N mode HT20
CH1 600mW
CH2-CH10 1000mW
CH11 800mW
N mode HT40
CH1 1000mW
CH2-CH10 1000mW
CH11 1000mW
so maybe these two offsets are only related to lowest/highest channel HT power settings in FCC domain (these power limits were not present with CN country code), but they could also have double meaning as they look convenient for well-known power limit
values starting at 138 also look interesting to change
mokba, how are you getting past the checksum error? I have tried a few things with no luck, any advice would be appreciated. Thanks.
Check out this thread the OP posted modded drivers as well as a VMWare image with everything ready to go. Tx power is set to 69 dB and the signal is really stronger. I have a 10dB difference compared to original drivers with airbase-ng.
https://hackforums.net/showthread.php?tid=5578652
a wildstyle method... not recommended
10dB stronger signal, very unstable.. @81Mbps rate i measure -66dBm in access point, @90Mbps (which was max in HT mode) -36dBm... legacy mode best rate 36Mbps -33dBm in access point, @24Mbps -65dBm. an obvious throughput regression so i didn't even bother to do iperfs. same conditions, only turned off virtual kali machine, with my current driver 150/150Mbps -43dBm.
i've finished modding tl-wn722n device but my eeprom died in the end, need to get few new chips and re-check backup, otherwise it works stable with 26dBm output @11b rates, 23dBm @11g and 20dBm @11n HT40 rates. same or better (depending on xPA) mod can be applied to alfa eeprom.
Sorry to bring this back. Seems like you guys found a way to raise power of a locked card. Can someone please give more specific instructions on how to do that? I read the whole thread 3 times and still couldn't fully understand :(
zeraoo98
2017-02-17, 18:36
Just found this thread and I'm interested in the topic as well. Can someone who knows this stuff here reply please?
download compat-wireless or backports, do what i wrote in comment 70, build the driver, restart. use as short as possible and HQ USB cable. do some bandwidth/range tests (iperf?) and post results here
zeraoo98
2017-02-23, 21:35
What steps are required in order to get and edit the eeprom.h? What hardware is necessary and is there some soldering going on? I really want to learn how this unlock is done but i just never had any experience with eeprom editing before.
zxcvcxzz[not_a_spammer]
2017-04-28, 06:14
@mokba my awus036h died :( and I remain with awus036nha .. any progress so far with modded divers to increase txpower ?!
Check out this thread the OP posted modded drivers as well as a VMWare image with everything ready to go. Tx power is set to 69 dB and the signal is really stronger. I have a 10dB difference compared to original drivers with airbase-ng.
https://hackforums.net/showthread.php?tid=5578652
^^ Thanks! Unluckily registration is needed there to see the thread. Hackforums.net does not send me an activation code. I asked for resending - without any effect. Edit: With a delay of 30 hours the activation mail(s) arrived.
It would be nice to post the info here!