On Tue, Jan 13, 2026 at 11:13:36PM +0100, Stefano Brivio wrote:
> On Tue, 13 Jan 2026 16:38:58 +1100
> David Gibson <david@gibson.dropbear.id.au> wrote:
> 
> > On Tue, Jan 13, 2026 at 12:26:36AM +0100, Stefano Brivio wrote:
> > > On Thu,  8 Jan 2026 13:29:41 +1100
> > > David Gibson <david@gibson.dropbear.id.au> wrote:
> > >   
> > > > Previously we created inbound listening sockets as we parsed the forwarding
> > > > options (-t, -u) whereas outbound listening sockets were created during
> > > > {tcp,udp}_init().  Now that we have a data structure recording the full
> > > > details of the listening options we can move all listening socket creation
> > > > to {tcp,udp}_init().  This means that errors for either direction are
> > > > detected and reported the same way.
> > > > 
> > > > Introduce fwd_listen_sync() which synchronizes the state of listening
> > > > sockets to the forwarding rules table, both for fixed and automatic
> > > > forwards.
> > > > 
> > > > 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.  With
> > > > typical ephemeral ports settings that's one port each in 1..5999,
> > > > 6001..32767 and 61000..65535.
> > > > 
> > > > Preserving the exact behaviour for this case would require a considerably
> > > > more complex data structure, so I'm hoping this is a sufficiently niche
> > > > case for the change to be acceptable.  
> > > 
> > > I guess so too, I wouldn't really worry.
> > > 
> > > 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 that
> > > the current rule was derived from the same port specification as the
> > > previous rule, which implies they would need to be deleted all together
> > > (but we can happily enforce that).
> > > 
> > > 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.  
> > 
> > I'll keep that approach in mind if it seems like we need it.
> > 
> > > 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.  
> > 
> > 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.
> 
> 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.
> 
> 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=131, because at that point it
> becomes "when you can"... and we would already have that implemented,
> actually.

Right.

-- 
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