OpenWrt Forum Archive

Topic: Netgear WNR2000v4

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


Altough there is already a general WNR2000 topic I decided to create a new one for the WNR2000v4, as the hardware of this device is quite different.

I tried to get openwrt running by applying this patch here:
I also followed the last 2 pages of this topic (concerning the wnr2000v4): … 79&p=9

The above patch works just fine, however only the initramfs works. I cannot apply the squashfs-sysupgrade image. I get the following error when trying to boot:

## Booting image at 9f040000 ...                                                                                                           
   Image Name:   MIPS OpenWrt Linux-3.10.36                                                                                                 
   Created:      2014-05-04  20:22:17 UTC                                                                                                   
   Image Type:   MIPS Linux Unknown Image (uncompressed)                                                                                   
   Data Size:    1041408 Bytes = 1017 kB                                                                                                   
   Load Address: bf070000                                                                                                                   
   Entry Point:  bf070000                                                                                                                   
   Verifying Checksum ... OK                                                                                                               
Wrong Image Type for bootm command                                                                                                         
Trying eth1

Bukington and rpsoft (openwrt forum members) both provided a sysupgrade image that works just fine:
You can get it here if you want: … pgrade.bin

## Booting image at 9f040000 ...                                                                                                                       
   Image Name:   MIPS OpenWrt Linux-3.10.21                                                                                                           
   Created:      2013-12-26   2:00:03 UTC                                                                                                             
   Image Type:   MIPS Linux Kernel Image (lzma compressed)                                                                                             
   Data Size:    1024623 Bytes = 1000.6 kB                                                                                                             
   Load Address: 80060000                                                                                                                             
   Entry Point:  80060000                                                                                                                             
   Verifying Checksum ... OK                                                                                                                           
   Uncompressing Kernel Image ... OK                                                                                                                   
No initrd                                                                                                                                             
## Transferring control to Linux (at address 80060000) ...                                                                                             
## Giving linux memsize in bytes, 33554432

I think the problem is the image generation. I think this here does not apply to the wnr2000v4 (target/linux/ar71xx/image/Makefile):

define Image/Build/Netgear/buildkernel
        $(call MkuImageLzma,$(2),$(3) $(4),-d20,,-M $(5))
        -rm -rf $(KDIR_TMP)/$(2)
        mkdir -p $(KDIR_TMP)/$(2)/image
        cat $(KDIR_TMP)/vmlinux-$(2).uImage > $(KDIR_TMP)/$(2)/image/uImage
        $(STAGING_DIR_HOST)/bin/mksquashfs-lzma \
                $(KDIR_TMP)/$(2) $(KDIR_TMP)/vmlinux-$(2).uImage.squashfs.tmp1 \
                -noappend -root-owned -be -b 65536
        ( \
                cat $(KDIR_TMP)/vmlinux-$(2).uImage.squashfs.tmp1; \
                dd if=/dev/zero bs=1k count=1 \
        ) > $(KDIR_TMP)/vmlinux-$(2).uImage.squashfs.tmp2
        mkimage -A mips -O linux -T filesystem -C none -M $(5) \
                -a 0xbf070000 -e 0xbf070000 \
                -n 'MIPS OpenWrt Linux-$(LINUX_VERSION)' \
                -d $(KDIR_TMP)/vmlinux-$(2).uImage.squashfs.tmp2 \

I am wondering how bukington and respectively rpsoft managed to generate the correct squashfs file.
Does anyone know how this could be done?

Thanks in advance,

Hi franz,
I to am trying to get openwrt running on my wnr2000v4. How exactly did you apply the patch that you linked to?
When i copy OpenWrt-Devel-ar71xx-Add-platform-machine-support-for-the-WNR2000v4.patch into /openwrt/trunk/ and run

git apply OpenWrt-Devel-ar71xx-Add-platform-machine-support-for-the-WNR2000v4.patch

i recieve this error message:

OpenWrt-Devel-ar71xx-Add-platform-machine-support-for-the-WNR2000v4.patch:55: trailing whitespace.
 *  under the terms of the GNU General Public License version 2 as 
OpenWrt-Devel-ar71xx-Add-platform-machine-support-for-the-WNR2000v4.patch:150: trailing whitespace.
OpenWrt-Devel-ar71xx-Add-platform-machine-support-for-the-WNR2000v4.patch:152: trailing whitespace.
fatal: corrupt patch at line 206

(Last edited by Growell on 13 Jun 2014, 19:44)

Hi Growell!

Sorry for the late response. The patch above is buggy, I couldn't apply it either I just edited the changes manually to get it to work. However the patch is not complete it doesn't work only with these changes. There were several additional changes necessary to get the device to work. I can provide a full patch if you want, I will try to upload it here in the evening (when I get away from work).


Thanks for responding Franz,

It would be much appreciated if you post that patch as manually applying the changes was my next move. Once that is applied can you successfully connect to the internet? Right now I am able to flash only sysupdgrade.bin files, whether it is one that I generate or the one you linked to and find the following relevant lines during bootup (using serial):

[   11.990000] ath: Invalid EEPROM contents
[   11.990000] ath9k ar934x_wmac: failed to initialize device
[   12.000000] ath9k: probe of ar934x_wmac failed with error -22
[   17.720000] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[   17.720000] device eth0 entered promiscuous mode
[   17.740000] IPv6: ADDRCONF(NETDEV_UP): br-lan: link is not ready
[   17.780000] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[   18.320000] eth0: link up (1000Mbps/Full duplex)
[   18.320000] br-lan: port 1(eth0) entered forwarding state
[   18.330000] br-lan: port 1(eth0) entered forwarding state
[   18.330000] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   18.440000] IPv6: ADDRCONF(NETDEV_CHANGE): br-lan: link becomes ready
[   20.150000] eth1: link up (100Mbps/Full duplex)
[   20.150000] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[   20.330000] br-lan: port 1(eth0) entered forwarding state

