Capitalization in .SS sections across pages (and sometimes even
within a single page) is wildly inconsistent. Make it consistent.
Capitalize first word in heading, but otherwise use lower case,
except where English usage (e.g., proper nouns) or programming
language requirements (e.g., identifier names) dictate otherwise.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
In IPv4,IP_MTU is only supported by getsockopt.
In IPv6, we can use IPV6_MTU to set socket's MTU,
but the return value of getsockopt() is the path MTU.
Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
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.txthttp://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>
Some of the sockets/network protocol pages included names of
the corresponding address family constants in the NAME line,
but this wasn't done consistently across all pages, and probably
it adds little value in those pages that did do this. So, remove
these constants from those pages that have them in the NAME
section.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The tendency in English, as prescribed in style guides like
Chicago MoS, is towards removing hyphens after prefixes
like "non-" etc.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The page should use the types specified by POSIX,
rather than the (equivalent) types used in the kernel.
See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=517074
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
PF_ constants have always had the same values; there never has
been a protocol family that had more than one address family,
and POSIX.1-2001 only specifies the AF_* constants.
PF_ constants have always had the same values; there never has
been a protocol family that had more than one address family,
and POSIX.1-2001 only specifies the AF_* constants.