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=dfNCCzoO; 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 6B17E5A0262 for ; Mon, 13 Jul 2026 02:39:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1783903182; 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=YrJ1XL1ZKvowfNfMxeqamgGQxWBpBwf54M0tat4GeaI=; b=dfNCCzoOMpz8lb/N0bF7pZkyrox77TMhHIuiTu8byBsKl6U5n2ZNgvVv7mB2r6tOWwtmLa bDiguyX4iAPmZdG+EWn6mPulTfgfCwMM86vt9+viBGshv0YkAj0rNObrRoYKDU7pPsvdqO IgE9uyhp9QYUjCysjY4RC5pC6sRf9W8= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-328-XMz2O1H4MAeoxg0o4zKylw-1; Sun, 12 Jul 2026 20:39:39 -0400 X-MC-Unique: XMz2O1H4MAeoxg0o4zKylw-1 X-Mimecast-MFC-AGG-ID: XMz2O1H4MAeoxg0o4zKylw_1783903178 Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-493bf840a69so18347875e9.3 for ; Sun, 12 Jul 2026 17:39:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783903178; x=1784507978; h=date:content-transfer-encoding:content-type:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to:content-type; bh=YrJ1XL1ZKvowfNfMxeqamgGQxWBpBwf54M0tat4GeaI=; b=Qt+X5o2XPRufIAMbbsZoKE5M28rI4u0tjOVPtNU69obYw1h4NpYLch9tG+vuIkwNel W67Qwv8Gexr8AaJkr8sqUMZw5E4RKhA6O1tk6Akn6swDrR9a9rp0m+mrBYUVPhmGQnZc cu+65d/m0uT25LVA7aOgfbKW7vn9Sb5x2ayHEk0bTgTfiCOncWn44A+5T541XuYonB+8 n+wVgOrmEPz2Rbcg/nRbj2DwPChoEjfe+4R+kW7a40dhpJ1kcB9vZEoBghQlqU0l3/Dt GjtPXw7MkAI1pRlV8tQ8Dysq/TmXzhU8pvbQuAAaw+CHNMOOVSMs8kVCuku8t+Cf2iss uTWQ== X-Gm-Message-State: AOJu0Yzt1ROzXzyjCzdZgZvXuQ2u4wi1Uj4RQFvCVEELgN6uhJbgRPJL gt6NkIopQ8VkhqDSLtk7SQ6BXdrvrdnGFeXREISvVKW7E8GoNZNwtC2NLhbF5Q/g0YQno5pW1ee lsY4kbxli7FVzENLcLVzirxSBMPpxZ0Z3dPhbhicOU8sjZcVuMyIjVAkKclJTxQ== X-Gm-Gg: AfdE7cnLvUpwBM9WkL/gOLH5cyr1g7FXZnzp6LdzyhDh6iDFzj/YXgK+9hsf1DKkI+s G1wmE1ExoiWDB1x6fx/lOdO7Q9mKCI6u/xTnGEbAjVdtIdLQpXeYouAbGbCvk/JH+1+uMccRiz2 lGVKD+wpHEycOg+aPPi1btS0Xcd4jGBvNXm+khZ0i08ReWrS48LykZWMq6QpLQgBXaLZ8OcLqiX mi4o6pB2INPo6F+HRlfBeTWNORvUmqXnLhRrKRYTYayq++Re5N8NUBSIl4DiAPXWzoKSw29Far1 vy1MzZ/THhm/Nj3kLShvUl1eFfdvdPs6CwWqLYy0G38MPDOG7gaWHcTq3wY5Hw1rJLASv1fIIZI h4c+SWNzpjGt6T4Ka+MzdtA== X-Received: by 2002:a05:600c:6088:b0:493:f86b:972c with SMTP id 5b1f17b1804b1-49402025a27mr11684585e9.24.1783903177771; Sun, 12 Jul 2026 17:39:37 -0700 (PDT) X-Received: by 2002:a05:600c:6088:b0:493:f86b:972c with SMTP id 5b1f17b1804b1-49402025a27mr11684375e9.24.1783903177212; Sun, 12 Jul 2026 17:39:37 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [2a10:fc81:a806:d6a9::1]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-493f2dd8376sm152100445e9.2.2026.07.12.17.39.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 12 Jul 2026 17:39:36 -0700 (PDT) From: Stefano Brivio To: David Gibson Subject: Re: [PATCH 1/5] fwd: Clarify semantics of --host-lo-to-ns-lo Message-ID: <20260713023935.48158b4f@elisabeth> In-Reply-To: <20260710065611.530947-2-david@gibson.dropbear.id.au> References: <20260710065611.530947-1-david@gibson.dropbear.id.au> <20260710065611.530947-2-david@gibson.dropbear.id.au> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.49; x86_64-pc-linux-gnu) MIME-Version: 1.0 Date: Mon, 13 Jul 2026 02:39:35 +0200 (CEST) X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: rBCpk7f1D593rYXOPkUOND128pY9vKn9Qvi8tdI7SCs_1783903178 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: 535F3NG6R5YIRJICSZ35ZP3M5CZFGJXK X-Message-ID-Hash: 535F3NG6R5YIRJICSZ35ZP3M5CZFGJXK 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: 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: Nits only (pretty much for the whole series, even though I have slightly more substantial remarks for 3/5 and 5/5, so I thought I'd point all of them out): On Fri, 10 Jul 2026 16:56:07 +1000 David Gibson wrote: > The semantics of --host-lo-to-ns-lo as described in the man page don't > quite make sense: It says without the option forwarded packets will appear > to come _from_ the guest's public address, which is not usually true. > Instead the packets will arrive *to* the guest's public address. The exact > semantics are also a bit confusing in general. > > Rewrite both the man page and code to clarify this. The new rule is that > it redirects connections addressed to a host loopback address to the same > loopback address in the guest. This is notionally different from what we > had in two ways: > * We can now deliver to nonstandard loopback addresses within the guest, > not just the default one. This is technically a behavioural change, > but I think will be less surprising behaviour. > * The decision is now made on the original _destination_ address, rather > than source address. That's different theoreically, but not in theoretically > practice, since loopback packets must have loopback addresses for both > source and destination. > > We make it explicitly incompatible with --no-splice - previously it > was allowed, but would have no effect in that case. > > As well as being more precise right now, these semantics will intersect > better with upcoming remapping of target address by forwarding rules. > > Signed-off-by: David Gibson > --- > conf.c | 2 ++ > fwd.c | 22 ++++++++++------------ > passt.1 | 9 +++++---- > 3 files changed, 17 insertions(+), 16 deletions(-) > > diff --git a/conf.c b/conf.c > index 6d83daef..5b6cc2be 100644 > --- a/conf.c > +++ b/conf.c > @@ -1796,6 +1796,8 @@ void conf(struct ctx *c, int argc, char **argv) > if (c->splice_only) > die("--splice-only is for pasta mode only"); > } > + if (c->no_splice && c->host_lo_to_ns_lo) > + die("--host-lo-to-ns-lo is incompatible with --no-splice"); > > if (c->mode == MODE_PASTA && !c->pasta_conf_ns) { > if (copy_routes_opt) > diff --git a/fwd.c b/fwd.c > index 3ae25fde..84400948 100644 > --- a/fwd.c > +++ b/fwd.c > @@ -1038,21 +1038,19 @@ uint8_t fwd_nat_from_host(const struct ctx *c, > * In either case, let the kernel pick the source address to > * match. > */ > - if (inany_v4(&ini->eaddr)) { > - if (c->host_lo_to_ns_lo) > - tgt->eaddr = inany_loopback4; > - else > - tgt->eaddr = inany_from_v4(c->ip4.addr_seen); > + if (c->host_lo_to_ns_lo && inany_is_loopback(&ini->oaddr)) > + tgt->eaddr = ini->oaddr; > + else if (inany_v4(&ini->eaddr)) > + tgt->eaddr = inany_from_v4(c->ip4.addr_seen); > + else > + tgt->eaddr.a6 = c->ip6.addr_seen; > + > + /* Let the kernel pick source address and port */ > + if (inany_v4(&tgt->eaddr)) > tgt->oaddr = inany_any4; > - } else { > - if (c->host_lo_to_ns_lo) > - tgt->eaddr = inany_loopback6; > - else > - tgt->eaddr.a6 = c->ip6.addr_seen; > + else > tgt->oaddr = inany_any6; > - } > > - /* Let the kernel pick source port */ > tgt->oport = 0; > if (proto == IPPROTO_UDP) > /* But for UDP preserve the source port */ > diff --git a/passt.1 b/passt.1 > index a8a06311..4f2a8e41 100644 > --- a/passt.1 > +++ b/passt.1 > @@ -672,10 +672,11 @@ Default is \fBauto\fR. > > .TP > .BR \-\-host-lo-to-ns-lo > -If specified, connections forwarded with \fB\-t\fR and \fB\-u\fR from > -the host's loopback address will appear on the loopback address in the > -guest as well. Without this option such forwarded packets will appear > -to come from the guest's public address. > +If specified, connections to a host loopback address forwarded with > +\fB\-t\fR or \fB\-u\fR will be delivered to the same loopback address > +on the guest. Without this option such connections are forwarded to > +the guest's public address. This option is incompatible with > +\fB--no-splice\fR. Pre-existing, but still somewhat confusing: this is one part of the man page where we don't specify "guest or namespace", we just use "guest", and yet it's never a guest, it's always a namespace. Should we just change all the occurrences of "guest" to "namespace" in this paragraph? > > .TP > .BR \-\-userns " " \fIspec -- Stefano