[  180.820000] eth0: link down
[  180.820000] br-lan: port 1(eth0) entered disabled state

Also are you using fuhry's u-boot environment? I had no luck applying that, but was able to change the environment variables with

setenv bootcmd bootn 0x9f040000

Hi Growell!

Until now I only tested the ethernet connection which is working just fine. I am sure wifi is working as well, however it might be necessary to install some wifi related packages to make it fully work.

Concerning the sysupgrade: Did you already manage to generate your own sysupgrade file? If yes, how did you do that? My changeset is a pretty ugly hack and at the moment I only generated the ramfs and the sysupgrade files.

I do not use fuhry's u-boot environment, as you already mentioned this cmd is adequate to disable the netgear firmware check.

setenv bootcmd bootm 0x9f040000

At the moment I cannot even communicate with the router via ethernet unless I boot into failsafe and even then all I can do is telnet in. As for generating a sysupgrade  file I followed the instructions on this page to set up a buildroot environment. Summed up:

mkdir ~/openwrt
svn co svn://
cd ~/openwrt/trunk
./scripts/feeds update -a
./scripts/feeds install -a
make menuconfig
#Configure the package that you want installed now#

then your generated sysupgrade file would be located at for example:


However I might add that I haven't gotten a functional one working yet as I am very new to this whole process.

(Last edited by Growell on 18 Jun 2014, 18:52)

OK. It's clear that this doesn't work. You cannot just take any sysupgrade file which was created. The sysupgrade must match your device. As the WNR2000v4 is not supported at the moment you'll not find a suitable sysupgrade for your device.

You can try with this patch:

You can apply it like this (from the root of openwrt)

patch -p1 < wnr2000v4.patch

Now you have to run make menuconfig and choose the new device NETGEAR WNR2000v4 (under Target Profile)
Then just run:
make V=s

You'll find the sysupgrade image within the bin folder - it is called "testfile" - sorry for that smile I was testing it and did not rename it to the right name.

With this changes the WNR2000v4 should work with the newest openwrt, however my changes are quite ugly maybe someone can beautify this and put it to mainline - Unfortunately I've no time for this now...


(Last edited by franz.flasch on 18 Jun 2014, 20:54)

Yeah i figured that out...  I just tried this on the trunk build and the patch appeared to apply but when I run

make menuconfig

"NETGEAR WNR2000v4" does not appear. Any ideas?

thanks for the patch!

**Scratch that i got it to show**
for the record it will not show up if you use the ./scripts/feeds line that i posted above

(Last edited by Growell on 18 Jun 2014, 21:33)

So I currently am able to create custom images and flash them onto the WNR2000v4. The process below is the method that I am using. However this is still very much experimental so follow at your own risk. To my knowledge the only way to get this to work is by using a serial cable (Somebody feel free to prove me wrong). I am NOT! responsible if you manage to brick your router by following this.

The process is as follows:

  1. Remove Firmware Check

  2. Setup Buildroot and Create a Custom Image

  3. Flash Custom Image

  4. Basic Setup

Remove Firmware Check

From the serial console during boot up you should see:

Hit any key to stop autoboot:  1

So press any button...
You know you made it in time when you see:


Next enter

setenv bootcmd bootm 0x9f040000
Setup Buildroot and Create a Custom Image

I followed this wiki page but to sum it up:

mkdir ~/openwrt
cd ~/openwrt
svn co svn://
cd trunk

Next I apply the patch that Franz so kindly provided here.
Here's another link to the same patch except it creates a more descriptive image name.

patch -p1 < ~/Downloads/wnr2000v4.patch

After the patch is applied then we can install feeds (optional)

./scripts/feeds update -a
./scripts/feeds install -a

Now configure the packages that you want installed and sit back and wait for it to compile

make menuconfig
make V=s
Flash Custom Image

Once its done compiling you will find your image at ~/openwrt/trunk/bin/openwrt-ar71xx-wnr2000v4-sysupgrade.bin
Note!!! if you you use the patch that Franz provided the file will be called testfile

If you don't want to setup a Buildroot you can use this basic image I've created.

In order to get the image onto the router I set up a tftp server although you could use a different approach. I will skip setting up the tftp server.

mv ~/openwrt/trunk/bin/openwrt-ar71xx-wnr2000v4-sysupgrade.bin /tftpboot

From the serial console or telnet (follow link to enable telnet access)
I assume your computers ip address is and your tftp server is setup on port 69.
WARNING! unplugging your router while it is flashing the firmware is like playing with fire. Unless you are prepared to get burned (ie brick your router) Don't unplug it!!!

cd /tmp
tftp -g -r openwrt-ar71xx-wnr2000v4-sysupgrade.bin 69
mtd -r -f write openwrt-ar71xx-wnr2000v4-sysupgrade.bin firmware
Basic Setup

Ethernet should work out of the box but wireless needs to be enabled by editing /etc/config/wireless
By default the contents of /etc/config/wireless are:

config wifi-device  radio0
        option type     mac80211
        option channel  11
        option hwmode   11g
        option path     'platform/ar934x_wmac'
        option htmode   HT20
        option disabled 1

config wifi-iface
        option device   radio0
        option network  lan
        option mode     ap
        option ssid     OpenWrt
        option encryption none

To enable wireless change to:

config wifi-device  radio0
        option type     mac80211
        option channel  11
        option hwmode   11g
        option path     'platform/ar934x_wmac'
        option htmode   HT20
        option disabled 0

