Hello, Le lundi 11 décembre 2006 22:55, Brian Haley a écrit : > Andrew Morton wrote: > > Where fd is a socket (datagram or raw) with IPv6 protocol family, > > getsockopt(fd, IPPROTO_IPV6, IPV6_UNICAST_HOPS, ...) succeeds, but > > the returned hop limit is -1. connect()'ing the socket first does > > not solve the problem. > > An IPv6 socket's hoplimit value is not set at creation time, instead, > the hoplimit in an outgoing packet is set dynamically at transmit > time to one of the following (in this order): > > 1. Hoplimit route metric (if set) > 2. Outgoing interface value (/proc/sys/net/ipv6/conf/ethX/hop_limit) > 3. Global IPv6 value (/proc/sys/net/ipv6/conf/all/hop_limit) > > A setsockopt() value *will* override this.
Relevant standard (RFC 3493) notes: The IPV6_UNICAST_HOPS option may be used with getsockopt() to determine the hop limit value that the system will use for subsequent unicast packets sent via that socket. I don't reckon -1 could be the hop limit value. IMHO, the value from case 1 (if socket is connected to some destination), otherwise case 2 (if bound to a scope interface) or ultimately the default hop limit ought to be returned instead, as it will be most often correct, while the current behavior is always wrong, unless setsockopt() has been used first. I don't if some people may think doing a route lookup in getsockopt might be overly expensive, but at least the two other cases should be ok, particularly the last one. -- Rémi Denis-Courmont - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
