> > > >We do have it for setsockopt(). It affects unicast traffic. > > > > > > Is there any dependency between IP_BROADCAST_TTL and > > > SO_BROADCAST? > > > >Given that SO_BROADCAST doesn't actually seem to do anything on Solaris > >(other than retrieve the value it was set to), there's no interaction > >today. In theory, one would have to enable SO_BROADCAST before being > >able to send packets that IP_BROADCAST_TTL would apply to. > > So there is no intention to change the way things are today?
Not as part of this case. > Given that this design has a very narrow scope in mind, it would > be beneficial if the name associated with the option was also > similarly narrow - something like IP_ALL_ONES_TTL - so as > to avoid confusion. What confusion? This is a consolidation-private socket option with one consumer. All IP_ALL_ONES_TTL would do is add cruft and complexity inside IP, since the semantics would no longer exactly mirror the cases where the ip_broadcast_ttl ndd tunable currently applies. Regardless, I fear this has become a shed-painting exercise. Surely there are more interesting matters to attend to? -- meem