config wifi-iface
        option device   radio0
        option network  lan
        option mode     ap
        option ssid     OpenWrt
        option encryption none

Hopefully this helps someone out!

(Last edited by Growell on 24 Jun 2014, 23:58)

Hi Growell!

Thanks for the nice tutorial! I only fear that this patch won't apply anymore in the future if there are many changes on these files. I hope someone takes pity on the WNR2000v4 and puts this on mainline, otherwise we have to re-modify the sources again and again to keep the WNR2000v4 up to date.

Anyway, thank you for this tutorial!


Hi !

I've (finally) upload my patch on github ( … 866e11b072) and also start the process to upstream it : … 29094.html
I hope I'll manage to get it merged.

I'm running this setup since a while now (almost a year) without any issues. It still requires physical serial access for the first flash. In theory it should be possible to build a bootstrap image flashable from official firmware but I didn't manage to make a 3.10 kernel image lighter than 832kb (needed for stock uboot to boot the image).... Maybe I'll try to do something with Netgear opensource package.

Good news, patch has been merged.

Not sure I ever mentionned it, but I managed to get USB working as it's supported by AR9341.
I power it with 3,3v which seems to be enough for an USB key (currently experimenting extroot on it).

Hi bukington!

I recently tested it with the latest version of openwrt. Works perfectly, thanks!

How do you connect your USB key? Are there any solderpads which can be used for the USB port?


Just realized that it doesn't work that perfectly... Please check the lan ports - none of them works, also the leds are wrong configured. With the patch which I've provided above everything seems to work just fine. It seems we have to compare the mach-files and check what is wrong.

franz.flasch wrote:

Just realized that it doesn't work that perfectly... Please check the lan ports - none of them works, also the leds are wrong configured. With the patch which I've provided above everything seems to work just fine. It seems we have to compare the mach-files and check what is wrong.

Hi Franz,

I'm surprised you have such issues.... Seems to me that leds are OK.... Same for LAN ports.
I'll try to do some testing just to be sure.

Maybe what you're experiencing is related to some issues I see since some weeks in trunk (not related to
my changes I guess), which leads to some incorrect behavior (sometimes lan ports stop to work), and I see some
kernel message error:
[224041.010000] eth1: tx timeout
[224041.010000] eth1: link down

Regarding USB, data pins needs to be soldered on Motherboard:
AR9341 pins

By chance on our routeur they're easily accessible as TP29-TP30. For GND and +5 I'v used GND and +3.3 from serial

Hi bukington!

Thanks for the answer! I expierenced issues with the leds of the lan ports. Example: When I plugin the ethernet cable to the lanport 1 the orange led of another lanport was turned on - not sure which lan port it was, I can retest it if you want. Furthermore none of the lanports actually worked I am not sure but it could be that the errors you mentioned above appeared.

I replaced the mach file with the mach file which I've provided in the patch above - and now the lan ports work perfectly. Only some of the leds are not configured properly.

If I've got the time I will retest your solution and check what's the problem with the machfile.


PS: Thanks for the hint with the USB pins - That's great, with this mod I can extend the memory which is very limited on this device! smile

(Last edited by franz.flasch on 3 Dec 2014, 14:12)


Extroot is working fine for me on USB key, that's a good news given the space available on board smile
Thanks if you can patch the leds... should be some confusion is my mach file.
I saw that we used different gpio for leds (green vs ambers).

bukington wrote:


Extroot is working fine for me on USB key, that's a good news given the space available on board smile
Thanks if you can patch the leds... should be some confusion is my mach file.
I saw that we used different gpio for leds (green vs ambers).

I am installing OpenWrt for the first time and having some problems. I first tried the build linked in #9, but I couldn't get the new package system to work with it. Everything else seemed to work though. When I tried to compile my own it first failed when i used svn, and franz's patch didn't work with either svn or git. I managed to get a booting build when I used git, but there was no working networking whatsoever.
Could you upload a working compiled build?

(Last edited by detector42 on 3 Jan 2015, 17:04)

Hi detector42!

It seems we ran into the same problems with the "official" WNR2000v4 support. The network didn't work either when I tested it. However if you exchange the file mach-wnr2000v4 with the one I provided in my patch the networking support is working fine. You can try it if you want.


That's really weird, I need to find some time to dig this but I'm not sure to be able to reproduce the issue.....

franz.flasch wrote:

Hi detector42!

It seems we ran into the same problems with the "official" WNR2000v4 support. The network didn't work either when I tested it. However if you exchange the file mach-wnr2000v4 with the one I provided in my patch the networking support is working fine. You can try it if you want.


Hi Franz,

(Sorry for my poor English since I am not a native English speaker.)

I'm a newbie in openwrt. I've just purchased a wnr2000v4 and want to replace its original firmware with openwrt so that it could pass the 802.1x authentication of our school's network. I've met some problems posted below. I'm wondering if you may help.....

I've met the EXACTLY same problem with your post #16 while my first try following Growell's guide except that I used a compiled image provided here.

In my second try, I replaced the firmware with the basic image provided by Growell in #9. The lan ports worked fine. In short, I think I've met the same problem with you in opposite way. Are there two versions of wnr2000v4 that their lan ports does not share the same address? What's the difference between the two patches?

Another problem is that during my second try using Growell's image, my router got reset whenever I reboot it. Every time I reboot it, changes I made and modules I installed disappeared as though I have never done so. Why this happened? Were there anything missed in Growell's guide?

Thanks for help!

(Last edited by lcy92 on 1 Apr 2015, 14:30)

important discoveries

1. Go into U-Boot prompt and update the env variable AFTER you flash the device.. not before. use the 'boot' cmd to proceed forward.

