Archive for March, 2007

printer maintenance

Sunday, March 25th, 2007

My Epson CX6400 hasn't been printing properly for a while. This weekend I got around to taking it apart to see what was up. The usual story with inkjets is that the waste ink tubes get clogged. I was unable to find a service manual for free online, so I just dived in with screwdriver and needle-nose pliers.

It took me a while to figure out exactly how to dismantle the whole thing: lacking a manual I had to experiment with looking around, seeing which screws connected which parts, and pulling things. After about half an hour I managed to get it safely stripped down.
Printer innards
The base of the printer contained the waste ink pipe, leading to a sludge trap. It was sealed off with wedges of felt.
Waste ink pipe
Believe it or not, this next picture is after cleaning. I wasn't looking to restore it to factory condition, merely to unclog the tube and clean most of the ink residue.
Waste ink area after cleaning
The next job was to clean the waste ink tube in the chassis section. It seemed to be curled inside a plastic housing, so I was limited to cleaning either end, which I did.
Waste ink tube: chassis end

End result: it still doesn't print properly. Oh well. Perhaps a laser? I'm fed up with inkjets.

fighting the code

Sunday, March 25th, 2007

Why doesn’t automake/autoconf properly recognise the way to use Flex/Bison with C++ scanner/parser generation? I use a .ll file and it thinks the output is going to be a .c instead of a .cc. Likewise I use a .yy file and it screws up the includes in my bison output because it decides to go substituting into the mix…

Making wrong assumptions is the quickest way for software to show itself as the unintelligent thing that it is.

Castlevania: SOTN on XBL Arcade!

Tuesday, March 20th, 2007

Run, don’t walk. This game is one of the more brilliant things you’ll play in your life. Actually, I don’t know if it’s quite out yet. I have it on the dev network. But soon if not now. Drool in anticipation.

port triggering with OpenWRT works!

Saturday, March 17th, 2007

I finally got around to compiling the ipt_TRIGGER kernel module with some logging in there, so I could tell where I was going wrong with my iptables commands.

The correct iptables commands are:

#iptables -t nat -A prerouting_wan -p tcp –dport 6881:6889 -j TRIGGER –trigger-type dnat
#iptables -A forwarding_wan -p tcp –dport 6881:6889 -j TRIGGER –trigger-type in
#iptables -t nat -A prerouting_rule -i br0 -p tcp –dport 6969 -j TRIGGER –trigger-type out –trigger-proto all –trigger-match 6881-6889 –trigger-relate 6881-6889

The first one handles NAT mangling for packets coming in off the WAN. The second one handles forwarding for the same packets. The last one is the one that creates a trigger when it spots an outbound BT packet.

Edit: update here.

should I tell them?

Friday, March 16th, 2007

I used one of my local open wireless access points to download some stuff on my laptop. Actually, just enough to get the wireless card working with WPA. Should I tell my neighbours to secure their AP?

wireless (in)security

Tuesday, March 13th, 2007

It's amazing what you can glean just from listening to the ether. Armed with an old laptop, wireless card, Kismet, and quarter of an hour, I can tell you the following about my neighbourhood:

There are 3 open wireless access points, 4 WEP-protected ones, and 5 or 6 WPA protected ones. One open point is run by a router with the default admin username and password. Several networks have their SSIDs hidden (but of course I still know them – “hidden” SSIDs mean little to Kismet). I also know (using MAC address vendor lookup) the make of each router and most of the stuff connected to it – for instance that several people use Apple computers, and one person has a wireless TiVo. Nobody except me has a Wii hooked up wirelessly :). Also, looking at the SSIDs of many of the networks, I can cross-reference with the phone book and find out exactly where the routers are (since many people put some variant of their surname in as the SSID).

So: hidden SSIDs mean nothing to an attacker (although they do stop random machines trying to automatically connect). MAC filtering again means very little to an attacker. WEP can be easily broken (say in half an hour) with monitoring and packet injection tools. And WPA(-PSK) can be subjected to a dictionary attack with information gleaned by the same tools.

My setup? Nothing out of the ordinary – just reasonable security. A strong admin password on the router. SSID “hidden”. I don't bother with MAC filtering because with the number of wireless devices I have in circulation, it's more inconvenient for me than for an attacker :). WPA encryption. A strong WPA password (not one that is susceptible to a dictionary attack). I estimate that a brute force attack on my password, testing a million keys a second, would take approx 50,000 years to succeed.

If you have a wireless network, don't wait until you see this on the pavement outside.

port triggering iptables config

Sunday, March 11th, 2007

I think the relevant iptables commands for port triggering with Bittorrent are:

#iptables -t nat -A prerouting_wan -p tcp –dport 6881:6889 -j TRIGGER –trigger-type dnat –trigger-proto tcp –trigger-match 6881 –trigger-relate 6881-6889

This tells the router to do NAT on the packets arriving on the WAN TCP ports 6881 through 6889 as allowed by the trigger on TCP port 6881.

#iptables -A forwarding_wan -p tcp –dport 6881:6889 -j ACCEPT

And this tells the router to forward packets on TCP ports 6881 through 6889 (it should forward packets that have reached here through application of the previous rule).

kernel hacking

Saturday, March 10th, 2007

Now that I’ve got my new router set up (it’s working fine btw) I decided to dig a bit deeper into the firmware possibilities. Warning: this post is mostly martian, and it’s long.

The first thing I wanted to investigate was the possibility of port triggering. Port triggering is an alternative to static port forwarding: when a packet goes out on a given port, it can trigger the opening of one or more inbound ports. This is useful if you have several machines behind the NAT box and you want them all to use apps like say, Bittorrent (which communicates initially on 6969 and listens on 6881-6889 or so).

