Some more tips and tricks

[wirespot]

I've had the WL-500gP for about a week now, using Oleg's firmware, with an USB HDD rack and it works really great. I wanted to point out some stuff I've learned the hard way.

Bittorrent client:

I've read this a lot of times and I didn't believe it until I tried and convinced myself: Oleg's torrent.cgi or transmission.cgi is really the best all around torrent client out there at this time.

As far as console clients go, I've tried transmission, ctorrent, enhanced-ctorrent, tornado and rtorrent. Most of them are single-torrent. tornado is multi-torrent but is not interactive. Really, the best console client out there is rtorrent, but after Oleg managed to port it I suddenly realised it lacks automated queue control and that I much more enjoy a web interface, since it's more likely to have a web browser handy wherever I go than a ssh client.

I've also tried various web interfaces. I've managed to make torrentflux-b4rt work with lighttpd, PHP4 and sqlite2, using tornado as a client (see this tutorial) and then managed to compile the special transmission version that comes with b4rt. With tornado it's a real hog. The combination of PHP, lighttpd, sqlite and Python is simply too much. Simply reloading a PHP page works the HDD a lot. With only one torrent going the load stays above 1.4 and I've heard that once you go to about 4 torrents at once the router is pretty much dedicated to that. I've tried and the load shot to 6 or 7. With transmission it's quite alright, but when I stood back and looked at the thing I realized that it didn't do anything that Oleg's cgi doesn't essentially do already.

And compare it to Oleg's cgi, which gives me average load of 0.3 or 0.4 with 6 torrents going. The only gripe I have with the transmission.cgi is that it doesn't move torrents around the queues by itself (LE yes it does, I just hadn't understood about the watchdog at the time). Well, overall is really a simple and very good torrent client and if I have the time I may hack it one day to clean up the code in the watchdog and cgi and add some more features. (I'd like it to know how to queue more than one torrent at once, or to change the speed limits from the web interface.)

How to allow SSH and other stuff from outside:

If you run iptables -L INPUT on your router, you'll probably see something like this in Oleg's latest firmware (1.9.2.7-7f):

logdrop  all -- anywhere anywhere state INVALID
ACCEPT   all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT   all -- anywhere anywhere state NEW
ACCEPT   all -- anywhere anywhere state NEW
SECURITY all -- anywhere anywhere state NEW
ACCEPT   udp -- anywhere anywhere udp spt:bootps dpt:bootpc
ACCEPT   tcp -- anywhere anywhere tcp dpt:ftp
logdrop  all -- anywhere anywhere

The reason many of you haven't been able to open up your outside ports (for SSH and other stuff) is because of that first rule. I don't know what the INVALID chain is for and where it comes from, but that's where the packets stop.

So this is how my /usr/local/sbin/post-firewall looks like:

#!/bin/sh
## FIREWALL
## set default policy
iptables -P INPUT DROP
## deny ftp access from WAN
iptables -I INPUT 1 -p tcp -i "$1" --syn --dport 21 -j DROP
## Allow access to various router services from WAN
for P in 22 65534 8008; do
  iptables -I INPUT 1 -p tcp --syn -i "$1" --dport $P -j ACCEPT
done

What I do with the firewall is:
A. I change the default policy from ACCEPT to DROP, which is saner, security-wise.
B. I insert some rules before the INVALID rule, thus bypassing it: first I deny FTP SYN packets on the outside interface, which cuts access to FTP. Second, I make a list of ports (ssh, torrent and transmission.cgi) and let SYN packages to pass through to them. That's it.

Some more security ideas:

1. For SSH: it would be a good idea to change the default port from 22 to something else, like 24. It cuts down on automatic scanners figuring out you have SSH open. It is NOT a foolproof security measure, but it's good nonetheless. You do this by finding where you start dropbear (probably /usr/local/sbin/post-boot) and adding -p 24 as parameter. Don't forget to change the firewall rule above too.

2. For torrent, opening up 65534 has really helped me. I get a LOT more peers now, about 2-4 times as many as before. I get so many it's ridiculous, it makes some instances of transmissiond have a hard time keeping up with them and use up CPU. (A configurable connection limit in transmissiond would be really sweet BTW.)

3. If you open up web access to transmission.cgi from outside be sure to protect it with a password. See the /opt/etc/httpd.conf help or /opt/etc/init.d/S80busybox_httpd for instructions on how to do that. EVEN SO, it still not good enough! The user and password pass around in cleartext! It will stop someone who accidentally stumbles across your web interface from using it, but if you access it from work for instance almost anyone (your admin definitely) can eavesdrop and pick up the user and password without a problem. So be warned. What would really help here is SSL, but I've yet to figure how to make busybox make a self-signed SSL website.

Wondershaper:

The place to add this is also in /usr/local/bin/post-firewall, at the bottom:

## WONDERSHAPER
/sbin/wshaper start "$1" 400 190

Replace 400 and 190 with appropriate numbers for your connection.

How to determine them? First, you take the maximum figures for your connection. If you know what they're supposed to be from your ISP (like mine are supposed to be 512 and 192) than start from there. Even better, do a test. I personally love the Speakeasy test. It will give you real figures (remember to stop all other traffic, such as torrents, while you do the test!)

So, you got 512 and 192. But for wshaper to work best you actually need to lower them somewhat. How much? To see how much, you need to ping an outside host, preferably from the router console, but you can do it from a LAN computer too. You can ping anything, such as www.google.com.

But the best would be to ping your gateway. To find out what it is, do this command: cat /proc/net/arp. You'll see something like this:

IP address       HW type     Flags       HW address            Mask     Device
89.xxx.xxx.xxx     0x1         0x2         XX:XX:XX:XX:F5:4B     *        vlan1

That IP on the vlan1 line is the gateway, ping that.

So now you have one console where a ping runs, and you watch the times. It would be best to start some heavy traffic, like torrents, too, to see how it does under real heavy conditions. My ping would go to around 300ms under these circumstances. Now, in another router console, run that wshaper command:

/sbin/wshaper start vlan1 512 192

(Note I use vlan1, not "$1", since we're in the console not post-firewall). Then look at the ping and see if it goes lower. It probably won't, not much, so start lowering both the download and the upload numbers slightly and run the command again, then look at the ping again. The download number needs to go down a lot more than the upload. I finally ended up with 400 and 190, and at that point my ping went between 10-60ms.

Note that this WILL NOT LIMIT your download speed! So don't be worried. All it does is to tweak the wondershaper for better latency, it has no connection to the actual download speed you get.

That's it for now, will get back if I find out more worthy stuff.