Thank your helpful answer. I understand now.
There are regulatory limit and hardware limit. I already replaced the regulatory.bin, the tx power still cannot be set more than 17 dBm because of some hardware limit.

Even I compile a build of OpenWrt with CONFIG_ATH_USER_REGD=y, the hardware limit still cannot be fixed.
Today, I have installed a Ubuntu in VirtualBox and downloaded the source of OpenWrt and made a build.
But I have no plan to flash the build, because it will not solve the problem.

Where does the setting of hardware limit for TX power be saved?
Is it technically feasible that I overwrite the ART data by using the data from G300NH that has no TX power 17dBm restriction?

root@OpenWrt:/proc# cat mtd
dev:    size   erasesize  name
mtd0: 00040000 00020000 "u-boot"
mtd1: 00020000 00020000 "u-boot-env"
mtd2: 00100000 00020000 "kernel"
mtd3: 01e60000 00020000 "rootfs"
mtd4: 01ce0000 00020000 "rootfs_data"
mtd5: 00020000 00020000 "user_property"
mtd6: 00020000 00020000 "art"
mtd7: 01f60000 00020000 "firmware"

root@OpenWrt:/# hexdump -v /dev/mtd6ro

Following webpage uses dd command to backup the mtd.
http://www.dd-wrt.com/phpBB2/viewtopic.php?p=552159
https://forum.openwrt.org/viewtopic.php?pid=101427

I tried following command to dump the art data to a file, the file size is 128Kbytes.
root@OpenWrt:/# dd if=/dev/mtd6ro of=/mnt/mtd6ro_art.bin

Can anybody provde a dump of your G300NH's ART?
I can compare and try to overwrite my G300NH's ART.

(Last edited by jetsun on 7 Jan 2012, 15:57)

http://luci.subsignal.org/~jow/wzr-hp-g300nh-art.bin

Thank you very much for provide the file.

Unfortunately,it does not work.
1.The boot does not continue because of BAD CRC of EEPROM, I need press Ctrl+C in serial console to make it boot.
2.The TX Power hardware limit is still 17dBm.

Maybe my guess is wrong, the hardware limit setting data of TX Power is not in art partition.
---------------------------------------
In order to write ART by using mtd, I modified some source of openwrt according to following web.
Change the art partition writable.
http://wiki.openwrt.org/toh/tp-link/tl-wr1043nd

root@OpenWrt:~# dd if=/tmp/wzr-hp-g300nh-art.bin of=/dev/mtd6
dd: can't open '/dev/mtd6': Permission denied

root@OpenWrt:~# mtd write /tmp/wzr-hp-g300nh-art.bin art
Could not open mtd device: art
Can't open device for writing!

root@OpenWrt:~# mtd unlock art
Could not open mtd device: art
Could not open mtd device: art
-----------------------------------------------------------
Following is the steps of replace ART:
root@OpenWrt:/# mtd unlock art
Unlocking art ...
root@OpenWrt:/# cd /tmp
root@OpenWrt:/tmp# wget http://192.168.1.221/wzr-hp-g300nh-art.bin
Connecting to 192.168.1.221 (192.168.1.221:80)
wzr-hp-g300nh-art.bi 100% |*******************************|   128k  0:00:00 ETA
root@OpenWrt:/tmp# mtd -r write wzr-hp-g300nh-art.bin art
Unlocking art ...
Writing from wzr-hp-g300nh-art.bin to art ...
Rebooting ...

In the boot,there is some error message in serial console.
TftpServer Timeout;
no file was loaded.
Bad CRC of EEPROM!!
# LED(0x2) Blink[2] (Please press 'Ctrl+c' to stop)

The system can boot after pressing Ctrl+c.
In the ssh of OpenWrt, the tx power still cannot be set more than 17dBm.
At last, I gave up and have to restore the ART to the original, and the CRC error of EEPROM gone.

I think that the CRC error is coming from the bootloader instead of OpenWrt, since there is a value buf_crc=5228EE27 (in my router) in u-boot-env. You could try to find out how that is calculated and replace it. My EEPROM is limited to 17 dBm as well, so I guess it's of no use to you.

Yes, the CRC error is from U-boot.

