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

From: Vlad Yasevich <[email-masked]>
Date: Tue, 19 Aug 2008 09:36:49 -0400

Yang Hongyang wrote:
> David Miller wrote:
>> From: Vlad Yasevich <[email-masked]>
>> 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?
>