svn commit: r217592 - head/sys/netinet

[John Baldwin]

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 224.1.2.3, then both sockets would receive traffic bound for 224.1.2.3
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.

-- 
John Baldwin