If and when you get around to it, please build 19.07.10 instead OpenWrt 19.07.10 service release
Will do, should be ready by end of May.
I've created 19.07.10 builds for all five devices, with a new additional build for the Netgear EX2700 Range Extender which previously could only run up to 18.06.9. All download links available in the first post above.
Please test and report any issues you may encounter, enjoy!
It seems to be running fine here - thanks a lot! According to the developers that's the final release in the 19 series, so I guess that's the final build from your hands. Much appreciated.
You’re welcome. I’m testing builds of 21.02.3 as we speak, and those should be available by June 11.
I've successfully built test images for 21.02.3, 22.03RC3, and the current master but I will not be posting them at this time. Unfortunately there seems to be a bug that causes the wifi to crash and restart when copying large numbers of simultaneous files between wireless clients on the LAN.
I don't think this issue is insurmountable, but it is going to require more debugging and testing. I'm unsure if the issue is related to image configuration, my test hardware (a WNR1000v2-vc), client hardware, a software bug, or a combination of all four variables. The issue is not present on 19.07.10.
I anticipate releasing test images of 21.02.3 sometime in the next two weeks, as I could use your assistance in testing them in different LAN/WAN environments.
I have a WNR1000v2 and I can help test. I don't know a lot about networking - I'm mostly using these older routers as "dumb" access points. But I'll give it a go - I just need to know what needs testing.
I've created images for 21.02.3 for WNR1000v2, WNR1000V2-VC, WNR612V2, and WNR2000v3. They include LuCi, IPv6, Relayd. They do not include opkg, PPP due to space limitations and I've tested these images on the 2000v3 and 1000v2-VC.
I highly recommend flashing from an existing installation of 19.07.10 via sysupgrade, do not keep settings, and see Post #1 for additional information if flashing for the first time. I also recommend flashing via command line instead of LuCi, as you will likely not have enough free available memory to flash via LuCi menu (unless you unplug WAN port, temporarily turn off Wifi radio, reboot router to free up memory before flashing.)
Note: I've manually migrated the WNR1000v2-VC to the Ath79 target to build for 21.02. When you flash this model from 19.07.10 in Luci, you will see an error message. Select the "Force Upgrade" box, make sure "Keep Settings" is unselected, and click continue - it will flash normally.
These images are mostly stable, but I've encountered a recurring wifi crash and device restart if you are copying a large number of files or create very heavy network transfer traffic between wireless clients if using device as a full router. If using the device as a properly configured dump access point these crashes do not occur.
Additionally, these crashes do not seem to occur when using the device as a full router if copying files over the network from wired to wireless clients, wired to wired clients, or typical internet browsing and streaming use among a variety of wireless and wired clients. I experienced stability for multiple weeks on a home network with 10 wifi devices, 2 wired devices, on a 300Mbps WAN connection - however, if I started copying many files between wireless clients the router would restart within a few minutes.
You can use iperf to conveniently test wifi client to wifi client network transfers and stability on your own network. Initiate an iperf connection between two wireless clients for at least 10 minutes and see what happens.
At this time my recommendation is to only operate these devices as a dumb access point if running 21.02.3.
It may also be reliable as a full router in a network environment with mostly wired clients and/or little to no wireless client to wireless client transfer traffic. If running as dumb access point, follow the instructions and disable unnecessary services (Ex. firewall, dnsmasq, odhpc, etc.) to conserve available memory. Free memory provides more stability, higher speeds, more wireless client capacity - the more free memory, the better...and every kB counts. Scheduling a periodic reboot via cron could increase stability over long periods although it is not necessary.
I'll continue to troubleshoot the cause of this wifi crash issue and appreciate users reporting their experience, network configurations, and specific situations when this may occur. (The same issue currently occurs on 22.03, master branch as well). The reality of the situation is that we're on the bleeding edge of incompatibility with the 5.4 kernel given the limited memory on these old Netgear devices.
The good news is that these Netgear devices can still be used successfully as reliable dump access points for the foreseeable future. I'll continue to debug the issue to hopefully enable use of these devices as a full router with the same solid stability we had on 19.07.
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
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 192.168.1.1 pings.
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.
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.
@Empterdose Did you mean version 19.07.10? If not, where did you download the build for the EX2700 on 21.02.3?