(usagi-users 02626) Re: UDP IPv6 Multicast

[David Stevens <dlstevens@xxxxxxxxxx>]

Sorry, I meant "fail" in the sense that socket wouldn't match (meaning the
test would succeed).
If it's not the "any" address,  the ipv6_addr_cmp() will return nonzero
when they don't match.

But I may be confused about whether that's checking the local addresses or
the remote addresses
(ie, verifying the bind() side on a receive or verifying the connect() side
on a receive). It may be
the later check, which does not do a "continue" if they don't match that is
the real place where it
should be skipped.

I believe inet6_mc_check() should *only* be called with an INADDR_ANY-bound
socket; those
bound to specific addresses that don't match should do a "continue" in the
loop before it gets
there.

I'm putting together some tests to reproduce the problem; will continue to
look at it.

                              +-DLS


Brian Buesker <bbuesker@xxxxxxxxxxxx> on 11/14/2003 01:22:51 PM

Please respond to usagi-users@xxxxxxxxxxxxxx

To:    usagi-users@xxxxxxxxxxxxxx
cc:
Subject:    (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
>
>
>
>
>