(usagi-users 02624) Re: UDP IPv6 Multicast

[David Stevens <dlstevens@xxxxxxxxxx>]

The situation you've described should fail the check:

                   if (!ipv6_addr_any(&np->daddr) &&
                       ipv6_addr_cmp(&np->daddr, rmt_addr))
                               continue;

in udpv6_mcast_next() if the sockets are indeed *bound* to those
group addresses, and not bound to INADDR_ANY.

      If the sockets are bound to INADDR_ANY, and you've simply done
joins of different groups on each of them, then the behaviour is
correct. Group membership is for the interface, not for a particular
socket. Any socket joining a group will result in all INADDR_ANY-bound
sockets receive packets sent to that group with their respective ports.
      If you indeed used bind() to each of the groups with the same port,
that looks like a bug. The semantics of inet6_mc_check() should be the
same, however-- the change was to add support for source filters, which
should only drop some packets that otherwise would've been delivered if
a source filter for that source says so.

                              +-DLS


Brian Buesker <bbuesker@xxxxxxxxxxxx> on 11/14/2003 10:10:29 AM

Please respond to usagi-users@xxxxxxxxxxxxxx

To:    usagi-users@xxxxxxxxxxxxxx
cc:
Subject:    (usagi-users 02621) UDP IPv6 Multicast



I am noticing strange behavior on the 2.6 series kernel (I tested on
2.6.0-test9). When I have two sockets which bind to and join different
multicast addresses but with the same UDP port, and then I send a packet
to one of those multicast addresses, the packet gets delivered to both
of them. For example, if one socket is bound to ff01::1:1 UDP port 2000
and joins multicast group ff01::1:1, and a second socket is bound to
ff01::1:2 UDP port 2000 and joins multicast group ff01::1:2, and then I
send a packet to ff01::1:1 UDP port 2000, it actually gets delivered to
both sockets. This does not happen in the 2.4 series kernel.

I have narrowed it down to the interaction between the following two
functions in the kernel: inet6_mc_check and and udp_v6_mcast_next. It
seems that the return semantics were changed for inet6_mc_check in the
2.6 series kernel without changing the logic used when calling it in
udp_v6_mcast_next. Is there a reason for this change, or is this just a
bug?

Thanks,
Brian Buesker