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]
Message-ID: <457F1C2B.9000800@hp.com>
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)

Powered by blists - more mailing lists