Following is the env from U-Boot.
ar7100> printenv
bootargs=console=ttyS0,115200 root=31:03 rootfstype=jffs2 init=/sbin/init mtdpar
ts=ar9100-nor0:256k(u-boot),128k(u-boot-env),1024k(uImage),31104k(rootfs),128k@3
2640k(ART),128k@32512k(properties)
bootcmd=bootm 0xbe060000
bootdelay=4
baudrate=115200
ethaddr=02:AA:BB:CC:DD:1A
tmp_ram=81F00000
tmp_bottom=83F00000
fw_eaddr=BE060000 BFFDFFFF
uboot_eaddr=BE000000 BE03FFFF
u_fw=erase $fw_eaddr; cp.b $fileaddr BE060000 $filesize; bootm BE060000;
ut_fw=tftp $tmp_ram firmware.bin; erase $fw_eaddr; cp.b $fileaddr BE060000 $file
size; bootm BE060000;
ut_uboot=tftp $tmp_ram u-boot.bin; protect off $uboot_eaddr; erase $uboot_eaddr;
cp.b $fileaddr BE000000 $filesize;
melco_id=RD_BB08011
uboot_ethaddr=02:AA:BB:CC:DD:1A
DEF-p_wireless_ath0_11bg-authmode=psk
DEF-p_wireless_ath0_11bg-crypto=tkip+aes
DEF-p_wireless_ath0_11bg-authmode_ex=mixed-psk
buf_ver=1.07
build_date=Dec 21 2009 - 10:37:11
buf_crc=420F2B9B
hw_rev=0
pincode=*********
custom_id=0
DEF-p_wireless_ath0_11bg-wpapsk=********
accept_open_rt_fmt=1
filesize=149f0fc
fileaddr=81F00000
ipaddr=192.168.11.1
serverip=192.168.11.2
region=AP
tftp_wait=4
stdin=serial
stdout=serial
stderr=serial
loadaddr=81F00000
ethact=eth0

Environment size: 1176/131068 bytes
ar7100> setenv region US
ar7100> saveenv
Saving Environment to Flash...
Protect off BE040000 ... BE05FFFF
Un-Protecting sectors 2..2 in bank 1
Un-Protected 1 sectors
Erasing Flash...Erase Flash from 0xbe040000 to 0xbe05ffff in Bank # 1 First 0x2
last 0x2
100%
Erased 1 sectors
Writing to Flash...
100%
done
Protecting sectors 2..2 in bank 1
Protected 1 sectors
ar7100>

The most recent trunk (as of 15 January 2012) appears to break the LAN Vlan for V1 hardware.

Please see https://dev.openwrt.org/ticket/10793 for more details.

After tftp flash, WAN comes up as expected (can see it pick up a dhcp lease from another server).  LAN does not provide dhcp services, and default ip is not pingable from any LAN port.

When sysupgrading from backfire, password settings seem to be lost as well.

The last few snapshots (in February and March) I tried all refused to boot on my A2 A0 model.  Has anyone flashed recent snapshots successfully on this hardware?

Not a recent snapshot, but the following has been working great (and stable) since January:

Buffalo WZR-HP-G300NH

Firmware Version:
OpenWrt Firmware Attitude Adjustment (r29561) / LuCI Trunk (trunk+svn8105)

Also noticed approx 15% increase in wifi range over the DD-WRT (2011-12-20 r18024).

Is yours an A2 AO?

Yes - A2 A0.

Do you know where I can find the Openwrt firmware r29561?

Thanks,
C.

The version I used was found in this thread posted by bcmalloy (mediafire links):
https://forum.openwrt.org/viewtopic.php … 22#p151422

(Last edited by loopy123 on 5 Apr 2012, 22:07)

New to open-WRT, forgive me.

I'm trying to change some of the environment variables in "u-boot-env" on my new Buffalo WZR-HP-G300NH version 1. I've installed the package uboot-env and configured fw_env.config as below.

# MTD device name    Device offset    Env. size    Flash sector size    Number of sectors
/dev/mtd1                0x0000        0x20000

As I understand it (apparently incorrectly) I should now have access to the commands fw_printenv, fw_setenv, fw_saveenv. Unfortunately only fw_printenv is available.

