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.


This is a very brief writeup of how to upgrade the BIOS on a X1 Carbon (G1) from Linux. For more information on this topic there is always the excellent ThinkWiki.


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


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().

If you’re still suspecting the firewall, or some other magic, test your theory with netcat. First start a server, with your relevant address and port, remember you need to be root, or have CAP_NET_ADMIN, to use ports <= 4096:

nc -l -u -p 9999

Here we bind to 0.0.0.0:9999. Now, start a client to test if the server can receive any data:

nc -u 127.0.0.1 9999

Type something on the console and press enter to send it to the server. If you receive the data then there’s no magic, execpt from bugs in you application, preventing your appplication from working.


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.