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.

[oleo]

The only gripe I have with the transmission.cgi is that it doesn't move torrents around the queues by itself

Not true. Transmisison and Torrent move packages from queue to queue from day one.

[wirespot]

Then it means I haven't figured it out. How do they determine how to do that? I've placed torrents under source/ and they stayed queued. I let them be and they wouldn't start by themselves. I had to push them by hand. When they finish they'd stay seeding (I put AUTOSEED=NO) instead of stopping and letting another one from the queue start.

[oleo]

watchdog shoul be run by cron every half an hour

[wirespot]

Watchdog is in cron, of course, and this still happens. I've figured watchdog must be taking care of this but even if I run it manually it doesn't move them around.

[oleo]

watchdog enqueues new if none in download queue (empty).

[wirespot]

I've modified transmission_watchdog and transmission.cgi to accomplish a small feature I wasn't able to live without anymore.

Sometimes I have these torrents that are extremely slow for some reason (no seeds ATM, slow peers etc.) I'd like them to keep on doing their job no matter how slowly, but I don't want them to be counted as running by the watchdog, because they keep the queue occupied and other queued torrents don't get a chance to run.

So what I've done is a 2 step hack:

Step 1: hacked transmission.cgi to offer a button that toggles an "ignored" flag on running torrents.

To do this, edit transmission.cgi (tipically found in /opt/share/www/cgi-bin/).

a) Add the following function somewhere:

# Toggle ignore flag
_toggle_ignore()
{
    if [ -z "$ID" ] ; then
        echo "<b>Please select torrent first!</b>"
        return
    fi
    _find

    if [ -f "${WORK}${TORRENT#${WORK}}" ]; then
       if [ -f "${TORRENT%.torrent}.torrent" ]; then
           DIR=$(dirname "$TORRENT")
           [ -f "${DIR}/ignored" ] && rm -f "${DIR}/ignored" || touch "${DIR}/igno
           echo "<b>$TORRENT toggled</b>"
       fi
    fi
}

b) Find the buttons, near the end of the file, and add this one:

<input type=submit name=ACTION value="Ignore">

c) Find the actions, almost all the way to the bottom, and add this one:

"Ignore") _toggle_ignore ; _list ;;

d) To show the ignored flag, find a place that looks like this:

            if [ -n "${URL}" ]; then
               echo "<td><a href=\"${URL}\" target=_blank>${DUMMY}</a></td>"
            else
               echo "<td>${DUMMY}</td>"
            fi

And change it to look like this:

            if [ -n "${URL}" ]; then
               echo "<td><a href=\"${URL}\" target=_blank>${DUMMY}</a>"
            else
               echo "<td>${DUMMY}"
            fi
            [ -f "$P/ignored" ] && echo "<b style="color:red">[I]</b>"
            echo "</td>"

Step 2: make the watchdog actually respect the flag.

Edit /opt/sbin/transmission_watchdog. Find a place that looks like this:

# Check if any torrent file exists in run env.
TORRENT=`ls -1 $WORK/*/*.torrent 2>/dev/null | head -n 1`

# Start up new  torrent if work is empty
if [ -z "$TORRENT" ]; then
    max_active_torrents=10
    if [ ${ACTIVE_TORRENTS} = ${max_active_torrents} ]; then

And change it to look like this:

