Builds for NETGEAR WNR1000V2, WNR1000V2-VC, WNR612v2, WPN824N, WNR2000v3, EX2700

Is there a way to get a build with the zeroTier package for the WNR2000v3 or would that just take up too much space for it to actually function as a router?

You do realize that zerotier alone weighs around 430 KB?

I do now :wink:

I flashed a NETGEAR WNR2000v3 using TFTP and the file OpenWRT_21.02.3/WNR2000v3/openwrt-ath79-tiny-netgear_wnr2000-v3-squashfs-factory.img. After the flashing, the power led stayed orange and the device did not respond to pings.
The file OpenWRT 19.07.10/WNR2000v3/openwrt-ar71xx-tiny-wnr2000v3-squashfs-factory.img works though. The power led changed to green shortly after flashing and was responsive after a few minutes.
EDIT: After I successfully flashed the device using the older version, I opened the Web UI and upgraded the firmware there using the file OpenWRT_21.02.3/WNR2000v3/openwrt-ath79-tiny-netgear_wnr2000-v3-squashfs-sysupgrade.bin which is different from the one above (containing "sysupgrade" within its name). This seems to be a valid upgrade path. I am not sure if the first attempt would have worked if I waited a bit longer..

Do I understand correctly that there are no plans to release a new version with the latest changes of critical vulnerabilities for branch 19 (for example 19.07.11)?

Hi all, I have created a couple of new builds based on OpenWrt release 22.03.2 for these routers.

Note that I am not the creator of this thread, jlpapple, nor have any affiliation to him or his builds. I have a few WNR1000v2-VC routers myself that I use for minor additions to my network, like a Relayd bridge client.

Most importantly, I have NOT tested these builds for "daily driver" 24/7 use, as I do not use this hardware as my normal router/access point. I appreciate any feedback on how these builds hold up in that scenario, but I will not be able to troubleshoot or diagnose any stability problems. I have created builds for most of the hardware in the title of this thread, but do not have all of these routers to even test that the upgrading/flashing process is successful. Please be comfortable with the TFTP recovery process before testing my images on your main hardware- it's actually a pretty simple process on these routers.

I have created two separate builds: one with the firewall3 set of packages and one with firewall4. One of the major differences with the 22.03 release is the move to firewall4. However, the firewall4 package is very large in comparison. To get firewall4 to fit at all, I had to significantly cut down pretty "standard" command-line functionality like printk/dmesg, busybox help messages, hex error messages, etc. There really is no room for additional packages or features, and the firewall4 build is provided to be compatible with the base OpenWrt 22.03.2 install, since there is no official release for these routers, but with no ability to add anything additional.

On top of not having to cut down as much, the firewall3 build also has Relayd, Wireguard, and Zram included. This takes care of my needs for this hardware and should even allow for using it for a VPN service- either a home VPN server or an always-on client with a commercial VPN service that supports Wireguard, or both! The addition of Zram as swap should help with the limited 32MB memory on this hardware.

Here is the link to download the builds:

As jlpapple has done, I have included my config (and additional .patch) files in the .zip file and steps to reproduce or modify my builds if necessary. I've opted to include git diff patches instead of the "official" method of using the quilt tool, because there are a large number of Makefiles that have been modified to squeeze as much space out of individual packages as possible, and I find the process of applying git patches easier. The patches may not hold up for future 22.03.x releases, and I don't have much intention at this time to maintain future releases for this hardware, especially since I only use my routers sparingly for non-crucial networking purposes.


@chainu127 Wow. Your work is a great contribution to our community builds for these devices - thank you! I'm impressed with how many features/packages you've been able to squeeze into the 22.03 series builds, as space and memory is at an extreme premium.

I've successfully flashed your build (fw3 version) to a WNR1000v2-VC and I'll start testing it over the next few weeks and will report my experience.

I've linked your builds in my initial post at the top of this thread for those who want to test/flash the 22.03 series of builds.

Hi Lucky, No. I don't believe there have been any commits to address this in the 19.07 branch and I doubt there will be any in the future.

I believe I read that these particular wifi vulnerabilities exist in Linux Kernel 5+, not 4.x (the kernel in the 19.07 branch). If you read the individual CVE reports you can confirm which kernel versions are affected.

1 Like

Thanks x 1000, @ chainu127!

I followed your instructions plus the relay configuration page here:

The result is that the noisy, heat-spewing old server is out in the shed where it can operate without pestering us in the main house. Linking the WNR1000V2-VC to my low-end Cisco E1200 in the house gives much better performance that having the server connect directly to the E1200 with its own PCI wifi card (which I can now remove and repurpose). Sustained throughput of about 2 MB/s, with 17.90 Mbps up/9.55 Mbps down speed testing from here in central Virginia to a site in NYC. As well, I can connect to it directly from the house when it is connected to the WNR1000V2-VC via ethernet.

