I would assume so, yes.
No chance of bricking the router with a TAR?
Nothing's fool proof, you could in theory encounter a power cut mid flash process ...
There's always recovery https://openwrt.org/toh/netgear/wndr3700#recovery_flash_in_failsafe_mode
Hey Frolic, I got this irritating, arbitrary ban on replying as a new user (and I couldn't PM to let you know) so I ended up doing a ton of other stuff. Sorry about the delay in replying. The problem with this router is that the recovery has never worked when it's been tested before.
Thanks 
Hi.
I have just try to upgrade from 19.07.7 stable to 21.02 snapshot and ran into a lot of troubles. But I managed to solve: here is a return of experience.
- I tried to upgrade directly with a custom build 21.02 : the router hung (orange blinking for a long time, no response). I didn't keep the settings while upgrading.
- I used nmrpflash to return to stock firmware.
- I flashed successfully the squash-factory provided in the snapshot repository, than upgraded to the custom build.
Everything seems to work properly now.
I too tried the direct sysupgrade route from 19.07 -> 21.02 rc3, indeed it's a no-go. However, it left my router in the recovery mode so it was pretty easy to hook up to the laptop and ftp over the factory image.
A couple of things I learned:
- Bridging WLAN is different, have to go to Network -> interfaces -> devices and bridge there. "Ports" are the terminology for the device name now. For example I bridged wlan0-1 (2.4ghz) and wlan1-1 (5ghz) for a guest network.
- In my guest network (using the wndr3700v4 as a dumb-AP), I had to add "custom dns" servers because guest DNS requests weren't being forwarded for some reason (triple checked dns zone, still not sure what's happening).
- Wireless performance seems a bit slower.
- Wireless stability is still in question. There are times when wireless seems to freeze, then return within a few seconds, with nothing in system log to indicate a problem. To be fair, this could happen in 19.07 and required me to setup daily reboots (not doing that with 21.02 to test).
- Chromecast w/ GTV does NOT like the WPA2/3 mixed setting, had to bump it down to WPA2-PSK. I saw something about disabling protection frames in WPA3, but that still didn't work ... still had to bump down to WPA2.
Hi,
I like a lot to have a spare/backup hardware. Even if is it not the same model or arch, even if it less powerfull and/or doesn't have wifi.
With a backup hardware you can first install the version you want to try on the backup hw without loosing internet access (because you will perhaps need to have internet working for installing mandatory packages) once this backup hw is working you can with this new experience in mind reinstall the main router
In my personnal case my ISP needs VLANs and Vlan-Prio in order to work, so I need at lease to install 2 packages (ip-full and iptables-mod-ipopt), no internet without them
The first time I add to reinstall my router (one year after the first install) I had forgotten that ... if was really harder to have a working configuration (not too hard, but not as fast: I had to share internet in wifi from my smartphone and connect the open-wrt router to this hostspot to install the 2 packages).
old routers can be found really cheap on ebay ...
good luck
I achived to install 21.02 using nmrpflash with a factory image. That is not an official way to do. Once the device is on 21.02, I was able to install successive RC without trouble.
The device seems to have issue when sysupgrading from 19.07
I also had an issue related to the image size. I tried first to upload an image >8MB and brick the router. Only image <8MB can be loaded. I think I will replace it without a better model, and recycle it as an AP in near future.
2 Likes
Hello,
I was following the instructions at Netgear WNDR3700v4 not booting anymore after upgrading to 21.02.01 - #2 by hnyman to no avail.
Tried tftp flashing to any of openwrt 21.02.x but it was just boot looping.
Flashing to openwrt 19.xx and stock firmware works fine.
Finally I used nmrpflash to flash openwrt 21.02.2, 21.02.1, 21.02.0 and it's still boot looping.
What to do, what to try?
Thanks!
Sysupgrade error (from 18.06, ar71xx to ath79) - Installing and Using OpenWrt - OpenWrt Forum
I also encountered a similar problem before, but I upgraded successfully after using tftp mode. If you are not using the firmware version with the ...squashfs-factory.img suffix, I suggest you use this version and try to upgrade in tftp mode. Because the version before 19 and the version after 21 may be different in terms of partitions
Yep, I was using factory.img all along for all versions of 21.02.x, but keeps boot looping. Just tried again tftp method with the latest openwrt-21.02.2-ath79-nand-netgear_wndr3700-v4-squashfs-factory.img, but same result.
tftp method works just fine for openwrt-19.07.9-ar71xx-nand-wndr3700v4-ubi-factory.img
Pure speculation, but there might be a bad flash block at the end of the kernel area, and that causes flash to skip a block, leading rootfs to start at a wrong place.
19.07 has smaller kernel than 21.02, so there the rootfs start at the expected place and the bad block is safely inside rootfs area.
If you have serial connection to the router, you could see if there is any indication about a bad block in the boot process or the tftp flashing process.
interesting suggestion, It could very well explain this mystery.
Unfortunately, I am traveling overseas at the moment, so don't have my serial USB dongle with me.
Once I get back (with the router), I'll hook up the serial console and try to figure out whether there are bad blocks. What would be an indication if there are bad blocks?
If it happens that there are bad blocks, what can be done? Just keep using version 19.07 that seems to work fine?
Similar issues have been rarely observed e.g. with the popular R7800.
One solution has been to first use a initramfs image to boot, and then sysupgrade from it.
As OpenWrt nand sysupgrade is two-stage, kernel and hand separately, it may help. On the other hand, as you started with a running OpenWrt and tried to sysupgrade from it, the problem should have been avoided already...
Just first connect the serial and see what the error actually is.
Edit:
have you actually tried sysupgrade from 19.07?
Or have you just tried with the factory image? (Factory image can suffer from that bad block problem)
Yes I did try the sysupgrade from 19.07 but that had the same result with boot looping.
I will try the initramfs booting once I get hold of the USB/Serial dongle.
Hi.
I'm afraid I can't tell more, you seemed to have tried all that is obvious.
As you can read in the message, I had a lot of issues, and managed to flash RC with nmrpflash. After, I was able to upgrade the device to later versions, until 21.02.2.
Reverse to netgear firmware, than try to flash RC1 with nmrpflash.
https://downloads.openwrt.org/releases/21.02.0-rc1/targets/ath79/nand/openwrt-21.02.0-rc1-ath79-nand-netgear_wndr3700-v4-squashfs-factory.img
If you succeed, than upgrade to 21.02.2.
If you don't, just keep it to 19.07.
Finally got around it, and setup the serial console. At the start there is some garbage in the console but quickly clears up, hope nothing is missed there. I suspect different baud rate for the first stage uboot.
This shows up and looks suspicious:
Bad eraseblock 73 at 0x000000920000
Here is the full log from the console:
� � 0�570375] Serial: �25�/16550 driver, 16 p�rt�, IRQ sharing en�bl�d
[ 0�57�342] console [tt�S0� disabled
[ 0.603275] ser�al�250.0: ttyS0 at �MI� 0�18020000 (irq = �1,�base_baud = 2500�00� i� a 16550A
[ 0.612482] console [ttyS0] enabled
[ 0.612482] console [ttyS0] enabled
[ 0.619895] bootconsole [early0] disabled
[ 0.619895] bootconsole [early0] disabled
[ 0.635389] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xf1
[ 0.641846] nand: Micron NAND 128MiB 3,3V 8-bit
[ 0.646484] nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
[ 0.654224] Scanning device for bad blocks
[ 0.662204] random: fast init done
[ 0.667828] Bad eraseblock 73 at 0x000000920000
[ 0.749881] 12 cmdlinepart partitions found on MTD device ar934x-nfc
[ 0.756356] Creating 12 MTD partitions on "ar934x-nfc":
[ 0.761667] 0x000000000000-0x000000040000 : "u-boot"
[ 0.768101] 0x000000040000-0x000000080000 : "u-boot-env"
[ 0.775606] 0x000000080000-0x0000000c0000 : "caldata"
[ 0.782069] 0x0000000c0000-0x000000140000 : "pot"
[ 0.788950] 0x000000140000-0x000000340000 : "language"
[ 0.795572] 0x000000340000-0x0000003c0000 : "config"
[ 0.802709] 0x0000003c0000-0x0000006c0000 : "traffic_meter"
[ 0.809724] 0x0000006c0000-0x0000008c0000 : "kernel"
[ 0.816828] 0x0000008c0000-0x000001fc0000 : "ubi"
[ 0.823155] 0x0000006c0000-0x000001fc0000 : "firmware"
[ 1.186217] 0x000001fc0000-0x000002000000 : "caldata_backup"
[ 1.193718] 0x000002000000-0x000008000000 : "reserved"
[ 1.206735] switch0: Atheros AR8327 rev. 4 switch registered on ag71xx-mdio.0
[ 2.503508] ag71xx ag71xx.0: connected to PHY at ag71xx-mdio.0:00 [uid=004dd034, driver=Atheros AR8216/AR8236/AR8316]
[ 2.514909] eth0: Atheros AG71xx at 0xb9000000, irq 4, mode: rgmii
[ 2.523713] NET: Registered protocol family 10
[ 2.533954] Segment Routing with IPv6
[ 2.537779] NET: Registered protocol family 17
[ 2.542399] bridge: filtering via arp/ip/ip6tables is no longer available by default. Update your scripts to load br_netfilter if you need this.
[ 2.556128] 8021q: 802.1Q VLAN Support v1.8
[ 2.564240] UBI: auto-attach mtd8
[ 2.567645] ubi0: attaching mtd8
[ 2.860614] ubi0: scanning is finished
[ 2.880221] ubi0: attached mtd8 (name "ubi", size 23 MiB)
[ 2.885772] ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
[ 2.892765] ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
[ 2.899654] ubi0: VID header offset: 2048 (aligned 2048), data offset: 4096
[ 2.906726] ubi0: good PEBs: 183, bad PEBs: 1, corrupted PEBs: 0
[ 2.912835] ubi0: user volume: 0, internal volumes: 1, max. volumes count: 128
[ 2.920168] ubi0: max/mean erase counter: 2/1, WL threshold: 4096, image sequence number: 835017511
[ 2.929361] ubi0: available PEBs: 160, total reserved PEBs: 23, PEBs reserved for bad PEB handling: 19
[ 2.938855] hctosys: unable to open rtc device (rtc0)
[ 2.944123] ubi0: background thread "ubi_bgt0d" started, PID 370
[ 2.950566] VFS: Cannot open root device "(null)" or unknown-block(0,0): error -6
[ 2.958211] Please append a correct "root=" boot option; here are the available partitions:
[ 2.966709] 1f00 256 mtdblock0
[ 2.966715] (driver?)
[ 2.973367] 1f01 256 mtdblock1
[ 2.973373] (driver?)
[ 2.980008] 1f02 256 mtdblock2
[ 2.980012] (driver?)
[ 2.986672] 1f03 512 mtdblock3
[ 2.986677] (driver?)
[ 2.993326] 1f04 2048 mtdblock4
[ 2.993331] (driver?)
[ 2.999967] 1f05 512 mtdblock5
[ 2.999971] (driver?)
[ 3.006630] 1f06 3072 mtdblock6
[ 3.006636] (driver?)
[ 3.013284] 1f07 2048 mtdblock7
[ 3.013290] (driver?)
[ 3.019925] 1f08 23552 mtdblock8
[ 3.019929] (driver?)
[ 3.026588] 1f09 25600 mtdblock9
[ 3.026594] (driver?)
[ 3.033243] 1f0a 256 mtdblock10
[ 3.033248] (driver?)
[ 3.039971] 1f0b 98304 mtdblock11
[ 3.039975] (driver?)
[ 3.0J���3] Kernel panic - not sI=M V�. VFS: �r�ble to mount root fs on unknown-block(0,0)
Looks like the bad eraseblock is the fourth block in the UBI partition. Possibly that location is needed for UBI subpartition logic, and causes the error.
UBI is good is handling bad blocks in the middle of the partition, but the first few blocks might be critical.
(But it seems to account for the bad block in the UBI init log part: 183 good, 1 bad PEB.)
Bad blocks near the kernel/rootfs border can be difficult.
If 19.07 works for you, you might to stick into it. 
Stock and 19.07 do work.
I'll stick to 19.07 then.
Thank you all for the help!
just "upgraded" v18.06.1 to v22.03.0 using luci / Flash new firmware image with squashfs-sysupgrade.bin although the release notes said it's not possible.