So I did a bit of research. The router runs the 2.4.30 kernel with iptables-1.3.3 (I’m using the OpenWRT whiterussian firmware). So I downloaded the OpenWRT source and started spelunking. It became clear that there were a couple of ways to achieve smooth Bittorrenting.

The first way would be to build a netfilter kernel module to track bittorrent connections. There are similar modules for several protocols aready. Perhaps the canonical example is FTP: when a connection goes out on TCP 21, the module tells the kernel to expect TCP 20 incoming. I poked around the web for a while and found that Jonathan Bastien-Filiatrault is (or was?) developing just such a module over at I found his code in Google caches and took a look. But it seemed to be unfinished. I may still pursue this avenue.

The next way to achieve my goal is of course the aforementioned port triggering approach. And in fact since this approach is applicable in general to more things than Bittorrent, I decided to tackle it. After reading lots of web material, I decided the best way to go was to download the stock Linksys firmware source and try to add its triggering functionality to the OpenWRT source I had.

It took me a while to understand how the OpenWRT build process works. Then I had to figure out how to add the required code and make sure that the build process pathways through Makefiles etc were correct. The easy part was iptables – all I had to do was add a source file in the extensions directory, add a header file in the linux headers tree (of which iptables has a separate copy – it doesn’t share the linux headers used in the kernel build, which made it easier), and make a trivial Makefile change.

So I did that, and built. It didn’t build my new .c file. No .so file was forthcoming. Hmm. A dependency issue? So I tried a make dep. No dice. Make clean it is then. And poof, the directory vanished. Not just the .o files, but the entire output directory. This was the point where I really grokked how the OpenWRT build process works. It downloads tarfiles for each package and keeps them in a dl directory. When it builds, it untars them to a build directory, applies patches, and then builds. OK, well then all I had to do was apply my changes to the iptables tarfile, and it should work. At this point I did not try to create a patch to achieve the same result – I went for the easy option. And it worked! I had in my iptables directory.

Next I looked through the kernel source aiming to do the same thing. First I tried the easy option. But I ran afoul of the many patches that OpenWRT applies to the kernel before building. I’d changed something (, Makefile, a header) and I confused the patch process which wasn’t expecting to see my changes in there and therefore couldn’t work out how to add its thing. So I had to do this the harder way: by making my own patches.

While spelunking through the Linksys kernel code, I also noticed ip_conntrack_sip.c and ip_nat_sip.c which I thought would be useful, so I went ahead and included them in my patching. In retrospect, this made the job harder. It was easy enough to put the code and Makefile changes etc into the kernel tree. The harder part was putting the Makefile and lines in the right place so that other patches to the same files would not get confused. After a couple of hours of mucking about I had a solution. This, unlikely as it may seem, was also the first time I’d really used diff and patch in anger. They’re useful!

So, now I had iptables working, and a patch for the kernel that was successfully applied by the OpenWRT build process and that didn’t cause anything else to barf. And when I ran make, somewhere in the flurry of output I was prompted to select my new code: I got the Y/n/m (include, don’t include, include as module) prompt! So I selected the new stuff as modules of course. And in the fullness of time, everything was happily built.

Next job was to try to use it. I scp‘ed the files over to the router and put them in the right place. First I tried out loading the iptables trigger module by giving it a rule with -j TRIGGER. Rightly, it complained that there was no such target. Then I tried to load the ipt_TRIGGER kernel module. It told me that it would taint the kernel because of having no license, but otherwise was OK. The next try with -j TRIGGER was accepted by iptables! So apparently now I have port triggering working successfully.

This was last night. This morning I’ve cleaned up my hacks and I have the trigger stuff as two patch files that get cleanly applied by OpenWRT during the build. The stage I’m at now is figuring exactly how to instruct iptables to do what I want.

new router

Monday, March 5th, 2007

Lately my SMC2804WBR has started to play up a bit (arbitrarily causing loss of connectivity), so this weekend I finally got around to replacing it. Mrs Elbeno was complaining of having to power cycle it 2 or 3 times a day.

Where wireless broadband routers are concerned, experience has taught me that once you get a working setup, you should not fiddle any more. And that pretty much all routers are flaky… it’s all down to getting stable firmware. Back in the UK I had an older SMC model that I kept relatively stable for a few years, which was why I bought SMC again when I moved to the US. However, I had prepared for this day when I knew the router would eventually fail. About 6 months ago I did my research and trawled through the local electronics stores looking for a Linksys WRT54G with the right serial number.

So after a visit to and some settings-tweaking for the last hour (and leaving my cable modem off for a while so that it would forget the MAC address of the machine using it – why oh why do they do that?), I am now connected to the Intertubes through a proper linux box. Yay! The SMC used to get very hot, particularly when stressing it (e.g. bittorrenting wirelessly). I have higher hopes for the new box, in part because I have much better control over it. Time will tell.

Mini-Elbeno can read!

Saturday, March 3rd, 2007

Lately mini-Elbeno has started to read words. No, really! Last week I printed out some flash cards and he can read about a dozen of them: nose, ears, dog, clap, wave, arms up, arms down, ball, book, and more I can't remember now. Although he can't say many of them intelligibly yet (only “buh” for ball, book and other words that start with B) he either does the action, points to the body part, or does the ASL sign (for dog, book, and ball). This morning we did a webcam with Grandad and amazed him.

I'm amazed too – kids are much smarter than we guess, and mini-Elbeno learns so much every day.