root@OpenWrt:~# ls /usr/sbin
brctl             hostapd           iwlist            uhttpd
chroot            iptables          iwpriv            upnpd
crond             iptables-restore  ntpd              wpa_supplicant
dnsmasq           iptables-save     pppd              wpad
dropbear          iw                px5g
fw_printenv       iwconfig          telnetd
root@OpenWrt:~# 
root@OpenWrt:~# fw_printenv
bootargs=console=ttyS0,115200 root=31:03 rootfstype=jffs2 init=/sbin/init mtdparts=ar9100-nor0:256k(u-boot),128k(u-boot-env),1024k(uImage),31104k(rootfs),128k@32640k(ART),128k@32512k(properties)
bootcmd=bootm 0xbe060000
bootdelay=4
baudrate=115200
ethaddr=02:AA:BB:CC:DD:1A
ipaddr=192.168.11.1
serverip=192.168.11.2
tmp_ram=81F00000
tmp_bottom=83F00000
fw_eaddr=BE060000 BFFDFFFF
uboot_eaddr=BE000000 BE03FFFF
u_fw=erase $fw_eaddr; cp.b $fileaddr BE060000 $filesize; bootm BE060000;
ut_fw=tftp $tmp_ram firmware.bin; erase $fw_eaddr; cp.b $fileaddr BE060000 $filesize; bootm BE060000;
ut_uboot=tftp $tmp_ram u-boot.bin; protect off $uboot_eaddr; erase $uboot_eaddr; cp.b $fileaddr BE000000 $filesize;
melco_id=RD_BB08011
tftp_wait=4
uboot_ethaddr=02:AA:BB:CC:DD:1A
DEF-p_wireless_ath0_11bg-authmode=psk
DEF-p_wireless_ath0_11bg-crypto=tkip+aes
DEF-p_wireless_ath0_11bg-authmode_ex=mixed-psk
buf_ver=1.07
build_date=Dec 21 2009 - 10:37:11
buf_crc=38EA54F9
hw_rev=0
pincode=40881096
custom_id=0
DEF-p_wireless_ath0_11bg-wpapsk=c8uu0jymxks97
region=EU
accept_open_rt_fmt=1
root@OpenWrt:~# fw_setenv
-ash: fw_setenv: not found

Where is fw_setenv? Do I need to make the mtd1 writeable first and if so how do I do that?

I'm using firmware version Attitude Adjustment (r30919) / LuCI Trunk (trunk+svn8349). Should I flash an older build? Maybe 10.03?

Any help will be greatly appreciated. Thanks

(Last edited by Okneun on 6 Apr 2012, 12:20)

I just noticed that Gargoyle 1.5.4 was recently released and its notes specifically states:

"Bumps OpenWrt version to latest Backfire version for latest wireless fixes and support of multiple switch models in Buffalo WZR-HP-G300NH routers"

