[quagga-dev 4312] Re: ripd fails to leave multicast group on deleted interface

Paul Jakma paul at clubi.ie
Sun Aug 20 20:02:06 BST 2006


Hi Michal,

Thanks for this report. That explains a couple of bugzilla entries 
too (search for "No buffer space available", e.g. #118 and #282).

On Wed, 16 Aug 2006, Michal Ruzicka wrote:

> Hello

> I've run into problems with ripd of quagga-0.98.5, which turned out 
> to be cuased by ripd failing to leave a multicast group after an 
> interface has been deleted (which is often the case of ppp 
> interfaces). The problem is partly caused by ripd itself and partly 
> by linux kernel (2.6.16).

Ok.

> The ripd part of the problem is the assumption that it is not 
> necessary to explicitly leave multicast group on an interface that 
> is not UP (as chcked by if_is_up() function). This is not the case 
> at least on linux.

Which is the Linux kernel bug you're chasing up with the Linux netdev 
people, right?

It seems very strange that you could issue any kind of commands on 
deleted interfaces..

> 2006/08/09 01:50:02 RIP: turn on l2tp46792-55982
> 2006/08/09 01:50:03 RIP: multicast join at l2tp46792-55982
> 2006/08/09 01:50:03 RIP: can't setsockopt IP_ADD_MEMBERSHIP No buffer space
> available
> 2006/08/09 01:50:03 RIP: multicast join failed, interface l2tp46792-55982
> not running

Ah.

> @@ -242,6 +242,9 @@
>   /* RIP is running on this interface. */
>   int running;
>
> +  /* Joined to multicast group for this interface. */
> +  int joined_multicast;
> +

> void
> rip_multicast_leave (struct interface *ifp, int sock)
> {
> +  struct rip_interface *ri;
>   struct listnode *cnode;
>
> -  if (if_is_up (ifp) && if_is_multicast (ifp))
> +  ri = ifp->info;
> +
> +  if (ri->joined_multicast)
>     {

Hmm, we've added similar "multicast refcounting" to ospfd a while 
back (Greg and/or Andrew IIRC).

This really should be generalised and handled generically within 
libzebra really, rather than replicated (in various ways) in each 
daemon.

> PS: May be simlar problems exist in other routing deamons: ospfd, 
> ... I've not checked that.

ospfd shouldn't have this problem I think, see:

 	ospf_interface.c::ospf_if_set_multicast()

ospfd's paranoid handling of multicast memberships ought to be 
factored out to lib/{if,sockopt} really. (hint hint ;) ).

Thanks for the detailed report.

regards,
-- 
Paul Jakma	paul at clubi.ie	paul at jakma.org	Key ID: 64A2FF6A
Fortune:
See you in hell, candy boys!!

 		-- Homer Simpson
 		   Homer Badman



More information about the Quagga-dev mailing list