> >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. > 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, 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. 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. -- meem
