27 Dec
2014
27 Dec
'14
4:58 a.m.
On 27-12-14 11:36, Marius Petrescu wrote:
You could try adding the -r option to ampr-ripd, so it
will use raw sockets
instead of multicast sockets.
This was added to overcome a problem on new ubuntu distributions with 3.x
kernels, which didn't work the traditional way on multicast in some cases.
The functionality is not impacted by any means by that (I even think to make
this the default mode...).
I'm running Slackware but also with a 3.x kernel. I'll try the -r option
but do not have high hopes because I do not even see the rip broadcasts
appearing on the tunnel interface with tcpdump.
It appears it works fine if I create the tunnel with:
/sbin/ifconfig tunl0 44.137.24.1 netmask 255.255.255.255 up
/sbin/route add -net 0.0.0.0 netmask 0.0.0.0 metric 128 tunl0
/sbin/route add -net 44.0.0.0/8 gw $GATEWAY tunl0
/sbin/route del default tunl0
But then I cannot set ttl to 64 (for traceroute).
it does not work when I create the tunnel with:
/sbin/ip tunnel add ampr0 mode ipip local 88.159.160.228 ttl 64
/sbin/ifconfig ampr0 44.137.24.1/32 multicast up
/sbin/ip route add default via 213.222.29.194 dev ampr0 onlink
table default
/sbin/ip rule add from 44.137.24.1 table default
/sbin/ip rule add from 44.137.24.1 to 44.0.0.0/8 table main
Strangely the static routes set above work.
But rip broadcasts don't come through. (I have changed the interface
name accordingly when starting ampr-ripd. i.e ampr0 instead of tunl0)
My firewall script does have the lines:
/usr/sbin/iptables -A INPUT -p ipip -j ACCEPT
/usr/sbin/iptables -A INPUT -p udp --dport 520 -j ACCEPT
On observation: using 44.137.27.112/28 in the -a option has no effect, since
44.137.27.112/28 is not broadcasted by UCSD.
ampr-ripd evaluates only EXACT entries in the encap, not IP ranges list.
But this should be of no importance for the moment.
I know. I removed 44.137.27.112/28 from my gateway on the portal a day
or two ago. I first want to get get it working for the single host.