Now to get that RT-N16 working properly under OpenWRT to replace the E1200.

Regards & thanks again,


@chainu127 I've been running your 22.03 builds on a WNR1000v2-VC for the last two weeks in a full router configuration. Typical home internet setup with 8-10 wlan clients, 300/20 cable WAN connection, 12-14 DHCP clients overall.

Stability and speed overall was good. However I could easily crash the router running a wlan client to wlan client speed test using iperf as described above. The router ran for 6-10 minutes under this constant ipef load then would crash via soft reboot - especially if LuCi was accessed simultaneously. This is likely due to lack of available memory.

Other than that issue, the router ran well! Note: I did not test as a dumb access point.

Hey @jlpapple, thank you so much for your build of 21.02.3 for the EX2700. Presumably to upsell customers to the EX3700, the stock firmware does not permit using this device as an access point – it must be used as a repeater/extender (the Ethernet port functions only as a downstream bridge). Some poor friends were getting terrible performance from one of these devices positioned only feet away from an Ethernet port it couldn't use. The official 18.06.8 build wouldn't boot (seemed to get stuck in the bootloader; no serial port, so it was hard to tell what exactly was going on), but 21.02.3 worked straight away. They're on very rural Internet service, so the 802.11g/n capabilities of this device are plenty for them, and I'm glad to save it from e-waste for a little longer.

1 Like

@Empterdose Did you mean version 19.07.10? If not, where did you download the build for the EX2700 on 21.02.3?

I sure did mean 19.07.10 :man_facepalming: Sorry if I got your hopes up. Maybe I should make my own newer AP-focused build for the EX2700 as penance.

1 Like

No one would complain I assure you :slight_smile:

I have a WNR2000v3 and I have tried every different build that has been posted on this thread and none will update via the Netgear webinterface. I did try uploading via tftp and the router will take the upload but then not apply it, no matter how long I wait. I tried loading dd-wrt on the router and that works - but then the dd-wrt webinterface fails so I would like to try openwrt on it. Flashing different versions of the factory firmware off Netgear's website works perfectly. I also tried flashing it by telnetting into dd-wrt and uploading the img file then writing it to the linux partition from the command line and I get an invalid trx file format. So I think something is wrong in all of the builds that have been posted. Even the regular official openwrt builds fail on this router. If anyone has any suggestions I'd appreciate it or if anyone wants the router for their own testing let me know.

Which version(s) of OpenWRT are you trying to install?

I've encountered your exact problem, multiple times, in the past. Typically the issue is the version of Netgear factory firmware that is installed may not accept the Openwrt .img. Keep trying to flash, with different Netgear factory firmwares installed, and be sure to check your computer IP settings. Review the troubleshooting steps in Post #1, too.

Lastly, I've encountered a higher likelihood of flashing issues with the WNR2000v3 than the WNR1000s. This may just be coincidental, based on the factory Netgear firmware installed on the WNR2000.

If ultimately you don't want to flash the device, let me know and I'd be happy to have it to use for future testing.

I'd gladly donate it to you if you would be using it to produce a usable firmware image but seeing as how the last image is a bit old I'm not sanguine that's ever going to happen. The other problem is that as you know (or should) this router has the Atheros tftp recovery so it is quite possible to flash it WITHOUT using the Netgear firmware at all. So it is pointless what version of Netgear firmware is on it. Yet, it fails to flash using that process also, which leads me to believe that the firmware image produced was simply never tested with a real WNR2000v3

Interestingly enough I ran across a WNR2000v5 and it flashed up fine using a fork of OpenWRT. DD-WRT also flashes fine on the WNR2000v3 using the Netgear webinterface regardless of what version Netgear firmware is on there.

To be honest there's a need for someone to fork OpenWRT into a distribution that will fit on 4/8, 4/16 and other 4MB flash Atheros devices. I'm really getting annoyed at reading the snooty "don't buy devices with less than 8MB flash" recommendations on the OpenWRT site. I've got several other Atheros 4MB flash devices and not everyone needs a router that can sing and dance a jig. There's plenty of room out there for these devices repurposed into 2.4Ghz access points as there's MANY environments where 5Ghz is not practical. We don't actually need ipfilters or any of that junk in a device that only is being used as an AP. The DD-WRT project continues to support TWO MB Broadcom devices and some 4MB Atheros devices, and OpenWRT developers need to quit making excuses about not supporting these 4MB Atheros devices anymore.

1 Like

