WNR1000V2 Builds for NETGEAR

Note: I've also built images for the WNR612v2, WPN824N, WNR2000v3 - see the bottom of this first post.

The NETGEAR WNR1000V2/VC was one of the most widely-distributed "free" routers from Comcast and was given to hundreds of thousands of customers in the United States. It is an old 4/32 router but is still very capable of basic networking tasks and also works very well as a dumb access point. I've been running OpenWRT on it for the past three years and it as reliable as the venerable Linksys WRT54G.

My motivation for this project is to reduce electronic waste by continuing to use viable products - with current software. Please abstain from 4/32 debates on this thread.

Build Information
I've compiled builds for 17.01.7 and 18.06.4. These are stable base builds compiled from each git branch that include LuCi, SQM, IPV6, and PPP support. opkg has been removed because there is no space to install additional packages. Build manifests, config.seed and sha256sums files are in the download folder.

I'm working on a stable 19.07 build - it is not yet ready, but testing looks promising.

Download - (Updated 08/04/19)
Download Link for Builds | Download Mirror
(All builds include stock Netgear firmware for brick recovery.)

Why Not Use the Official OpenWRT Firmware?
The standard, auto-generated official OpenWRT firmware images are too large. You will likely be able to install these official images, but the settings will not be retained upon reboot due to a lack of flash space.

How to Install

  1. Try to identify whether you have a v2 or v2-VC hardware version of the router. The product label will not identify if it is a v2-VC. If the router was provided by Comcast or another ISP is is likely a VC version. If you can open a serial console and view the boot log the first line of output identifies the model. You can also just try flashing the v2 and v2-vc .img files ending and see which one works. It will be safely rejected by U-boot if it is the wrong file.

  2. If the router is running original Netgear firmware you will need to flash a "factory" image of OpenWRT Breaker Barrier to begin. If it is already running OpenWRT, skip to Step 4. Open the "Flash from NETGEAR Firmware" folder from the file you download above and select the appropriate .img file for your model - V2 or VC. You then need to reboot the router in failsafe mode.

  3. For booting into failsafe mode, power up the device while holding the reset button with a pin. The power LED should have an amber colour. Hold the reset button until it is starting to flash green. It starts to flash green after it flashes the amber LED six times. After that, the device is in failsafe mode, accepting a firmware via its TFTP server. The device should respond to pings at 192.168.1.1, although the responses may be malformed. Configure your ethernet interface with a 192.168.1.0/24 IP address. I use 192.168.1.2 with netmask 255.255.255.0 but it should work with any free address from that block. (Credit to SaltwaterC - see his thread for troubleshooting.)

  4. Once the router is running Breaker Barrier (or higher) you can then upgrade to 17.01.7 or 18.06.4 via the sysupgrade .bin file using the "Backup / Flash Firmware" menu within the GUI. Make sure whenever you flash to verify the sha256sums to ensure it isn't corrupted. Uncheck "Keep settings" for maximum reliability when upgrading between versions.

Flashing Notes
The TFTP flashing method works, but it can be inconsistent. Keep trying, it seems to work best on Linux. Be patient after flashing as the green light can blink for a few minutes before the router comes back up after a flash. When in doubt, do not unplug for at least 5 minutes after a flash.

Build Notes

  • Once running 18.06.4 it can be difficult to flash reliably from the "Backup / Flash Firmware" menu to upgrade/downgrade. I suggest you flash via command line and drop caches to make more RAM available before flash. The drop cache command is "sync && echo 3 > /proc/sys/vm/drop_caches". The 17.01.7 builds do not have this issue.
  • The 18.06.4 build with PPP does not display a Kernel Log in LuCi - due to the lack of flash space to include printk timestamps. This PPP build also uses slightly more RAM - if you don't need PPP, flash the non-PPP build.
  • Free RAM, as reported by top, ranges from 4-7.5 MB depending on the build version.

Customization and Building Your Own
I won't be providing customization for these builds, as there is very little flash space for any additional packages. If you create your own build any firmware file much greater than 3.31MB (as reported/measured by OpenWRT immediately before flash) is likely too large and will cause a bootloop and/or will not preserve settings upon reboot.

Brick Recovery
I've placed the original Netgear firmware for the v2 and VC (North America Models only) in the same folder as the builds above in the event your brick your router.

Recovery for the VC Model
If you brick your router trying to upgrade to OpenWRT and need to revert your WNR1000v2-VC back to stock Netgear firmware via a TFTP flash, use the “WNR1000v2-VC-V1.0.0.12NA.img” file. It is likely the only firmware that will be accepted via TFTP flash.

Recovery for the v2 Model
It should be similiar to the VC model method described above. Start with the earliest version NETGEAR firmware when reflashing via TFTP.

Additional information on flashing these routers courtesy of mPratt14.

Related Models
I've built 17.01.7 and 18.04.6 firmware for models that share the same Atheros chipset as the WNR1000v2. I don't own these models, but the hardware is practically identical. If you download and install, please let me know how they run on your respective model.

