Posted: Mon Jan 11, 2021 6:44 Post subject: [SOLVED] Can't update firmware via web gui
Hello,
My hardware is belkin f7d3302 v1.
I just wanted to ask every time i need to update dd-wrt I use the web gui (firmware upgrade tab) for that, after clicking "upgrade" i receive the message upgrade successful, rebooting..., and baam... after reboot it's still the same firmware. The same issue with tftp.
In the end i have to use CFE to update the firmware.
Is this truly normal? Why can't i update via gui?
I can restore defaults settings via gui just fine but i can't upgrade the firmware.
Or is there a setting I am missing?
Regards!
Last edited by AlphaCJ44 on Sat Jun 19, 2021 4:26; edited 2 times in total
Joined: 16 Mar 2019 Posts: 353 Location: Szczecin, Poland EU
Posted: Mon Jan 11, 2021 22:10 Post subject:
In first step restore factory default on your router. Now start ssh service on actual DD-WRT version. Login to command line and update firmware. In the end of operation you have information about problem. For example: "File is too big". I have the same situation when firmware for my Netgear is too big or incorrect. I'm update via command line always.
Joined: 24 Oct 2008 Posts: 1079 Location: Latin America
Posted: Tue Jan 12, 2021 15:29 Post subject: Re: Can't update firmware via web gui
AlphaCJ44 wrote:
Hello,
My hardware is belkin f7d3302 v1.
I just wanted to ask every time i need to update dd-wrt I use the web gui (firmware upgrade tab) for that, after clicking "upgrade" i receive the message upgrade successful, rebooting..., and baam... after reboot it's still the same firmware. The same issue with tftp.
In the end i have to use CFE to update the firmware.
Is this truly normal? Why can't i update via gui?
Which builds have you tried? I don't recall having issues with that router (with stable builds) except requiring an extra reboot at the end if I choose reset to factory settings while flashing. _________________ If you want support, please read first the announcements and forum rules.
Si usted desea ayuda, por favor lea primero los anuncios y las reglas del foro.
Posted: Wed Jan 13, 2021 7:13 Post subject: Re: Can't update firmware via web gui
feliciano wrote:
Which builds have you tried?
I am trying using beta builds, dd-wrt.v24-34311_NEWD-2_K3.x_mega_f7d3302.bin for example. There's no other issue besides not being able to upgrade ddwrt version via gui or tftp or command ssh, only works by cfe.
I did a factory reset (with the gui) after boot up with the correct bios.
I used the following login during the process:
usr: root
pw: root
I did a lot of testing so I used v24-sp2 (03/25/13) build 21061 mini (dd-wrt.v24-21061_NEWD-2_K2.6_mini_f7d3302.bin) as a middle step but I don’t know if that is needed.
I waited at least 10 min after each try and then a power cycle.
https://ftp.dd-wrt.com/dd-wrtv2/downloads/betas/ _________________ "The woods are lovely, dark and deep,
But I have promises to keep,
And miles to go before I sleep,
And miles to go before I sleep." - Robert Frost
"I am one of the noticeable ones - notice me" - Dale Frances McKenzie Bozzio
Posted: Sun Nov 05, 2023 13:15 Post subject: Re: [SOLVED] Can't update firmware via web gui
AlphaCJ44 wrote:
Hello,
My hardware is belkin f7d3302 v1.
I just wanted to ask every time i need to update dd-wrt I use the web gui (firmware upgrade tab) for that, after clicking "upgrade" i receive the message upgrade successful, rebooting..., and baam... after reboot it's still the same firmware. The same issue with tftp.
No Alpha, it's not you. This is a bug I have mentioned in several build posts.
The problem is that with many routers they don't have a lot of free ram. This is HIGHLY dependent on the firmware build used. Your router for example has 64MB of ram - but if you load a larger build on there that has a lot of features on it, when that build is running it creates data structures in memory that use very large chunks of ram up.
The way the webinterface seems to work during updating is the build file itself must entirely fit into process memory in order for the webinterface to flash it. If it's out of process ram then it just errors behind the scenes. The webinterface is not written to pass these errors back to the user.
If you telnet into your router, and issue a cd/tmp, wget http://blahblahblah/buildIwant then write buildIwant linux - then you WILL see the error but usually it will flash anyway because when run from the command line the router is able to break the file into smaller chunks then write them into the flash.
Read the wiki entry on flashing from the command line for more information.
Flashing from tftp during some special recovery mode as you did is highly router-dependent, some of them support it some don't, some require the ckecked builds some don't. I DON'T recommend that since you are bypassing every safety check available inside of dd-wrt to prevent the flash chip from being flashed with a build too large.
What the CFE tftp servers seem to do is just take whatever you feed them and write it all out - some routers have critical CFE variables saved at the very end of the flash ram but the CFE tftp servers will happily allow you to write right over them and brick the router. This is why you so often see recommendations to go from dd-wrt BACK to factory flash then from that back to DD-WRT. Some factory flashes are built in such a way that the manufacturer tacks on those special CFE variables to the end of the flash file and with those routers even if you have flashed too large a build on to the router and bricked it, the tftp recovery method will magically make everything right. Of course, you have to have enough variables left in the special place for the CFE to actually get a MAC address and IP address assigned for this to work and sometimes those are trashed also. In that case serial recovery is the only way followed by the special commands to reenter a MAC and IP into the CFE variable space.