linux-kernel - [PATCH 2/2] man/man7/ip.7: Reword IP

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <38cfae87620d99ab0fa15f1970ef18d4ab5ff5a5.1763130571.git.not@dzwdz.net>
Date: Fri, 14 Nov 2025 15:29:31 +0100
From: Jakub Głogowski <not@...dz.net>
To: Alejandro Colomar <alx@...nel.org>
Cc: Jakub Głogowski <not@...dz.net>,
	linux-man@...r.kernel.org,
	LKML <linux-kernel@...r.kernel.org>,
	Linux API <linux-api@...r.kernel.org>,
	ej@...i.de
Subject: [PATCH 2/2] man/man7/ip.7: Reword IP_PKTINFO's description

I've heavily cut down the first paragraph (which wasn't really saying
anything), and emphasized the difference between how recvmsg(2) and
sendmsg(2) treat this struct.

"This works only for datagram oriented sockets" is redundant with
"Not supported for SOCK_STREAM", and the mention of sendmsg(2) was moved
down.

I called it a boolean option because that's how these were introduced at
the start of the section.

I've tried rewording ipi_spec_dst's effect on sendmsg to be a bit more
clear.

The only piece of new information which this adds is that you can use
the structure returned by recvmsg with sendmsg, which directly follows
from the preceding text.

RFC 3542, Section 6, directly calls out this usecase for in6_pktinfo:

> Some UDP servers want to respond to client
> requests by sending their reply out the same interface on which the
> request was received and with the source IPv6 address of the reply
> equal to the destination IPv6 address of the request.  To do this the
> application can enable just the IPV6_RECVPKTINFO socket option and
> then use the received control information from recvmsg() as the
> outgoing control information for sendmsg().  The application need not
> examine or modify the in6_pktinfo structure at all.

I'm not sure if this is the best place to document this, as the sendmsg
behavior is unrelated to the IP_PKTINFO sockopt at all.  Maybe some of
the control messages should be broken out to another manpage?

Signed-off-by: Jakub Głogowski <not@...dz.net>
---
 man/man7/ip.7 | 49 +++++++++++++++++++++----------------------------
 1 file changed, 21 insertions(+), 28 deletions(-)

diff --git a/man/man7/ip.7 b/man/man7/ip.7
index a7f118b42..aa2508bc7 100644
--- a/man/man7/ip.7
+++ b/man/man7/ip.7
@@ -783,20 +783,13 @@ .SS Socket options
 .TP
 .BR IP_PKTINFO " (since Linux 2.2)"
 .\" Precisely: since Linux 2.1.68
-Pass an
-.B IP_PKTINFO
-ancillary message that contains a
-.I pktinfo
-structure that supplies some information about the incoming packet.
-This works only for datagram oriented sockets.
-The argument is a flag that tells the socket whether the
-.B IP_PKTINFO
-message should be passed or not.
-The message itself can be sent/retrieved
-only as a control message with a packet using
+If this boolean option is enabled,
 .BR recvmsg (2)
-or
-.BR sendmsg (2).
+outputs an
+.B IP_PKTINFO
+ancillary message containing an
+.I in_pktinfo
+structure.
 .IP
 .in +4n
 .EX
@@ -809,37 +802,37 @@ .SS Socket options
 .EE
 .in
 .IP
-When returned by
-.BR recvmsg (2) ,
+In this context,
 .I ipi_ifindex
 is the unique index of the interface the packet was received on.
 .I ipi_spec_dst
 is the preferred source address for replies to the given packet, and
 .I ipi_addr
-is the destination address in the packet header.
+is the destination address from the packet header.
 These addresses are usually the same,
 but can differ for broadcast or multicast packets.
 Note that, depending on the configured routes,
 .I ipi_spec_dst
 might belong to a different interface from the one that received the packet.
 .IP
-If
-.B IP_PKTINFO
-is passed to
-.BR sendmsg (2)
-and
+This structure can also be passed as an ancillary message to
+.BR sendmsg (2) .
+In that case,
 .\" This field is grossly misnamed
 .I ipi_spec_dst
-is not zero, then it is used as the local source address, for the routing
-table lookup, and for setting up IP source route options.
-When
+is used as the local source address
+(if non-zero),
+including for the purposes of setting up IP source route options.
+It's also used for the routing table lookup, unless
 .I ipi_ifindex
-is not zero, the primary local address of the interface specified by the
-index overwrites
-.I ipi_spec_dst
-for the routing table lookup.
+is non-zero \(en
+then the primary local address of that interface is used there instead.
 .I ipi_addr
 is ignored.
+The structure returned by
+.BR recvmsg (2)
+can be reused,
+which effectively sends a reply to the original packet.
 .IP
 Not supported for
 .B SOCK_STREAM
-- 
2.47.3