Date: Fri, 16 Apr 2010 10:39:38 +0000 (UTC) From: "Bjoern A. Zeeb" <bz@FreeBSD.org> To: Bruce Simpson <bms@incunabulum.net> Cc: svn-src-head@freebsd.org, Alexander Leidinger <Alexander@Leidinger.net>, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r206452 - head/sys/netinet Message-ID: <20100416103826.X40281@maildrop.int.zabbadoz.net> In-Reply-To: <4BC83A12.2080700@incunabulum.net> References: <201004101205.o3AC5VGp074266@svn.freebsd.org> <4BC7486C.9010804@incunabulum.net> <20100416102318.16752py80bkf418g@webmail.leidinger.net> <4BC83A12.2080700@incunabulum.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 16 Apr 2010, Bruce Simpson wrote: > On 04/16/10 09:23, Alexander Leidinger wrote: >> >>> IP multicast group membership is always scoped to physical links [1]. The >>> 4.4BSD API originally used the "primary IP address" to identify each link. >>> Unfortunately this is not a persistent identifier, especially so in the >>> use-case which had problems. >> >> >> Is/was this the reason why multicast does not work in jails? > > The above point is totally unrelated to jail. > > I think the problem with jail is the fact that to receive multicast, sockets > normally need to be bound to INADDR_ANY. Obviously, jail changes socket > behaviour in interesting ways. > > This may require refactoring udp_input() considerably. We use the 4.4BSD > legacy LIST_FOREACH() loop to deliver, rather than using a fan-in map (which > is the Windows/Solaris approach). > > Linux also has 4.4BSD semantics, but can work around this by examining the > SO_BINDTODEVICE option in the same path. SO_BINDTODEVICE would not be enough of a check unless the interface could be dedicated to a jail which classic jails did and do not support. Virtual network stacks will be the solution for this. -- Bjoern A. Zeeb It will not break if you know what you are doing.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100416103826.X40281>