[quagga-dev 3674] Re: Patch to fix multicast problem on FreeBSD 5.x

Andrew J. Schorr aschorr at telemetry-investments.com
Wed Sep 21 16:29:35 BST 2005

On Wed, Sep 21, 2005 at 11:11:28AM -0400, Greg Troxel wrote:
> This is tough, at least until we find a standard that specifies
> drop-while-down behavior.  (Seriously, pointers appreciated - NetBSD
> is very hard core about standards compliance and if wrong I'd like to
> fix it.)  An OS could drop on a up->down transition, or maintain.  So
> I think drop failing leads to 'uncertain'.

So you would vote for the 3-way logic that I had originally suggested?

> A good point, and maybe true.  But drop/add and getting an ok return
> code is defensive.

Agreed.  The whole reason I added the state flag was to make the code
more defensive.  I didn't realize there were still potential problems
out there.  But it seems as if adding an uncertain state and dropping
before joining (if the state is uncertain) should probably fix the

> I think that fundamentally this is a workaround for not being able to
> drop memberships on an interface that is down, so it belongs in the
> highest-level multicast handling code we can put it.

I don't have strong feelings about this.  If there's a consensus,
then we can change the state to use 2 bits, and solve the problem
with extra logic in ospf_if_set_multicast.

On the other hand, this doesn't help solve the ripd problem.  If this
affects many daemons, then another approach would be to push it down
to the lowest level (lib/sockopt.c:setsockopt_multicast_ipv4) and
solve it once and for all in one function.

The submitted patch in bugzilla 212 covers the 3 places in the code where
setsockopt_multicast_ipv4 is called with IP_ADD_MEMBERSHIP (2 in ospfd, and 1
in ripd).  It seems to me that we should either push it down into the
setsockopt_multicast_ipv4 function so the patch is in one spot, or we should
push it up to a higher level on the theory that there's a logical problem
here that needs to be understood and handled by the user code...


More information about the Quagga-dev mailing list