Posted: Thu Jul 09, 2015 6:18 Post subject: WRT54GL on newer DD-WRT v3.0 builds (r27490+) K2.4 and K2.6
jwh7 wrote:
I got this build [27490] running yesterday on a WRT54GL v1.1 (./broadcom/ dir) that had been on OpenWRT (donated from a friend). TFTP'd via Serial CFE break to dd-wrt.v24_mini_wrt54g.bin, then set password, reset defaults, update via GUI to dd-wrt.v24_vpn_generic.bin, set password, reset defaults, set password, set up incl. clkfreq to 250...and good to go. Kernel 2.4.x (not on it now to post the specifics); tested WiFi and LAN as gateway...no issues.
Wow, this will be music to the ears of a friend of mine. He still uses an old Tomato on his WRT54GL v1.1
Can you give more details on how you performed this first step: TFTP'd via Serial CFE break to dd-wrt.v24_mini_wrt54g.bin ? I'm not familiar with this unit...
I got this build running yesterday on a WRT54GL v1.1 (./broadcom/ dir) that had been on OpenWRT (donated from a friend). TFTP'd via Serial CFE break to dd-wrt.v24_mini_wrt54g.bin, then set password, reset defaults, update via GUI to dd-wrt.v24_vpn_generic.bin, set password, reset defaults, set password, set up incl. clkfreq to 250...and good to go. Kernel 2.4.x (not on it now to post the specifics); tested WiFi and LAN as gateway...no issues.
Wow, this will be music to the ears of a friend of mine. He still uses an old Tomato on his WRT54GL v1.1
Surely I'm not the only one to put a recent build on a WRT54G/GL/GS?! I also have it on a GS v6 (runs the micro build).
KrypteX wrote:
Can you give more details on how you performed this first step: TFTP'd via Serial CFE break to dd-wrt.v24_mini_wrt54g.bin ? I'm not familiar with this unit...
That was in reference to my friend running a GUI-less OpenWRT build on it, so I had to TFTP. But it wouldn't work at boot up; once, the very first try, I got a TTL=100 ping reply; any other try yielded zilch (and yes, boot_wait was on, boot_time 10sec). It already had a serial->USB PL2303 so I used picocom (Linux netbook) to break the CFE at power-up (rapidly ctrl-C when plugging in), then ran 'nvram erase', then 'flash -ctheader : flash1.trx', then the TFTP worked a-ok (I just used the cmd line version in Win10; driver didn't support my pl2303 revision) with the trailed build (dd-wrt.v24_mini_wrt54g.bin), let it be for a while, then ran 'go' and it booted, then I had a dd-wrt GUI. Ref: http://www.dd-wrt.com/wiki/index.php/Serial_Recovery#Serial_Commands
Then I set the password, reset defaults, set password, updated to the VPN build via GUI (w/o selecting to reset default w/ the update since the update never works for me w/ it).
That said, you should be able to use the trailed build directly from the Tomato GUI, but I'm not sure. My parents have a GL v1.1 running the latest TomatoUSB ToastMan build from ~Dec'14, so I will probably DD it next time I'm there.
Long ago, I used 2.6 kernel TomatoUSB (VPNnoUSB) builds and had a lot of issues; most notably a race condition causing constant high load values. And then the post-Fedor TomatoUSB builds stopped updating the 2.6 branch entirely, so I took it as a sign to avoid it. I've never tried it w/ DD, but given your noted link, I planned to stay far away from them. I found it odd though that it talks about modifying the CFE, as the Tomato build was just another GUI flash. Maybe that's just really old info...surely others have asked about it; I'll do some searches.
You need earlier driver for 2303. 2303 clones or earlier editions do not seem to work in Windows 8 and no doubt 10 using latest drivers. The earlier version is recognised by the Prolific diagnostic test software with Clone PL2303 or earlier 2303
You need earlier driver for 2303. 2303 clones or earlier editions do not seem to work in Windows 8 and no doubt 10 using latest drivers. The earlier version is recognised by the Prolific diagnostic test software with Clone PL2303 or earlier 2303
Right on...after forcing Win10 to use the older driver (despite having selecting to delete the driver files and also uninstalling the driver) it is now working; PuTTY up and running. Though the Intel AMT driver might have also been interfering...
And since it is up, I will post the serial boot log, masked MAC of course. There are some 'iptables' and 'nonexistent directory' messages I found curious; when I saw them on the initial flash and boot, I figured they were cuz I had no WAN connection. I am still seeing them though now...that said, everything appears to be working fine.
I also have it on a GS v6 (runs the micro build).
