Peter Memishian wrote: > > >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? > > FWIW, this behaviour, of IP_TTL vs IP_BROADCAST_TTL vs > > IP_MULTICAST_TTL is going to differ from other platforms, > > increasing the difficulty of porting applications to/from Solaris. > > Whereas IP_MULTICAST_TTL seems to be common across > > the board, as to IP_TTL, IP_BROADCAST_TTL is not and in > > its place, IP_TTL is used. What benefit do we (Solaris and > > OpenSolaris) gain by being architecturally different in this > > to both BSD and Linux? > > > > Or in other words, why shouldn't we just fix IP_TTL to apply > > to both unicast and broadcast packets (but not multicast) > > like everyone else? > >Have you verified the behavior on the various BSDs and Linux? According >to the Linux documentation I've seen, IP_TTL would also apply to multicast >packets, > The source code disagrees with the documentation. >and looking at the FreeBSD source's ip_output(), it looks like >e.g. sending to 255.255.255.255 always sends with a TTL of 1 (regardless >of IP_TTL), and that is precisely the case that's of interest to the DHCP >client here. > > Not all of them exhibit this behaviour and only FreeBSD ditinguishes between 255.255.255.255 and other broadcast addresses. >Regardless, neither IP_TTL nor the proposed IP_BROADCAST_TTL are >documented interfaces nor does this case propose to make them such, so if >someone finds a grand unifying plan across the various Unices here and >wants to implement it, this case certainly doesn't stand in their way. > > 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. Darren