WERKIN=$ACTIVE_TORRENTS
IGNEUR=$(ls "$WORK"/*/ignored 2>/dev/null | wc -l)
DIFFER=$((WERKIN-IGNEUR))

echo "<p>${WERKIN} active torrents, ${IGNEUR} ignored, ${DIFFER} acknowledged.</p>
if [ "$DIFFER" -lt 1 ]; then
    if [ "$DIFFER" -gt 9 ]; then

How to use:

When in the cgi web interface, select an Active torrent then click on the "Ignore" button. You should see a bold I appear next to it. Do it again to clear the flag.

You can only toggle the flag for Active torrents. As long as they have the flag, they are not counted towards active torrents when the watchdog determines if it needs to promote more torrents from the Queued ones.

Use this to mark slow torrents which you want to keep chugging along slowly and not keep back the other torrents.

Warning! ipkg upgrade may override the modified files!

Everytime the transmission package is upgraded you may lose the files you've just modified! So you are advised to make copies for personal use and name them something else. To do this:

a) Rename transmission.cgi to transmission2.cgi.
b) Rename transmission_watchdog to transmission_watchdog2.
c) Edit your cgi (transmission2.cgi), look at the bottom, find transmission_watchdog among the actions for the buttons, and replace it with transmission_watchdog2.
d) Start using /cgi-bin/transmission2.cgi instead of the original.

[oleo]

Nice. I was also thinking about that.
I will include this in next transmission package release.

Another wish of mine is to show also upload/download percentage and maybe a ascending listing of best seed suggestion.

[wirespot]

If you include it, please note that you can only toggle the ignore flag on active torrents. If it ends or you push it, for instance, you can't toggle it anymore. So perhaps the check for Active should be skipped, to allow it to be toggled in any state.

[oleo]

Patchlevel 3 in http://trac.nslu2-linux.org/optware/changeset/5505 includes Bypass capability and proper error handling.

[wirespot]

I've hacked wshaper to take a 9th parameter, which specifies ports that are to be given priority over other kinds of traffic.

To hack wshaper yourself, edit it and look for the following two snippets of code. The bold parts are to be added by you, the non-bold parts are what you should look for:

# low priority destination ports
NOPRIOPORTDST="$8"
# high priority destination ports
HIPRIOPORTDST="$9"

    match u8 0x10 0xff at 33 \
    flowid 1:10
 
# some traffic suffers a better fate
for a in $HIPRIOPORTDST
do
       tc filter add dev $DEV parent 1: protocol ip prio 14 32 \
          match ip dport $a 0xffff flowid 1:10
done
 
# some traffic however suffers a worse fate
for a in $NOPRIOPORTDST
 do

I think I did it properly. I've also tested it: after I made use of the new parameter, I've used a bandwidth measurement site while I had a couple of torrents going. I got the full speed of my line in the test, even though the torrents were using about half of it. This is because now port 80 (http) takes priority.

To use this you need to run wshaper at least once on your router, and re-run it after every boot. It's best to edit /usr/local/sbin/post-firewall and add the call to wshaper in there. Remember to save the modifications to flash!

Here's how I run it:

wshaper start $1 400 190 "" "" "" "" "20 21 22 25 110 143 80 443 587 995"

If you run wshaper from post-firewall you need to use $1. If you run it from the command line you need to use "vlan1".

To determine the proper values for the 3rd and 4th parameters (400 190) you need to read the first post in this thread.

The ports I've included in the example are: FTP, SSH, SMTP (outgoing email), POP3 and IMAP (incoming email), regular web, secure web, plus a couple of other ports I'm using.

REMEMBER! This setup refers to ports on remote sites or machines, opened with programs on the computers in your LAN (or on the router).

[Rui_Carlos]

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.

the first rule will block all invalid packects. INVALID is not a chain, but a state of the packets (like RELATED, ESTABLISHED or NEW).

[wirespot]

Yeah, figures. But the fact remains that it blocks you from having a FTP or SSH server. Why would those count as INVALID? (It's good paranoia, security-wise, but still wondering.)

[Rui_Carlos]

Yeah, figures. But the fact remains that it blocks you from having a FTP or SSH server. Why would those count as INVALID? (It's good paranoia, security-wise, but still wondering.)

I still have that rule and the ssh server is working (the ftp server isn't active).
In my pc, I also have that rule and the ftp/ssh servers are working.

[wirespot]

Then I can only guess that something about my Internet connection makes those packages come in as INVALID for some reason.

OK, so it's good to know that Oleg's INVALID rules are good and removing them is only a particular workaround, not a generally good advice.