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=EWlFuqoV; 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 2FEE85A0008 for ; Wed, 26 Mar 2025 16:59:08 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1743004747; 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; bh=/JDimoh21Wb8sKAMBs3Th6GaeN4gnJm5rpNV3xYNnNE=; b=EWlFuqoVGHGR24mFx16njGSrUb3UN5aLPLLR/FLE1r9qfCzEalAmwCH4wL4/SnluI4EhBM HrgYXQdJ0Ad/0atiOj47jTuGdZtLOsQoGrFN2I2UQzFSsLQx9/8gBisAkxWnrjDQ2PfGgz nArxUlWeaRi4jeNYy8EYEB0ztHDAnhw= Received: from mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-192-TxJWEbyKPPm3PC_tLFET8A-1; Wed, 26 Mar 2025 11:59:05 -0400 X-MC-Unique: TxJWEbyKPPm3PC_tLFET8A-1 X-Mimecast-MFC-AGG-ID: TxJWEbyKPPm3PC_tLFET8A_1743004745 Received: from mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.93]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id E1E80180899B for ; Wed, 26 Mar 2025 15:59:04 +0000 (UTC) Received: from jmaloy-thinkpadp16vgen1.rmtcaqc.csb (unknown [10.22.80.15]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 18BE6180A803; Wed, 26 Mar 2025 15:59:02 +0000 (UTC) From: Jon Maloy To: passt-dev@passt.top, sbrivio@redhat.com, lvivier@redhat.com, dgibson@redhat.com, jmaloy@redhat.com Subject: [PATCH v2] udp: correct source address for ICMP messages Date: Wed, 26 Mar 2025 11:59:02 -0400 Message-ID: <20250326155902.2903258-1-jmaloy@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.93 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: I0riTCLbspwliCxgK8Rli1PLNgL_s8wS4a2CA5U2KVE_1743004745 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: 8bit content-type: text/plain; charset="US-ASCII"; x-default=true Message-ID-Hash: ISFXO7UHXZ2SRI4H3U3VGWIOPPWEZK2Z X-Message-ID-Hash: ISFXO7UHXZ2SRI4H3U3VGWIOPPWEZK2Z 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 Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: While developing traceroute forwarding tap-to-sock we found that struct msghdr.msg_name for the ICMPs in the opposite direction always contains the destination address of the original UDP message, and not, as one might expect, the one of the host which created the error message. Study of the kernel code reveals that this address instead is appended as extra data after the received struct sock_extended_err area. We now change the ICMP receive code accordingly. Fixes: 55431f0077b6 ("udp: create and send ICMPv4 to local peer when applicable") Fixes: 68b04182e07d ("udp: create and send ICMPv6 to local peer when applicable") Signed-off-by: Jon Maloy --- v2: Removed stray comment and unecessary initializations, as per feedback from David Gibson --- udp.c | 22 ++++++++++++---------- 1 file changed, 12 insertions(+), 10 deletions(-) diff --git a/udp.c b/udp.c index 80520cb..9d16529 100644 --- a/udp.c +++ b/udp.c @@ -510,10 +510,13 @@ static void udp_send_conn_fail_icmp6(const struct ctx *c, */ static int udp_sock_recverr(const struct ctx *c, union epoll_ref ref) { - const struct sock_extended_err *ee; + struct errhdr { + struct sock_extended_err ee; + union sockaddr_inany saddr; + }; + const struct errhdr *eh; const struct cmsghdr *hdr; - union sockaddr_inany saddr; - char buf[CMSG_SPACE(sizeof(*ee))]; + char buf[CMSG_SPACE(sizeof(struct errhdr))]; char data[ICMP6_MAX_DLEN]; int s = ref.fd; struct iovec iov = { @@ -521,8 +524,6 @@ static int udp_sock_recverr(const struct ctx *c, union epoll_ref ref) .iov_len = sizeof(data) }; struct msghdr mh = { - .msg_name = &saddr, - .msg_namelen = sizeof(saddr), .msg_iov = &iov, .msg_iovlen = 1, .msg_control = buf, @@ -553,7 +554,7 @@ static int udp_sock_recverr(const struct ctx *c, union epoll_ref ref) return -1; } - ee = (const struct sock_extended_err *)CMSG_DATA(hdr); + eh = (const struct errhdr *)CMSG_DATA(hdr); if (ref.type == EPOLL_TYPE_UDP_REPLY) { flow_sidx_t sidx = flow_sidx_opposite(ref.flowside); const struct flowside *toside = flowside_at_sidx(sidx); @@ -561,18 +562,19 @@ static int udp_sock_recverr(const struct ctx *c, union epoll_ref ref) if (hdr->cmsg_level == IPPROTO_IP) { dlen = MIN(dlen, ICMP4_MAX_DLEN); - udp_send_conn_fail_icmp4(c, ee, toside, saddr.sa4.sin_addr, + udp_send_conn_fail_icmp4(c, &eh->ee, toside, + eh->saddr.sa4.sin_addr, data, dlen); } else if (hdr->cmsg_level == IPPROTO_IPV6) { - udp_send_conn_fail_icmp6(c, ee, toside, - &saddr.sa6.sin6_addr, + udp_send_conn_fail_icmp6(c, &eh->ee, toside, + &eh->saddr.sa6.sin6_addr, data, dlen, sidx.flowi); } } else { trace("Ignoring received IP_RECVERR cmsg on listener socket"); } debug("%s error on UDP socket %i: %s", - str_ee_origin(ee), s, strerror_(ee->ee_errno)); + str_ee_origin(&eh->ee), s, strerror_(eh->ee.ee_errno)); return 1; } -- 2.48.1