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

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

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

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

Most things in ip.[ch] related purely to IP addresses and headers with
no dependency on other passt/pasta internals.  A number of these will be
useful to re-use in pesto.  The exception is ipv6_l4hdr() which uses
iov_tail.

The only caller of this is in tap.c, so move the function there.  Along
with moving the constant byteswapping functions to common.h, that lets
ip.[ch] to be linked into pesto as well as passt/pasta.

Signed-off-by: David Gibson 
Reviewed-by: Laurent Vivier 
[sbrivio: Dropped duplicate definition of __bswap_constant_32() while
 at it, reported by Laurent]
Signed-off-by: Stefano Brivio

treewide: Spell ASSERT() as assert()

2026-03-20T20:05:29+00:00

The standard library assert(3), at least with glibc, hits our seccomp
filter and dies with SIGSYS before it's able to print a message, making it
near useless.  Therefore, since 7a8ed9459dfe ("Make assertions actually
useful") we've instead used our own implementation, named ASSERT().

This makes our code look slightly odd though - ASSERT() has the same
overall effect as assert(), it's just a different implementation.  More
importantly this makes it awkward to share code between passt/pasta proper
and things that compile in a more typical environment.  We're going to want
that for our upcoming dynamic configuration tool.

Address this by overriding the standard library's assert() implementation
with our own, instead of giving ours its own name.

The standard assert() is supposed to be omitted if NDEBUG is defined,
which ours doesn't do.  Implement that as well, so ours doesn't
unexpectedly differ.  For the -DNDEBUG case we do this by *not* overriding
assert(), since it will be a no-op anyway.  This requires a few places to
add a #include  to let us compile (albeit with warnings) when
-DNDEBUG.

Signed-off-by: David Gibson 
[sbrivio: Fix some conflicts and missing conversions as a result of
 applying "vu_common: Move iovec management into vu_collect()" first]
Signed-off-by: Stefano Brivio

Add missing includes to headers

2026-03-04T16:39:57+00:00

Support build systems like bazel that check that headers are
self-contained.

Also update includes so that clang-include-cleaner succeeds.

Tested with:
clang-include-cleaner-19 --extra-arg=-D_GNU_SOURCE --extra-arg=-DPAGE_SIZE=4096 --extra-arg=-DVERSION=\"git\" --extra-arg=-DHAS_GETRANDOM *.h *.c

Signed-off-by: Peter Foley 
Signed-off-by: Stefano Brivio

conf: Support CIDR notation for -a/--address option

2026-02-24T11:05:53+00:00

We extend the -a/--address option to accept addresses in CIDR notation
(e.g., 192.168.1.1/24 or 2001:db8::1/64) as an alternative to using
separate -a and -n options.

We add a new inany_prefix_pton() helper function that:
- Parses address strings with a compulsory /prefix_len suffix
- Validates prefix length based on address family (0-32 for IPv4,
  0-128 for IPv6), including handling of IPv4-to-IPv6 mapping case.

For IPv4, the prefix length is stored in ip4.prefix_len when provided.
For IPv6, the given prefix length is still overridden by the default
value 64

Mixing -n and CIDR notation results in an error to catch likely user
mistakes.

Also fix a bug in conf_ip4_prefix() that was incorrectly using the
global 'optarg' instead of its 'arg' parameter.

Signed-off-by: Jon Maloy 
[sbrivio: Fix merge conflict with commit 0c611bcd3120]
Signed-off-by: Stefano Brivio

conf, fwd: Check forwarding table for conflicting rules

2026-01-18T11:47:53+00:00

It's possible for a user to supply conflicting forwarding parameters, e.g.
    $ pasta -t 80:8080 -t 127.0.0.1/80:8888

We give a warning in this case, but it's based on the legacy
forwarding bitmaps.  This is too strict, because it will also warn on
cases that shouldn't conflict because they use different addresses,
e.g.
    $ pasta -t 192.0.2.1/80:8080 127.0.0.1/80:8888

Theoretically, it's also too loose because it won't take into account
auto-scan forwarding rules.  We can't hit that in practice now,
because we only ever have one auto-scan rule and nothing else, but we
want to remove that restriction in future.

Replace the bitmap based check with a check based on actually scanning
the forwarding rules for conflicts.

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

inany: Let length of sockaddr_inany be implicit from the family

2025-12-02T22:07:14+00:00

sockaddr_inany can contain either an IPv4 or IPv6 socket address, so the
relevant length for bind() or connect() can vary.  In pif_sockaddr() we
return that length, and in sock_l4_sa() we take it as an extra parameter.

However, sockaddr_inany always contains exactly a sockaddr_in or a
sockaddr_in6 each with a fixed size.  Therefore we can derive the relevant
length from the family, and don't need to pass it around separately.

Make a tiny helper to get the relevant address length, and update all
interfaces to use that approach instead.

In the process, fix a buglet in tcp_flow_repair_bind(): we passed
sizeof(union sockaddr_inany) to bind() instead of the specific length for
the address family.  Since the sizeof() is always longer than the specific
length, this is probably fine, but not theoretically correct.

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

treewide: Improve robustness against sockaddrs of unexpected family

2025-04-22T10:42:00+00:00

inany_from_sockaddr() expects a socket address of family AF_INET or
AF_INET6 and ASSERT()s if it gets anything else.  In many of the callers we
can handle an unexpected family more gracefully, though, e.g. by failing
a single flow rather than killing passt.

Change inany_from_sockaddr() to return an error instead of ASSERT()ing,
and handle those errors in the callers.  Improve the reporting of any such
errors while we're at it.

With this greater robustness, allow inany_from_sockaddr() to take a void *
rather than specifically a union sockaddr_inany *.

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

inany: Improve ASSERT message for bad socket family

2025-04-10T17:46:13+00:00

inany_from_sockaddr() can only handle sockaddrs of family AF_INET or
AF_INET6 and asserts if given something else.  I hit this assertion while
debugging something else, and wanted to see what the bad sockaddr family
was.  Now that we have ASSERT_WITH_MSG() its easy to add this information.

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

inany: Add inany_pton() helper

2024-09-25T17:03:17+00:00

We already have an inany_ntop() function to format inany addresses into
text.  Add inany_pton() to parse them from text, and use it in
conf_ports().

Signed-off-by: David Gibson