Hello Arno,
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...).
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.
Marius, YO2LOJ
-----Original Message----- From: 44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of Arno Verhoeven Sent: Saturday, December 27, 2014 12:19 To: AMPRNet working group Subject: Re: [44net] How to make traffic coming in on the tunnel interface get answered from that interface?
(Please trim inclusions from previous messages) _______________________________________________
On 27-12-14 11:09, Marius Petrescu wrote:
@Arno: Congratulations. Nice to hear that.
Thanks, but I'm not completely there yet. For some reason I lost ampr-ripd functionality. ampr-ripd is running, but does not actually set any routes.
with 'tcpdump -vvv -s0 -n proto ipencap' I see encapsulated ripv2 traffic arriving at eth0. But when I check with 'tcpdump -i tun1 -vv' I see none of those on the tunnel interface.
It worked before, and I can figure out why it doesn't work now....
_________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net