passt/fwd_rule.h, branch 2026_05_07.1afd4ed

pesto, conf, fwd_rule: Add options and modes to add, delete, clear rules

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

Instead of just being able to add to the existing tables, implement
an explicit --clear option to replace them, which now becomes the
default behaviour, and implement explicit --add and --delete options
to maintain the table and add or delete specific ports.

The option --clear PIF forces the clearing of a table, instead.

These options can be combined arbitrarily and are handled as
sequential commands, as now described in pesto(1).

If no option is given before forwarding specifiers for a matching
table, the command line is interpreted as a replacement of the
existing rules.

To this end:

- there's no protocol change, as pesto is anyway sending updated
  copies of the table

- the forwarding table functions now include a new fwd_rule_del(),
  which deletes existing rule only if a matching one is found

- a trivial fwd_rule_clear() is factored out from the existing
  conf_handler() implementation, so that it can be directly used
  in pesto

The entry points for parsing of port specifiers now take an additional
'del' parameter which is passed down all the way before reaching the
fwd_rule_add() implementation. If a rule should be deleted, at that
point, fwd_rule_del() is called instead.

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

pesto: Parse and add new rules from command line

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

This adds parsing of options using fwd_rule_parse(), validates them and
adds them to the existing rules. It doesn't yet send those rules back to
passt or pasta.

Message-ID: <20260322141843.4095972-3-sbrivio@redhat.com>
[dwg: Based on an early draft by Stefano]
Signed-off-by: David Gibson 
[sbrivio: Recycled usage messages for -T and -U from conf.c as
 suggested by Laurent, dropped unrelated whitespace change]
[sbrivio: Add description of -t, -u, -T, -U to pesto.1]
[sbrivio: Fix conflicts in Makefile]
[sbrivio: Add description of -s to pesto.1 as well]
Signed-off-by: Stefano Brivio 
Reviewed-by: Laurent Vivier

pesto: Read current ruleset from passt/pasta and optionally display it

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

Implement serialisation of our current forwarding rules in conf.c,
deserialising it to display in the pesto client.  Doing this requires
adding ip.c, inany.c, bitmap.c, lineread.c and fwd_rule.c to the pesto
build.  With previous preparations that now requires only a trivial change
to lineread.c.

Signed-off-by: David Gibson 
Reviewed-by: Laurent Vivier 
[sbrivio: Use ntohs() for rule->to instead of htons() in
 fwd_rule_read(), reported by Jon Maloy]
[sbrivio: Add upper bound check on pc->fwd.count for count of rules
 received by pesto, reported missing by Laurent, plus nits also
 reported by Laurent]
[sbrivio: Fix conflicts in Makefile]
Signed-off-by: Stefano Brivio

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: Generalise fwd_rules_info()

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

fwd_rules_info() is used to print a full table of forwarding rules for
debugging or the like.  Currently it has one caller, and uses info() to
dump the messages.  However for the upcoming configuration client, we're
going to want to dump the rules in some similar, but not quite identical
ways.  For example, at different severity levels, or to stdout instead of
stderr / system log / logfile.

So, generalise fwd_rules_info() to fwd_rules_dump() which takes a printing
function as a parameter.  Because we want this to work with "functions"
like info, which is actually a macro, we have to convert fwd_rules_dump()
to a macro as well.  We also allow the prefix and suffix for each rule /
line to be provided as a parameter.

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

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