44net October 2013

44net@mailman.ampr.org

38 participants
33 discussions

RIP question
by Lakenet 03 Oct '13

03 Oct '13

I run JNOS 2.0i with Ubuntu Linux 12.04. I am set up to receive RIP broadcasts and they are working fine. Along with the encapsulated RIP broadcast is coming non encapsulated data and JNOS is responding Unreachable Port Returned. Is this non encapsulated data something that I asked for in AmperNet registration or does it just come along or have to come along with the encap data? Jerry, N0MR

2 1

Attempting to contact 4Z4ZQ
by Assi Friedman 01 Oct '13

01 Oct '13

Folks: Apologies for the note, but I am trying to get in touch directly with Ronen Pinchook 4Z4ZQ, who is a member here. Ronen: do you mind contact me directly at assi(a)kiloxray.com regarding amprnet business. Thank folks, over and out. Assi KK7KX/4X1KX P.S: Brian, if you want to beat me over the head for this, you know where to find me :)

1 0

rip44d rp_filter problem fixed
by Heikki Hannikainen 01 Oct '13

01 Oct '13

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

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net October 2013