[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
problem.

> 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...

Regards,
Andy



More information about the Quagga-dev mailing list