Archive for the ‘Linux’ Category

KDevelop: so much promise, but a bit rough around the edges

Tuesday, April 3rd, 2007

I’ve been trying to put together an app using KDevelop as my IDE. IDE-wise, it seems fine: all the usual stuff like syntax highlighting (of course) and code completion, etc. But I find its handling of the gnu autotools a bit rough.

I haven’t found a way yet to specify a build order for files, or better yet, identify source/includes generated by the build process. This means, for instance, that I need to make sure that my .y (bison source) file is before my .l (flex source) file in the compile, so that bison can run and output the include file to define symbols for flex.

Another sticking point is the fact that I can’t seem to get KDevelop to properly define libraries to link against. When I list them as required in the project options, the make fails with e.g. “no rule to make ‘cppunit'”.

I’ve got around both of these issues by manually hacking the Makefile.am, but it’s not very promising for future productivity.

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.

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 x2a.org. 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 libipt_TRIGGER.so 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 (Config.in, 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 Config.in 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 OpenWRT.org 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.

Some Linux/Unix commands worth knowing…

Tuesday, February 27th, 2007

It seems like not a day goes by when I don’t run across someone’s blog listing “top 10 Linux commands you must know” or something like it. I get the feeling these are mostly posted by people who switched to Linux recently and want to share the experience. I switched to Linux 12 years ago, so here’s my version of “some Linux (or really Unix…) commands worth knowing”. I’m not going to be more specific than that. They are in approximate order of increasing skill/knowledge/foolhardiness.

  • ls -al
    We all know that ls is the command to list files in a directory. The -l option gives you details, and the -a option lists the “hidden” files that begin with . (period). So ls -al is the standard “power version” of ls.
  • mv/cp/rm
    Move, copy, remove files and directories. Move is also used to rename.
  • <command> –help
    Putting –help after a command usually tells you what arguments it takes. This is something I really really miss when having to use Windows. You can also try -? or -h (or simply nothing). If that fails, try man <command>.
  • find / -iname <filename>
    The equivalent of Windows’ directory search – but without the world’s worst UI. Running it with / (root directory) as the second parameter is liable to spit out some errors because (unless you are root, which you shouldn’t ordinarily be) you won’t be able to read some directories. -iname is probably the most useful option for the newbie – it means do a case-insensitive name match.
  • vi
    You should know just enough to get by, although these days any distro is likely to have nano or something friendlier than vi anyway. You can get by pretty well just knowing: i to start “editing mode” (insert), x to delete a character, dd to delete a line, ESC to stop editing and enter “command mode” again, :q! to quit without saving, ZZ to save and quit.
  • chmod
    A vital command for mucking about with files. 90% of the time you will want chmod 755 <file> and 9.9% of the time you’ll want chmod 644 <file>. The first makes a file executable, the second makes it “normal” (usually to be used if it came from a bizarre place like a Windows filesystem).
  • grep
    A bit overrated. In the sense that one doesn’t often need it as a new user. But the real reason it’s one of the standard tutorial things is that what you really need to know are regexps (regular expressions). Grep can be viewed really just as a way to get familiar with regexps. Learn them and love them.
  • less
    Forget cat and more – for reading text files, just use less. Cat and more you can learn later when you want to do other stuff besides just read files.
  • ps aux | grep <name> and kill
    Useful for when things go wrong. Find a rogue process with ps. Kill it with kill. Job done.
  • Ctrl-Z and bg
    Forgot to add the & on the end of a command and your command prompt didn’t come back? No worries – hit Ctrl-Z and type bg and Bob’s your uncle.
  • kill -HUP
    Useful for restarting a process and/or having it re-read the config files. A good example is when for whatever reason, X fails to start and you are left at a text prompt. So (using your minimal vi knowledge) you quite happily fix up your X config file, but then what? If you are a newbie, chances are you reboot (that being the only way you know to restart X). But probably all you need to do is something like ps aux | grep gdm followed by kill -HUP. And you’re back at a nice graphical login.
  • tar -zxvf <file>
    The standard way to unpack a tarred and gzipped file. The options are: z for zipped, x for extract, v for view (you can leave this out if you like) and f for you guessed it, file. You can also use -jxvf if the file is bzipped rather than gzipped.

That’s a good set of standards to get oneself up and running as a newbie. On the hairier side of things, some other useful commands to know are:

  • lsmod and modprobe
    For listing and loading kernel modules.
  • lspci and lsusb
    For inspecting your hardware.
  • dmesg
    For seeing what went wrong when you just plugged in your iPod.
  • lsof and dd
    Given that practically everything in Unix is abstracted as a file, there is almost nothing you can’t do with the combination of these two absurdly powerful tools.

more linux fiddlings

Sunday, February 18th, 2007

Some things I’ve tried over the past week or so:

Getting Second Life to work on Linux (compiling from source). Well, it worked in a very limited way, after a fashion. I didn’t get any sound (had to compile without FMod because v3.75 isn’t downloadable for 64-bit Linux). And there were some graphics artifacts too. Linden Labs says that the Linux client is alpha. I don’t think it’s even there yet. Anyway, since I don’t really play Second Life (if you don’t fancy gambling or cybersex, there’s nothing to do) I’m not bothered.

VMWare Player. It’s nice. I like the concept a lot. And although it doesn’t give you any tools to create virtual machines, I soon discovered QEMU (for creating the disks with qemu-img) and EasyVMX. But VMWare doesn’t work that well with FreeDOS. Perhaps I’ll try breaking out the old MS-DOS 6.22 disks.

After some fiddling around with that, I gave up and went for DosBOX. Which plays things (old games) very nicely. With sound, even! I have now set up Eye of the Beholder 1 & 2 and also Sam & Max Hit the Road and Day of the Tentacle. It’s all good. Now I just need to figure out a way to host those slightly younger games from the Win95/98 period, some of which use early forms of 3D acceleration. Roll on VMWare supporting 3D stuff.

getting stuff working on Linux

Friday, February 2nd, 2007

Inspired by ‘s recent wibblings on Linux, I decided it was time to iron out my own wrinkles. So after a very little googling, I was able to get a bunch of stuff working that for one reason or another had broken when I upgraded from Dapper to Edgy.

  • Sound works on the desktop again (a simple matter of an outdated .asoundrc).
  • Eclipse works (an x86_64 bug was mitigated).
  • My webcam works (after a quick compile of the latest module) which means I can use Ekiga to talk the family.
  • Flash 9 works through nspluginwrapper (Adobe are apparently incapable of releasing a 64-bit version).
  • And I downloaded some games: Neverball and the Neverwinter Nights Linux client binary.

The only time I have to boot Windows now is if I want to VPN to work.

5 hours' work, wasted

Monday, December 11th, 2006

For the sake of 10 minutes. Because Mrs Elbeno insisted that I turn off the computer NOW and go to bed last night, and /tmp gets cleared on boot. Grrr. If you’re reading this, Mrs Elbeno, I’m never listening to you again over such matters!

after 12 years, why not?

Thursday, July 6th, 2006