Recently I needed a simple TCP/UDP port redirector and stumbled upon this Stackoverflow post. As usual I wasn’t first wanting to this without using iptables.

There were several alternatives, but since my target was embedded with limited amount of RAM and flash I wanted something really small. So the best fit turned out to be redir, which unfortunately only could handle TCP connections. This is what led me to write uredir to complement redir. Eventually I ended up adoptiing redir as well, which meant giving it a bit of a facelift and to give them both the same look and feel.

Currently they are two separate applications, which in some use-cases can be beneficial (small size), but I may in the future transplant the UDP functionality of uredir into redir. We’ll see, right now though I have several other projects to attend to :-)

How do you know when your UNIX service (daemon) is ready? Simple, it has created a PID file, signalling to you how to reach it. Usually this file is created as /var/run/daemon.pid, or /run/daemon.pid, and has the PID of daemon as the first and only data in the file. This data may or may not have a UNIX line ending.

Only trouble is: most UNIX daemons do not re-assert that PID file properly on SIGHUP (if they support SIGHUP that is). When I send SIGHUP to a daemon I expect it to re-read its /etc/daemon.conf and resume operation, basically a quicker way than stop/start.

Annoyingly however, most daemons do not signal us back to tell us when they’re done with the SIGHUP. Naturally a new movement has risen that says we should all instrument our daemons with D-bus … I say no. Simply touch the PID file instead.

Days like these inconspicuously start out just like any other day, except on days like these you accidentally manage to erase $HOME and have no real backup to rely on … Maundy Thursday will forever be Black Thursday for me, from now on.

Best thing your can do, after cursing at yourself constantly for a couple of hours, is to:

1. Come up with a useful backup and restore strategy
2. Read up on undeletion tools for Ext4
3. Blog about it, naturally

BUT FIRST – QUICK – UNMOUNT OR POWER-OFF YOUR COMPUTER – PULL OUT THE BATTERY – AND STEP AWAY FROM THE COMPUTER! Must protect the partition from being accidentally written to – I completely fumbled this step, so take heed young people!

Recently issue #70 was reported to pimd. That number of issues reported is cool in itself, but this was a question about Docker and pimd.

Up until that point I had only read about this new fad, and played around with it a bit at work for use as a stable build environment for cross-compiling. I had no idea people would want to use a Docker container as a multicast sink. Basically I was baffled.

The reporter used a Java based tool but simply couldn’t get things to work properly with pimd running on the host:

                eth0
 MC sender ---> [ Server host ]    <--- router running pimd
                       |
               ________|________
              /     docker0     \   <--- bridge    ______
             /         |         \                |      |   <--- MC receiver
  __________/          |          \_______________|______|_____
 \                     |                            /         /
  \                     `------------------>-------'         /
   \________________________________________________________/
      Container ship

For the better part of the last ten years I have been working with multicast in one way or another. I’ve used many different tools for testing, but on most systems I usually resort to ping(1) and tcpdump(1), which are quite sufficient. However, you often need to tell bridges (switches) to open up multicast in your general direction for your pings to get through, so you need to send an IGMP “join” first.

Way back in 2006 I stumbled upon a neat tool called mcjoin, written by David Stevens and announced in this posting to LKML. I started improving and adding features to it over the years.