Joined: 31 Jul 2021 Posts: 2146 Location: All over YOUR webs
Posted: Tue Aug 02, 2022 11:07 Post subject:
unregd wrote:
I see, thanks, but I missed the worst part, I've edited the original post, this new r49599 boot loops, doesn't work at all.
What perhaps would shed some light on this, is flashing via CLI the 49599 build, and grabbing the flash output, then flashing the router database build via CLI and grabbing that flash output.
Then we can compare what blocks get erased vs written on both builds and see if the router has ran out of blocks or not.
You can flash the 49599 build via cli grab output to file and straight after without rebooting flash the router database build grab the output to file. Only after rebooting the flash will apply so technically you can flash many builds via CLI in sequence to make any comparisons to blocks erased/written etc between builds.
Then attach both outputs to your reply for comparison.
Joined: 08 May 2018 Posts: 14242 Location: Texas, USA
Posted: Tue Aug 02, 2022 13:06 Post subject:
Are we sure that the right upgrade file after initial flash is being used? Something to note here is the firmware image size differences between the v1 and v2 for factory-to-ddwrt.bin files, but the webflash.bin files are the same size:
So, the possibility of image being too big might be the issue, but only a CLI flash OR flash with either tail -f /var/log/messages running via telnet / ssh or serial hooked up OR TFTP / serial flash with serial hooked up would tell us what's wrong.
I see, thanks, but I missed the worst part, I've edited the original post, this new r49599 boot loops, doesn't work at all.
What perhaps would shed some light on this, is flashing via CLI the 49599 build, and grabbing the flash output, then flashing the router database build via CLI and grabbing that flash output.
Then we can compare what blocks get erased vs written on both builds and see if the router has ran out of blocks or not.
You can flash the 49599 build via cli grab output to file and straight after without rebooting flash the router database build grab the output to file. Only after rebooting the flash will apply so technically you can flash many builds via CLI in sequence to make any comparisons to blocks erased/written etc between builds.
Then attach both outputs to your reply for comparison.
To flash via CLI you enable SSH and upload the firmware or grab via curl to /tmp folder on router then issue write filename.extension linux the flash will begin and output the validation erase/write process
Router/Version: Netgear R6300V2
File/Kernel: Linux 4.4.302-st14 #6836 SMP Sat Jul 30 03:31:48 +07 2022 armv7l
Previous/Reset: R6300v2-V1.0.4.52_10.0.93/Reset before and after upgrade
Mode/Status: AP Wireless 2.4g and 5g
Issues/Errors: With ASUS PCE-AC88 mixed/161/vht80/upup, can't get 1300 mbps (5Ghz), only 975mbps max. It works fine while using the Netgear factory firmware.
Router/Version: Asus RT-N66U
File: dd-wrt.v24-49599_NEWD-2_K3.x-big-RT-N66U.trx
Firmware: DD-WRT v3.0-r49599 big (07/30/22) (prev. DD-WRT v3.0-r49567 big (07/27/22))
Kernel: Linux 4.4.302-st14 #17672 Sat Jul 30 05:22:56 +07 2022 mips
Mode: Gateway, SFE disabled, Wifi disabled, WAN disabled, Wireguard Endpoint for external VPS, connected via LAN to WRT1900ACS v2, Keep Alive reboot 6:05 in the morning
Reset: No
Status: Installed at release, ok.
I see, thanks, but I missed the worst part, I've edited the original post, this new r49599 boot loops, doesn't work at all.
What perhaps would shed some light on this, is flashing via CLI the 49599 build, and grabbing the flash output, then flashing the router database build via CLI and grabbing that flash output.
stock -> 11-03-2020-r44715 factory-to-ddwrt + after flashing do nothing -> 07-30-2022-r49599 webflash
= works
This makes me wonder if the newer factory-to-ddwrt versions bootloop for the same reason when upgrading from stock to newer than the above 11-03-2020-r44715.
Huh, on this page of the main Archer C9 thread, it was reported r33772 was the last that could go from stock to DD-WRT without bricking (later factory-to-ddwrt apparently don't overwrite a special TP-Link partition holding radio settings which makes it easier to return to stock, but if this keeps it from booting...) and r44715 is later than when that thread was locked.
In any case unregd, you are now the person reporting the latest working build on the Archer C9 v1 is r49599. Can I ask if you are using it as Gateway or AP? The previous latest reported working build was r49418 which might not work with IPv4 if used as Gateway (perhaps unless CTF is enabled)
Joined: 31 Jul 2021 Posts: 2146 Location: All over YOUR webs
Posted: Sat Aug 06, 2022 11:05 Post subject:
unregd wrote:
the-joker wrote:
unregd wrote:
I see, thanks, but I missed the worst part, I've edited the original post, this new r49599 boot loops, doesn't work at all.
What perhaps would shed some light on this, is flashing via CLI the 49599 build, and grabbing the flash output, then flashing the router database build via CLI and grabbing that flash output.
stock -> 11-03-2020-r44715 factory-to-ddwrt + after flashing do nothing -> 07-30-2022-r49599 webflash
= works
This makes me wonder if the newer factory-to-ddwrt versions bootloop for the same reason when upgrading from stock to newer than the above 11-03-2020-r44715.
I see, thanks, but I missed the worst part, I've edited the original post, this new r49599 boot loops, doesn't work at all.
What perhaps would shed some light on this, is flashing via CLI the 49599 build, and grabbing the flash output, then flashing the router database build via CLI and grabbing that flash output.
stock -> 11-03-2020-r44715 factory-to-ddwrt + after flashing do nothing -> 07-30-2022-r49599 webflash
= works
This makes me wonder if the newer factory-to-ddwrt versions bootloop for the same reason when upgrading from stock to newer than the above 11-03-2020-r44715.
I still dont see the CLI flash outputs I asked for to see what is what on that side, if the flashes that bootloop need more blocks than available or what, cant tell without the flash outputs.
The
"
Firmware Upgrade and Reset
After Flashing
"
to clear or not to clear the nvram breaks it or makes it. I don't see the need for cli flash logs now since it is working from the gui, without turning on clearing the nvram.