netdev - Re: Fw: [Bugme-new] [Bug 7665] New: getsockopt(IPV6_*CAST

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 12 Dec 2006 16:16:27 -0500
From:	Brian Haley <brian.haley@...com>
To:	Rémi Denis-Courmont <rdenis@...phalempin.com>
Cc:	Andrew Morton <akpm@...l.org>, netdev@...r.kernel.org,
	David Miller <davem@...emloft.net>
Subject: Re: Fw: [Bugme-new] [Bug 7665] New: getsockopt(IPV6_*CAST_HOPS) returns
 -1

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

-1 means un-initialized.

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

The following patch seems to work for me, but this code has behaved this 
way for a while, so don't know if it will break any existing apps.

-Brian


Signed-off-by: Brian Haley <brian.haley@...com>


View attachment "ipv6hops.patch" of type "text/x-patch" (777 bytes)