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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 08 Aug 2008 10:58:04 -0400
From:	Vlad Yasevich <vladislav.yasevich@...com>
To:	David Miller <davem@...emloft.net>
Cc:	yanghy@...fujitsu.com, yoshfuji@...ux-ipv6.org,
	netdev@...r.kernel.org
Subject: Re: [PATCH] IPv6:fix the return interface index when get it while
 no message is received

David Miller wrote:
> From: Yang Hongyang <yanghy@...fujitsu.com>
> Date: Fri, 08 Aug 2008 13:59:54 +0800
> 
>> Yang Hongyang wrote:
>>> when I use getsockopt(sk, IPPROTO_IPV6, IPV6_2292PKTOPTIONS,(char *)incmsg, &cnt)
>>> to get receiving interface index while no message is received,
>>>
>>> What interface index should be returned?
>> When get receiving interface index while no message is received,
>> the bounded device's index of the socket should be returned?
>>
>> Signed-off-by: Yang Hongyang<yanghy@...fujitsu.com>
> 
> To me it seems to be an undefined operation.
> 
> One cannot expect something valid from this socket option until a
> packet really is received on the socket.

Here is what 2292 has to say:

>   The corresponding receive option
> 
>        getsockopt(fd, IPPROTO_IPV6, IPV6_PKTOPTIONS, &buf, &len);
> 
>    returns a buffer with one or more ancillary data objects for all the
>    optional receive information that the application has previously
>    specified that it wants to receive.  The fourth argument points to
>    the buffer that is filled in by the call.  The fifth argument is a
>    pointer to a value-result integer: when the function is called the
>    integer specifies the size of the buffer pointed to by the fourth
>    argument, and on return this integer contains the actual number of
>    bytes that were returned.  The application processes this buffer
>    exactly as if the buffer were returned by recvmsg() as control
>    information.


So, there return value should be any sticky options set.

In the case of PKTINFO, the interface should be either 0 or the one
set by the sticky option.

The address should be should be from the options or IN6ADDR_ANY.

This is all for RFC2292 style.

For RFC 3542 style,  there what should be done:

   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.

-vlad
--
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