2. In order to subvert the device not saving its settings after reboot, run the command 'mtd erase rootfs_data' then reboot. Afterwards, settings should save. like they do for me.

All of my experience was based on Growell's "basic" image. My wireless and ethernet works as directed in Growell's tutorial.

3. I later got ambitious and tried flashing the WNR200v4 image hosted at … x/generic/ I flashed in the same way as flashing the basic image.. but this image, the LEDs were messed up.. Wrong led on ethernet and wrong colors, and the ethernet jacks did not function, so I could not repair.. I will have to re-install stock firmware via FACTORY reset.

4. Netgear is the only firmware I can use to gain rootshell via UDP telnetenable hack.. I modified the python telnetenable.. I am writing my own wiki with details.. Coming soon

5. growell's Basic Open-wrt image cannot be flashed via FACTORY RESET mode [by holding factory reset until serial shows the factory reset message, continue holding button down as you send image via TFTP, release button after TFTP transfers start ACKing] because of Checksum failures.. So the image must be flashed via root shell in stock netgear firmware. HOW to make a firmware that passes the checksum??

6. Accessing U-boot 'terminal' by stopping auto-boot functions fine, but when using the serial terminal to access both the stock netgear firmware or new open-wrt firmware's root linux console, there are issues with the input. At first I thought it was my fault, but like I said, U-Boot functions perfectly with its keyboard input, but the open-wrt is mangling my input, making it EXTREMELY difficult to enter commands without them failing, because it is inserting weird characters...
I have a lot of questions. I'm new to open-wrt + compiling kernel manually.

1. for the D+ D- USB lines, do any resistors need to be connected? How is the 3.3V working for VCC, must it not be 5V?

2. In make menuconfig, do you include the bootloader U-Boot, or is this bootloader automatically already present in the Router.

3. I am right now compiling a kernel with U-boot attached and Luci, because I want the web interface.. I set filesystem to JFFS2 like the basic image was... I hope it will work.. I think the image has to be < 4MB because of flash limitation.. Anything else? If Growell is reading this, could you please detail your setup of the basic image, so I can repeat the setup and include Luci in my own configuration.

4. The compilation was successful but I do not see a sysupgrade image anywhere, and I can't figure out how to generate one...

I want to ask more questions, about VLAN.. In Open-WRT VLAN documentation, there are port numbers, usually 0-5, and 4 is unused [says the documentation]. However in WNR200v4, the ports in the switch /etc/config/network are 0 1 2 3 4.  I am trying to figure how they correspond to actual router port numbers as displayed, and also the mythical CPU port.

From my dabbling with swconfig, the port 0 is the CPU port, because it is always listed as connected even when no ports are connected on the router.. port 1-4 seem to be the ethernet switch, and the WAN port does not seem to be included. It may be Port 5.. And why is this not included in the Switch configuration?? In the open-wrt docs, port 5 is often included... Please correct me, I am new to ALL of this..

Compiling kernel
if I change options in make menuconfig, can I just do a make after that, or must I make clean first?? Perhaps another option?

Anyone have advice how to do this properly in WNR2000v4? I imagine it would make testing changes to the kernel easier / faster.. A sort of possible solution has been offered at ,

My Desired Network Configuration
The purpose I am doing this is because I want a special network.
1 ethernet must be segmented from the other 3 ethernet + wlan. I want to use VLAN to avoid IP spoofing subnet hacks, rather than subnetting and firewall trafficking. I hope someone understands and can guide me.. I'm very new and I have broken my networking many times already LOL.

(Last edited by bazz on 13 Apr 2015, 17:39)

Thanks for your discoveries! It seems we are in the same trouble flashing the "newest" image. Could you please tell me how can I recover my changes on U-boot env?;oe=55D9076D

Welcome to my longest post yet. Shoutz to Bukington for the USB pic, Growell and Franz for their great contributions.

For the most part I'm going to be shining light on things, but I am still a n00b and need help sometimes, so please consider reading about my questions if you are an expert. My questions will be at the bottom of the article in its own section.

Long story short I've figured out a lot and I'm working on compiling the information on my wiki, and later disseminating it to this thread.
Here are some things I've accomplished since:

  • How To Compile a Latest, Working Image

  • How to Fix the LED issue

  • How to Achieve my Desire VLAN Setup

  • How to Successully mod with USB flash drive ExtRoot

Bare in mind, I am a novice so I am all-encompassing all the knowledge.
I realize I may be iterating some information that can be found All over the web, wiki, and forums, so I have brought it to you here in one format.

New Firmware Images smile

It just dawned on me, there's no reason to use these images over Growell's basic image. At first, I thought to produce images so that you could use opkg.. but the thing is that the snapshot git moves so fast, that they can easily become incompatible again.. So the best way is to compile yourself, and then add as modules <M> any new packages you want later in make menuconfig.. those will get compiled as IPK when you make.. and you can send them to router for opkg install..

So first off, the impression that was made upon this thread is that the latest trunk is mangled (bad LEDS, ethernet broken), and that by applyng franz's patch it will be fixed again. Since I've done all this and more, let me elaborate.

Since a month or more had passed since the last post, I decided to try the trunk image, or trunk compile stock, and see if progress had been made. both still behaved badly, same issues as talked about. Bad ethernet, bad LEDS.

So I patched the mach-file with franz's patch.
Not only should the mach-file be patched, but also since ./target/linux/ar71xx/base-files/etc/uci-defaults/01_leds has been changed to use wnr2000v4 led prefix, his patch must also reflect that, or vice-versa. So I've done all of that, I'm learning how to create a patchfile, will update.