Hi, I would like to try your builds but I can’t download the archive, can you post it to another resource please?

I've changed the download host and updated the link above.

1 Like

Thanks!
I successfully updated my Chaos Calmer 15.05 / LuCI (git-15.248.30277-3836b45) router to a version 17.01.7 using sysupgrade.
I haven’t really tested it yet, but the settings are saved after a reboot :+1:
In the last builds, as I understand it, PPP package (that we still use to connect to the Internet) is not included. Do you plan to return this package or decided to abandon it due to lack of space?

That's great news. I'll work on a version of 17.01.7 with PPP to see if I can squeeze it in, stay tuned.

1 Like

Please test this version for a few days - it includes PPP. Let me know if it works.

Download 17.01.7 with PPP

Ok, thanks! Already flashed.
I’ll test it for several days and write about the results.
P.S. One moment surprises me:
How did you manage to reduce the build size so much including the PPP package (3 201 KB) as compared to the previous one (3 393 KB), without it?

I took the extra step of modifying the kernel to only support this specific device, see the link below. I hadn’t known about this option in the previous build I complied for 17.01.

Let me know how the testing goes, as I don’t have access to a PPP connection.

1 Like

Ohh, it's very cool! :clap:
I'm currently testing the last build on the PPPoE connection, via wifi. It is still very stable. From my laptop with intel 6300 card shows the following speeds: DL - 35 Mbps, UL - 44 Mbps. This is all with an average load. I also plan to test on a lot of connections, with which the router may have problems.

1 Like

Great, thanks for testing it under additional load. Do you have SQM configured? If not, please turn it on as part of your testing. It will use more RAM and CPU, but it should be stable.

https://openwrt.org/docs/guide-user/network/traffic-shaping/sqm

1 Like

I've updated all builds to include PPP, as well as changed the Fragment_Cache_Size value to "1" and reduced the block size to "256" on most images to improve memory management and increase free memory. All users should update to these latest images.

1 Like

I have never used the SQM feature before, but thanks for the tip. Now I will use it regularly, because a quick test shows that it really works! Now I got the following results:

before enabling SQM

after turning on SQM

I think I’ll also spend some time fine tuning SQM and later share the results from your new build.
P.S. I have a friend who has a problem under high load on NETGEAR WNR612 v2 (the same hardware as WNR1000 v2), and could also test the SQM option on his WNR612 v2 if you build for him as well.

1 Like

Very glad to hear these builds are working well for you!

I've built a version for the WNR612V2 with PPP, SQM, etc. Give it a try and report back. Be careful if you're flashing from original Netgear firmware - there seem to be some instructions here. Make sure to use the .img file if flashing from original Netgear firmware.

Download for WNR612V2 builds for 17.01.7

I would follow the instructions in this thread, specifically Post #10, if you need to flash from the original Netgear firmware. I definitely would use the TFTP method.

Does your friend have the WNR612V2 or the N150R?

It was the original WNR612V2 rebranded from our local internet provider ER Telecom, I downgraded it to the factory firmware and then upgraded to Chaos Calmer 15.05 where the problems with a heavy load started. I will try to pick up the router from him for a test soon.
Thanks for the build!

1 Like

You should have no trouble upgrading it since it is already on Chaos Calmer.

You're welcome!

After upgrading to a fresh build, I noticed that SQM didn’t work as well as before. Maybe I need to reconfigure again after sysupgrade, or I don’t have much experience yet :smile: , in general, I will try further ...
I configure SQM considering the speed of Wi-Fi, but it might be more correct to do this via a wired connection. I don’t know yet.
In the setup instructions (see post #11), I found slightly different settings than the default settings in the firmware. Maybe you can integrate these settings into the firmware, if they are more correct?
P.S. Regarding 612v2, I will write the result as I take it to myself

Fresh results after configuring SQM from scratch:
before

after

The best method to configure SQM is over a wired connection, with few to no other users on the same network and with little to no network traffic. Turn off SQM and run a few speed tests. Average the results, reduce them by 5-10% of your download and upload speed, and enter those values in kbits/second into the SQM fields. Then turn SQM back on and run another speed test.

More detailed instructions are here:
https://openwrt.org/docs/guide-user/network/traffic-shaping/sqm

I always select "cake" as the queue discipline and "Piece of Cake" as the queue setup script. Those work well for you me, but your results may vary based on your type of connection. Also, remember to set your appropriate Link Layer Adaptation.

Hi @jlpapple!
The problem is that my wired connection is about 100 mbps but the wireless pulls only 35 maximum (due to the limitations of the Wi-Fi chipset). In the SQM settings, I can specify one algorithm for one connection, and in my case 2 is required, at least. One for wired connection and the second for Wi-Fi.

You should set the SQM to match the speed of your Internet connection/service to your home or office modem/router- not to the WiFi speed. Example, if the service to you location is 50Mbps, set the SQM to 90-95% of this speed - don’t worry about the WiFi speed.