Posted: Fri Aug 26, 2011 2:55 Post subject: Questions to DD-WRT forum for Linksys WRT54GS V2 conversion
Bear in mind that my level of expertise in router firmware is near zero; previous experience limited to upgrading my Linksys routers.
I have been considering conversion of my WRT54GS V2 , firmware V4.71.4 to DD-WRT to possibly coax a little more power out of it as well as having more features in the firmware. However recently my priority to do this was increased because the WRT54GS does not play well with my new MagicJack phone; dropped calls. A friend loaned me his Buffalo running DD-WRT and viola!! MagicJack problem solved. So here I am reading up on how to convert and have run into a couple of confusing pieces of instruction on the WIKI; both in the Peacock thread:
Note 9- How to backup your CFE - DO IT! This note contains 2 active links the first one, http://www.dd-wrt.com/phpBB2/viewtopic.php?t=55577 gives instructions that seem to pertain only to a router that already contains DD-WRT; am I misunderstanding this?
The second link http://192.168.1.1/backup/cfe.bin which I thought might be for a router with Linksys firmware installed leads to the following error message:400 Bad Request Cross Site Action detected!
Not wishing to take unecesary risks, I thought that it would be a good preventative to save the Linksys bootloader in case the DD-WRT doesn't work out; however, I am not sure that is what is intended in the WIKI. But the bold title of note 9 is a bit intimidating to overlook. I am tempted to ignore note 9 at this point and not look back and go ahead and flash with DD-WRT based on my experience with the borrowed Buffalo.\; but the next hurdle described below in note 1. is currently preventing progress.
1.DO A HARD RESET *BEFORE AND AFTER* YOU FLASH FIRMWARE. This note contains the following: “Note: WRT54GS v1.1, GS v2, and GS2.1 models can brick after a hard reset no matter how it is done.” Now that is a rather intimidating note that names my router as a candidate. However it further states: “See this thread and the solution in Vulcan's post:
http://www.dd-wrt.com/phpBB2/viewtopic.php?t=45024 “ Clicking on this link leads to
“DD-WRT will only work is if I do not use the reset to factory defaults and also when i chose no reset when you upgrade the firmware. It works fine along that, but the second you do 30/30/30, no response, basically bricks with power light flashing at you. “ Further down the thread:
Vulcan's April 08 post states: “Meanwhile, try this. It has worked for me a few times.
erase nvram;nvram set sdram_init=0x010b;nvram commit;reboot
I got the idea from http://forum.openwrt.org/viewtopic.php?id=580&p=5
Take a look at post #114 on that link.
Edit 18/11/2008. I don't think the nvram commit is required. See my post below. “
Looking at the openwrt.org link I find:
2005-4-22 post by rzeldent as follows: The first time it booted there were also a lot of panics etc but i repeated booting a feew times. Suddenly it came up and had a working DD-WRT image (that was on the image). I notices that sometimes it came up and had this stange message while booting: 'The sdram_init is 0x000b, not 0x010b'. When it came up, I checked the nvram and the sdram_init was 0x010b.
I reflashed the OpenWRT software and still kermel panics. I was unable to set any NVRAM variables; the commit never returned from the commit function. Next I used the JTAG to clear the NVRAM and using the CFE monitor to set the sdram_init to 0x010b and it worked. Since, the WRT54GS is working like a charm............. I bought the WRT54GS in the Netherlands, so the EU version. I don't know if the sdram_init value of 0x010b is the same on all the WRT54GS v1.1 routers.
And the last post on the peacock note 1 by
varaonaid pm 19 March 2011states: " NVM,seems the router specific page on the wiki gives other instructions that makes this unnecessary. Thanks for all the work though!"
CONCLUSION: I give all the details above in case anyone else is trying to do the same thing as I am and it might be useful to them to follow the threads; but the bottom line boils down to three questions:
1.Is there a capabilty available for backing up the Linksys bootloader via web gui?
2.Is the final post by varaonaid on 19 March 2011, the final answer to this question of how to reset a WRT54GS that has been flashed to DD-WRT? It sounds as if varanaid is suggesting that the DD-WRT firmware has been altered to have the correct starting address for SDRAM and one can simply follow the latest flash instructions and not have to edit the hex code or worry about bricking the WRT54GS router? I cannot find this solution offered on the WIKI.
3. Do the EU (Europe) versions of this router require different firmware?
Maybe someone out there has waded through all this already and has answered these questions?
Posted: Fri Aug 26, 2011 3:08 Post subject: Re: Questions to DD-WRT forum for Linksys WRT54GS V2 convers
JPfrmME wrote:
1.Is there a capabilty available for backing up the Linksys bootloader via web gui?
2.Is the final post by varaonaid on 19 March 2011, the final answer to this question of how to reset a WRT54GS that has been flashed to DD-WRT? It sounds as if varanaid is suggesting that the DD-WRT firmware has been altered to have the correct starting address for SDRAM and one can simply follow the latest flash instructions and not have to edit the hex code or worry about bricking the WRT54GS router? I cannot find this solution offered on the WIKI.
3. Do the EU (Europe) versions of this router require different firmware?
1. No. CFE backup requires dd-wrt firmware.
2. Can't comment on this as I've never had to do it. You will have to sort out who appears to be credible.
3. No. The GS v2 will be the same in EU and North America. You can check the supported devices wiki and compare FCC codes if there is one on your router.
Posted: Fri Aug 26, 2011 16:01 Post subject: Linksys WRT54GS V2 conversion
Pinnochio Thanks for the response. I'm still learning my way around this forum. As a result of replying to you here, a "Topic Review" appeared at the bottom of my question, with a 2011 thread between vulcan59 and ichilton that I had not seen before. It contains a lot of information on this topic for me to digest before I attempt to do the flash. I don't understand the architecture of the router or it's OS; so am having to try to read between the lines to understand everything. I have never heard of Jtag until yesterday; so I think I should read up on that to better understand what is being said. e.g. the suggestion to Backup cfe using http://192.168.1.1/backup/cfe.bin I thought would be done via the ethernet input; but maybe this requires Jtag too? I can try it via ethernet; I think no harm would be done.
Posted: Sun Sep 04, 2011 1:30 Post subject: Linksys WRT54GS V2 conversion
I am happy to report on the successful conversion of a LinkSys WRT54GS V2 from stock software to DD-WRT via web gui without any problems. No telnet; no jtag was used. No problems or unexpected results were experienced. My linksys router is now running v24-sp2 (12/18/09)mini build 13491M VINT Eko and my problem with the Magic Jack phone dropping calls has been solved. I did not make any speed measurements before the switch over so I can't give actual speed numbers; but it appears to be running as least as fast as it was before the conversion to dd-wrt.
In addition, I can report that I took the Buffalo WHR-HP-G54 that is running v24-sp2 (10/10/09)std build 13064 and set it up as a repeater with WPA2-personal-TKIP security on the primary link to the Linksys and WPA-personal-TKIP on the virtual interface. Initially I had WPA2 on both the input and output of the repeater; but it only allowed connections to ms Windows machines. Neither a second Buffalo WHR-HP-G54 not a laptop running Linux would connect to the repeater running WPA2. We (the owner of the borrowed Buffalo & myself) found by experiment that changing the output security of the first repeater to WPA- that the linux machines (additional repeater as well as linux laptop) as well as the windows machines could connect.
If there are any details I missed that anyone wants, I will provide them upon request. One comment I would make about the Peacock thread is that is sure was difficult to digest and sort out the wheat from the chaff. e.g. No where in any of the procedures that I followed was a 30/30/30 reset required.
Posted: Thu Jun 27, 2013 19:25 Post subject: v1.1 fail
I read the wiki, peacock thread, this thread, and several others. New to router tinkering, but computer literate. Using linux (Mageia 3) I bricked a GS V1.1 (or so I think). It appears very likely recoverable with a jtag (hardware seems to work) but I plan to get another router instead.
I think my big error was not clearing nvram per the instructions above before trying to fix the bootloader to allow 30-30-30 resets. Alternately, it could have been deleting the character after boot_wait=on, though it appears based on the post above that it should work that way (delete for a one byte shorter file v.s. add a space to keep the file size identical).
My full procedure was:
1: upgrade stock (3.7something) firmware to WRT54GSv3_4.71.4.001_fw.bin using web update. That was successful with the new firmware version shown on the routers web interface after the upgrade.
2: power cycle (not 30-30-30).
3: install dd-wrt.v24_mini_generic.bin via web interface. That was successful.
4: power cycle (not 30-30-30).
5: DD-WRT worked and allowed cfe backup. Retrieved CFE from unit. Also backed up settings. All successful.
6: Edited cfe sdram_init to 0x010b. Turn SSH on, SCP cfe to /tmp, telnet, unlock and install per the instructions. All reported success messages.
7: 30-30-30 reset. Brick = power light flashes fast and doesn't ever stop (have let it go quite a while > 10 minutes). Ping = destination unreachable with rig=192.168.0.10 to 192.168.0.1 and rig=192.168.1.10 to 192.168.1.1 (and I tried one other IIRC). LAN lights do work. Interestingly, router works as a generic hub passing traffic from port to port but the web interface cannot be reached nor does the box reply to a ping.
Lessons learned? I probably should have erase nvram, nvram set sdram_init=0x010b prior to fixing the bootloader? Or given DD-WRT worked after flashing it, should I have just used it? Not sure.
I'll let my son play with it. He may have a box with a serial port and windows and might try to resurrect it with jtag if he saves up a few bucks (he's 12 and loves these kids of projects). I'll get a new router known to work (and 30-30-30 without bricking) and try again. Mostly looking for an economical VPN solution.
Thanks for all the help in this thread. One recommendation: clean the whole thing up into a usable procedure known to work. That would have been handy and might have saved the box. If I were to guess, I'd guess fixing the bootloader should wait until after clearing nvram.
Posted: Thu Aug 22, 2013 21:05 Post subject: wrt54gs
i have searched high and low and i know this is an old thread BUT ..... i have a linksys WRT54GS .... i had it all setup to flash the dd-wrt firmware so i can extend my wireless signal .... somehow someway it crapped out ..... the ONLY firmware it would let me load was for a WRT54G ... not the GS like i had ... again had it to the final setup page ... didnt work under wrt54g ... now my page looks like this when i access it http://prntscr.com/1mt2qx .... i am at a loss to get this to work .. im more stubborn then anything this has to be able to be fixed .... it will not go into mgmt mode or anything ... dmz doesnt like up .... i can connect to it by cable and wireless ... .but i need it flashed so i can extend my wifi ... can ANYONE help me
i have a WRT54GS v.5 it currently has a corrupted WRT54G v.5 firmware .... what can be done?
Wow, bit of a surprise to see my post from nearly three years ago being quoted. I still have that WRT54GS 1.1, it's rock solid and works perfectly so worth trying to resurrect yours.
JTAG is the way to go. I got mine working by pin shorting because I didn't have JTAG at that time and needed to do something quick. However, you are definitely on your own if you go that route.
You shouldn't need to do anything to the cfe. Chances are it's still ok. When you can access the router again then you can update the cfe to make the fix permanent if you want. I found some old notes I made at the time about this.
1. Backup cfe using http://192.168.1.1/backup/cfe.bin
2. Edit cfe.bin using an editor which allows binary editing. Change boot_wait=off to boot_wait=on and sdram_init=0x000b to sdram_init=0x010b (I think I used bpe on linux to do this).
3. Copy updated cfe back to the router to /tmp/newcfe.bin
4. Enter command mtd unlock cfe
5. Enter command mtd write -f/tmp/newcfe.bin cfe
Hope that helps. Good luck.
1. Can you elaborate and provide a step-by-step(for noobs) instructions to permanently update cfe.bin
2. Also how do we make the necessary changes to the cfe.bin, i tried downloading the BlessHexEditor on ubuntu but i dont see any of the entries mentioned above that needs to be modified in the said files.
-------------EDIT----------------
(GOT THROUGH WITH THIS DID A TEXT STRING SEARCH AND CHANGED IT TO THE ABOVE SETTINGS)
3.How to replace the modified cfe.bin ?
i have saved this file as cfe.bin (should save it as newcfe.bin ?)
Where have you saved the updated cfe.bin? Is it on your Ubuntu machine or have you copied it to the router?
You should be able to copy the file to the router using scp. e.g. from Ubuntu cd to where the updated cfe.bin is. You can call the file what you want. I called it newcfe.bin. Then scp newcfe.bin root@192.168.1.1:/tmp/
That should get the updated cfe onto the router then you continue with step 4 and 5 on the router command line
Where have you saved the updated cfe.bin? Is it on your Ubuntu machine or have you copied it to the router?
You should be able to copy the file to the router using scp. e.g. from Ubuntu cd to where the updated cfe.bin is. You can call the file what you want. I called it newcfe.bin. Then scp newcfe.bin root@192.168.1.1:/tmp/
That should get the updated cfe onto the router then you continue with step 4 and 5 on the router command line
thanks @vulcan59 for the quick reply,in spite of the thread being a very old one.
Yes i made the modification on my Ubuntu machine.
ok then the commands go as follows ...
executed from the Ubuntu terminal ...
Command 1:
scp newcfe.bin root@192.168.2.1:/tmp/ (as that is my router IP)
after the above command should the following commands be executed through the router web-GUI->Administration->commands ???
Command 2:
mtd unlock cfe
Command 3:
mtd write -f/tmp/newcfe.bin cfe
about the changes to the pulled cfe.bin ...
Original cfe.bin is 262.1 kB (2,62,144 bytes)
the modified cfe.bin was 262.1kB (2,62,143 bytes) 1 byte less than original size as 'off' was modified to 'on' when additional alphabet 'f' was deleted it reduced the size by 1 byte. will this 1 byte smaller file hinder the update process ?
One other thread here suggested to just put your keyboard in 'insert' mode and just hit 'spacebar' instead of deleting the alphabet 'f' ... doing this maintains the byte size to the exact original one, but it creates an empty space in the place of the alphabet 'f' as shown in the image below.
Is the space ok ... will it hinder the router update in anyway ???
executed from the Ubuntu terminal ...
Command 1:
scp newcfe.bin root@192.168.2.1:/tmp/ (as that is my router IP)
after the above command should the following commands be executed through the router web-GUI->Administration->commands ???
Command 2:
mtd unlock cfe
Command 3:
mtd write -f/tmp/newcfe.bin cfe
about the changes to the pulled cfe.bin ...
Original cfe.bin is 262.1 kB (2,62,144 bytes)
the modified cfe.bin was 262.1kB (2,62,143 bytes) 1 byte less than original size as 'off' was modified to 'on' when additional alphabet 'f' was deleted it reduced the size by 1 byte. will this 1 byte smaller file hinder the update process ?
One other thread here suggested to just put your keyboard in 'insert' mode and just hit 'spacebar' instead of deleting the alphabet 'f' ... doing this maintains the byte size to the exact original one, but it creates an empty space in the place of the alphabet 'f' as shown in the image below.
Is the space ok ... will it hinder the router update in anyway ???
AND CAN I EXECUTE THE ABOVE COMMAND OVER WIFI ???
My original and modified cfe are the same length 262144. If I remember correctly I deleted the "f" and then inserted a x'00' later in the file after nv_ver=2. You can see what I did below but I can't say if it was really necessary. Think I just tried to play it safe.
I did the update while logged into the router by ssh. Telnet would work and I guess it should work through the admin commands screen as well but didn't try. I'm always cautious with router updates and do them wired not over wifi so no guarantees from me but I think it should be ok.
Code:
$ hexdump -C cfe.bin_wrt54gs_v1.1.original | grep -A 5 -B 5 boot_wait
00001220 61 64 64 72 3d 62 66 63 34 30 30 30 30 00 6c 61 |addr=bfc40000.la|
00001230 6e 5f 69 70 61 64 64 72 3d 31 39 32 2e 31 36 38 |n_ipaddr=192.168|
00001240 2e 31 2e 31 00 6c 61 6e 5f 6e 65 74 6d 61 73 6b |.1.1.lan_netmask|
00001250 3d 32 35 35 2e 32 35 35 2e 32 35 35 2e 30 00 73 |=255.255.255.0.s|
00001260 63 72 61 74 63 68 3d 61 30 31 38 30 30 30 30 00 |cratch=a0180000.|
00001270 62 6f 6f 74 5f 77 61 69 74 3d 6f 66 66 00 77 61 |boot_wait=off.wa|
00001280 74 63 68 64 6f 67 3d 35 30 30 30 00 62 6f 6f 74 |tchdog=5000.boot|
00001290 6e 76 5f 76 65 72 3d 32 00 00 00 00 00 00 00 00 |nv_ver=2........|
000012a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
$ hexdump -C cfe.bin_wrt54gs_v1.1.modified | grep -A 5 -B 5 boot_wait
00001220 61 64 64 72 3d 62 66 63 34 30 30 30 30 00 6c 61 |addr=bfc40000.la|
00001230 6e 5f 69 70 61 64 64 72 3d 31 39 32 2e 31 36 38 |n_ipaddr=192.168|
00001240 2e 31 2e 31 00 6c 61 6e 5f 6e 65 74 6d 61 73 6b |.1.1.lan_netmask|
00001250 3d 32 35 35 2e 32 35 35 2e 32 35 35 2e 30 00 73 |=255.255.255.0.s|
00001260 63 72 61 74 63 68 3d 61 30 31 38 30 30 30 30 00 |cratch=a0180000.|
00001270 62 6f 6f 74 5f 77 61 69 74 3d 6f 6e 00 77 61 74 |boot_wait=on.wat|
00001280 63 68 64 6f 67 3d 35 30 30 30 00 62 6f 6f 74 6e |chdog=5000.bootn|
00001290 76 5f 76 65 72 3d 32 00 00 00 00 00 00 00 00 00 |v_ver=2.........|
000012a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
My original and modified cfe are the same length 262144. If I remember correctly I deleted the "f" and then inserted a x'00' later in the file after nv_ver=2. You can see what I did below but I can't say if it was really necessary. Think I just tried to play it safe.
I did the update while logged into the router by ssh. Telnet would work and I guess it should work through the admin commands screen as well but didn't try. I'm always cautious with router updates and do them wired not over wifi so no guarantees from me but I think it should be ok.
thanks @vulcan59 ...
i modified the cfe.bin file with exact byte size by copying 00 afternv_ver=2 ... as you had mentioned
Next i was able to 'scp' the modifed file into the /tmp/ of the router.
reached as far as this ...
I tried running 'mtd unlock cfe' command via connecting to the router via ssh(putty in ubuntu)
i get the following
root@DD-WRT:~# mtd unlock cfe
Unlocking cfe ...
Could not open mtd device: cfe
could you please point out the error of my ways ?
I am doing this over wifi, could that be the reason ?
I sure can run all these commands over wifi, can't i ?
Possibly your mtd0 is not called cfe although I have no idea why that would be the case. Maybe you have flashed something else in the past which set the router up differently. If you have a different name then try mtd unlock with the different name. If that works then use that name instead of cfe on the mtd write command as well.
Possibly your mtd0 is not called cfe although I have no idea why that would be the case. Maybe you have flashed something else in the past which set the router up differently. If you have a different name then try mtd unlock with the different name. If that works then use that name instead of cfe on the mtd write command as well.
its the same except for the size differences in mtd2 & mtd4 ...
I have tired unlocking cfe on my secondary router it does unlock, i have neighbours router which i manage running dd-wrt as well, that one too unlocks except for my primary router.
the following command too gives the same error
mtd unlock mtd0 (it works on the other 2 dd-wrt routers).
What do you recommend i do to now ? _________________ Primary : Linksys Wireless G(WRT54GS v.2)
Firmware: DD-WRT v3.0-r33492 mega (10/10/17).
Hardware: Broadcom BCM4712 chip rev 1 / 216Mhz / 32MB)
I have no idea why the unlock is failing although a quick search shows others have reported the same problem. Are you running the same build on all your routers? According to your sig you are not. Maybe try flashing the primary router with a later version. Build 14929 works perfectly for me.
I have no idea why the unlock is failing although a quick search shows others have reported the same problem. Are you running the same build on all your routers? According to your sig you are not. Maybe try flashing the primary router with a later version. Build 14929 works perfectly for me.
thanks Vulcan, I finally found time to attempt this.
and successfully updated my cfe
added '00' to make up for the file size difference,
used putty 'telnet' to access router after using scp to push the modified file to the router as described in your post.
before doing that i upgraded my router with this build
"DD-WRT v24-sp2 (12/22/14) mini - build 25697"
things went flawlessly !!! _________________ Primary : Linksys Wireless G(WRT54GS v.2)
Firmware: DD-WRT v3.0-r33492 mega (10/10/17).
Hardware: Broadcom BCM4712 chip rev 1 / 216Mhz / 32MB)
