## Multicast routing with PIM-SM over GRE

GRE tunnels are useful in many ways. This blog post shows how to set up multicast routing with pimd over a GRE tunnel. To achieve this we will also set up OSPF over GRE with Quagga, because PIM, unlike DVMRP (mrouted), require unicast routing rules to be established.

        .----{ Intranet }----.
/    192.168.1.0/24    \
/                        \
.10 /                          \.20
+--'---+.1   GRE Tunnel   .2+-----+
|      |====================|      |
|  R1  |   172.16.16.0/30   |  R2  |
|      |                    |      |
+--.---+                    +------+
| .1                        | .1
|    10.0.1.0/24            |    10.0.2.0/24
| .2                        | .2
+--'---+                    +--'---+
|      |                    |      |
|  C1  |                    |  C2  |
|      |                    |      |
+------+                    +------+


In this post we are using the home WiFi network, 192.168.1.0/24, to hook up the GRE tunnel. It is just as easy to extend this to a big corporate Intranet with more routers between R1 and R2. As long as that IT department takes care of the unicast routing between R1 and R2 so that the GRE tunnel can be established.

## Redirecting Ports For Fun and Profit

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 :-)

## Using netcat to test your Internet daemon

So you’re having a problem with the Internet daemon you wrote. You’re convinced the firewall, or some other magic, in your modern Linux distribution is eating your packets. No. First, make sure your daemon is actually running and has successfully bound to the address and port in question: sudo netstat -atnup If your application is not listed there you have a problem with it binding its server socket. Check the return values from bind(). [Read More]

## The key to successful boot

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.

## Lecture from the UNIX beards

After the rm -rf /* disaster that hit me a couple of weeks ago I’ve been rebuilding my setup, restoring the few files I’ve had backed up, and collecting advice from the elders. Turns out there are a few tricks that can save your home directory from accidents like mine. The first one is rather obvious, but I’m writing it down anyway: Keep separate accounts. If possible, use separate accounts (with different permissions obviously) for different projects. [Read More]

## Disaster Recovery

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

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!

## Testing multicast with Docker

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.