Non-USB image that is already outdated hehe
Yes it's not as good as USB image but still great -- if I could find some help on the green LEDS you will see me talking about later, I need help on that.

This image is outdated because I made the USB mod, and have done a lot of work with the USB mod I don't look back.. Also there are discoveries I made after USB that's why only the USB has the new discoveries present and not this older-compiled image.. I hope it still serves your purposes well. We are cutting-edge after all smile

If you do not want to read my long tutorial, please consider downloading this no-USB version of the latest openwrt, however it lacks the latest bugfixes I have found smile. openwrt-ar71xx-generic-wnr2000v4-squashfs-sysupgrade.bin.nousb

Your WLAN LED will not work for instance, Power LED doesn't work, and not all buttons supported.. Consider this temporary that you decide to use it. although I have fixed this issue privately. I can still help you patch at least the LEDS yourself. Buttons will require kernel patching, or when I release new image whatever. Please follow my instructions exactly, trust me. If you don't trust me it isn't going to work tongue.
Edit /etc/config/system -- change all sysfs entries that say 'wnr2000-v4' to say 'netgear' instead'. Save the file and do /etc/init.d/leds reload should work, if not, try reboot.

USB enabled image that is brand-spanking new
Only use this image if you are planning on doing USB mod, because it includes all the kernel modules required for it, and hence takes up more space. It also includes my latest patches. All buttons should be supported [untested] and all LEDS can be controlled/triggered except green LAN/WAN ones cannot yet be controlled [working on it, not sure if it's possible].. The thing about the green LEDS is that they seem to be controlled externally somehow. So they automatically blink on activity even tho they are not configured in the BSP (board support package).

Note: I could not add usbutils to this image [lsusb], because it made the image too big such that JFFS2 would not save.. It must be able to save in order to save an EXTROOT configuration.

Note on Flashing my images
If you flash these images from Stock Netgear [other versions untested], you may have to use the -f flag in mtd command.. otherwise it complains "image verification failed" or something.. but the image is legit and it flashes successfully when forced.

mtd -f -r write bazz_img.bin firmware

Note about sysupgrade image being SquashFS
-- If you are n00b like me, do not be scared of SquashFS, it doesn't mean that your Linux installation is read-only, its just the firmware image, it will later use JFFS2 automatically.

If you want a USB-enabled image, with all LEDS working, you are in luck. It is my latest image so has all the bug fixes.

How to Unbrick

I am not talking about any brick.. I mean if you flashed the firmware, not the bootloader, like from Growell's tutorial:

mtd -r write blabla.img firmware

In case you have bricked your router this way, there is one way I am familiar with to restore it -- Restore factory image. It is the last solution I post. First are some untested solutions I assume you will skip but I am interested in.

Of course, you could use the serial terminal shell right? But mine did not function properly, so I could not :[. So these are the other solutions you can try.

Untested: Boot into FailSafe mode
You do this over serial line when it asks you to press keys at bootup. We want to see if we can get ethernet working.

Untested: Boot from RamDisk
I have not yet learned this, but if a small,reliable,checksum passing RamDisk unbrick image could be made, it is a faster recovery than the next method, which is the only method I know.

Tested: Restore Factory image capable of Telnet Root
From my experience, I can only get telnetenable working with NetGear firmware Download the img.

Must have tftp client. ie. sudo apt-get install tftp

You can try doing this without serial terminal, just wait a long time wink holding the button down. But it's advocated that you work towards getting your serial hooked up if you don't want headaches down the road.

This is not a script, I want you to open TFTP and execute the following commands. lines starting with # are just comments from me to you, do not write them in.

# execute following commands in tftp
rexmt 1
# no connection has been made yet. ;)

# Now, holding down the factory reset button on wnr2000v4, turn it on, watch serial console, 
# you will see eventually it start flashing "Factory Reset" -- keep the button held still! 
# wait until you see it say a different thing and it will also say the TFTPD has started listening.
# now you can run this next command
put bla-bla-insurance-person-come-help.bin
# you put the netgear firmware

Now that's done, you should see a bunch of ACK messages and data transfers.
NOTE: this method cannot be used to transfer openWrt images because they fail a Checksum check thing.

The image will be flashed and we will have stock firmware.. Now we must use UDP telnetenable.
Here is the one I use:
EXPERT NOTE: this is a mod of the TCP version and I did not modify the extended password parameter of UDP version.. but the stock router password is 'password' which fits in the new model anyways..

import sys
import socket
import array
from optparse import OptionParser
from Crypto.Cipher import Blowfish
from Crypto.Hash import MD5


# The version of Blowfish supplied for the telenetenable.c implementation
# assumes Big-Endian data, but the code does nothing to convert the
# little-endian stuff it's getting on intel to Big-Endian
# So, since Crypto.Cipher.Blowfish seems to assume native endianness, we need
# to byteswap our buffer before and after encrypting it
# This helper does the byteswapping on the string buffer
def ByteSwap(data):
  a = array.array('i')
  if(a.itemsize < 4):
    a = array.array('L')
  if(a.itemsize != 4):
    print "Need a type that is 4 bytes on your platform so we can fix the data!"

  return a.tostring()

def GeneratePayload(mac, username, password=""):
  # Pad the input correctly
  assert(len(mac) < 0x10)
  just_mac = mac.ljust(0x10, "\x00")

  assert(len(username) <= 0x10)
  just_username = username.ljust(0x10, "\x00")
  assert(len(password) <= 0x10)
  just_password = password.ljust(0x10, "\x00")

  cleartext = (just_mac + just_username + just_password).ljust(0x70, '\x00')
  md5_key =

  payload = ByteSwap((md5_key + cleartext).ljust(0x80, "\x00"))
  secret_key = "AMBIT_TELNET_ENABLE+" + password

  return ByteSwap(, 1).encrypt(payload))

def SendPayload(ip, payload):
  for res in socket.getaddrinfo(ip, TELNET_PORT, socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_IP):
    af, socktype, proto, canonname, sa = res
      s = socket.socket(af, socktype, proto)
    except socket.error, msg:
      s = None

    except socket.error, msg:
      s= None

  if s is None:
    print "Could not connect to '%s:%d'" % (ip, TELNET_PORT)
    print "Sent telnet enable payload to '%s:%d'" % (ip, TELNET_PORT)
def main():
  args = sys.argv[1:]
  if len(args) < 3 or len(args) > 4:
    print "usage: python <ip> <mac> <username> [<password>]"

  ip = args[0]
  mac = args[1]
  username = args[2]

  password = ""
  if len(args) == 4:
    password = args[3]

  payload = GeneratePayload(mac, username, password)
  SendPayload(ip, payload)


Now, with router on, and ethernet cable plugged from this computer, recommended ethernet port 1, shouldn't matter tho.. we run the following:

python [Router MAC] admin password

Replace [ROUTER MAC] with your router's MAC address. This can easily be found over in your router's main Advanced Configuration page. The MAC must all uppercase and you MUST remove the ':' ie. 12:12:12:AA:BB:CC becomes 121212AABBCC

Next, try telnet - and you should be inside an OpenWrt root shell.. You can resume your image flashing procedure now smile Same as before, which we hosted a TFTP server on our machine as given in Growell's tutorial on page 1 of this thread.

Getting by with Growell's Basic Img

What happened with using Growell's image, and what might happen with mine as they age, is that opkg packages from internet became too different to be compatible.. This section is an archival purpose demonstrating pitfalls I ran into trying to get opkg to work on Growell's image, and you might face these problems with mine if you try to use mine in the coming months after posting.. When in doubt learn to build the source yourself. Fortunately I show you how now.

Even if you adapt your /etc/opkg.conf to point to the new repositories.. Here's how that would have looked [I do NOT recommend trying this, this is for archival purpose only:

src/gz base
src/gz luci
src/gz management
src/gz packages
src/gz routing
src/gz telephony

But although this will enable opkg update to work, I cannot tell you how new packages will install well with it.. Because I initially decided to upgrade my installed packages, which is a BIG NONO on OpenWrt..  It bricked my router effectively.. You can find more info about Why on wiki, but opkg is risky when doing remote installaton of new packages, due to possible mismatch in kernel properties or LibC stuff. Can someone shed light on proper way to rely on opkg?

Anyways, due to the problems I ran into with opkg, and because I want to learn about compiling kernels and modifying BSP (board support package), I opted to do some kernel hacking. Also, I figured opkg would work with a new compile [which it does, I effectively installed Luci and usbutils, granted I needed USB mod to have the memory smile ]

Current Trunk Shortcomings

We've already identified how the current trunk image [or even self-compiled from trunk image] is faulty. For me and at least one other, the result is ethernet does not work, and the LEDs are incorrect. Since ethernet is not working and firmware starts with no wireless, the device is effectively bricked, unless maybe your serial terminal root shell works, unlike me, then maybe you can save it without modifying kernel. But that's not curing the root problem anyways, a bug in the source code, yeah?

The last place this thread left off, was that franz.flasch mentioned the cure, that we can the router working again if we replace the current trunk's mach file with his old patch (hosted in Growell's tutorial) .. So what I did was take out just the mach file from the patch and made a machfile from it. This can be done because the patch for the mach file, is really the creation of a machfile.. Once I replaced the trunk mach file, my router was working again, but with caveats. [I figured out the fix too smile]

