passt/inany.h, branch bug209

conf: Use new parsing tools to handle -a option

2026-07-04T11:14:25+00:00

The -a command line option can take either an address prefix, or a bare
address.  Current parsing of this is pretty awkward, using the special
purpose helper inany_prefix_pton().  With the new incremental parsing
helpers this can be done more naturally.  Rework it to use them.

This does requiring extending parse_inany() to parse_inany_() which also
reports the format of the address as parse, as opposed to the family of
the resulting address.  This is so that ::ffff:192.0.1.1/112 will be
correctly interpreted the same as 192.0.1.1/16, rather than the
nonsensical 192.0.0.1/112.

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

parse: Add helpers for parsing IP addresses

2026-07-04T11:14:09+00:00

parse_ipv[46]() are wrappers around inet_pton() that are more
convenient for use when the IP is part of a longer string, rather than
the entire string.  parse_inany() replaces inany_pton() which again
will become more convenient for strings including IPs that aren't just
an IP.

For now we only have some simple and sometimes awkward use cases,
we'll replace these with more natural uses in future.

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

inany: Fix doc comment to match u32 field, not u64

2026-06-19T11:10:24+00:00

The original siphash incremental patch added a u64[2] member to
union inany_addr for hashing. During review, this was changed to u32[4]
to preserve 4-byte alignment: a u64 member would have forced 8-byte
alignment on the union, mismatching struct in6_addr.

The doc comment was not updated, fix @u64 references to @u32.

Fixes: fc8f0f8c48ef ("siphash: Use incremental rather than all-at-once siphash functions")
Signed-off-by: Laurent Vivier 
Reviewed-by: David Gibson 
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

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