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
| ||
|
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
Powered by blists - more mailing lists