The problems you will see is that LEDs function properly, IIRC, except the WLAN will never light up.. IIRC sometimes power light is off as well.. Anyways the biggest issue was the WLAN.. But also, Franz's mach file doesn't have USB registration, and it also lacks full button support.

I will later identify how I combine the best of both worlds to create my own mach file comprised of both the trunk and Franz's mach files, so that I get the best mach file to date. WARNING: I have now modded my router to have USB port, and I am no longer sure if USB registration function in mach file firmware init causes issues with non-USB-router / kernel.

OK SO let's begin first by identifying, how can we build our own sysupgrade image from openwrt source?

How To Compile a Latest, Working Image

First off, Barrier Breaker is too old, there is no wnr2000v4 code in the release. So we must go from current trunk.

I will not explain any more on patchin the mach file. I will give important locations.
If you want to edit the mach file before attempting compilation, it will be at


if you want to modify after you've compiled once, you must change instead the


Take into account how your version numbers may be different. Also, I have buildroot take care of everything. I am not using external toolchain, take care the possibility that the paths might be different.

Next step is the Feeds, although Growell listed this as optional. I always do it -- it enables me to see all packages in make menuconfig. It does not actually install anything to kernel. Do the feeds like in Growell's tutorial.
I noticed a lot of

WARNING: No feed for package 'libyaml' found, maybe it's already part of the standard packages?
WARNING: No feed for package 'libedit' found, maybe it's already part of the standard packages?
WARNING: No feed for package 'sctp' found, maybe it's already part of the standard packages?

But I never had any problems...


make menuconfig

Make sure Target SYstem is Atheros 7XXX/9XXX
Subtarget: Generic
Target Profile: Netgear WNR2000V4
Target Images: SquashFS

I don't recall changing anything else, but you're free to have a gander smile

