While debugging the "suddenly lost route" that happened again at our gateway today, I stopped and restarted ampr-ripd to use the debug option, and now it suddenly no longer receives any multicast packets. I think I have read on this list or elsewhere that there is an issue with a recent glibc update or kernel update (not sure which one it was). Does anyone have details?
Now ampr-ripd only works when the -r flag is passed. Without -r it sets up everything and it opens the multicast socket (which appears to work OK when looking in the trace, it is opened on the tunl0 interface), but nothing is ever received.
It looks like it worked OK during the previous run, which was probably using an older glibc that was updated recently (but the system had not been rebooted). It is a Debian Wheezy system, so similar issues probably occur on the Raspberry Pi.
W.r.t. the problem I was tracking: the route to 44.137.33.48/28 via 92.108.199.241 dev tunl0 has suddenly vanished at 17:00 local time (16:00 UTC), but when I looked in a wireshark dump it was appearing in the RIP broadcast. ampr-ripd did not pick it up. To trace that I recompiled ampr-ripd with debug code, started it, and then I noticed it would no longer receive ANYTHING.
With -r it again receives packets and it also inserted the route to 44.137.33.48/28 again, so I am still at a loss what happened there.
Rob
Rob et al.
On my server running Debian-7.7.0 i686 updated&upgraded to date, I invoke ampr-ripd WITH -r option for a long time already. That's why I did not noticed such strange effect yet.
Being curious will try to remove -r just to see what is going to happen then...
Best regards.
Hi Rob,
ampr-ripd works as expected without the -r option on my debian 7 setup with kernel 3.2.0-4 and libc 2.13.38-0deb7u7. I never upgraded to 2.13.38-0deb7u8, so the problem could be there.
By the way, as sugested by Brian, N1URO, I think the -r option could be dropped so that the daemon always uses raw sockets. The only restriction would be that it must be run as root, since access to raw sockets is restricted to root only, but this shouldn't be a problem.
73s de Marius, YO2LOJ
Marius et al.
My server uses newest libc6-i686:i386 2.13-38+deb7u8 now. Restarted system at 19:30UTC, ampr-ripd WITHOUT -r option! I think I can confirm Rob's observation :(( System still uses data received at 19:20UTC.
Will report again few hours later.
Best regards.
Marius (et al)
On Mon, 2015-03-02 at 21:44 +0200, Marius Petrescu wrote:
ampr-ripd works as expected without the -r option on my debian 7 setup with kernel 3.2.0-4 and libc 2.13.38-0deb7u7. I never upgraded to 2.13.38-0deb7u8, so the problem could be there.
I've seen some funkiness with some of the newer libc and it varies based on distro. My fear is that they're slowly getting ready for System D :\
Marius, Rob et al.
After running ampr-ripd WITHOUT -r option. Hereby I confirm that for more than hour there was not even single RIP packect received.
Now my ampr-ripd runs WITH -r opiton just happily; when after few minutes received data at 20:50 UTC full updated routing cames to life.
Best regards,
on my linux mint mate desktop x64: ve1jot@jj-desktop4 ~ $ dmesg | grep systemd [ 1.952731] systemd-udevd[131]: starting version 204 [ 18.827583] systemd-udevd[398]: starting version 204 ---------------------------------------------------------------------------------- and: Linux jj-desktop4 3.13.0-46-lowlatency #76-Ubuntu SMP PREEMPT Thu Feb 26 19:18:14 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux ------------------------------------------------------------------------------------------ and: libc6_2.19-0ubuntu6.6_amd64
On 15-03-02 04:47 PM, Brian wrote:
(Please trim inclusions from previous messages) _______________________________________________ Marius (et al)
On Mon, 2015-03-02 at 21:44 +0200, Marius Petrescu wrote:
ampr-ripd works as expected without the -r option on my debian 7 setup with kernel 3.2.0-4 and libc 2.13.38-0deb7u7. I never upgraded to 2.13.38-0deb7u8, so the problem could be there.
I've seen some funkiness with some of the newer libc and it varies based on distro. My fear is that they're slowly getting ready for System D :\