Kamikaze delayed...
Still waiting on the Release Candidate that should have been out early this month. Lots of fixes in the new release, still no new kernel for my WRT, though. Stupid Broadcom not releasing drivers for their chipset...
Still waiting on the Release Candidate that should have been out early this month. Lots of fixes in the new release, still no new kernel for my WRT, though. Stupid Broadcom not releasing drivers for their chipset...
Due in August. Time to prep my backup router...
There is probably a better way to do this, but I've gotten tired of my son screwing around on the net and not doing his homework, so I've decided to block a few sites at the router. His system uses DHCP addressing, so he picks up the DNS server info from OpenWRT, which till now just passed along those requests to the configured ISP DNS servers. My other systems are on static, and have these DNS entries listed manually.
So, it seemed to be an easy process to insert a few entries into the /etc/hosts file on the router.
I'm going to take another crack at installing Kamikaze on my new spare WRTSL54GS that I picked up before the holidays. After I install a new serial jack on it, that is. :)
I've had this one just idling with power on and nothing else hooked up as a burn in test, since it's still chugging I think I'm past the issue I had with my last spare router now.
A few weeks ago, I had purchased a spare WRTSL54GS to do testing on, and unfortunately shortly after installing a new serial port (installed almost immediately after opening the box) and then installing Kamikaze, discovered that the router had become unresponsive after just a few days.
Consulting several experts led me to believe that he router was bricked. I shipped it off to a friend to verify, and all indications are that I had experienced an actual hardware failure, possibly as a result of a power fluctuation here (something I had ignored at the time, but now seems likely to have been the culprit). It is also possible I had bad hardware from the factory, but as I had quickly modified it, I had no way of knowing if it may have been bad originally. Bummer.
A bit of trickery to print to a printer on my home LAN via the internet. The example below assumes the printer is being connected to externally on port 12345, and actually accepts connections on port 9100 (HP Jet Direct).
Tested and working, but may not be perfect. OS X wasn't able to identify the printer model automatically, but setting this manually let the jobs print normally.
# Printer
iptables -t nat -A prerouting_rule -d $WANIP -p tcp --dport 12345 -j DNAT --to 192.168.1.99:9100
iptables -A forwarding_rule -d 192.168.1.99 -p tcp --dport 9100 -j ACCEPT
iptables -t nat -A postrouting_rule -o $LAN -p tcp -s $network -d 192.168.1.99 -m multiport --dports 9100 -j SNAT --to-source $WANIP
For posterity, here is my working iptables config:
#!/bin/sh
. /etc/functions.sh
WAN=$(nvram get wan_ifname)
LAN=$(nvram get lan_ifname)
iptables -F input_rule
iptables -F output_rule
iptables -F forwarding_rule
iptables -t nat -F prerouting_rule
iptables -t nat -F postrouting_rule
# Note: Firewall must be re-run if WAN IP address changes
WANIP=`ifconfig $WAN | grep inet\ addr | sed -r 's/.*inet addr:([0-9.]+) .*/\1/'`
network="192.168.1.0/24"
server="192.168.1.10"
iptables -t nat -A postrouting_rule -o $WAN -j SNAT --to-source $WANIP
There you have the basic setup. The variable WANIP will find the current IP address of the WAN interface, network is whever you have defined for your local LAN, and server is the server you're routing ports to. You could easily define server2, server3, etc, for as many systems as you want to map here.
# identd
iptables -t nat -A prerouting_rule -i $WAN -p tcp --dport 113 -j ACCEPT
iptables -A input_rule -i $WAN -p tcp --dport 113 -j ACCEPT
This is my config for identd (still not working for some reason?) to open the correct port, and set up the router itself to answer on this port (that part, at least, works).
# Lines below let WAN address work from LAN
# SMTP
iptables -t nat -A prerouting_rule -d $WANIP -p tcp --dport 25 -j DNAT --to $server:25
iptables -A forwarding_rule -d $server -p tcp --dport 25 -j ACCEPT
iptables -t nat -A postrouting_rule -o $LAN -p tcp -s $network -d $server -m multiport --dports 25 -j SNAT --to-source $WANIP
# HTTP
iptables -t nat -A prerouting_rule -d $WANIP -p tcp --dport 80 -j DNAT --to $server:80
iptables -A forwarding_rule -d $server -p tcp --dport 80 -j ACCEPT
iptables -t nat -A postrouting_rule -o $LAN -p tcp -s $network -d $server -m multiport --dports 80 -j SNAT --to-source $WANIP
# POP/IMAP
iptables -t nat -A prerouting_rule -d $WANIP -p tcp --dport 110 -j DNAT --to $server:110
iptables -A forwarding_rule -d $server -p tcp --dport 110 -j ACCEPT
iptables -t nat -A postrouting_rule -o $LAN -p tcp -s $network -d $server -m multiport --dports 110 -j SNAT --to-source $WANIP
iptables -t nat -A prerouting_rule -d $WANIP -p tcp --dport 143 -j DNAT --to $server:143
iptables -A forwarding_rule -d $server -p tcp --dport 143 -j ACCEPT
iptables -t nat -A postrouting_rule -o $LAN -p tcp -s $network -d $server -m multiport --dports 143 -j SNAT --to-source $WANIP
Opening up various ports that will be handled by 'server', and tricking things so that requests via the LAN port for the WANIP will get routed correctly, so you can use your own external domain name internally (default router config doesn't allow this to work). This was the tricky bit solved in the forum thread mentioned in my last post.
# Access webif from WAN on port 65321
iptables -t nat -A prerouting_rule -i $WAN -p tcp --dport 65321 -j DNAT --to :80
iptables -A input_rule -i $WAN -p tcp --dport 80 -j ACCEPT
This took a small bit of research. This will redirect port 65321 from the WAN side to port 80 on the router itself, in case you want the router's web interface to be accessible externally. Use this same trick if you wanted to SSH into the router, or externally access any other router specific service by remapping the port.
After a few months of tinkering with getting to know this guy, and doing my final (for now?) hardware mod and getting a proper serial connection in place, I've finally replaced my old Asante router that had served me well these last several years.
The trickiest bit was figuring out the iptables command and setting things up so that I could access my web/mail server via the LAN using the WAN address (so I could refer to it by name instead of a local IP). This posting over on the OpenWRT forums was a great help in doing exactly what I needed.
My TTL-232R-3V3-AJ USB cables arrived last week (I ordered a spare), a quick test after installing the OS X driver indicated that I was indeed seeing a new serial port after plugging the cable in, so it was now time to replace my hacked Keyspan interface with a clean looking 3.5mm stereo audio jack on my WRT. Having it in the back with the other ports would have been ideal, but there was just no real estate left. I opted for the top case opposite the antenna jack.

I wish now that I'd had some heat shrink tubing on hand for the jack, but I'm not planning to go back to fix that unless I have to. A quick desoldering of my old cable from the underside of the board and soldering the new cable to the top of the board and I was in business.

A recent post in the OpenWRT forums hilighted the TTL-232R-3V3-AJ USB cable, a TTL Level Serial Converter, or in other words, it takes a 3.3v RS-232 signal and converts it to USB, perfect for use with my WRTSL54GS, thanks to the fact that they also have Mac drivers available. This will allow me to ditch (with some slight regret) my hacked USB serial interface, and simply add a clean looking 3.5mm stereo audio connector to the side of my WRT, which this cable will plug right into.
Several versions of this cable are available for 5v and 3.3v sources, with several alternate ends, the AJ (Audio Jack) version to me seems the most flexible to adding a serial interface as it is easily removable from the unit when not needed.