Hi, see below David Young wrote:
On Mon, Mar 16, 2009 at 11:02:54AM +0100, Wolfgang Stukenbrock wrote:Hi, see below David Young wrote:I cannot answer your question at the moment, because the software uses the (RAW) socket to send data to all interfaces and recieves data from everywhere. (But I think it would use that address, because the src-address of the socket is the first one used when the outgooing address is determined by the kernel.) But for any software that uses RAW (or UDP) socket for all multicast communication it is impossible to bind to any address without loosing the socket for all other addresses. So bind(2) is no option.On Fri, Mar 13, 2009 at 01:50:00PM +0000, Wolfgang.Stukenbrock%nagler-company.com@localhost wrote:Number: 41005 Category: kern Synopsis: kernel failed to select correct outgoing address for Multicast packets Confidential: no Severity: serious Priority: high Responsible: kern-bug-people State: open Class: sw-bug Submitter-Id: net Arrival-Date: Fri Mar 13 13:50:00 +0000 2009 Originator: Wolfgang Stukenbrock Release: NetBSD 4.0 Organization:Dr. Nagler & Company GmbHEnvironment:System: NetBSD s012 4.0 NetBSD 4.0 (NSW-S012) #9: Fri Mar 13 12:31:52 CET 2009 wgstuken@s012:/usr/src/sys/arch/amd64/compile/NSW-S012 amd64 Architecture: x86_64 Machine: amd64Description:If alias addresses are defined on an interface, the kernel does not use the information passed to it by IP_MULTICAST_IF option. Instead it always uses the primary address of the interface. This will break e.g. gated on such interfaces. The problem is, that the information passed by IP_MULTICAST_IF is only used to select the interface itself in the call and to pass it back to user level on a call got getoption IP_MULTICAST_IF under some circumstances. But is is ignored when sending packets with .e.g. sendto().What if you bind(2) the source address that you want? Aren't the multicast packets sent with the correct source address, then? DaveThe program that failed was gated. It uses multicast and does some checks on the packet contents and the check fail with the wrong src address. E.g. our Solaris the systems uses the address set with IP_MULTICAST_IF and everything works fine. The intent of IP_MULTICAST_IF looks to me, that it selects the interface and the address to be used - if an address is specified. (remark : I haven't read the RFC's about Multicast, so I may be wrong - even RFC's defines sometimes strange semantics.)I also haven't completly analysed the way netbsd selects addresses. I've recognised that at the interface level multicast packets send over the socket will ony come there without an address assigned, if there are alias addresses defined on the interface. If there is only one address, it is already set int the packet. Where this is done I haven't analysed.The whole problem is only related to multicast communication.If unicast pakets are send over the socket, the correct src address is selected from the set of alias addresses.It is my understanding of ip(4) that IP_MULTICAST_IF is only intended to select the output interface. I think that in applications where the source address matters, you can and you should specify it with bind(2). There is no strong notion of "correct source address" in the kernel, unless you use 'options IPSELSRC'. Dave
The IP_MULTICAST_IF has two ways of selecting the interface. 1. use an IP-address 2. use the interface indexWhen using the interface index and there are multiple addresses on the interface, this call does not specify a specific address. In this case any address can be selected - but it should be always the same one ...
If an address is specified, from my understanding this is the address to be used in the multicast packet. It is only possible to specify on of the addresses of the interface, but it is a little bit strange to select one address, but an other is used in the packets. Most applications will use the address for identification of partners. Of cause, most aplication will normaly not use more than one address on an interface - only routing software needs to do so. Otherwise the source address may be not on one of the interfaces of the partner and perhaps there is no routing information setup for security reason (or whatever), so that the client sudddenly cannot reach the partner that send the multicast packet to setup an unicase connection.
It looks like the specification of ip(4) is not 100% clear in this point and both ways may have arguments. I think it is less surprising for applications, if the address used in IP_MULTICAST_IF is the address in the packet too.
Wolfgang