From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=none (p=none dis=none) header.from=gibson.dropbear.id.au Authentication-Results: passt.top; dkim=pass (2048-bit key; secure) header.d=gibson.dropbear.id.au header.i=@gibson.dropbear.id.au header.a=rsa-sha256 header.s=202512 header.b=T8D/BYhP; dkim-atps=neutral Received: from mail.ozlabs.org (mail.ozlabs.org [IPv6:2404:9400:2221:ea00::3]) by passt.top (Postfix) with ESMTPS id 7A5DE5A0625 for ; Wed, 14 Jan 2026 01:42:03 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202512; t=1768351319; bh=H2iWpzdkwVJrEaMCyXvSlK96ffOE5Fm0WUEiwRC265g=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=T8D/BYhPETdKEJI1PxM+6KbH4CT3B0ytYyiQTM4wkSr73rwuQZfgQjUoCpmaggCbE 9XrO44GFdGNQs0E0sRV2yRxofQksQIH3lbb/J4dAttWD8vEhtHZrDd1drYL5FRQY4K l0GYNM0ejUmAa+wjspxN6ePwVzZwLRl2sMZMdZ424T3qt6G80DcKeYNeGZTX7ejzy0 iyZAxlS/Yy0TUWtAFQXicnM4izfuRDnpBNvDFVwjCBwsKJKKrRtif4TXmzsIiIMnWT sI2O9q4uNoTsSjEQ8b6GtDQL2ItoyeuuCLLK4M+yroPcYovycFXpiMPrkqm+HckvIx KTMozFqf6L6lA== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4drS472zWWz4wRM; Wed, 14 Jan 2026 11:41:59 +1100 (AEDT) Date: Wed, 14 Jan 2026 10:59:20 +1100 From: David Gibson To: Stefano Brivio Subject: Re: [PATCH v3 07/14] fwd, tcp, udp: Set up listening sockets based on forward table Message-ID: References: <20260108022948.2657573-1-david@gibson.dropbear.id.au> <20260108022948.2657573-8-david@gibson.dropbear.id.au> <20260113002636.43c77c0a@elisabeth> <20260113231336.0711e84a@elisabeth> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="T8gOKNYgHfrSgQFX" Content-Disposition: inline In-Reply-To: <20260113231336.0711e84a@elisabeth> Message-ID-Hash: 42M3QKBBD52HWH7Z3W7JJMXDWS4YU7J7 X-Message-ID-Hash: 42M3QKBBD52HWH7Z3W7JJMXDWS4YU7J7 X-MailFrom: dgibson@gandalf.ozlabs.org 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: --T8gOKNYgHfrSgQFX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 13, 2026 at 11:13:36PM +0100, Stefano Brivio wrote: > On Tue, 13 Jan 2026 16:38:58 +1100 > David Gibson wrote: >=20 > > On Tue, Jan 13, 2026 at 12:26:36AM +0100, Stefano Brivio wrote: > > > On Thu, 8 Jan 2026 13:29:41 +1100 > > > David Gibson wrote: > > > =20 > > > > Previously we created inbound listening sockets as we parsed the fo= rwarding > > > > options (-t, -u) whereas outbound listening sockets were created du= ring > > > > {tcp,udp}_init(). Now that we have a data structure recording the = full > > > > details of the listening options we can move all listening socket c= reation > > > > to {tcp,udp}_init(). This means that errors for either direction a= re > > > > detected and reported the same way. > > > >=20 > > > > Introduce fwd_listen_sync() which synchronizes the state of listeni= ng > > > > sockets to the forwarding rules table, both for fixed and automatic > > > > forwards. > > > >=20 > > > > This does cause a change in semantics for "exclude only" port > > > > specifications. Previously an option like -t ~6000 wouldn't cause a > > > > fatal error, as long as we could bind at least one port. Now, it > > > > requires at least one port for each generated rule; that is for each > > > > of the contiguous blocks of ports the specification resolves to. W= ith > > > > typical ephemeral ports settings that's one port each in 1..5999, > > > > 6001..32767 and 61000..65535. > > > >=20 > > > > Preserving the exact behaviour for this case would require a consid= erably > > > > more complex data structure, so I'm hoping this is a sufficiently n= iche > > > > case for the change to be acceptable. =20 > > >=20 > > > I guess so too, I wouldn't really worry. > > >=20 > > > Well, I'm not sure if it works, but one relatively simple idea could = be > > > to have a "with_prev" bit in the rule struct representing the fact th= at > > > the current rule was derived from the same port specification as the > > > previous rule, which implies they would need to be deleted all togeth= er > > > (but we can happily enforce that). > > >=20 > > > Then, in the fwd_listen_sync_() loop, before reporting failure, you > > > would check the next entry: if the "with_prev" bit is set, report > > > failure only if we fail (keeping a local boolean flag) for all the > > > entries up to the first one with "with_prev" unset. =20 > >=20 > > I'll keep that approach in mind if it seems like we need it. > >=20 > > > I would be inclined to say it's worth it if it's that simple, but I > > > haven't tried, so I might be very well missing something. =20 > >=20 > > I also considered making WEAK mean we'd always continue on listen > > failures, even if all of them fail. Maybe that's a bit unexpected? > > But it would allow an option to "forward single port X, if you can" > > which seems like it might be useful. >=20 > I think that's a different feature, perhaps it would need its own flag. > But I don't think we should have it on by default with the current > command-line interface. >=20 > Perhaps the client should have a different command/specifier to add a > set of ranges which can all fail entirely. But I guess it risks being a > bit too much for the command line. That's fair. Hmm... for the client protocol, we could potentially return the number of sockets we managed to bind(), and the client could decide if it's good enough. Setting up a listening rule already can't really be atomic, so I think it's probably ok for the client to have to explicitly delete/rollback. Not sure if that's a good idea, but it's a thought. > By the way, that should make more sense once we add the possibility of > specifying ports or ranges for automatic port forwarding, or for > https://bugs.passt.top/show_bug.cgi?id=3D131, because at that point it > becomes "when you can"... and we would already have that implemented, > actually. Right. --=20 David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson --T8gOKNYgHfrSgQFX Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmlm3FcACgkQzQJF27ox 2GcoUA/9FJn9KuMdEOXYlQBkga56mcLWZe4gOh0vTQqYh7qnF/OqhB4Wsn2B+LYx pHolp1cxna0u1YGVGoffyCzR8oVf0L5yozdj/ZPgq6pqyagGKoPm+Ot5dyD5BgBp Lsr1WmDAN2S/dL07hDii9CEKGyx3HgsxFOnKH1EqZ9OGGTAL9cSNT/pWpFzpfJlm 6ZWMrlA6X1+UkGNNvRXIi6VpyTLjg2FIRLE34l9Q7yEIiN9o92pnN3WVr2ZvzaPZ cJcWBy0Sg2qSlRFrZF1QUo9xPb8f9vvnfs2A44URq5avDOVy+1Brjo0Gx3T4HVqH JUViftPAy7NiMKhfdInNfEw6Nb1so1lrYMWWw//ieYFYJMWbMNyIXMSoowwbgfw2 G5mMIkQsUQW5KISuEI16Epz1A4PKRSlcBO8wvjovKos88lTzaS35aMssBZK1u7Mb 43Ceu9i1Jds3VDInL8LYozSLM8JCLtbzUPF3WBQM3edilmP9Ckfoyn5vBfDTDfOG m3AqCHmzNrJgwpuwKN9nOwKKo+K1jISKEak3OMXaZLVetNRtq1RazsVcmjAwRoYJ 9GDWw6WN/V2Z9whIOfOD8zxTS5VnqJKhdkYulqq4VRdh/tcdafkS8zKb9MzSvjOP 5oB0vcleF8I1Xwz5DYKrjhQLjx5w7L2R7r0C8bOZaNNXeYtjeTI= =DqFw -----END PGP SIGNATURE----- --T8gOKNYgHfrSgQFX--