OpenWrt Forum Archive

Topic: WNR1000v2: some success! (need advice on board-specific init)

The content of this topic has been archived between 16 Apr 2018 and 18 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

I also used a Mac a few times (MBA + Apple USB Ethernet adapter), but I didn't get the transfer timeout. In fact, the only time when I had an issue was with Kali Linux using Wicd as network manager as it decided that the connection was lost (it wasn't) and it started to connect to my wireless instead. I got a corrupted firmware, but the device booted in failsafe mode and I could recover it easily.

I guess you could try disabling all the network interfaces except for the ethernet as the network manager may try to be a little bit more helpful than it should be. I don't think it's a firewall issue as the default from OS X only blocks incoming connections, but it wouldn't hurt to disable it for a flash.

Thanks for the quick reply. I've had some limited success, with the router now accepting some data from the computer. However, partially through the process to send (or receive?) seems to timeout after it has sent "block=13". See below.

Any other advice? Do I need to unlock the router via Telnet first? (As described in

I will disable the other network interfaces on the Mac, just in case.

tftp> put /Users/jp/Downloads/openwrt-ar71xx-generic-wnr1000v2-vc-squashfs-factory.img 
sent WRQ <file=/Users/jp/Downloads/openwrt-ar71xx-generic-wnr1000v2-vc-squashfs-factory.img, mode=octet>
received ACK <block=0>
sent DATA <block=1, 512 bytes>
received ACK <block=1>
sent DATA <block=2, 512 bytes>
sent DATA <block=2, 512 bytes>
received ACK <block=1>
discarded 1 packets
sent DATA <block=2, 512 bytes>
sent DATA <block=2, 512 bytes>
received ACK <block=2>
sent DATA <block=3, 512 bytes>
received ACK <block=3>
sent DATA <block=4, 512 bytes>
received ACK <block=4>
sent DATA <block=5, 512 bytes>
received ACK <block=5>
sent DATA <block=6, 512 bytes>
received ACK <block=6>
sent DATA <block=7, 512 bytes>
received ACK <block=7>
sent DATA <block=8, 512 bytes>
received ACK <block=8>
sent DATA <block=9, 512 bytes>
received ACK <block=9>
sent DATA <block=10, 512 bytes>
received ACK <block=10>
sent DATA <block=11, 512 bytes>
received ACK <block=11>
sent DATA <block=12, 512 bytes>
received ACK <block=12>
sent DATA <block=13, 512 bytes>
received ACK <block=12>
sent DATA <block=13, 512 bytes>
sent DATA <block=13, 512 bytes>
sent DATA <block=13, 512 bytes>
sent DATA <block=13, 512 bytes>
sent DATA <block=13, 512 bytes>
Transfer timed out. 


I downgraded to Netgear Firmware WNR1000v2-VC-V1.0.0.3NA, then retried the tftp upload. Worked like a charm!

Note, the firmware that I had been running on the 1000v2-VC was WNR1000v2-VC-V1.1.2.56. If a user is also running this identical firmware, they may encounter the same tftp issues that I did.

Now running  CHAOS CALMER (Bleeding Edge, r44455) on this WNR1000v2-VC.

How do you incorproate your WNR1000V2 patch into Image Generator for OpenWRT? When I use Imager Generator currently there is no WNR1000V2 bin file created when using the "Minimal" profile.

I can compile it with no problem, but I'd like to be able to use the Image Generator. Thanks

(Last edited by jlpapple on 24 Feb 2015, 00:49)

TBH, I did't use the Image Generator. I simply used WNR2000v3/WNR612v2 as template for adding the devices and I simply assume that all the bits are in place. I'll need to see how it works, but I don't know when I'm going to be able to do it.

Wow! Glad to see this thread perked up. Having real OpenWRT support might keep these devices out of the landfill. smile

I'm pretty happy with it. It's been running like a champ with my hacked up image since I last posted. I wish I had known enough to contribute a fully working patch when I got it running. Sadly, once I had time to work on the thing again, I couldn't find my img file or the buildroot I had used.

It did hiccup last week: I managed to trigger a bug similar to this one.

I had a Minecraft server running on a machine behind the AP and I was spamming creepers. Apparently lots of small packets makes the radio furious. Although on a second thought, I SSH'd into the thing to reset it, so obviously the radio was working...maybe the switch crashed then? I'll have to do more testing to find out. I distinctly remember getting the "transmit queue" error though.

Thanks for all your hard work SaltwaterC!

(Last edited by supertanker on 29 Mar 2015, 01:03)

Does the Wi-Fi work?


Apologies for bring up a semi dead thread, but wanted to share my findings:

ar7240: (accessable via /sys/class/gpio)
[x] 0 = Internet LED (Amber) [Active low]
[x] 1 = Power LED (Amber) [Active low]
[ ] 2 = 
[ ] 3 = 
[ ] 4 = 
[ ] 5 = 
[x] 6 = Lan Port 1 (Amber) [Active low]
[x] 7 = Lan Port 2 (Amber) [Active low]
[x] 8 = Lan Port 3 (Amber) [Active low]
[ ] 9 = 
[ ] 10 = 
[x] 11 = Power LED (Green) [Active low]
[x] 12 = Lan Port 4 (Amber) [Active low]
[x] 13 = Lan Port 1 (Green) [Active low]
[x] 14 = Lan Port 2 (Green) [Active low]
[x] 15 = Lan Port 3 (Green) [Active low]
[x] 16 = Lan Port 4 (Green) [Active low]
[x] 17 = Internet LED (Green) [Active low]

ar9285: (accessable via /sys/kernel/debug/ieee80211/phy0/ath9k/(regidx=0x4048,regval))
bits 12 to 21 of regval are gpio 0 to 9
[ ] 0 = 
[x] 1 = Wireless LED [Active high]
[ ] 2 = 
[ ] 3 = 
[ ] 4 = 
[x] 5 = WPS LED [Active low]
[x] 6 = WPS Button [Pressed low]
[x] 7 = Reset Button [Pressed low]
[x] 8 = Wireless Toggle Button [Pressed low]
[ ] 9 = 

It seems the gpio available in /sys/devices/gpio does not cover everything, and some is available in the ath9k itself, boxes marked with x are confirmed. As you can probably guess I have one of these routers, the VC version, and I'm willing to test specific stuff if wanted.

EDIT: After fiddling with 0x18040028 (GPIO_FUNCTION_1, 0x8040028 in ath9k's regidx file) I managed to get all of the LED's to turn on and be changeable, added all other LAN Port gpio's and Internet LED green gpio

(Last edited by gamax92 on 30 May 2015, 09:17)

gamax92 wrote:

Apologies for bring up a semi dead thread

Nah, I can't say it's actually dead.

gamax92 wrote:

added all other LAN Port gpio's and Internet LED green gpio

Thanks for the work you put in to reveal how GPIO actually works on these devices. By "added" you mean there's an actual patch for OpenWrt? If there's none, I could take a stab at this, but unfortunately the device is quite far away for the moment and I won't get my hands on my kit sooner than end of July.

I've been playing with this for a few hours now, and I finally figured out my issue. Thought I'd post to help someone with the same issue.

I have two WNR1000v2 routers that I've collected @ garage sales recently, and have been unable to do anything use with them until now.

I was trying to use tftp, as instructed in the gist here:  with no success. From everything I can observe, what I have is a pair of WNR1000v2 routers, with no mention whatsoever of "VC". The problem is that I let the auto check updater  update them to version (I think), and everything in the gist mentions v1.1.x.x...

what I would get was basically the same output as posted by jlpapple above. finally I found a post somewhere that mentioned doing a 30-30-30 reset, and then trying the tftp put operation. That would get me to uploading the firmware, but it would fail every time, with the green light blinking..

I ended up googling a bit, and finding v1.2.2.56 of the firmware. I figured I'd see if that would upload, and then figure out the difference between the two, and do some hacking... what I failed to notice (thank you a few trader joe's 9% beers) was tt v1.2.2.256 firmware had a "VC" in it.. but it worked..

so... hoping that no fuzzy little kittens would actually die, I decided to try and tftp the "-vc" version of the firmware... and it worked!

I now have two working routers running barrier breaker.

hope this helps someone.

U-Boot 1.1.4 (Sep  3 2009 - 20:04:48)

WNR1000v2 (ar7240) U-boot dni7 V0.8
#### TAP VALUE 1 = 9, 2 = 9
32 MB
Top of RAM usable for U-Boot at: 82000000
Reserving 269k for U-Boot at: 81fbc000
Reserving 192k for malloc() at: 81f8c000
Reserving 44 Bytes for Board Info at: 81f8bfd4
Reserving 36 Bytes for Global Data at: 81f8bfb0
Reserving 128k for boot params() at: 81f6bfb0
Stack Pointer at: 81f6bf98
Now running in RAM - U-Boot at: 81fbc000
id read 0x100000ff
flash size 4194304, sector count = 64
Flash:  4 MB
In:    serial
Out:   serial
Err:   serial
Net:   ag7240_enet_initialize...
No valid address in Flash. Using fixed address
No valid address in Flash. Using fixed address
eth0: up
: cfg1 0xf cfg2 0x7214їH
eth1: up
ATHRS26: resetting s26
ATHRS26: s26 resэСЃdone

Nothing happens...
why :(

(Last edited by shadowmaster63 on 5 Aug 2015, 21:04)

looks like boot failed before copuld:

Verifying Checksum ... OK
### SQUASHFS loading 'image/uImage' to 0x80800000
### SQUASHFS load complete: 708303 bytes loaded to 0x80800000
## Booting image at 80800000 ...

so it can not read/load something called uImage.......missing / damaged
if you read this post from the beginning, that is a very bad news....

(Last edited by jenom on 14 Oct 2015, 20:16)

I have also a WNR1000v2...trying to put OpenWrt...downloaded all available files "openwrt-ar71xx-generic-wnr1000v2-"
from "latest"+"trunk"+"chaos_calm"
Collected Netgears firmwares:
Upgrades from WebInterface failed with any combinations of the above files: rejected with BAD IMAGE message

Going to run Windoz "TelnetEnable.exe" later today, and try to do "tptp" transfer
Is the command  "tftp -i PUT openwrt-xxxx.img" ?

Noticed, that holding RESET button at boot does not change the color of PW light, so maybe no "tftp " at boot ?


(Last edited by jenom on 14 Oct 2015, 20:33)


I will start by apologizing if the answer has already been asked. I also apologize for the quality of my English. I am French and I use Google translation to understand you.

I retrieved a Netgear WNR1000v2 router. I tried to flasher it once. Photo of patience, I blocked this one.

I managed with the recovery tool to reset the latest firmware. Since then, I can not make new attempts. When I try to install the latest version of OpenWRT, the mistletoe tells me: "your * .img file is not good."

Thank you for your help


Up :-)

The discussion might have continued from here.