IPv6:fix the return interface index when get it while no message is received

When get receiving interface index while no message is received, the bounded device's index of the socket should be returned.

RFC 3542:
Issuing getsockopt() for the above options will return the sticky option value i.e., the value set with setsockopt(). If no sticky option value has been set getsockopt() will return the following values:

- For the IPV6_PKTINFO option, it will return an in6_pktinfo structure with ipi6_addr being in6addr_any and ipi6_ifindex being zero.

Signed-off-by Yang Hongyang<[email protected]>

When get receiving interface index while no message is received, the bounded device's index of the socket should be returned.

RFC 3542:
Issuing getsockopt() for the above options will return the sticky option value i.e., the value set with setsockopt(). If no sticky option value has been set getsockopt() will return the following values:

- For the IPV6_PKTINFO option, it will return an in6_pktinfo structure with ipi6_addr being in6addr_any and ipi6_ifindex being zero.

Signed-off-by Yang Hongyang<[email protected]>

---
 ipv6_sockglue.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

net/ipv6/ipv6_sockglue.c +1 -1

index 2cabac9..e4f8d29 100644
@@ -911,7 +911,7 @@ static int do_ipv6_getsockopt(struct sock *sk, int level, int optname,
 		} else {
 			if (np->rxopt.bits.rxinfo) {
 				struct in6_pktinfo src_info;
-				src_info.ipi6_ifindex = np->mcast_oif;
+				src_info.ipi6_ifindex = np->mcast_oif ? np->mcast_oif : sk->sk_bound_dev_if;
 				ipv6_addr_copy(&src_info.ipi6_addr, &np->daddr);
 				put_cmsg(&msg, SOL_IPV6, IPV6_PKTINFO, sizeof(src_info), &src_info);
 			}

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.

Additionally the address returned is completely bogus as well. We are returning the address our peer instead of the one of our own addresses.

From: Vlad Yasevich <[email protected]>
Date: Mon, 18 Aug 2008 09:31:07 -0400

Quoted 4 lines

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.

Quoted 4 lines

Additionally the address returned is completely bogus as well. We are returning the address our peer instead of the one of our own addresses.

Yang, please fix this up, thank you.

Quoted 3 lines · David Miller

From: Vlad Yasevich <[email protected]>
Date: Mon, 18 Aug 2008 09:31:07 -0400

Quoted 4 lines

Quoted 4 lines

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?

Quoted 4 lines

Quoted 4 lines

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.

Quoted 4 lines

Yang, please fix this up, thank you.

Seems that I misunderstood the RFC?

Quoted 11 lines · Yang Hongyang

Quoted 7 lines · David Miller

From: Vlad Yasevich <[email protected]>
Date: Mon, 18 Aug 2008 09:31:07 -0400

Quoted 4 lines

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.

Quoted 6 lines

Quoted 3 lines

Quoted 3 lines

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

Quoted 4 lines

Quoted 3 lines

Yang, please fix this up, thank you.

Seems that I misunderstood the RFC?

Quoted 28 lines · Vlad Yasevich

Quoted 11 lines · Yang Hongyang

Quoted 7 lines · David Miller

From: Vlad Yasevich <[email protected]>
Date: Mon, 18 Aug 2008 09:31:07 -0400

Quoted 4 lines

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.

Quoted 6 lines

Quoted 3 lines

Quoted 3 lines

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.

Quoted 4 lines

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?

Quoted 7 lines

-vlad

Quoted 4 lines

Quoted 3 lines

Yang, please fix this up, thank you.

Seems that I misunderstood the RFC?

Quoted 8 lines · Yang Hongyang

Quoted 6 lines · Vlad Yasevich

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.

Quoted 2 lines

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.