Page 1 of 2 12 LastLast
Results 1 to 50 of 80

Thread: ALFA AWUS036NHA hacking EEPROM via UART/JTAG

  1. #1

    Arrow 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
    Code:
    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.

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

  3. #3
    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?

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

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

  6. #6
    Quote Originally Posted by mokba View Post
    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).

    Code:
    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)

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

  8. #8
    Quote Originally Posted by mokba View Post
    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
    Code:
         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.
    Last edited by brunoaduarte; 2016-01-10 at 14:52.

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

    TL-WN721NC.bin.zip

  10. #10
    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
    Last edited by brunoaduarte; 2016-01-20 at 02:47. Reason: Found regulatory bytes

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

    ath9k/common-init.c
    Code:
    #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.
    Last edited by brunoaduarte; 2016-01-18 at 14:54.

  12. #12
    Join Date
    2014-Mar
    Posts
    163
    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 .

  13. #13
    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?

  14. #14
    Join Date
    2016-Jan
    Posts
    11
    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

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

    Code:
    [   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)

  16. #16
    Join Date
    2016-Jan
    Posts
    11
    Gah!
    There is a checksum in there.

    Code:
    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
    Last edited by mrflash; 2016-01-24 at 09:55.

  17. #17
    Join Date
    2016-Jan
    Posts
    11
    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

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

    Code:
    	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
    Last edited by mrflash; 2016-01-24 at 12:53.

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

  19. #19
    Join Date
    2016-Jan
    Posts
    11
    Quote Originally Posted by mokba View Post
    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.

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

    Code:
    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

    Code:
    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
    Last edited by brunoaduarte; 2016-01-25 at 03:02.

  21. #21
    Join Date
    2016-Jan
    Posts
    11
    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)

    Code:
    [   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?

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

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

  24. #24
    Quote Originally Posted by mokba View Post
    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 ?
    Last edited by brunoaduarte; 2016-01-25 at 03:09.

  25. #25
    Quote Originally Posted by brunoaduarte View Post
    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
    Last edited by mokba; 2016-01-25 at 21:10.

  26. #26
    Quote Originally Posted by aanarchyy View Post
    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?

  27. #27
    Join Date
    2016-Jan
    Posts
    11

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

  29. #29
    Quote Originally Posted by mrflash View Post
    Cool device ! I've just bought one for me too...

    Quote Originally Posted by aanarchyy View Post
    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

    Last edited by brunoaduarte; 2016-01-27 at 18:01.

  30. #30
    @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?

  31. #31
    Join Date
    2016-Jan
    Posts
    11
    Quote Originally Posted by aanarchyy View Post
    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?

  32. #32
    Join Date
    2016-Jan
    Posts
    11
    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
    Last edited by mrflash; 2016-01-27 at 20:34.

  33. #33
    Quote Originally Posted by mrflash View Post
    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.

    Quote Originally Posted by mrflash View Post
    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.

  34. #34
    Quote Originally Posted by mokba View Post
    @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.

    Code:
    country US: DFS-FCC
    	(2402 - 2472 @ 40), (30)
    country BO is not good on newer regulatory files...

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

  35. #35
    Quote Originally Posted by brunoaduarte View Post
    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.

  36. #36
    Quote Originally Posted by mokba View Post
    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
    Last edited by brunoaduarte; 2016-01-28 at 03:23.

  37. #37
    Join Date
    2016-Jan
    Posts
    14
    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.

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

  39. #39
    Quote Originally Posted by mokba View Post
    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

  40. #40
    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
    Last edited by aanarchyy; 2016-02-01 at 01:10.

  41. #41
    Join Date
    2016-Jan
    Posts
    14
    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.

  42. #42
    Join Date
    2016-Feb
    Posts
    2
    so, conclusion is that get more output power as 23dB is impossible from this card, and other region tries are only cosmetics ?

  43. #43
    Quote Originally Posted by paulik View Post
    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.

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

  45. #45
    Join Date
    2014-Sep
    Posts
    2
    Any news on this?

  46. #46
    Join Date
    2016-Jan
    Posts
    14
    I'd like to know also how the testing is going. Either way the awus036nha rocks!!

  47. #47
    Join Date
    2016-Jan
    Posts
    14
    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)

  48. #48
    Join Date
    2016-Jan
    Posts
    14
    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


    Quote Originally Posted by aanarchyy View Post
    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

  49. #49
    Quote Originally Posted by kalifornia View Post
    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

  50. #50
    Join Date
    2016-Feb
    Posts
    8
    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?

Similar Threads

  1. Alfa AWUS036NHA issues
    By Hillbilly123 in forum TroubleShooting Archive
    Replies: 0
    Last Post: 2022-02-03, 14:01
  2. ALFA AWUS036NHA Disconnects after a while
    By Cuboy in forum TroubleShooting Archive
    Replies: 2
    Last Post: 2017-08-08, 19:43
  3. Alfa AWUS036NHA NEED HELP!!
    By ea0977 in forum How-To Archive
    Replies: 1
    Last Post: 2015-11-12, 18:21
  4. Alfa awus036nha
    By johnsmith in forum General Archive
    Replies: 3
    Last Post: 2015-01-07, 18:35

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •