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: <im2kp5dhyoqac7fs46zh2xmxcahkfy3a4qafeufakwrbezfv6j@ubfts6zwryx4>
Date: Mon, 24 Nov 2025 17:11:21 +0100
From: Alejandro Colomar <alx@...nel.org>
To: Jakub Głogowski <not@...dz.net>
Cc: linux-man@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>, 
	Linux API <linux-api@...r.kernel.org>, ej@...i.de
Subject: Re: [PATCH 2/2] man/man7/ip.7: Reword IP_PKTINFO's description

Hi Jakub,

On Fri, Nov 14, 2025 at 03:29:31PM +0100, Jakub Głogowski wrote:
> 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>

This patch doesn't apply anymore.  I guess it's some of the amendments
I applied in patch 1/2.  Would you mind rebasing and sending v2?


Have a lovely day!
Alex

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

-- 
<https://www.alejandro-colomar.es>
Use port 80 (that is, <...:80/>).

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