public inbox for passt-dev@passt.top
 help / color / mirror / code / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: Jon Maloy <jmaloy@redhat.com>
Cc: passt-dev@passt.top, sbrivio@redhat.com, lvivier@redhat.com,
	dgibson@redhat.com
Subject: Re: [PATCH v5 4/4] udp: create and send ICMPv6 to local peer when applicable
Date: Mon, 24 Feb 2025 13:21:40 +1100	[thread overview]
Message-ID: <Z7vXtGlmVIAKbPtc@zatzit> (raw)
In-Reply-To: <20250223225951.3534010-5-jmaloy@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 6297 bytes --]

On Sun, Feb 23, 2025 at 05:59:51PM -0500, Jon Maloy wrote:
> When a local peer sends a UDP message to a non-existing port on an
> existing remote host, that host will return an ICMP message containing
> the error code ICMP_PORT_UNREACH, plus the header and the first eight
> bytes of the original message. If the sender socket has been connected,
> it uses this message to issue a "Connection Refused" event to the user.
> 
> Until now, we have only read such events from the externally facing
> socket, but we don't forward them back to the local sender because
> we cannot read the ICMP message directly to user space. Because of
> this, the local peer will hang and wait for a response that never
> arrives.
> 
> We now fix this for IPv6 by recreating and forwarding a correct ICMP
> message back to the internal sender. We synthesize the message based
> on the information in the extended error structure, plus the returned
> part of the original message body.
> 
> Note that for the sake of completeness, we even produce ICMP messages
> for other error codes. We have noticed that at least ICMP_PROT_UNREACH
> is propagated as an error event back to the user.
> 
> Signed-off-by: Jon Maloy <jmaloy@redhat.com>
> ---
>  tap.c |  8 ++++----
>  tap.h |  4 ++++
>  udp.c | 47 ++++++++++++++++++++++++++++++++++++++++++++++-
>  3 files changed, 54 insertions(+), 5 deletions(-)
> 
> diff --git a/tap.c b/tap.c
> index 380a7b9..31aec62 100644
> --- a/tap.c
> +++ b/tap.c
> @@ -247,10 +247,10 @@ void tap_icmp4_send(const struct ctx *c, struct in_addr src, struct in_addr dst,
>   *
>   * Return: pointer at which to write the packet's payload
>   */
> -static void *tap_push_ip6h(struct ipv6hdr *ip6h,
> -			   const struct in6_addr *src,
> -			   const struct in6_addr *dst,
> -			   size_t l4len, uint8_t proto, uint32_t flow)
> +void *tap_push_ip6h(struct ipv6hdr *ip6h,
> +		    const struct in6_addr *src,
> +		    const struct in6_addr *dst,
> +		    size_t l4len, uint8_t proto, uint32_t flow)
>  {
>  	ip6h->payload_len = htons(l4len);
>  	ip6h->priority = 0;
> diff --git a/tap.h b/tap.h
> index b7b8cef..67aa9e6 100644
> --- a/tap.h
> +++ b/tap.h
> @@ -53,6 +53,10 @@ void *tap_push_uh6(struct udphdr *uh,
>  		   void *in, size_t dlen);
>  void *tap_push_ip4h(struct iphdr *ip4h, struct in_addr src,
>  		    struct in_addr dst, size_t l4len, uint8_t proto);
> +void *tap_push_ip6h(struct ipv6hdr *ip6h,
> +		    const struct in6_addr *src,
> +		    const struct in6_addr *dst,
> +		    size_t l4len, uint8_t proto, uint32_t flow);
>  void tap_udp4_send(const struct ctx *c, struct in_addr src, in_port_t sport,
>  		   struct in_addr dst, in_port_t dport,
>  		   const void *in, size_t dlen);
> diff --git a/udp.c b/udp.c
> index 3dfd478..0e37fb3 100644
> --- a/udp.c
> +++ b/udp.c
> @@ -88,6 +88,7 @@
>  #include <netinet/ip.h>
>  #include <netinet/udp.h>
>  #include <netinet/ip_icmp.h>
> +#include <netinet/icmp6.h>
>  #include <stdint.h>
>  #include <stddef.h>
>  #include <string.h>
> @@ -440,6 +441,46 @@ static void udp_send_conn_fail_icmp4(const struct ctx *c,
>  	tap_icmp4_send(c, oaddr, eaddr, &msg, msglen);
>  }
>  
> +
> +/**
> + * udp_send_conn_fail_icmp6() - Construct and send ICMP to local peer

s/ICMP/ICMPv6/

> + * @c:	          Execution context
> + * @ee:	  Extended error descriptor
> + * @ref:	  epoll reference
> + * @in:	  First bytes (max 8) of original UDP message body
> + * @dlen:	  Length of the read part of original UDP message body
> + * @flow:	  IPv6 flow identifier

As with 2/4 a bunch of these function comments seem to use
inconsistent tabs/spaces before the parameter descriptions.

> + */
> +static void udp_send_conn_fail_icmp6(const struct ctx *c,
> +				     const struct sock_extended_err *ee,
> +				     const struct flowside *toside,
> +				     void *in, size_t dlen, uint32_t flow)
> +{
> +	const struct in6_addr *oaddr = &toside->oaddr.a6;
> +	const struct in6_addr *eaddr = &toside->eaddr.a6;
> +	in_port_t eport = toside->eport;
> +	in_port_t oport = toside->oport;
> +	struct {
> +		struct icmp6_hdr icmp6h;
> +		struct ipv6hdr ip6h;
> +		struct udphdr uh;
> +		char data[8];
> +	} __attribute__((packed, aligned(__alignof__(max_align_t)))) msg;
> +	size_t msglen = sizeof(msg) - sizeof(msg.data) + dlen;
> +	size_t l4len = dlen + sizeof(struct udphdr);
> +
> +	memset(&msg, 0, sizeof(msg));
> +	msg.icmp6h.icmp6_type = ee->ee_type;
> +	msg.icmp6h.icmp6_code = ee->ee_code;
> +
> +	/* Reconstruct the original headers as returned in the ICMP message */
> +	tap_push_ip6h(&msg.ip6h, eaddr, oaddr, l4len, IPPROTO_UDP, flow);
> +	tap_push_uh6(&msg.uh, eaddr, eport, oaddr, oport, in, dlen);
> +	memcpy(&msg.data, in, dlen);
> +
> +	tap_icmp6_send(c, oaddr, eaddr, &msg, msglen);
> +}
> +
>  /**
>   * udp_sock_recverr() - Receive and clear an error from a socket
>   * @c:	          Execution context
> @@ -498,8 +539,12 @@ static int udp_sock_recverr(const struct ctx *c, union epoll_ref ref)
>  	if (ref.type == EPOLL_TYPE_UDP_REPLY) {
>  		flow_sidx_t sidx = flow_sidx_opposite(ref.flowside);
>  		const struct flowside *toside = flowside_at_sidx(sidx);
> +		uint32_t flow = sidx.flowi;
>  
> -		udp_send_conn_fail_icmp4(c, ee, toside, data, rc);
> +		if (ee->ee_type == ICMP_DEST_UNREACH)
> +			udp_send_conn_fail_icmp4(c, ee, toside, data, rc);
> +		else if (ee->ee_type == ICMP6_DST_UNREACH)
> +			udp_send_conn_fail_icmp6(c, ee, toside, data, rc, flow);

Ah... there's another little wrinkle I didn't consider looking at 2/4.
This will work or now, but at some point we want to allow passt to be
configured to NAT between IPv4 and IPv6.  That means that we shouldn't
base whether we sent an ICMP or ICMPv6 to the guest on whether we
received an ICMP or ICMPv6 on the socket side.  Instead we should look
at whether the guest is using IPv6 for this flow, so using inany_v4()
the addresses in toside.

>  	} else {
>  		trace("Ignoring received cmsg on listener socket");
>  	}

-- 
David Gibson (he or they)	| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you, not the other way
				| around.
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

      reply	other threads:[~2025-02-24  2:21 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-23 22:59 [PATCH v5 0/4] Reconstruct ICMP headers for failed UDP connect Jon Maloy
2025-02-23 22:59 ` [PATCH v5 1/4] tap: break out building of udp header from tap_udp4_send function Jon Maloy
2025-02-23 22:59 ` [PATCH v5 2/4] udp: create and send ICMPv4 to local peer when applicable Jon Maloy
2025-02-24  2:13   ` David Gibson
2025-02-23 22:59 ` [PATCH v5 3/4] tap: break out building of udp header from tap_udp6_send function Jon Maloy
2025-02-24  2:16   ` David Gibson
2025-02-23 22:59 ` [PATCH v5 4/4] udp: create and send ICMPv6 to local peer when applicable Jon Maloy
2025-02-24  2:21   ` David Gibson [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Z7vXtGlmVIAKbPtc@zatzit \
    --to=david@gibson.dropbear.id.au \
    --cc=dgibson@redhat.com \
    --cc=jmaloy@redhat.com \
    --cc=lvivier@redhat.com \
    --cc=passt-dev@passt.top \
    --cc=sbrivio@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://passt.top/passt

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for IMAP folder(s).