My A2 A0 is running great on this build (I had tried 1.5.3 and it didn't work).  btw, Gargoyle 1.5.4 corresponds with OpenWRT revision r30752.

How do I install this firmware?  My unit is at least a year old.  It's been all but useless, N wireless drops or locks up.  Their locked down firmware loader is extremely annoying.  I will never purchase another Buffalo product.  A shame, because I've used and instructed many others to purchase their older routers.  This unit, their firmware bugs and locked down FW process makes it useless.

I've tried using tftp, without it ever responding.  It responds to DD-WRT .enc files from Buffalo's site.  I've used this process several times after failed attempts to use the mtd flashing method.  It's clear their tftp flashing process responds only to .enc files.

I've tried using mtd from within Buffalo's DD-WRT software using squashfs and jffs files.  In both cases, the mtd command shows it erasing and writing blocks, it drops my ssh connection and reboots.  However, it never actually boots.  Instead the diag LED lights up solid.  I've waited an hour for it to reset and reformat itself.  The diag LED remains solid, even if power cycled after an hour.

I'd turn off the uboot enc format requirement, but Buffalo's DD-WRT firmware doesn't include a uboot env tool.

Nothing works.  Their firmware isn't stable (N connectivity) and doesn't use jffs in a sane manner.  I also don't understand or wish to use the old style NVRAM based admin.  The current OpenWrt jffs overlay appears to be easy to use, but I can not figure out how to load it.

Buffalo's DD-WRT indicates my unit uses the rb style LAN hardware.  The tag on the side of the unit contains "A2 F0B".

I returned my first unit to Buffalo (RMA) due to the constant dropping of N wireless connections.  I received this unit as a replacement, it doesn't work any better.  After years of using and helping others use their WHR-HP-G54 product this product is a complete train wreak.  It has never worked correctly.

LizardMan--the instructions at http://wiki.openwrt.org/toh/buffalo/wzr-hp-g300h in the 'OEM installation using the TFTP method' section will work if your device is not otherwise damaged.  One thing I'm not sure of is which MAC address you should set with the arp command.  On the few occasions I've actually tftp'd an image to my G300H, I've had to try a few different things.  I believe I use the SSID on the label.  Also, not sure about the A2 F0B, but I've got the A2 A0 and I need to use trunk that I get at http://downloads.openwrt.org/snapshots/trunk/ar71xx/.  The A2 A0 has the rtl8366rb switch so Backfire doesn't work.

If you think your device is physically ok, I'd definitely take the time screwing around with tftp to get OpenWRT on it.  Mine works great, and once you've got it going, you can use sysupgrade images to do subsequent updates.  I install luci and load the .bin right through the web interface.

The latest official Buffalo DD-WRT loads fine using tftp.  The kernel probes show this unit uses the rb style LAN switch hardware.  However, the 10.03.1 FW should support it.  I just can't find a way to load it.  Buffalo seems to have locked down these A2 F0B units.  It rejects all attempts to use anything but their .enc files.

I've tried the tftp method:

Set static arp for the MAC used by the uboot firmware
Set computer IP addr to 192.168.11.2
Power up router
Send FW using tftp in binary mode

If I use the 15MB *.enc FW file from the Buffalo site (latest Alpha code on their site) it works fine.  I've flashed using this method several times.  It's the only way to recover from attempts to use the mtd flash update method.

If I use a 3 to 4 MB OpenWrt squashfs or jffs file the router never responds to tftp write request probes.  It just sits there.  It ignores tftp, unless it's a .enc file.  If I understand the last 16 pages of this thread correctly, this is because the uboot FW checks for the a header in the enc file.  I could turn that check off, if I had access to the uboot env tool, but it's not included in the DD-WRT version (.enc file) available from the Buffalo site.  Chicken and egg problem.

Method two:
Load the Buffalo .enc DD-WRT FW
Transfer a copy of sysupgrade OpenWrt to /tmp on router
Write file to flash using the mtd command as shown on the OpenWrt site for this router
"mtd -r write OpenWrt-firmware-file linux'
Wait while new FW is written and router reboots.

I've tried this many times.  It seems to work, except the router reboots to a Diag LED on solid and never turns off.  I've waited an hour for it initialize and reformat jffs, but nothing happens.  It just sits there with the green LED on (power symbol), red diag LED on, and an LED at the bottom (blue?).

After 30min to 60min I've power cycled it, it goes back in to the same diag LED solid state.  The only way to recover is use the official Buffalo .enc DD-WRT image with tftp.  This works every time.  I've used the tftp transfer method with their FW file many times.  It's rock solid, but only if I use their file.

I don't want to use DD-WRT on this router.  I've used DD-WRT for years on many routers (WRT-54GS, WRT-54G and WHR-HP-G54).  However, I've never found a version of DD-WRT that is stable on this router in N mode, never.  It locks up and/or drops wireless clients.

I've used DD-WRT for years.  It's not in current development, and attempts to use the large flash space in this router with ipkg (no opkg) fail with a file system R/O error.  I find the endless mass of NVRAM variables admin process a mess.  The OpenWrt overlay file system is nice!

I'm moving away from DD-WRT in general.  I've loaded OpenWrt on WHR-HP-G54 units, it works but leaves little flash/jffs space for loading additional programs (IPv6 tunnels, IPv6 utils and VPN code).  This router has far more flash and RAM, but I haven't found a way to load OpenWrt on it, because Buffalo locked uboot down to prevent loading and/or using it.

I don't understand why the mtd method doesn't work.  I've tried it several times with both squashfs and jffs files.  I found a slightly different mtd command on another board (adds -e linux), it erases the linux FW area first, before writing.  Using either mtd method the diag LED comes on solid and the router never reboots.  It's like the uboot code looks for a signature in the linux area before jumping to it, and only the Buffalo blessed FW images have this signature.  Their FW files are much larger.  Maybe they use a large file to initialize and write a signature across the entire flash area, a signature their uboot code looks for, before it jumps to the FW in flash.

This product has never worked correctly.  From day 0 it has dropped or locked up if setup in N mode.  The latest Buffalo DD-WRT FW works if I disable N mode.  However, it's an N router and that FW will not allow me to load additional tools.  I purchased this unit for N, its large flash and RAM for progs/utils and gigabit interfaces.  Only the gigabit interfaces actually work, N doesn't and the extra flash space is useless with their DD-WRT.

I sent my first unit back to Buffalo (RMA) because it locked hard (unresponsive even on the wired interfaces) if in N mode.  They sent this replacement a long time ago.  It too locked up in N mode, so I ran DD-WRT in G mode.  A few weeks ago I loaded their latest alpha version, which works a bit better, but drops N connections.  It doesn't completely lock up, but it's not stable in N mode either.

I need to find a way to break out of Buffalo's locked down uboot code.  It rejects all tftp transfers that aren't .enc files and rejects non Buffalo FW written to flash with mtd.

Why?  This will only drive people to stop purchasing their products.  It's not like their FW actually works.  This unit has been a major pain from day one, and has never worked correctly.  Their WHR-HP-G54 units worked so well.  I have several of them and helped people use DD-WRT on them for years.

LizardMan, sorry I missed your comment before about the particular hardware revision that you have being locked.  Maybe someone else will have some suggestions.  As for 10.03.1 supporting the rtl8366rb switch, I'm not so sure.  Something in the release notes for one of the 10.03.1 release candidates made me think it would, but it never worked for me.  A build of Attitude Adjustment from the link I included above worked after the first successful tftp.

Does anyone have a copy of the uboot env update tool I could run under Buffalo's blessed DD-WRT to turn off the uboot locks?  Previous posts seem to indicate it's possible to change a few variables to disable tftp .enc checks and extend the tftp time-out window.

Does anyone know if their uboot code looks for a signature in the linux flash area before jumping to that code while booting?  If so, I'd need to turn that check off as well.  I've repeatedly tried using the mtd flashing method within Buffalo's DD-WRT without any success.

I'm stunned.  My 300NH has sat for hours with a solid red LED after another attempt at the mtd flash method early this morning.  I started to reflash Buffalo's DD-WRT using tftp when I remembered I'd downloaded gargoyle.  It would only take a few minutes to try it.  I wasn't expecting it to accept the gargoyle FW, but tried it anyway.

Gargoyle loaded using tftp on the first attempt.  It just worked.  I used the exactly the same process, including computer and cables I used trying to load various OpenWrt files.  I was shocked when tftp started transferring.  Then the diag LED started blinking, rather than remaining on steady.

I'm using gargoyle to connect to the Net to post this.  It's in N mode, but hasn't run long enough to determine how stable it is yet.

I didn't find a uboot env tool in gargoyle either.

(Last edited by LizardMan on 19 Apr 2012, 04:31)

if you bought your router in the EU then its locked to EU regulatory domain, so it cannot exceed the 20dbm eirp, so thats 17dbm power + antenna gain to stay within regulations.

the restriction is not in the firmware, thats why the firmware builds for both EU and USA routers are the same. the restriction is in ROM (READ ONLY MEMORY) which has the region code burned in it and cannot be changed since its read only.

some preliminary testing seems to indicate that its not rom based region lockout, but from the factory, the amplifiers are disabled from factory limiting max output to 17dbm.

After over 24 hours of continuous use (streaming data) in N mode gargoyle hasn't dropped or locked up.  No other FW has ever worked this well.  A single error message related to the N drop/lockup problem was logged, just one.

The latest Buffalo blessed DD-WRT generated streams of them, plus dropped clients.  Previous versions, both from Buffalo's site and DD-WRT locked up within minutes, or a best an hour or two.

The error is:
ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020 DMADBG_7=0x000286c0
ath: Could not stop RX, we could be confusing the DMA engine when we start RX up

Any idea what causes this error message?  HW bug, or driver issue?

Posted too soon.  Two hours ago it dropped the client.

The client logged errors stating no response from AP.

After several attempts it finally was able to reconnect to the 300NH, without rebooting either end.
On the 300NH I found only one error was in the log from before the drop.  No new errors were logged during the event that caused the client to drop.

Another client drop.

Logged on the client:
No probe response from AP 00:24:a5:XX:XX:XX after 500ms, disconnecting.

Logged on 300HN:
ath: Failed to stop TX DMA, queues=0x004!
ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020 DMADBG_7=0x00006020
ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020 DMADBG_7=0x00006020
ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020 DMADBG_7=0x00026020
ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020 DMADBG_7=0x00006020
ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020 DMADBG_7=0x00006020
ath: Could not stop RX, we could be confusing the DMA engine when we start RX up

This time a very log string of these messages.