From mboxrd@z Thu Jan 1 00:00:00 1970
Authentication-Results: passt.top; dmarc=pass (p=quarantine dis=none) header.from=redhat.com
Authentication-Results: passt.top;
dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=I33ucN4z;
dkim-atps=neutral
Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124])
by passt.top (Postfix) with ESMTPS id 871B25A0008
for <passt-dev@passt.top>; Wed, 26 Mar 2025 23:24:03 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
s=mimecast20190719; t=1743027842;
h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
to:to:cc:mime-version:mime-version:content-type:content-type:
content-transfer-encoding:content-transfer-encoding:
in-reply-to:in-reply-to:references:references;
bh=E4mFDyE4smYqp17gnhh8mm3yEcYF1iqVRufwfC3qDaA=;
b=I33ucN4zkN5ecsXhqfRa0rxWNlftmQLbvmEcImlod4phU6wHk+8J4vK/hGyUGFvSnYdB7f
mlgPwTCU7MeX2LRRiXFa3fUTHKIkgryHX4N04ESNnO75BmCnZfiKQAT3M17T5roezN0x3P
M6M7Mf+IV+9/xtF+UsdijxHru9SZRYM=
Received: from mail-il1-f198.google.com (mail-il1-f198.google.com
[209.85.166.198]) by relay.mimecast.com with ESMTP with STARTTLS
(version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
us-mta-644-TsBujHK7MS6AiOhTpIEIzw-1; Wed, 26 Mar 2025 18:24:01 -0400
X-MC-Unique: TsBujHK7MS6AiOhTpIEIzw-1
X-Mimecast-MFC-AGG-ID: TsBujHK7MS6AiOhTpIEIzw_1743027840
Received: by mail-il1-f198.google.com with SMTP id e9e14a558f8ab-3d3dee8d31aso2748085ab.2
for <passt-dev@passt.top>; Wed, 26 Mar 2025 15:24:00 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1743027840; x=1743632640;
h=content-transfer-encoding:in-reply-to:from:content-language
:references:to:subject:user-agent:mime-version:date:message-id
:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
bh=E4mFDyE4smYqp17gnhh8mm3yEcYF1iqVRufwfC3qDaA=;
b=kaPf5c4RPChad++ZQC05jAhi4qC+XCLw507fZJIS+wlIl0D1dZoMsjkajf+480/OxS
8LydfCGFoFcSMOPMcrKMNcxgcDaDzLsM0jGGAYGJCbXPw5aQm2sMlFoQG3zq4bEO2AUJ
779pabHCSfoxgrHaYwhuW59BBAUu0/xlEQvCHjjhJr0dz22zRec+g/rhvq2GJEccsw5K
LxqrUHWYq/DcWiEZvm1oFHHjuyfaeE2JdycGTPwM2em1akKTVyr+PpvJ4gsff32xy4fX
VvqJF/5YfghZBkeRtSkplcHA7ngHnOVVLEitMEF2PP6luLEz4UT3ohny40kkoYpaZoOE
e+Kg==
X-Forwarded-Encrypted: i=1; AJvYcCVaysYdJthKG2wPniadeCvv5Fbgi5NnzIXGN3AhRzOfPCZmkC1qZLgc8I2zDrhxctKuf6mKMxoYH6I=@passt.top
X-Gm-Message-State: AOJu0YyJ6CofDLC0Ki7S6bshv6gVK6tNWjVq4gcC2VxDrkYWyyDgDINj
miqk6/Rt1/TF1T4BRE/DzMwv3oYq8wmZoI+LA4Yy016pFB3ufnJ5EUxx0/ZlCJgEnxGxLhw2uPf
5bWKH/gXdD1H7nDYR1yhc4Cr2JatLyTZUrXK6gZwIsN/tbEcJFA==
X-Gm-Gg: ASbGncvA2uElzgyRXLytQ2DzH3RUybif7vLC8RWmbnIY9ke6YhamJWDQWoJ1oiWEhU+
G651NmRlYp6FdjZ/uCo2egmKVouANSFOCAVSF3XXR2uDWuYt7SHKR5o9NmanY9KEWxh/4GjWQZ2
wtV9fYJ+oCqKLlNSbkdnEaBpB3VJFCuo8ZACwv1TAVeyR56tbXVXApvEh+Nbgx8xCZ7LNUCQdOP
rwc2FlTjwowZXOgVAYteD4DKFI5vMOISi7PdOBVnfREW0KyxsYTsqcvbNVFN63jUba8D32aFiIc
yQX31HxPR3su52sh4hhWPVfSj9qRnwFSWOq7/FBLZGUH7FJwXMfofkh7ka5rc/E=
X-Received: by 2002:a05:6e02:3c04:b0:3d3:deee:de2f with SMTP id e9e14a558f8ab-3d5ccdc9b8fmr16703575ab.7.1743027840103;
Wed, 26 Mar 2025 15:24:00 -0700 (PDT)
X-Google-Smtp-Source: AGHT+IFNK5nPeXMrIapK/o0/ifIrdWsJ2TuC0I7ewRtqlIuUqIM4rtxXdpDqfWMgn8kU+ooT+9tI2g==
X-Received: by 2002:a05:6e02:3c04:b0:3d3:deee:de2f with SMTP id e9e14a558f8ab-3d5ccdc9b8fmr16703495ab.7.1743027839664;
Wed, 26 Mar 2025 15:23:59 -0700 (PDT)
Received: from ?IPV6:2001:4958:231f:7c01:99a2:ef22:1861:9725? ([2001:4958:231f:7c01:99a2:ef22:1861:9725])
by smtp.gmail.com with ESMTPSA id 8926c6da1cb9f-4f2cbdd064esm3063627173.37.2025.03.26.15.23.59
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Wed, 26 Mar 2025 15:23:59 -0700 (PDT)
Message-ID: <b288a0cb-d39b-41a0-ad38-a7496b437e23@redhat.com>
Date: Wed, 26 Mar 2025 18:23:58 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/2] udp: Don't attempt to forward ICMP socket errors to
other sockets
To: David Gibson <david@gibson.dropbear.id.au>,
Stefano Brivio <sbrivio@redhat.com>, passt-dev@passt.top
References: <20250326001501.1866234-1-david@gibson.dropbear.id.au>
<20250326001501.1866234-2-david@gibson.dropbear.id.au>
From: Jon Maloy <jmaloy@redhat.com>
In-Reply-To: <20250326001501.1866234-2-david@gibson.dropbear.id.au>
X-Mimecast-Spam-Score: 0
X-Mimecast-MFC-PROC-ID: tLWNZww9g9sYeOLcDiHoP6Q0beoJzCRTnRle_YDSqUU_1743027840
X-Mimecast-Originator: redhat.com
Content-Language: en-US
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID-Hash: N2YNSVYYT2BAISNYATT5ZUSXUTCGCHDQ
X-Message-ID-Hash: N2YNSVYYT2BAISNYATT5ZUSXUTCGCHDQ
X-MailFrom: jmaloy@redhat.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.8
Precedence: list
List-Id: Development discussion and patches for passt <passt-dev.passt.top>
Archived-At: <https://archives.passt.top/passt-dev/b288a0cb-d39b-41a0-ad38-a7496b437e23@redhat.com/>
Archived-At: <https://passt.top/hyperkitty/list/passt-dev@passt.top/message/N2YNSVYYT2BAISNYATT5ZUSXUTCGCHDQ/>
List-Archive: <https://archives.passt.top/passt-dev/>
List-Archive: <https://passt.top/hyperkitty/list/passt-dev@passt.top/>
List-Help: <mailto:passt-dev-request@passt.top?subject=help>
List-Owner: <mailto:passt-dev-owner@passt.top>
List-Post: <mailto:passt-dev@passt.top>
List-Subscribe: <mailto:passt-dev-join@passt.top>
List-Unsubscribe: <mailto:passt-dev-leave@passt.top>
On 2025-03-25 20:15, David Gibson wrote:
> Recently we added support for detecting ICMP triggered errors on UDP
> sockets and forwarding them to the tap interface. However, in
> udp_sock_recverr() where this is handled we don't know for certain that
> the tap interface is the other side of the UDP flow. It could be a spliced
> connection with another socket on the other side.
>
> To forward errors in that case, we'd need to force the other side's socket
> to trigger issue an ICMP error. I'm not sure if there's a way to do that;
> probably not for an arbitrary ICMP but it might be possible for certain
> error conditions.
>
> Nonetheless what we do now - synthesise an ICMP on the tap interface - is
> certainly wrong. It's probably harmless; for a spliced connection it will
> have loopback addresses meaning we can expect the guest to discard it.
> But, correct this for now, by not attempting to propagate errors when the
> other side of the flow is a socket.
>
> Fixes: 55431f007 ("udp: create and send ICMPv4 to local peer when...")
> Fixes: 68b04182e ("udp: create and send ICMPv6 to local peer when...")
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> ---
> udp.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/udp.c b/udp.c
> index 80520cbd..a706fed9 100644
> --- a/udp.c
> +++ b/udp.c
> @@ -559,7 +559,10 @@ static int udp_sock_recverr(const struct ctx *c, union epoll_ref ref)
> const struct flowside *toside = flowside_at_sidx(sidx);
> size_t dlen = rc;
>
> - if (hdr->cmsg_level == IPPROTO_IP) {
> + if (pif_is_socket(pif_at_sidx(sidx))) {
> + /* XXX Is there any way to propagate ICMPs from socket
> + * to socket? */
> + } else if (hdr->cmsg_level == IPPROTO_IP) {
> dlen = MIN(dlen, ICMP4_MAX_DLEN);
> udp_send_conn_fail_icmp4(c, ee, toside, saddr.sa4.sin_addr,
> data, dlen);
I never thought about this. I'll try to think of a solution, if there
even is any.
In the meantime:
Acked-by: Jon Maloy <jmaloy@redhat.com>