LDP
/
man-pages
mirror of https://github.com/mkerrisk/man-pages
0
1
Fork 0
Code Releases Activity

ipv6.7: Document IPV6_RECVPKTINFO 

Notes from Bert Hubert:
    Recently PowerDNS needed to support the getting of the
    original destination address of packets received on ::.
    Following the advice in ipv6(7) generated an error on
    setsockopt().

    Some googling confirmed that setsockopt() with
    IPV6_PKTINFO indeed does not work, but we found that
    IPV6_RECVPKTINFO did.

   Our experiences are detailed in
   http://bert-hubert.blogspot.nl/2012/10/on-binding-datagram-udp-sockets-to-any.html

    Please find attached a quite naive patch to ipv6.7 that at
    least fixes 'my' problem, but does not document if
    IPV6_PKTINFO ever worked as a flag. It does document that
    IPV6_RECVPKTINFO is available since 2.6.13.

    Please let me know if this patch is acceptable, or if you
    want me to dig deeper into the IPV6_PKTINFO situation.

Notes from mtk:
    Drop mention of IPV6_PKTINFO; that's IPV6_2292PKTINFO nowadays
    (and needs to be documented). And, confusingly, there's nowadays
    an IPV6_PKTINFO that is a quite different thig.

    With kernel commit 333fad5364d6b457c8d837f7d05802d2aaf8a961
    (Sep 2005) PV6_PKTINFO disappeared from the
    getsockopt/setsockopt API, and IPV6_2292PKTINFO took its place.
    Meanwhile, IPV6_RECVPKTINFO was added.

    Then kernel commit b24a2516d10751d7ed5afb58420df25370c9dffb
    (Dec 2008) added IPV6_PKTINFO back to the
    getsockopt/getsockopt API, but with what looks to be a
    rather different meaning (it takes a 'struct in6_pktinfo'
    as the third arg).

    This seems consistent (if confusing) with the RFCs:
    http://www.ietf.org/rfc/rfc2292.txt
    http://www.ietf.org/rfc/rfc3542.txt (obsoletes 2292)

    Both of those RFCs define an IPV6_PKTINO sockopt, but the
    former takes an int arg, and the latter takes a
    'struct in6_pktinfo'.

    So, my summary of your patch is that it's correct. (But I think
    that IPV6_RECVPKTINFO is present since 2.6.14, not 2.6.13.)

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This commit is contained in:
Bert Hubert 2012-10-21 12:51:33 +02:00 committed by Michael Kerrisk
parent 251da60bbb
commit d796c68d5a
1 changed files with 4 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
man7/ipv6.7
View File

@ -4,7 +4,7 @@
.\" and in case of nontrivial modification author and date
.\" of the modification is added to the header.
.\" $Id: ipv6.7,v 1.3 2000/12/20 18:10:31 ak Exp $
.TH IPV6 7 2012-05-10 "Linux" "Linux Programmer's Manual"
.TH IPV6 7 2012-10-12 "Linux" "Linux Programmer's Manual"
.SH NAME
ipv6 \- Linux IPv6 protocol implementation
.SH SYNOPSIS
@ -141,7 +141,7 @@ structure.
.\" FIXME IPV6_CHECKSUM is not documented, and probably should be
.\" FIXME IPV6_JOIN_ANYCAST is not documented, and probably should be
.\" FIXME IPV6_LEAVE_ANYCAST is not documented, and probably should be
.\" FIXME IPV6_RECVPKTINFO is not documented, and probably should be
.\" FIXME IPV6_PKTINFO is not documented, and probably should be
.\" FIXME IPV6_2292PKTINFO is not documented, and probably should be
.\" FIXME there are probably many other IPV6_* socket options that
.\" should be documented
@ -183,10 +183,11 @@ in an integer.
Control whether the socket sees multicast packets that it has send itself.
Argument is a pointer to boolean.
.TP
.B IPV6_PKTINFO
.BR IPV6_RECVPKTINFO " (since Linux 2.6.14)"
Set delivery of the
.B IPV6_PKTINFO
control message on incoming datagrams.
Such control messages contain a struct in6_pktinfo, as per RFC 3542.
Only allowed for
.B SOCK_DGRAM
or