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 _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
