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

(usagi-users 02625) Re: UDP IPv6 Multicast

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.

Yes, I did bind the sockets to the group addresses. I agree that the check above should fail, since the socket is not bound to the any address. Since it fails, that means the following check will eventually be performed (assuming the other checks succeed):

           if(!inet6_mc_check(s, loc_addr, rmt_addr))
               continue;

This check should succeed when the bound address is different from the group address, causing the loop to be continued. However, on the 2.6 series kernel it also succeeds and thus the socket is returned. The reason I asked about the semantics for inet6_mc_check changing was because in 2.4.20, it appears to me that 1 is returned if a match is found, and 0 is returned if a match is not found and in 2.6.0-test9, the opposite is done (1 is returned for not found and 0 is returned for found). However, the same if statement above is used in both kernel versions. If so, then udp_v6_mcast_next is misinterpretting the return value of inet6_mc_check.

Brian

      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