From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vlad Yasevich Subject: Re: [PATCH] IPv6:fix the return interface index when get it while no message is received Date: Wed, 20 Aug 2008 09:10:34 -0400 Message-ID: <48AC17CA.8010306@hp.com> References: <48A911AD.7060102@cn.fujitsu.com> <48A9799B.4040409@hp.com> <20080818.223857.125980599.davem@davemloft.net> <48AA6800.1020506@cn.fujitsu.com> <48AACC71.5090701@hp.com> <48AB87DE.1010205@cn.fujitsu.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: David Miller , netdev@vger.kernel.org, yoshfuji@linux-ipv6.org To: Yang Hongyang Return-path: Received: from g5t0007.atlanta.hp.com ([15.192.0.44]:23179 "EHLO g5t0007.atlanta.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752945AbYHTNKi (ORCPT ); Wed, 20 Aug 2008 09:10:38 -0400 In-Reply-To: <48AB87DE.1010205@cn.fujitsu.com> Sender: netdev-owner@vger.kernel.org List-ID: Yang Hongyang wrote: > Vlad Yasevich wrote: >> Yang Hongyang wrote: >>> David Miller wrote: >>>> From: Vlad Yasevich >>>> 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. > > Since here we do not recive any packet,we should return > src_info.ipi6_ifindex=0 and src_info.ipi6_addr=0::0,right? That's what I've done in other implementations. -vlad > >> -vlad >> >>>> Yang, please fix this up, thank you. >>>> >>>> >>> Seems that I misunderstood the RFC? > > >