8 MB RAM has never been supported by OpenWrt

16 MB RAM hasn't been sufficient (or supported) in well over a decade (officially discontinued in 2012, well after the fact of it having become unviable).

4 MB flash has been formally discontinued in early 2021, well after the fact that images haven't been buildable for most devices since at least 2019 (almost half a decade by now) - and already had basically no margins to install anything on top.

Never supported by OpenWrt.

Do we really need to discuss something last updated in August 2008 (v24-SP1), shipping kernel v2.4.36?
If you want to go down to that level, - you even get the choice between v2.4.35 and v2.6.25.20, no that is obviously not sensible either.

Please try - and experience yourself where the problems are with that, rather than expecting others to do your bidding.

OpenWrt's focus is on keeping stuff maintainable, using 'modern' (in the sense of the current/ supported LTS kernel release) software (the same goes for the userspace) on all targets, including ones that weren't even deemed possible with v2.4. Software (kernel- and userland) grows over time, new features are added or deemed as required, security fixes will need attention (think about things like meltdown or spectre, which do have quite significant effects on kernel size and performance; it's not -at all- limited to those). If your focus is different, you're free to start your own project - just honour the licenses and you're set, the rest is just down to your skills.

Disclaimer: Speaking only for myself, not OpenWrt as a project (with which I have no relation with, other than being a user and very casual patch contributor).

This thread concerns 32MB devices which you would know if you are an openwrt expert intending on discrediting my post - which you are trying to give every impression of doing. No, I didn't look up the ram amount before posting. 32MB. There, happy?

It's the height of hubris to post a statement like this IN A THREAD THAT CONTAINS VIABLE 4MB IMAGES

The "official" images aren't buildable for that size anymore because the OpenWRT developers made them that way. Mainly because they have always striven to turn a router into a PC by throwing the kitchen sink into it. Which is frankly ridiculous. What idiot runs a phone system with 100 users on a $30 router running OpenWRT? Or any other critical server?

OK fine, some small number of OpenWRT users are doing this but most are not. Most have 1 device as their internet router.

In the interests of full disclosure I currently manage a wifi network covering 14 sites with around 30 routers configured as APs - all running OpenWRT. And more being added to clear dead spots. Which to me seems the obvious and normal and intelligent way to use OpenWRT or DD-WRT or Tomato - as a WIRELESS node OS. I have run other distributed wifi networks using DD-WRT. I decided to do up this latest one using OpenWRT to check back in with the project and see if it was now stable enough to use for production work (it is) and if it's community of users might have developed some humility (they haven't, you proved that.)

Why do I do this instead of using some commercial distributed wifi solution like Ubiquity?

Because higher end stuff like that and even the highest end stuff like from Cisco (which I have also deployed) all use the identical radio chips from the same handful of manufacturers from Asia. So, why would I pay $150-$200 a pop for Ubiquity APs or $800 for Cisco and have them completely dependent on the cloud AKA golden handcuffs from a vendor ($6000 on up for my network by my math) when I can fish out stuff like Netgear WNDR3700v4 devices from Goodwill for $9 a device and flash them to OpenWRT making them equal in reliability to the expensive stuff? And if I want to integrate them into a management console I can opkg install snmpd? Which is really unnecessary anyway. And doing that I get a device that is AS RELIABLE as the Cisco.

I'm well aware of that and why - that was not an opening for you to git me religion, Holmes. It is, however, an example of what is possible with effort.

The 2MB flash devices are mainly a Linksys invention intended to shave a nickel off manufacture of their ugly-as-sin blue wrt54g devices and they could only do this because both Broadcom and vxworks were paid a large enough sum to crunch the space down on the driver and bootloader and linux kernel.

They ALSO were intended to harm the early OSS router firmware efforts which were built around the 54Gv1 which had 4MB flash. Linksys thought "well eff you guys see if you can fit Linux in THAT you arseholes" and then immediately came out with the 45gL which cost 4 times more so they could pretend they were supporting instead of biting the very hands that were feeding them

Except, as I pointed out, it backfired when the OSS router community trumped them. Then Linksys was sold to Cisco who actually tried for a few years to carry the franchise, straddling the OSS/non-OSS fence but ultimately Cisco learned the same thing I had already - which is that things like the WRT310 and friends were as stable and reliable as their $800 APs and network managers were starting to deploy them into the enterprise. Linksys-by-Cisco was cutting into their Enterprise profits. So in a panic they sold it off to Belkin which is probably one of the most unfriendly-to-OSS companies in the known Universe and who has proceeded to fritter away their lead in wifi gear to Netgear.

But in the meantime the 2nd and 3rd tier wifi chipset vendors (like Atheros) were given an opening into the market and they proceeded to fill it with OSS-friendly devices.

