DD-WRT /

Linksys WRT56GS v7

This router was upgraded 2012-04-23 to DD-WRT v24-sp2 (08/12/10) micro (SVN revision 14929).
Details of this upgrade are fuzzy now, but I recall having some anxious moments while it seemed that the router wouldn't reboot as expected. However, in the end, after a couple of power cycles, it works fine.
2MB ROM / 16MB RAM
2014-02-23: After a few days of trails I was finally able to get this router enabled for TWO BSSIDs, in addition to all its other functions. This lets me use an 'internal' SSID for my normal LAN functions, and have an 'external' SSID with access only to the internet for house guests. I ended up blending two sources of how-to to get a working system. I used the dd-wrt.com wiki article on Multiple WLANs, and an external writeup by another user. Turns out that the wiki article's GUI-based setup instructions work fine, but I ended up using the IPTABLES firewall config from the other writeup. Those steps, finally!, produced a working setup:
- Use the DD-WRT wiki tutorial on mulitple WLANs (http://dd-wrt.com/wiki/index.php/Multiple_WLANs), stopping before entering the IPTABLES commands:
  - Reset router to 'factory config'
  - Setup the general basics: WAN IP settings, DHCP, NAT rules, etc.
  - Create the Virtual Wireless AP (SSID #2)
  - Configure WLAN security settings for both WLAN #1 and WLAN #2
  - Create and assign and new bridge ('br1')
  - Setup DHCP for WLAN #2
- Then, using the following firewall commands (http://www.pennock.nl/dd-wrt/Multiple_BSSIDs.html):
  - ```
  if [ "`nvram get wan_proto`" = "pppoe" ]; then
     wanif="`nvram get pppoe_ifname`"
   else
     wanif="`nvram get wan_ifname`"
   fi
  
   # Make sure br1 has access to the internet:
   iptables -I INPUT -i br1 -m state --state NEW -j logaccept
   iptables -I FORWARD -i br1 -o $wanif -m state --state NEW -j ACCEPT
   # Keep the two wireless networks from talking to each other:
   iptables -I FORWARD -i br0 -o br1 -j logdrop
   iptables -I FORWARD -i br1 -o br0 -j logdrop
   # Keep br1 from accessing the router:
   iptables -I INPUT -i br1 -p tcp --dport telnet -j REJECT --reject-with tcp-reset
   iptables -I INPUT -i br1 -p tcp --dport ssh -j REJECT --reject-with tcp-reset
   iptables -I INPUT -i br1 -p tcp --dport www -j REJECT --reject-with tcp-reset
   iptables -I INPUT -i br1 -p tcp --dport https -j REJECT --reject-with tcp-reset
```
- It works!
Bad Dog! 2014-05-20
- Today I made a grand mistake. While configuring another router at 192.168.1.1, I mistakenly re-flashed this router with incorrect firmware. It is now bricked!
- I cobbled together a so-called passive parallel-port JTAG cable and tried various JTAG software to try to revive it, using my Gateway Profile 3 as a host device. The pinouts are given in the DD-WRT forums for this unit.
- Sadly, while it seemed that communications were active, the CPU was never recognized, with a return for CPU ID of 0001007F. I'm beginning to doubt that the communications are working, especially since at least the ZJTAG software claims to support the BCM5354 CPU in this router.
- 2015-04-16: In hindsight, I believe my trouble stemmed from two issues: 1) I hesitated to solder the JTAG cable to the PCB, and so it was floating loosely in the through-holes, perhaps making poor connections, or shorting one line against another, and 2) I wasn't using software (or version) that truly supported the CPU chip, thought what I had claimed to do so.
Yeehaw! 2015-04-16
- I was successful at recovering this unit using JTAG methods. More than once I almost rubbished this router, and now I'm glad that I held on to it; I figured I might have one more go at debricking. I ended up using a Windows XP system as a host, using TJTAG v2.1.4 with last year's 'passive' parallel port JTAG cable.
- HairyDiaryMaid v4.8 tool doesn't support the CPU chip
- Urjtag v0.10 doesn't support the CPU chip
- TJTAG v3.x claims to support the chip, but doesn't detect it correctly
- TJTAG v2.1.4 works!
  - For this unit, the key was that I needed to clear the KERNEL space (as I learned while familiarizing myself with this whole JTAG capability) of the flash chip. Last year I inadvertently flashed a vxkiller temporary firmware that was intended for a WRT54G unit, so it was incompatible with this WRT54GS (note the 'S') unit. Besides, I had already run vxkiller on this unit the first time I switched to DD-WRT.
  - Running TJTAG (on windows) is easy; it expects the passive cable by default. TJTAG has a pretty limited command set (unlike full-fledged JTAG tools) since it was more or less written for the purpose of debricking DD-WRT compatible devices.
    - C:\tjtag.exe with no options produces a help listing of commands and options
    - For this unit I had to use the /noemw switch, otherwise it would hang on 'Enabling Memory Write'
    - C:\tjtag.exe -probeonly /noemw identifies the CPU and Flash chips, confirming that the software can be used with this unit.
    - C:\tjtag.exe -backup:cfe /noemw /silent copies the 'bootloader' portion of the flash. I used this about six times in order to compare that the unit's CFE was still intact. I compared my backup files (each is named with date and time automatically) against a 256MB CFI.BIN that was offered on the DD-WRT forums in case someone needed it. The only difference between my backup and the download from the forum was the MAC address, so this proved that my CFE was still clean.
    - C:\tjtag.exe -erase:kernel will clear the kernel section of the flash chip. This is the erroneous code that I had installed by mistake. By clearing it, the CFE on next boot will recognize that no kernel is available and enter TFTP download mode.
  - So that's what I did. I used Windows XP's TFTP.EXE to send a DD-WRT micro build, as suggested by searching the DD-WRT database. Turns out it suggest the r14896 08/09/12 build and that's what I used. Lo! It worked! After the TFTP transfer was finished, I waited. About 5 minutes after the transfer the unit rebooted and came up, running DD-WRT!
2015-04-16: Using the DD-WRT GUI Firmware Upgrade facility I installed the generic micro r14929 08/12/10 build. This is the build recommended by DD-WRT experts for this unit.
2023-02-09: Using the DD-WRT GUI Firmware Upgrade facility I installed the generic DD-WRT v3.0-r44715 micro (11/03/20) build. This is the latest build recommended in the DD-WRT database for this unit.