NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: kern/41005: kernel failed to select correct outgoing address for Multicast packets

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:

On Fri, Mar 13, 2009 at 01:50:00PM +0000, wrote:

Number:         41005
Category:       kern
Synopsis:       kernel failed to select correct outgoing address for Multicast 
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

Dr. Nagler & Company GmbH


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: amd64


        If alias addresses are defined on an interface, the kernel does not use 
        information passed to it by IP_MULTICAST_IF option. Instead it always 
        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 
        to select the interface itself in the call and to pass it back to user 
        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?


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.

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


The IP_MULTICAST_IF has two ways of selecting the interface.
1. use an IP-address
2. use the interface index

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


Home | Main Index | Thread Index | Old Index