That's the REAL story of why OpenWRT does not support Broadcom. It wasn't Broadcom it was their largest customer - Linksys - who was caught with their pants down because they never realized there would be such a thing as OSS router firmware until there was, then it was too late.

That's mainly a lie. The current DD-WRT 2MB flash builds of K2.4 have all of the modern vulnerabilities (like KRACK) patched. Far from being last updated August 2008.

But you still don't get it anyway. Radio has NOT changed. A brand new laptop with the latest AX chip will still associate with a 20 year old WRT54G or Motorola or whatever other old 4MB device you can dig up. In some environments EVEN IF the AP is brand new with AX the laptop will still switch down to 2.4Ghz because 2.6Ghz radio can go places that 5Ghz can't. People running the 20 year old gear don't NEED the modern kernels - 2.4 works fine for them. It's an AP. It's not connected to the Internet. All they need it to be is stable, reliable, able to pass their security network audits, and does not ever go down - which they won't get from the manufacturer's firmware. But they get it from the Big Three OSS router firmware projects.

No it isn't. It's focus is on keeping stuff on "modern." Maintainability is a side effect, it happens because it's easier to get less experienced people involved in a project that is running "more modern" Linux so there's more eyes on the code, but that isn't why people build OpenWRT. Particularly in this thread.

The OpenWRT developers crow like cocks on the rooftops when they can get "targets that weren't even deemed possible with v2.4" to run modern kernels. This very thread is an example of a "target that wasn't deemed possible" What's the definition of a software developer God other than a software developer who can respond to "No you can't do that" with a good "eff you I just built one last night in my garage, you moron so I'm smarter than you are!"

Total excuses. As I said the micro images in the DD-WRT project built yesterday for 2MB flash targets are secure, so quit using that BS excuse about security, you sound like a politician trying to justify setting the 55Mph speed limit. Let the OpenWRT user determine what is secure and what is advisable to run on the perimeter.

Thank you for making my point for me in your last sentence.

1 Like

I was giving the (short version of the) progression when which of the system requirements were phased out in OpenWrt, taking the system profiles you raised as examples. This is an attempt to explain what happened when, not an attack.

That is debatable, twenty years ago WPA1/TKIP was still considered viable -even WEP64/ WEP128 was still in common use-, neither of those still are. WPA3/SAE has entered the stage, and -surprise- the WRT54G radio hardware (BCM4306) can even do that, with a 'modern' kernel (>=v3.8) and hostapd (>=v2.9), if it had enough flash/ RAM. Yes, you can teach an old dog new tricks - and there are some people who want (or depend on) these new features.

A security audit for kernel v2.4.36, uClibc, busybox and hostapd (or broadcom-wl/ nas) of that vintage is going to be …'interesting', you may get the rubber stamp, but not the t-shirt.

Apparently you yourself don't really consider it viable, if I may quote your previous post:

As you noted yourself, the world is no longer centered around Broadcom - and what the world centers around these days (mt7621, mt7622, filogic 820/ 830/ 880, ipq40xx, ipq806x, ipq807x, (ipq50xx, ipq60xx), rockchip, sunxi, bcm27xx, x86_64, …) is not content with kernel v2.4 or v2.6 or v3.x or v4.x or v5.x, they really need at least semi-current versions to function.

Something similar could be said about those expecting 20 year old wireless hardware to run today, in an environment that is hostile and actively scanned for vulnerable systems to add to multi-national botnets. Or expecting kernel v2.4 and matching (micro-) userspace to remain secure. Vulnerabilities are constantly being found, both for internet side attack, but also for the wireless side (and KRACK is by far not the only example of this). But KRACK is a good example here, as it affected most vendors - bugfixes had to be prepared for (almost) all operating systems and (almost) all drivers, has broadcom-wl been updated (it hasn't in OpenWrt, not that this driver is shipped in any images), has broadcom-nas (hostapd has quite a few security issues found & fixed per year, either Broadcom has written 'perfect' code without any vulnerabilities two decades ago, or…) been updated for security issues - are you sure?

So in which scenario can you still run software that old 'safely'?

  • it obviously mustn't be internet facing (as in, used as router, which is what most of the devices your quote have been designed to be)
  • these days, with ECMAscript, web-assembly and other things, you may not connect any 'untrusted' or internet connected clients to it by wireless either
  • given the wireless vulnerabilities found over the last decade, you may not operate in any location where third parties may get into range to stage their attacks (e.g. war-driving)

…this doesn't leave that many options.

I'm not out for a fight, I was merely trying to explain the background - so end of discussion as far as I am concerned.