svn commit: r217592 - head/sys/netinet
jhb at freebsd.org
Wed Mar 30 18:27:51 UTC 2011
On Wednesday, March 30, 2011 11:42:01 am Daniel Eischen wrote:
> > BMS preserved this behavior and your patch changes
> But he changed the behavior on output. Pre-BMS and post-BMS
> behave differently and not like Solaris 10 or VxWorks. Haven't
> tried Linux.
Yes, I am not debating that. I'm merely talking about the input side.
> > it. UDP sockets start off with inp_moptions == NULL, so if you never do any
> > multicast-related setsockopt() you will receive all matching multicast packets.
> > However, once you do any multicast-related setsockopt() (IP_MULTICAST_LOOP,
> > IP_ADD_MEMBERSHIP, etc.) then inp_moptions is allocated and is non-NULL.
> > At that point it only accepts packets that match, except that even then we
> > used a sysctl which defaulted to off (!) to see if we should check the list of
> > memberships (net.inet.udp.strict_mcast_mship). This options structure was never
> > free'd, however, so you could get the truly bizarre behavior of:
> > - bind a new socket, it will not receive all matching multicast traffic
> > - use IP_ADD_MEMBERSHIP to add a group, it will now receive only matching multicast
> > traffic for the group
> > - use IP_DROP_MEMBERSHIP to remove the group, it will now receive no multicast
> > traffic
> > The different behavior in states 1 and 3 I find confusing and odd. By default
> > all sockets just always received all matching multicast traffic though. :)
> Not if a multicast group was not joined. The pre-BMS changes
> did not loop back multicast packets in ip_output.c.
Well, they would receive all multicast traffic that wasn't loopback traffic.
That is, if I had two sockets bound to *:2000 and *:4000 and one socket joined
a group 126.96.36.199, then both sockets would receive traffic bound for 188.8.131.52
if it matched their ports in both the pre-BMS code and in post-BMS but pre-RRS.
Now only the socket that did the join will receive the packets, so it is a
change in behavior.
Now I find this unintuitive, but other folks I have talked to have pointed out
that that could be a valid interpretation of binding to INADDR_ANY.
More information about the svn-src-head