I think I have found and fixed a problem which caused rip44d multicast reception to mysteriously fail on some systems. The workaround is present in rip44d version 1.4, which is available at: https://raw.github.com/hessu/rip44d/master/rip44d I just upgraded the Linux distribution on my gateway, and rip44d stopped working. After some slight hair-pulling I figured it out. The same thing will affect the C implementation, and doing the same workaround will remove the need to use a raw socket instead of the more optimal multicast socket. Some distributions/kernels (some of the new ones, and maybe some old ones too?) enable strict reverse path verification (rp_filter) by default. Reverse Path filtering looks at the source IP address of packets coming in on an interface, and checks that an outgoing packet destined to that same address would be routed out on that same interface according to your routing table. That's a nice feature as such - it drops spoofed packets, which is good for security. If someone on the Internet sends packets to you, and fakes the source address to be one of your internal addresses, it could save your day. Or, if a client/user on your network tries to send packets to the Internet with a fake source address (typically his computer is infected with a bot, and the bot is taking part in a DDOS attack), rp_filter will drop those packets with invalid source addresses. However, it affects multicast packets too. Our RIP packets come in on tunl0, with a source address of 44.0.0.1. Before your tunnel routing table is populated with RIP, there is no route to 44.0.0.1 pointing to tunl0. The RIP announcements do contain a route for 44.0.0.1, but we need to have it there to be able to receive any RIP packets. There are a couple of alternative workarounds to this: 1) Disable rp_filter on the tunl0 interface. sudo sysctl net.ipv4.conf.tunl0.rp_filter=0 (and put net.ipv4.conf.tunl0.rp_filter=0 in /etc/sysctl.conf) *or* 2) Set up a dummy route for 44.0.0.1/32 pointing to the tunl0 interface. It'll be replaced by the real one once the first RIP packets come in. I opted for option 2, rip44d 1.4 does that when starting up. If you have an asymmetric routing setup, rp_filter might cause some other surprises too. Good to keep it in mind. - Hessu, OH7LZB