> > Sure, it's a workaround (it actually only clobbers it for apps that > > haven't explicitly requested a TTL). > > but that would cause most well-behaved apps to be affected by > the workaround for the problem app
Most apps are not very sensitive to the TTL so the affect is negligible in practice. Again, this is a knob that is tweaked in the field in an act of desperation. I think it'd be fine if it was only an mdb tunable, though I recall we got feedback that some customers are allergic to workarounds that involve mdb. > Looking at the code, it seems like ips_ip_def_ttl is used for all > the icmp errors. This then begs the question, "so what is icmp_def_ttl?"- > that's the ttl that can be set by both IP_TTL and by ndd for raw sockets > Then there's tcp_ttl: that seems to be used for creating the > header template for all tcp packets on a conn. All the ulp ttls seem to > follow a similar pattern. And all of them can be over-ridden by the > IP_TTL sockopt. I don't know why there are so many of these knobs; I suspect the source revision history will tell some interesting stories :-) > If all we want is a sledge-hammer to force ttls, can we not achieve > this by at most one ndd tunable that sets the ip ttl (instead of > having so many ulp ttls!)? Probably, though there is utility in having the unicast, multicast, and broadcast tunables remain separate. -- meem
