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=GoBJQLJ/; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by passt.top (Postfix) with ESMTPS id 7EE5B5A0271 for ; Mon, 17 Mar 2025 18:40:56 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1742233255; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=xh6AtndTCUKytprP5AFcaqvo3SBK3x5lN7zZSxNl3xI=; b=GoBJQLJ/Nc3LNULp0z9xrbscvttxJMOBq8cLnUW2k8Iw80CjENZzzGCt6CfJilSNBeGrZX p/baxQzX5Zh0qFS6c+/Lmv1U+QHlmORlBppMnURz1Kwg8D/gwQCzZeW1dRj3yg3HsibHZ0 e+h5PoqUDwCYDVK9QVOaZu+LsV+sNEk= Received: from mail-il1-f200.google.com (mail-il1-f200.google.com [209.85.166.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-471-0N4Hmdw9OiyY43x4ZWNMuA-1; Mon, 17 Mar 2025 13:40:53 -0400 X-MC-Unique: 0N4Hmdw9OiyY43x4ZWNMuA-1 X-Mimecast-MFC-AGG-ID: 0N4Hmdw9OiyY43x4ZWNMuA_1742233253 Received: by mail-il1-f200.google.com with SMTP id e9e14a558f8ab-3ce8cdf1898so50653455ab.1 for ; Mon, 17 Mar 2025 10:40:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742233253; x=1742838053; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=xh6AtndTCUKytprP5AFcaqvo3SBK3x5lN7zZSxNl3xI=; b=mWp1yzejFOwlny8XEfSpDZOu5OQeionfoHNRVb/FT6yVa+C/Cb4VBSLrElJR6C4eWN rKVpXYtoq1WNeuboBzoPApbB7LZK6Sj1ZD9QIck9u9NA3n2hxq2iEgm62kN9tENtXnDK uBLMshldp8eI8C1+orO7Go5Me76a0y3lUSdbRfNLSzIM1l4eYnvBVd/DDBqcW9NjsilK aBremN8S8JjrXvOjGNJ8XkrS6eKC9kD35zGefqCj10r3GihVdNRF1JmIp7AvzzxeMIWU ov6xq0o33+Dsp+BwKnHK2F6mHz/OOnQL9cra9w/YWjbVQTMqgEX6IYGoeDvYxxaHz9Aq CrBA== X-Gm-Message-State: AOJu0YyjJW9MffUmTK40j103y65KMno6PUt1HnugcNnAlVNXHkBraIm/ H5S+UfKTdNSNxxChQpa8i8tzrNAcgP0vOiBBBFDDPKzUZx2EKtmlErXCpcZn0XVw5a9dB3/hDmN HOSqE9IUuMHWTmrQOicFzF/HF/E+RgFjn2q5FXmz5OJw4UPJ/BQ== X-Gm-Gg: ASbGncv5QpjqOvkK9vW3PGNXO4OAmotC8Pf7K/IgzKxwgH/z8iHQGOiA9FiWekp23mR wT2RbPMRnUEKni2tK4ixUR+1pdxRif0WTBrrorznrlm2o/w/MUWAJNLLN7qjkzJXHHt1DSLmTPd zjQPZm+6y04spIwv/xepEcfgzRt13ApIIArCN4BovvrNNkaJNXqR3TU4YQ6/uS23yWUBoQJ1CeV tHviscWNHStUKAblI+A9z7CJCW0DG+npYzZZA6KdrceiWE8bZ0IMuE1kSfcdGAF/5cWjw6cWHyc eFiG68EqNKhOvR0xci5vGwcKmzIsE34uwiPgc111GomtXQLKDLcnI2knISXft48= X-Received: by 2002:a05:6e02:3d4a:b0:3d4:28c0:1692 with SMTP id e9e14a558f8ab-3d57b9b09a7mr8244065ab.5.1742233252894; Mon, 17 Mar 2025 10:40:52 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHfqUJzONT0dhYZq7PPCwDF9LkxI88rpcI8byUZkAu0Hme8PYJVVSygzOCUmS7qeHi1RZ/hAg== X-Received: by 2002:a05:6e02:3d4a:b0:3d4:28c0:1692 with SMTP id e9e14a558f8ab-3d57b9b09a7mr8243825ab.5.1742233252515; Mon, 17 Mar 2025 10:40:52 -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-4f2637fb8c9sm2375870173.96.2025.03.17.10.40.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 17 Mar 2025 10:40:52 -0700 (PDT) Message-ID: <2c6759d6-c58b-414d-9e94-2faac0c410a5@redhat.com> Date: Mon, 17 Mar 2025 13:40:51 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/2] udp: support traceroute for IPv4 To: David Gibson References: <20250315153245.435293-1-jmaloy@redhat.com> <20250315153245.435293-3-jmaloy@redhat.com> From: Jon Maloy In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: fIjX-vzj3FmM0i4_2WVlMr6-rvkfqnQtU_o_sjHji4w_1742233253 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: XEWCBP6ZCJ2FLP35DENER7TDA4Y7IPS5 X-Message-ID-Hash: XEWCBP6ZCJ2FLP35DENER7TDA4Y7IPS5 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 CC: passt-dev@passt.top, sbrivio@redhat.com, lvivier@redhat.com, dgibson@redhat.com 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: On 2025-03-16 22:58, David Gibson wrote: > On Sat, Mar 15, 2025 at 11:32:45AM -0400, Jon Maloy wrote: >> Now that ICMP pass-through from socket-to-tap is in place, it is >> easy to support UDP based traceroute functionality in direction >> tap-to-socket. [...] >> + uint8_t ttl, const struct pool *p, int idx, >> + const struct timespec *now) >> { >> const struct flowside *toside; >> struct mmsghdr mm[UIO_MAXIOV]; >> @@ -933,6 +935,12 @@ int udp_tap_handler(const struct ctx *c, uint8_t pif, >> mm[i].msg_hdr.msg_controllen = 0; >> mm[i].msg_hdr.msg_flags = 0; >> >> + if (ttl <= 30) { >> + if (setsockopt(s, IPPROTO_IP, IP_TTL, >> + &ttl, sizeof(ttl)) < 0) > > AFAIK this will set the TTL on every subsequent packet, not just the > next one, so this isn't quite right. To use this I guess we'd have to > store the correct TTL in the flow, and do the sockopt if it's > different from the guest side one. I forgot one thing at our discussion about this at our meeting. Traceroute works by sending three packets with ttl=1, then three with ttl=2, then three with ttl=3 and so forth. For each packet sent it steps the destination port number, starting at 33334, and in the most extreme case (assuming it stops at ttl=32, which linux traceroute does in practice) stopping at port number 33524. The whole port range [33434:33535] is unassigned by IANA, and no sane developer would use it for his application, for obvious reasons. This means that every single traceroute/udp message will become a separate flow, and there is no need to complicate things by storing the ttl in the flow or use it as criteria. It also means that my current approach works fine. I don't even need to restore the ttl in the outgoing socket, since that, just like the associated flow, is a single-shot affair. >Unless there's a way to set TTL > via cmsg. Maybe there is, but I haven't spotted it in a quick glance. I seems I can add it as ancillary data if I add a control buffer to struct mmsghdr.msghdr. However, it is hard to see any benefit of this, given the above. It will cost more performance on the critical code path than the simple test I am doing now. ///jon > >> + perror("setsockopt (IP_TTL)"); >> + } >> + >> count++; >> } >> >> diff --git a/udp.h b/udp.h >> index de2df6d..041fad4 100644 >> --- a/udp.h >> +++ b/udp.h >> @@ -15,7 +15,8 @@ void udp_reply_sock_handler(const struct ctx *c, union epoll_ref ref, >> uint32_t events, const struct timespec *now); >> int udp_tap_handler(const struct ctx *c, uint8_t pif, >> sa_family_t af, const void *saddr, const void *daddr, >> - const struct pool *p, int idx, const struct timespec *now); >> + uint8_t ttl, const struct pool *p, int idx, >> + const struct timespec *now); >> int udp_sock_init(const struct ctx *c, int ns, const union inany_addr *addr, >> const char *ifname, in_port_t port); >> int udp_init(struct ctx *c); >