Re: Fw: [Bugme-new] [Bug 7665] New: getsockopt(IPV6_*CAST_HOPS) returns -1

["Rémi Denis-Courmont" <rdenis@simphalempin.com>]

	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