I have a Netgear WNDR3300. I was wanting to flash a different build on it so I did "erase nvram; reboot" from SSH. The old build was the 12548 eko mini build, and the new one is the 21286 standard generic. It wasn't till after that I read this on the Peacock thread:
Quote:
Finally, don't listen to users telling you to do "erase nvram" on a telnet cmd line.
This wipes out the complete nvram area (nvram variables and the nvram header) together with anything else residing in the mtd partition named nvram.
After flashing the new build (successfully), it works *pretty* well. There are just two issues I've found with it:
1. The MAC addresses reset to 00:00:FF:00:00:00
2. The router crashes when applying settings in the Web GUI, then reboots and hangs, requiring a manual power cycle.
#1 was annoying for a bit until I learned how to set the hardware/MAC addresses in NVRAM. It's kind of annoying though that I have to add these variable assignments to a startup script. I wonder, is there a way to set the MAC addresses to stay even when I do an NVRAM reset? I've done a 30/30/30 reset plenty of times in the past and the MACs have always stuck.
#2 is more than annoying, it actually interferes with things. I know it's possible that it's the build that's the problem, but before I rule that out, I wonder if running "erase nvram" screwed more stuff up than just the MAC addresses.
I'm sorry I didn't read the entire Peacock thread before flashing (though I have read it in the past).
I hope there's someone that can point me in the right direction.
I'm not sure if the wiki article is completely up to date, but if you have not read through that, then there's a start. Looks like the recommended build is 33679.
You may be able to get away with the std build, if it's small enough. Older routers like that, erasing nvram can be a bad thing. Hopefully, it didn't affect the bootloader. If you have a way to set up for serial recovery, watching the CFE boot log, etc. might help figure out what's going on. Telnet / ssh and 'cat /var/log/messages' after boot-up may not show what exactly is causing the issues. You *may* have to go back to stock and start over, or worse, but hopefully not. I was trying to search the threads on this device to see if there was known issues, but have not found anything yet.
I have a Netgear WNDR3300. I was wanting to flash a different build on it so I did "erase nvram; reboot" from SSH. The old build was the 12548 eko mini build, and the new one is the 21286 standard generic. [...]
After flashing the new build (successfully), it works *pretty* well. There are just two issues I've found with it:1. The MAC addresses reset to 00:00:FF:00:00:00
2. The router crashes when applying settings in the Web GUI, then reboots and hangs, requiring a manual power cycle.#1 was annoying for a bit until I learned how to set the hardware/MAC addresses in NVRAM. It's kind of annoying though that I have to add these variable assignments to a startup script. I wonder, is there a way to set the MAC addresses to stay even when I do an NVRAM reset? I've done a 30/30/30 reset plenty of times in the past and the MACs have always stuck.
#2 is more than annoying, it actually interferes with things. I know it's possible that it's the build that's the problem, but before I rule that out, I wonder if running "erase nvram" screwed more stuff up than just the MAC addresses.
Does the router status page still report properly as a WNDR3300? That would be the other issue that can arise from loss of non-recoverable nvram.
You shouldn't need a startup script to set the nvram. Just a `nvram set {parameter}={value}` for each, then a `nvram commit` to save it over reboots. Does the WNDR3300 thread talk about `erase nvram` usage? Nothing in the wiki. I use it on my WNDR4000 and 4500v2. I take it you never saved an nvram backup (manually w/ `nvram show` or via GUI backup)?
Joined: 08 May 2018 Posts: 14222 Location: Texas, USA
Posted: Wed Jul 25, 2018 20:05 Post subject:
https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=27684 < - original support request thread, I think. There's a lot of posts to sort through on this device. I didn't find anything regarding nvram wiping, BUT I just noticed the closest partition on OEM firmware is board data....
I'm not sure if the wiki article is completely up to date, but if you have not read through that, then there's a start. Looks like the recommended build is 33679.
Sweet, I'll try it.
kernel-panic69 wrote:
If you have a way to set up for serial recovery, watching the CFE boot log, etc. might help figure out what's going on. Telnet / ssh and 'cat /var/log/messages' after boot-up may not show what exactly is causing the issues.
I may need some guidance on this. I'll wait and see if the other stuff works first.
kernel-panic69 wrote:
You *may* have to go back to stock and start over, or worse, but hopefully not. I was trying to search the threads on this device to see if there was known issues, but have not found anything yet.
Worst-case scenario, I may need to do this.
jwh7 wrote:
Does the router status page still report properly as a WNDR3300?
Yes, thankfully.
jwh7 wrote:
You shouldn't need a startup script to set the nvram. Just a `nvram set {parameter}={value}` for each, then a `nvram commit` to save it over reboots.
Yeah, I had tried that previously but after a reboot, it never stayed. Kept reverting to the 00:00:FF:00:00:00 address. And yes, I made sure to run `nvram commit`.
jwh7 wrote:
I take it you never saved an nvram backup (manually w/ `nvram show` or via GUI backup)?
I did on the older build (12548). Maybe I could flash that build and then restore the backup, if I can still find it... Yikes.
https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=27684 < - original support request thread, I think. There's a lot of posts to sort through on this device.
Wow, that thread is huge.
kernel-panic69 wrote:
I didn't find anything regarding nvram wiping, BUT I just noticed the closest partition on OEM firmware is board data....
Right. What does that imply? Sorry, bit of a noob here.
By the way, thanks guys for replying and not making me feel like an idiot.
Joined: 08 May 2018 Posts: 14222 Location: Texas, USA
Posted: Wed Jul 25, 2018 20:27 Post subject:
I'm going to guess that board_data could include things like mac addresses and other hardware-related information like that. That is at least my logic and best semi-educated guess and would seem to be a possibility for the issue. I would re-read thoroughly the peacock and that other thread I linked to see if there is any mention of this kind of issue and whether or not erasing nvram is a bad idea on this device. There are plenty of threads if you search for "WNDR3300" with "Broadcom...." and "DD-WRT" limitations selected in the search function. Lots of reading. Because people don't use the search function, perhaps, or maybe not.
That thread may help resolve returning to DD-WRT, but the file from the wiki *should* work. The mac address issue seems to lead me to believe there is a larger issue at hand, and worst case scenario is serial recovery or JTAG, but it's not completely bricked.... and I would think the board_data partition would've been restored. Did you do a full reset when you flashed back to stock?
Joined: 08 May 2018 Posts: 14222 Location: Texas, USA
Posted: Thu Jul 26, 2018 7:16 Post subject:
Also, I'm wondering if what you actually need to do is to grab the stock 1.0.14 file from here and use it to downgrade to it before trying to install initial flash:
I seem to recall some routers are finicky on what stock firmware version will work with the initial flash, but I'm drawing at straws since others aren't chiming in....
That thread may help resolve returning to DD-WRT, but the file from the wiki *should* work. The mac address issue seems to lead me to believe there is a larger issue at hand, and worst case scenario is serial recovery or JTAG, but it's not completely bricked.... and I would think the board_data partition would've been restored. Did you do a full reset when you flashed back to stock?
It looks like the solution on that thread was to flash a different build bin file. My understanding is that I have to use a chk file when I'm on stock firmware; is that correct?
By full reset do you mean 30/30/30? If so, then yes.
kernel-panic69 wrote:
Also, I'm wondering if what you actually need to do is to grab the stock 1.0.14 file from here and use it to downgrade to it before trying to install initial flash
Worth a try for sure. I tried a different stock chk file from Netgear and tried uploading it from the stock web GUI but it still said "upgrade failed". But I will try this one.
kernel-panic69 wrote:
I seem to recall some routers are finicky on what stock firmware version will work with the initial flash, but I'm drawing at straws since others aren't chiming in....
I really appreciate your help. I'll keep making my way through the WNDR3300 thread.
This is frustrating. I'm not sure what do to. The 1.0.14 firmware didn't work. TFTP didn't work either, though I had to kind of guess at how to do it since the only instructions I could find were for if you already have DD-WRT on it. So yeah... Not sure what to do. Also, looks like the Netgear Recovery Utility doesn't exist anymore, couldn't find it anywhere.
That's straight off the Netgear site. I tried to find the recovery tool software, too, no luck. You may have to work your way up to the latest Netgear firmware and try each to see if it will take, or, just do the TFTP method. Worst case is you set up to do a serial recovery and recover it as if it were bricked completely and go from there. Kinda wished I had the thing here in front of me to see if I could get it to act right.
I haven't posted in a while so I suppose I should give an update:
I kept trying different things and I think I eventually bricked. I figured I'd cut my losses and just get a new (-ish) router. So I suppose we can consider this incident closed. Thanks for all your help!
Oh, and I guess if anyone wants a basically bricked Netgear WNDR3300v1 let me know.
