passt/fwd.c, branch 2026_05_07.1afd4ed

conf, fwd: Allow switching to new rules received from pesto

2026-05-07T06:06:30+00:00

We can now receive updates to the forwarding rules from the pesto client
and store them in a "pending" copy of the forwarding tables.  Implement
switching to using the new rules.

The logic is in a new fwd_listen_switch().  For now this closes all
listening sockets related to the old tables, swaps the active and pending
tables, then listens based on the new tables.  In future we look to improve
this so that we don't temporarily stop listening on ports that both the
old and new tables specify.

Signed-off-by: David Gibson 
[sbrivio: In fwd_listen_switch(), use the destination size as argument
 to memcpy(), instead of sizeof(tmp), as suggested by Laurent]
Signed-off-by: Stefano Brivio 
Reviewed-by: Laurent Vivier

pesto, conf: Send updated rules from pesto back to passt/pasta

2026-05-07T06:06:30+00:00

Extend pesto to send the updated rule configuration back to passt/pasta.
Extend passt/pasta to read the new configuration and store the new rules in
a "pending" table.   We don't yet attempt to activate them.

Signed-off-by: Stefano Brivio 
[dwg: Based on an early draft from Stefano]
[sbrivio: Add redundant check on interface names being terminated in
 conf_recv_rules(), to make static checkers happy]
[sbrivio: Make conf_recv_rules() return -1 if fwd_rule_read() fails,
 as suggested by Jon Maloy]
[sbrivio: Fix conflicts in Makefile]
Signed-off-by: David Gibson 
Reviewed-by: Laurent Vivier

inany: Prepare inany.[ch] for sharing with pesto tool

2026-05-07T06:06:30+00:00

inany contains a number of helpful functions for dealing with addresses
which might be IPv4 or IPv6.  We're going to want to use that in pesto.
For the most part inany doesn't depend on other passt/pasta internals,
however it does depend on siphash.h, which pesto doesn't need.

Move the single dependent function, inany_siphash_feed() to siphash.h,
renaming to match.  Use that include inany.[ch] into pesto as well as
passt/pasta.  While we're there reformat pesto.c's header comment to match
the convention used in most other files.

Signed-off-by: David Gibson 
Reviewed-by: Laurent Vivier 
Signed-off-by: Stefano Brivio

fwd, conf: Move rule parsing code to fwd_rule.[ch]

2026-05-07T06:06:30+00:00

The code parsing command line options into forwarding rules has now been
decoupled from most of passt/pasta's internals.  This is good, because
we'll soon want to share it with a configuration update client.

Make the next step by moving this code into fwd_rule.[ch].

Signed-off-by: David Gibson 
Reviewed-by: Laurent Vivier 
Signed-off-by: Stefano Brivio

fwd_rule: Move ephemeral port probing to fwd_rule.c

2026-05-07T06:06:30+00:00

We want to move parsing of forward rule options to fwd_rule.c so it can
eventually be shared with a configuration client.  As a preliminary step,
move the ephemeral port probing there, which that will need to use.

Signed-off-by: David Gibson 
Reviewed-by: Laurent Vivier 
Signed-off-by: Stefano Brivio

conf, fwd: Stricter rule checking in fwd_rule_add()

2026-05-07T06:06:30+00:00

Although fwd_rule_add() performs some sanity checks on the rule it is
given, there are invalid rules we don't check for, assuming that its
callers will do that.

That won't be enough when we can get rules inserted by a dynamic update
client without going through the existing parsing code.  So, add stricter
checks to fwd_rule_add(), which is now possible thanks to the capabilities
bits in the struct fwd_table.  Where those duplicate existing checks in the
callers, remove the old copies.

Signed-off-by: David Gibson 
Reviewed-by: Laurent Vivier 
Signed-off-by: Stefano Brivio

fwd, conf: Add capabilities bits to each forwarding table

2026-04-21T00:09:35+00:00

conf_ports_spec() and conf_ports() take the global context structure, but
their only use for it is seeing if various things are possible: which
protocols and address formats are allowed in formatting rules.  Localise
that information into the forwarding table, with a capabilities bitmap.

For now we set that caps map to the same thing for all tables, but keep it
per-table to allow for the possibility of different pif types in future
that might have different capabilities (e.g. if we add a forwarding table
for the tap interface, it won't be able to accept interface names to bind).

Use this information to remove the global context parameter from
conf_ports() and conf_ports_spec().

Signed-off-by: David Gibson 
Reviewed-by: Laurent Vivier 
Signed-off-by: Stefano Brivio

fwd: Improve error handling in fwd_rule_add()

2026-04-15T21:31:51+00:00

fwd_rule_add() sanity checks the given rule, however all errors are fatal:
either they're assert()s in the case of things that callers should have
already verified, or die()s if we run out of space for the new rule.

This won't suffice any more when we allow rule updates from a
configuration client.  We don't want to trust the input we get from
the client any more than we have to.

Replace the assert()s and die()s with a return value.  Also include warn()s
so that the user gets a more specific idea of the problem in the logs or
stderr.

Signed-off-by: David Gibson 
Signed-off-by: Stefano Brivio

fwd_rule: Move rule conflict checking from fwd_rule_add() to caller

2026-04-15T21:31:49+00:00

Amongst other checks, fwd_rule_add() checks that the newly added rule
doesn't conflict with any existing rules.  However, unlike the other things
we verify, this isn't really required for safe operation.  Rule conflicts
are a useful thing for the user to know about, but the forwarding logic
is perfectly sound with conflicting rules (the first one will win).

In order to support dynamic rule updates, we want fwd_rule_add() to become
a more low-level function, only checking the things it really needs to.
So, move rule conflict checking to its caller via new helpers in
fwd_rule.c.

Signed-off-by: David Gibson 
Signed-off-by: Stefano Brivio

fwd: Split rule building from rule adding

2026-04-15T21:31:46+00:00

Currently fwd_rule_add() both builds the struct fwd_rule and inserts it
into the table.  This will be inconvenient when we want to dynamically add
rules from a configuration client.  Alter fwd_rule_add() to take a
pre-constructed struct fwd_rule, which we build in the caller.

Signed-off-by: David Gibson 
Signed-off-by: Stefano Brivio