netdev - Re: [PATCH] IPv6:fix the return interface index when get it while no message is received

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: <48AACC71.5090701@hp.com>
Date:	Tue, 19 Aug 2008 09:36:49 -0400
From:	Vlad Yasevich <vladislav.yasevich@...com>
To:	Yang Hongyang <yanghy@...fujitsu.com>
Cc:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
	yoshfuji@...ux-ipv6.org
Subject: Re: [PATCH] IPv6:fix the return interface index when get it while
 no message is received

Yang Hongyang wrote:
> David Miller wrote:
>> From: Vlad Yasevich <vladislav.yasevich@...com>
>> Date: Mon, 18 Aug 2008 09:31:07 -0400
>>
>>> I don't think that's correct at all.  The code path shows here is
>>> when there are no received options and no sticky options set.  In
>>> such case, we shouldn't be returning multicast or bound interfaces.
>>> We should be returning 0.
> 
> I use setsockopt() to set the bounded interface of the socket, and 
> then I get receiving interface index while no message is received through
> the above socket,shoudn't the bounded interface be returned?

One of the problems is that we don't seem to support the sticky IPV6_PKTINFO
option as specified in rfc3542.

The setting of SO_BINDTODEVICE should not impact the return of the sticky option
values when they are not set.  A return of 0 in the sticky options means that
that value has not been specified.  If you return anything else, you give
the illusion that a sticky option was set.

> 
>>> Additionally the address returned is completely bogus as well. We
>>> are returning the address our peer instead of the one of our own
>>> addresses.
> 
> If message is received,the address returned is what the received
> message refered to, otherwise the address returned is what I used setsockopt()
> to set before.

We are returning np->daddr, which is the peer address.

The expected value is "destination of the received packet".  In the worst case,
it should be the locally bound address.  In the correct case, it should be the
address set in the sticky options if such is set.  It really should be 0::0, if there
are no sticky options and no packets have been received.

-vlad

> 
>> Yang, please fix this up, thank you.
>>
>>
> 
> Seems that I misunderstood the RFC?
> 

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html