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=SfMWJXHK; 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 BA3025A026F for ; Fri, 04 Apr 2025 13:01:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1743764510; 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=1dtriO8Yb2ojXKuBekC7vFQoCmEHbimybsgV2sMOToE=; b=SfMWJXHKKXjN35Xofoy1rEleXdzM1eRYNSnh+1IBz42lVc3gyVh9X6XeNwsjpCYEtjqx8h DOp3B1/wNuKh7aMWH73UesAw9nwl8Yd0A7NuSuoHZpHEkIuBFhUFoGsHPRqW+MTl456zFv ywcDmxdEMGLFB5x62+pQRvNH/WJs4uI= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-93-zo8C0MzOP5GBIf0bm_FGEw-1; Fri, 04 Apr 2025 07:01:49 -0400 X-MC-Unique: zo8C0MzOP5GBIf0bm_FGEw-1 X-Mimecast-MFC-AGG-ID: zo8C0MzOP5GBIf0bm_FGEw_1743764508 Received: by mail-wr1-f71.google.com with SMTP id ffacd0b85a97d-3913f97d115so979730f8f.0 for ; Fri, 04 Apr 2025 04:01:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743764508; x=1744369308; h=content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=1dtriO8Yb2ojXKuBekC7vFQoCmEHbimybsgV2sMOToE=; b=ojvFJuQ20tzeeWAwqD7IEtO5ns0R4/BsXEOjyYxIO4X99sWyAmAVtj1gcKIQ4aOy0B 7BsvDUuo0gGIClNoz4fu7YRGTkbljbiiR54Bsda0S1r/kODnvTPZJLbT3TOWB7pCXj8V WdMqMUuxr+jHDkkwaaM6T2GOdtBnO+MVxuVUnlau/KndWC4ZSvMRvhwX1OMqNv/pOj49 oB9CR73V4f/r915Jh4Q0ac2M55PKCbu5krFeyVJgYRHC+ONCd8QtFjuG/HC8uW6ruNtV 4feO0zF6JIfzTIpkfg8nVBNiMTtoweG6OPt/efG3Hm84qVrU6S3VOV1KNH6fUGtLib53 QpHg== X-Forwarded-Encrypted: i=1; AJvYcCWGUK3mHvELcQwmGN1G9Gcj0B1X7LKr/j0MAdqSMrB9mo7xlLbVHvYbkDLSFaSvXpoPHUu80yTJNWg=@passt.top X-Gm-Message-State: AOJu0YyBd5rfbU2STuCVdmZ9hmiFiAYGnNujcKEWKSxikTV9HeWNs3I2 SGxFjS/Gk3tj5y5YIsXZ8RBhufF8whRvSPClAm1Bq7K+eDoM9wzaLLEmIShSq4oUPxKm1umiriN Pgx9IDjf20puSfGaBHV05gVOCmthMGOOXT8FEXsjvgz1jKazAZk9WmZbLsw== X-Gm-Gg: ASbGnctRjZg9zcZ9Z9o2jrxgEQYegOne0v6WpSmZdWeuPjPToSKWRNbI8nTbqlnkJDf DGEn0AADaQwxZYAdOWgSzRsTotexLeKA+U3u1mvHdbe1kdfizXRao/zPe3oSqQAH7tlnmDOpNfZ yUB/IwwT9REyJEctrOkKYAGVjsOVAU+D6e32xO0Hm4XkbMfja+nmWIdN1OXBBV+I0oE3jQEDMCs B3TSdSdgsV/uRiAim2o+DUyJ60q/aHU7dJHlSsREh2ziaCyDr4ll5FbSSTmAstEvnC/s9OSkuk1 XvxJjAytAYgugirmlA8WRjnCBL1ExbWYsYVurtTyPla/ X-Received: by 2002:a05:6000:220e:b0:38f:3224:65e5 with SMTP id ffacd0b85a97d-39cb35b8aa5mr2375352f8f.12.1743764507861; Fri, 04 Apr 2025 04:01:47 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFOCk0BDyadJvsfuKLoaYu+qw4ACph+47Yl9vzI2Zogot0Dxce6TRWJA/w5jJDhcomdegGpJQ== X-Received: by 2002:a05:6000:220e:b0:38f:3224:65e5 with SMTP id ffacd0b85a97d-39cb35b8aa5mr2375326f8f.12.1743764507500; Fri, 04 Apr 2025 04:01:47 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [176.103.220.4]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-39c3020d98bsm4066515f8f.76.2025.04.04.04.01.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Apr 2025 04:01:47 -0700 (PDT) Date: Fri, 4 Apr 2025 13:01:45 +0200 From: Stefano Brivio To: David Gibson Subject: Re: [PATCH v5] udp: support traceroute Message-ID: <20250404130145.57b91f6c@elisabeth> In-Reply-To: References: <20250403222706.1036876-1-jmaloy@redhat.com> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.41; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: pNleQUhe6pvQHt-KJTmh55fbA63jF2OuqQjT14tOyIE_1743764508 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: ZVZ272WBNHRXUYOYVC6IKRPDAIKAKS5J X-Message-ID-Hash: ZVZ272WBNHRXUYOYVC6IKRPDAIKAKS5J X-MailFrom: sbrivio@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: Jon Maloy , passt-dev@passt.top 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 Fri, 4 Apr 2025 11:57:58 +1100 David Gibson wrote: > On Fri, Apr 04, 2025 at 10:40:27AM +1100, David Gibson wrote: > > On Thu, Apr 03, 2025 at 06:27:06PM -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. > > > > > > We fix that in this commit. > > > > > > Link: https://bugs.passt.top/show_bug.cgi?id=64 > > > Signed-off-by: Jon Maloy > > > > Reviewed-by: David Gibson > > > > One commont below. > > Oh.. wait. I just realised this patch has a weird side effect, for > flows which are initiated from outside, rather than from the guest. > > If the flow is initiated from outside, it's maybe a bit unlikely, but > we could still get a non-default TTL from the guest on reply > datagrams. That will trigger this code and alter the socket's TTL. > But in this case the socket is not a flow specific socket, but the > listening socket which initiated the flow, which could be handling > packets on many flows. > > The "cached" TTL is stored per-flow, not per-socket, so we won't look > at the right value when we process datagrams from other flows, so they > may go out with the wrong TTL. > > I think the obvious way to address this is to stop using the > "listening" socket to send datagrams for a flow, using a connect()ed > socket instead. We have other reasons to do that too, and I'm working > on implementing that right now. > > The question is whether this is a serious enough problem to delay this > until the "both sides connect()ed sockets" change is merged. On the other hand, this patch applies cleanly on top of your "Use connect()ed sockets for both sides of UDP flows" series, and also semantically I couldn't spot any particular change or integration that we would need as a result in this patch. I haven't reviewed the series yet, but I don't think that an eventual re-spin would change this, so... problem solved I guess? I can just wait and apply them together. -- Stefano