passt/fwd_rule.c, branch bug205

fwd_rule: Allow parsing * as a forwarding address

2026-05-15T05:34:04+00:00

In our output in various places, we use "*", or sometimes "[*]" to indicate
a dual stack unspecified address: that is a case where we listen on both
0.0.0.0 and ::.  However we don't currently allow the same syntax when
specifying forwarding rules on the command line.

A * address can be indirectly specified by omitting the address entirely,
but for consistency allow an explicit "*" or "[*]" as well.

Signed-off-by: David Gibson

fwd_rule: Don't attempt dual stack listen()s if only one IP family

2026-05-15T05:27:35+00:00

With the recent rework to forwarding configuration, we're stricter about
what forwarding rules we allow.  In particular we don't allow dual stack
forwards (listening on both IPv4 and IPv6 addresses) if we only have one
IP family enabled.

This makes what I think was a pre-existing minor bug into a nasty failure.
If we use default forwards with no address specified, e.g.:
    $ pasta -t 1234 -4
    $ pasta -U 4321 -6
these are interpreted as dual-stack forwards.  Previously these would be
applied, leading to a surprising dual stack socket.  Since 0aeda87ca185,
they instead result in an immediate fatal error.

Add logic to interpret a default "any" address as only one IP family if
only one IP family is enabled.

Link: https://bugs.passt.top/show_bug.cgi?id=205
Reported-by: 
Fixes: 0aeda87ca185 ("conf, fwd: Stricter rule checking in fwd_rule_add()")
Signed-off-by: David Gibson

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

fwd_rule: Fix static checkers warnings in fwd_rule_add()

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

The new checks are actually sufficient but not enough for Coverity
Scan. Now that fwd->sock_count and new->last are affected or supplied
by clients, we need explicit (albeit redundant) checks on them.

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

fwd_rule: Fix some format specifiers

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

The new warnings in fwd_rule_add() have some not quite technically correct
format specifiers.  For some weird reason these don't trip warnings on
passt itself, but do when we re-use this code in the upcoming configuration
client.  Fix them.

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_rule: Move conflict checking back within fwd_rule_add()

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

2bffb631d31e ("fwd_rule: Move rule conflict checking from fwd_rule_add()
to caller") moved rule conflict checking out of fwd_rule_add().  This
seemed like a good idea at the time, but turns out to be kind of awkward:
it means we're now checking for conflicts *before* we've checked the rule
for internal consistency (including first <= last), which leaves an awkward
assert() which might fire in unexpected places.

While it's true that it's not really necessary to include this in order to
safely add a rule, the benefits from skipping it are pretty marginal.  So,
for simplicity, fold this check back into fwd_rule_add(), making it
non-fatal.  If we ever have cases with enough rules that the O(n^2) nature
of the check matters, we might need to revisit.

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