I sure did mean 19.07.10 
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 
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, https://archive.openwrt.org/kamikaze/8.09.2/ - 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.
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.
Granted - but it entirely depends on the use case. I would not put an AP like this on a private network but if it's a wifi network given over to the general public I don't give a fig if someone breaks into it. Worst case is it becomes no worse than your garden variety Starbucks wifi network. Use At Your Own Risk. Probably better since it's so underpowered if someone tried using it as a mule they would just make it fall down on it's face.
Apparently, you yourself don't really consider it viable, if I may quote your previous post:
That was for the WNR2000v3 of which I have 1 specimen. I have 3 of the WNR1000v2's and those are used in border case areas and the posted firmware for them in this thread loads and runs fine. Uptimes of months, that sort of thing.
The originator of this thread clearly had a box of WNR1000v2s and decided to compile an image - he did, it worked. He must, like me, be using those devices in areas where it's of no concern if the AP gets broken into because the AP itself is on an untrusted network. Once he had a working image, he was done. Since he had no concerns of security, why update the image with new security patches? My initial post was pointing out that I could not get the WNR2000v3 image to flash. It was mainly a warning/informative to other readers that stumble over the thread and have an old WNR2000v3 that if they can't get it to flash, they aren't the only ones having problems. I was surprised with the OP responding.
If the OP has the toolchain setup, such as on a virtual image, that he could spin up and if he did sufficient documentation to be able to fire up the build environment and recompile, then it shouldn't be at all difficult to fix. As I mentioned the error is "invalid trx" so clearly something was missed during the final conversion of the build into a trx file. Very likely it's simple.
But of course, if he didn't save all of this, then forget it. I know he's not going to spend the hours putting everything back together just to identify an error he might have made 4 years ago and if I really want a working image, I'll have to do it myself - and would I for a router that is worth about $10? Would I to support around 4-5 4/32MB Atheros units I have? No, of course not. Several of the 4/32 Atheros units I have work perfectly with DD-WRT so that's an option. I might possibly do it just to prove I can, but the world is full of cheap wifi units that have support in the 23.x train so once more, I'd be wiser to concentrate on those.
But there may be someone else out there who DOES have a box of 50 or so units which would make it worth their time to spend time reading this thread and trying to update them.
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.
Yes, that is for new radios for the AX gear and friends. But, like I said with radio, it hasn't changed.
You are dealing with some fundamental physical laws here, To push higher bandwidth over radio you must use higher radio frequencies, but higher frequencies do not operate like visible light emanating from a light bulb. Arguably, the 2.4Ghz spectrum is ALREADY too high.
There are LOTS of people, homeowners and such, who with the most modern cable modems with included radios, cannot get a wifi signal from one end of the house where the internet modem is, to the other. No problem doing this with an AM radio of course, because construction materials like drywall are transparent to lower frequencies. But lower frequencies are lower bandwidth.
What good is an AX radio when it's propagation range inside of a building is no greater than the 20 year old 24Ghz WRT54g it replaced? Honestly, it's probably going to be lower.
The reason the wifi vendors are pushing this gear is because in order for it to "work" you have to blanket the area with multiple APs. So they get to sell more boxes. $$$$, not understanding of radio, is driving this market.
…this doesn't leave that many options.
But it does. In the large scale wifi network I mentioned - which, incidentally, is in a medical facility - that network is entirely outside of the private network. If employees connect to it, they cannot reach the internal network. They can only reach public facing servers, email, etc. It is no different than if they took a laptop home. All of this was deliberate, and it wasn't to be able to build the network out of old wifi units, it was because if the wifi network DID connect with the internal network then I would have to be sure all hosts on the internal network were locked down. And there's too many of them to be sure of that. So, slight amount of increased nuisance for using the network for employees, a gigantic increase in security. It's a no-brainer.
1 Like
Agreed, the people fearmongering about v2.x.x don't know what they're talking about, to be honest. I reckon these are the same people who would rather buy a new board when it breaks instead of trying to fix it.
The kernel TCP/IP stack is perfectly fine, the only real risk IMO would be userspace <--> kernel, any other attacks would involve physical access.
Attacks which are absolutely pointless when the SSID and password for it are written on the wall next to it, and the network a "successful" attack gets you access to is untrusted.
And, which within 6 feet of the AP there exists an Ethernet port on the trusted network that a VoIP phone is plugged into, a phone that has a "piggyback port" on it. Hell the attacker doesn't even HAVE to unplug the phone, the piggyback port is just waiting for them.
The fearmongers are idiots.
Further update on this router. I finally got OpenWRT version 22.03.2 loaded on it, the community version listed above. The file I used was located in the OpenWrt_22.03.2\OpenWrt_22.03.2\22.03.2 with firewall3 relayd wireguard zram\WNR2000v3 folder of the archive, filename openwrt-22.03.2-ath79-tiny-netgear_wnr2000-v3-squashfs-factory-NA.img It was so nice to finally see the OpenWRT login page on this router! Even though the DD-WRT project does have a build for this router, their builds for it have not worked for many years, they crash shortly after booting.
The key to get the firmware loaded was to note the message in the Install instructions for this router located here: https://openwrt.org/toh/netgear/wnr2000 specifically the reference to using a serial cable and the board ID issue. Also the archived https://dev.archive.openwrt.org/ticket/18959 ticket helped. Basically with this router, the TFTP recovery in the uboot will not take an img file unless the img file had a board ID and model name that match.
The Techinfo link for this router is no longer valid but I was able to find the information in the Wayback machine of that link which says:
"There are two revisions of the WNR2000v3 and I was able to get a hold of the second one that has 1 screw instead of two and recover it through serial.
To recover, connect a serial adapter to the board and stop the boot. you should see something like this while booting:
Hit any key to stop autoboot: 0
After stopping it, type
bootm
The router should now be waiting for a TFTP client to connect and give it firmware. One issue I was having was that the bootloader's settings were messed up. The hardware ID as well as the model name were wrong(12 ÿ characters) and as a result, the bootloader denied the firmware. To fix, run these commands:
board_hw_id_set 29763551+04+32
if you want to tftp any new dd in the wnr2000v3 with out check hw id use this:
board_hw_id_set "" board_model_id_set wnr2000v3
After that, TFTP as usual."
Now it so happens that the community build above uses WNR2000V3 as a model ID in it instead of wnr2000v3. I do not know which is right. The archived bug seems to claim the lowercase one. But in my router, both the board ID and the model ID were screwed. The board ID was blank or nulls. The model ID was lowercase. I also do have a "revision 2" with the single screw (which by the way is a #6 torx head, Home Depot has a small screwdriver kit which has this)
It appears the Netgear-built factory firmwares have some mechanism to bypass this check. They can be loaded via tftp recovery even though the board ID is empty. But dd-wrt and OpenWRT -are- subject to this check and the board ID and model ID -must- match exactly for tftp.
It IS possible to go from factory firmware webflash to dd-wrt but not to openwrt, the webflash rejects openwrt. Only tftp works for openwrt.
The serial port already had headers soldered to it so it was very easy to access via 3v+ serial adapter. Here for posterity is the output of the serial console from the first tftp attempt that failed and the commands to make it succeed:
.
.
.
Done!
Bytes transferred = 3670149 (380085 hex)
HW ID on board:
HW ID on image: 29763551+04+32
Firmware Image HW ID do not match Board HW ID
Board HW ID mismatch,it is forbidden to be written to flash!!
Trying eth1
.
.
[next attempt after changing board ID]
Done!
Bytes transferred = 3670149 (380085 hex)
HW ID on board: 29763551+04+32
HW ID on image: 29763551+04+32
Firmware Image HW ID matched Board HW ID
MODEL ID on board: wnr2000v3
MODEL ID on image: WNR2000V3
[now reboot and break the boot]
nmrp server is stopped or failed !
Hit any key to stop autoboot: 0
ar7240>
ar7240>
ar7240> board_model_id_set WNR2000V3
Burn board_model_id (= WNR2000V3) into ART block
First 0x3f last 0x3f sector size 0x10000
63
write addr: 9f3f0000
Done.
ar7240> bootm
Booting image at 81000000 ...
Bad Magic Number
Trying eth1
The Router is in TFTP Server Firmware Recovery mode NOW!
Listening on Port : 69, IP Address: 192.168.1.1...
Upgrade Mode
Rcv:
.................................................................
.................................................................
.................................................................
.................................................................
.................................................................
.................................................................
.................................................................
.................................................................
.................................................................
.................................................................
.................................................................
..
Done!
Bytes transferred = 3670149 (380085 hex)
HW ID on board: 29763551+04+32
HW ID on image: 29763551+04+32
Firmware Image HW ID matched Board HW ID
MODEL ID on board: WNR2000V3
MODEL ID on image: WNR2000V3
Firmware Image MODEL ID matched Board model ID
[after this is all the Erase Flash indicators]
After the router completes flashing it takes a LONG time to come ready much longer than the factory firmware. Probably because of the newer kernel.
And, yeah. Netgear DID keep the OpenWRT logo and exhortation about router firmware being free - in it's factory firmware with the check that denies regular openwrt to be flashed via uboot. Hopefully the programmers that did that got fired over something years later.
1 Like