Warning: the filesize of the image is very important.. If it's too big, JFFS2 won't be able to save on reboot, which will be bad... I had a case where 3407876 bytes was too big but 3604484 fit and kept JFFS2 functioning.. Mind you I used that image to mount a USB stick 4GB so big_smile... So if you just didn't change anything the image should be about 3145732 bytes, which is fine size.

When it's done successfully navigate to bin/ar71xx and that's where the sysupgrade image will be, among others.. I don't know how to use the other images, although I'd love to learn what's the point of making a JFFS2 image if it already works with the Squash one.. anyways, you only need the sysupgrade image wink

You should be able to do the rest with all of the material laid out in this thread. [not post] see Growell's tutorial page 1

How to Fix the LED issue

For all the people wondering why is the LEDs messed up, and why do they work in franz patch? It took a lot of work and I cannot explain everything -- please understand I've only been working with OpenWrt for 4 days.

There are 2 different LED issues I've identified

  • Incorrect Amber LAN LEDS [Fixed]
    See Wiki [TBA]

  • Mysterious External control of Green segment of the LAN / WAN LEDS

I've discovered that all of the green LEDS on the board besides the WPS and POWER, seem to be controlled outside of /etc/config/system -- but from where??

They are not controlled in /etc/config/system, and they are no longer part of gpio_led structure. I cannot identify how they are controlled, but whomever submitted latest trunk knows this because they removed the green LEDS from the code as well.. However their LAN1-4 code is buggy and I fixed. The issue lies in incorrect port settings in /etc/config/system. I am still not sure why latest official code has no ethernet working out-of-box. But when I use Franz's mach, and correct the LED settings. I am golden.

I want to make patches and submit to official. How to do this?

How to Achieve my Desired VLAN Setup

Warning I'm super n00b at this. I hope someone can guide me.

I have an almost perfect setup, made possible with the graphical assistance of Luci. But I have further questions on it, so I am aiming to make a new thread asking for help. I can speak about what I've done so far conceptually.

let me see here. I have it so Ethernet 1-3 and WLAN is on its own 'network' for lack of better terms, and Ethernet 4 is on its own VLAN. I wonder if IP spoofing makes it possible to transcend the network boundaries, but I cannot answer myself..

The initial VLAN configuration on wnr2000v4 openWrt is Vlan1 and ports 0-4 are all present and untagged.
port 0 is the elusive CPU port which I don't fully understand, but must be present on all VLANs, I think... (I don't actually know this). Ports 1-4 are respectively the real ethernet jack ports 1-4.
So I made another VLAN and since it has CPU port on more than one VLAN, cpu must now be tagged on both VLANS.
now, VLAN 1 is 0t 1 2 3
VLAN2 is 0t 4

Initial Net  config is 'lan' that WLAN0 and bridged with ETH1 (the ethernet switch). Eth0 is WAN FYI.
What I do is instead, bridge WLAN0 with ETH1.1.
I make a new network I call 'elan' stands for ethernetLAN. This network is on a different subnet, so IP is as an example. Whereas the
'lan' IP is
I set physical interface to eth1.2
any other settings are inspired from 'lan' like netmask

I create a new firewall zone "elan" and set covered network to "elan" -- not sure what I'm doing, for instance if I should have one zone cover both the elan and lan.. but probably not I speculate. Allow forward to WAN, but not the other way around.. [why does this work?] doesn't wan traffic need to come into these interfaces?? I'm n00b..

In the circumstance my Ethernet 4 unit gets hacked.. I do not want to to be able to reach Luci or SSH of the router.. I also do not want gateways to respond to ping..
So I add rules to reject traffic on TCP from ELAN to any router,
I also reject ICMP from ELAN to any router.

Question -- what is the difference between Device (input) and Any Zone (forward)

At this point, my configuration does seem to work. I've tested with multiple computers, over wireless and ethernet. All results I am aiming for succeed. For example,
Ethernet computers and wireless are on same subnet.
Ethernet4 is on its own subnet..
Communication appears impossible between ELAN and LAN. Not sure how to extensively test this or further test against hacking attempts.
Ping from ELAN to any gateway IP returns unreachable, as desired.
SSH from ELAN to openWrt is refused, either gateway address.

Good good, but I do have an issue.. In the System Log, I am getting this message a lot, and haven't found online a solution to it. I barely understand it [not network guru]

Wed Apr 15 00:39:49 2015 daemon.warn odhcpd[822]: A default route is present but there is no public prefix on eth1.2 thus we don't announce a default route!
Wed Apr 15 00:39:49 2015 daemon.warn odhcpd[822]: A default route is present but there is no public prefix on br-lan thus we don't announce a default route!

Actually the messages shown above display pretty frequently even on a fresh openwrt installation... Wonder what's that all about?

How to Successully mod with USB flash drive ExtRoot

Earlier posts in this thread provided good pics and explanations. I can say a little more now that I've successfully implemented this mod..

As mentioned earlier in this thread, 3.3V is ok for the flash drive, and since I already have pin headers installed on the serial, I instead grabbed the 3.3V from a via located right beneat the PWR LED. you'll see 2 vias they both supply 3.3V.
For GND, I just use the shield framing. I suggest using pin headers so you can switch D+ and D- incase you screw up.
Also, keep D+ and D- as short as possible. My wires are about 3 inches to get right about the ethernet jacks where I've mounted the USB socket with hot glue. I used to have longer wires and it wouldn't work.

Really great article here:

Despite the article, I am doing OK without a filter capacitor and without resistors..

Kernel Modules Required
kernel modules to enable in the kernel. I recommend compiling them in rather then relying on opkg [personal preference]. You can do a google search for openwrt mass storage usb to get an idea of the kernel modules.. but since I already figured it out I might as well try to see what exactly was necessary..

make menuconfig

