Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 24 Dec 2008 17:56:40 +0200
From:      Ian FREISLICH <ianf@clue.co.za>
To:        Bruce Simpson <bms@incunabulum.net>
Cc:        Gerald Pfeifer <gerald@pfeifer.com>, Vladimir Grebenschikov <vova@fbsd.ru>, Kip Macy <kip.macy@gmail.com>, Qing Li <qingli@freebsd.org>, freebsd-net@freebsd.org, freebsd-current@freebsd.org, Sergey Matveychuk <sem@FreeBSD.org>
Subject:   Re: HEADSUP: arp-v2 has been committed 
Message-ID:  <E1LFW6C-0000uF-5C@clue.co.za>
In-Reply-To: <49524131.7010700@incunabulum.net> 
References:  <49524131.7010700@incunabulum.net> <494FAFAC.90802@FreeBSD.org> <E1LEfm2-000BPk-Rs@clue.co.za> <E1LF09h-0004XQ-O2@clue.co.za> 

next in thread | previous in thread | raw e-mail | index | archive | help
Bruce Simpson wrote:
> Ian FREISLICH wrote:
> > ...
> > I can't quite remember exactly why imr_ifindex doesn't work, but
> > on my hosts which have several hundred interfaces and my OSPF
> > sessions are never on the interface that has the default route,
> > until I explicitly set the imr_address, the kernel always chooses
> > the interface which has the default route.
> >   
> 
> Do you have applications which do not explicitly specify the interface 
> address to use for multicast group joins?
> 
> If they do not,  that's a bug in the application -- IPv4 and IPv6 
> multicast *requires* that a link be specified somehow, either using the 
> new APIs which take an ifindex, or an IPv4 "primary address".

quagga does specify the ifindex passed in a struct ip_mreqn in the
imr_ifindex member to setsockopt, which reading the documentation
should be sufficient, yet it is not.  I have checked that it does
set the correct ifindex.   Setting the IP address in the imr_address
member of the same struct correctly chooses the interface.

> Unfortunately there has been historical breakage in the multicast APIs. 
> There are some apps which run before all interfaces have been ifconfig'd 
> up in the system, and they need to create multicast sockets.
> 
> The kernel behaviour you describe is historical and I had to reintroduce 
> it to avoid breaking such applications. It is a kludge which we probably 
> can't retire until their developers fix their multicast apps to be aware 
> of multiple interfaces on the system.

Is this the BSD struct ip_mreq hack?  This particular code isn't
using that.

Ian

--
Ian Freislich



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E1LFW6C-0000uF-5C>