In menuconfig, navigate to kernel modules
block devices -> kmod-scsi-core
filesystems -> kmob-fs-ext4 -- because my USB is formatted ext4 [any advice on better filesystem?]
USB support ->


Don't expect to format your drive on OpenWrt, don't install utilities to do that, there's no space right now! We barely have enough to keep JFFS2 operable. Instead, pre-format your drive on the computer.

Be sure not to install ANYTHING else, as merely be enabling the aforementioned kernels, there is barely enough space for JFFS2 to allow you to save config, which is required to update /etc/config/fstab in order to perform EXTROOT at boot. I tried installing usbutils atop these packages, but it was too big.

If you want to learn how to perform EXTROOT, there a couple ways to do it (pivot overlay vs. pivot root). Pivot Root is for whatever reason not recommended on ChaosCalmer, but I did it anyways {oops}, but I'm having a fine time. So if you want to do that you can learn @ … wrt-router

Also OpenWrt Wiki has good knowledge on how to do it too smile . Google is usually best for finding openwrt wiki pages tongue


@Icy92 -- Recover your changes on U-boot env? Too vague man, I can't help you.. But from my experience, I only alter the bootcmd env variable from U-boot via serial, it has to be done over serial at bootup, and there's nothing to recover lol.. Have you destroyed your set of env variables? I have no problem recording my set to see if that helps..

ar7240> printenv   
bootargs=console=ttyS0,115200 root=31:02 rootfstype=jffs2 init=/sbin/init mtdparts=ath-nor0:256k(u-boot),64k(u-boot-env),6336k(rootfs),1408k(uImage),64k(mib0),64k(ART)
lu=tftp 0x80060000 ${dir}u-boot.bin&&erase 0x9f000000 +$filesize;cp.b $fileaddr 0x9f000000 $filesize
lf=tftp 0x80060000 ${dir}db12x${bc}-jffs2&&erase 0x9f050000 +0x630000;cp.b $fileaddr 0x9f050000 $filesize
lk=tftp 0x80060000 ${dir}vmlinux${bc}.lzma.uImage&&erase 0x9f680000 +$filesize;cp.b $fileaddr 0x9f680000 $filesize
bootcmd=bootm 0x9f040000
Environment size: 680/65532 bytes


I want to submit my patches with comments on what I've done. We already know that several people can't get ethernet working on the official trunk and the LEDS are broken.. I have fixed both in my version.. Although not perfectly. Green LEDS, how are they being handled outside of /etc/config/system? Need the answers so that we can control them too..

Questions / Observations

Green LAN/WAN Leds
I've been trying hard to understand the Green LAN / WAN LEDS. These LEDS are not controlled thru /etc/config/system like the rest of the LEDS are. Because these LEDS are externally controlled (somewhere in CPU code? or maybe another peripheral?), adding them as LEDS in the gpio_led, and trying to turn them on / off in /sys/class/leds does not work.. Also the value of brightness does never even reflect the true on/off of the LED. HOWEVER, the gpio number is correct, as when the LED is not registered as gpio_led, we can watch it in /sys/class/gpio, and watch its logic change.. Also, if we set the gpio to input-only, the external control is disabled...

So if we can figure out where is this external control coming from, we can learn how to put the green LAN/WAN led control back to /etc/config/system for greater user-level control. Right now, the current control is mysterious but it does do a job at lighting up based on LAN/WAN activity..

Does anybody have ideas where these green LEDS are getting controlled from, even when they are not registered in the led_gpio structure?

Why Ethernet does not work in Trunk
So I've figured out aforementioned why the Trunk's LEDS are broken, but why does its ethernet not function correctly. Should we bother to diagnose why, or should we simply implement the version I created which works in total? I am investigating how to create the kernel patchfile.

Why is ath9k-phy0 listed as an LED
What is this all about?? See it /sys/class/leds or in Luci as well.. What is it?? I don't see any light big_smile

Why does WLAN button not work?
Just like the Green LEDs it does not respond to GPIO toggling.. anybody?

(Last edited by bazz on 16 Apr 2015, 07:41)


Thanks for your guide, I have no more questions on uboot, but after flashing your image several times, my mac address disappeared and thus I cannot roll back to the factory image(to work). Could you please help me recover it?

At first I flashed your non-usb version image from the factory version erased rootfs_data), and tried to install luci until it told me that there were not enough space. I thought I could make more space through uninstall something, so I removed some part of the image and rebooted. To my surprised, the system got reset, so I erased rootfs_data and reboot again.

After I found that it was impossible to install luci, I tried to just open its wireless function, at which time I found no "wireless" file in /etc/config . I thought I must have missed something, so I flashed it again. And again. And again, until I thought there might be some mistakes in this image so I turned to the usb version you offered.

Following your guide, I noticed that you installed luci,(Oh yes I forgot the "wireless" file and your're modeling your router with a usb storage), so I install luci again and failed again(and certainly, no "wireless" file). So I turned back to growell's basic image, until I found that "wireless" seems to have disappeared forever. What's more, my board_hw_id and mac address have disappeared too at that time.(hw id ="", mac address = FF:FF:FF:FF:FF:FF in U-boot)

Meanwhile I was told by my tftp software that the factory images are no longer available in Upgrade mode,so I set my hw id back in U-boot to flash the factory image. I succeed in flashing the image but  it still didn't work due to "Kernel panic - not syncing: Fatal exception in interrupt".

I can't flash any image except the factory versions using TFTP under upgrade mode, and the factory version seems not to work. What should I do now?

p.s, I have a backup version of u-boot; u-boot-env; and ART (in .bin format), will these files help?

(Last edited by lcy92 on 15 Apr 2015, 15:25)