passt/pif.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

pesto: Expose list of pifs to pesto and display them

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

Extend the dynamic update protocol to expose the pif indices and names
from a running passt/pasta to the pesto tool.  pesto records that data
and prints it out.

Signed-off-by: David Gibson 
Reviewed-by: Laurent Vivier 
[sbrivio: In read_pif_conf(), force a redundant termination of the
 interface name, the existing check isn't obvious enough for static
 checkers]
[sbrivio: Drop @resv_ left-over in description of struct
 pesto_pif_info, reported by Jon Maloy]
[sbrivio: Fix minor nits reported by Laurent]
[sbrivio: Initialise struct pesto_pif_info in conf_send_rules() with
 zeroes, otherwise the pif name might be seen as not terminated, and
 we'll expose memory from the back-end]
[sbrivio: Fix conflicts in Makefile]
Signed-off-by: Stefano Brivio

pif: Limit pif names to 128 bytes

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

All current pif names are quite short, and we expect them to remain short
when/if we allow arbitrary pifs.  However, because of the structure of
the current code we don't enforce any limit on the length.

This will become more important with dynamic configuration updates, so
start enforcing a length limit.  Specifically we allow pif names to be up
to 128 bytes (PIF_NAME_SIZE), including the terminating \0.  This is
more or less arbitrary, but seems like it should be comfortably enough for
all the cases we have in mind.

Signed-off-by: David Gibson 
Reviewed-by: Laurent Vivier 
[sbrivio: Fixed typo in comment, reported by Laurent]
Signed-off-by: Stefano Brivio

pif: Remove unused PIF_NAMELEN

2026-03-16T22:34:33+00:00

PIF_NAMELEN was meant to represent the maximum length of a pif name.
However, so far all names are compile-time strings, so we haven't needed a
length.  Remove it, since it's slightly misleading.  We can re-introduce
something like it if/when we actually need it.

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

fwd, pif: Replace with pif_sock_l4() with pif_listen()

2026-03-04T16:52:55+00:00

It turns out all users of pif_sock_l4() use it for "listening" sockets,
which now all have a common epoll reference format.  We can take advantage
of that to pass the necessary epoll information into pif_sock_l4() in a
more natural way, rather than as an opaque u32.

That in turn allows union fwd_listen_ref can become a struct, since the
union only exist to allow the meaningful fields to be coerced into a u32
for pif_sock_l4().

Rename pif_sock_l4() to pif_listen() to reflect the new semantics.  While
we're there, remove the static_assert() on the fwd_listen_ref's size.  We
do still need it to fit into 32 bits, but that constraint is imposed only
by the fact that it needs to fit into the whole, epoll_ref structure,
which we already check with a static_assert() in epoll_ctl.h.

Signed-off-by: David Gibson 
Reported-by: Peter Foley 
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

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

util, pif: Replace sock_l4() with pif_sock_l4()

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

The sock_l4() function is very convenient for creating sockets bound to
a given address, but its interface has some problems.

Most importantly, the address and port alone aren't enough in some cases.
For link-local addresses (at least) we also need the pif in order to
properly construct a socket adddress.  This case doesn't yet arise, but
it might cause us trouble in future.

Additionally, sock_l4() can take AF_UNSPEC with the special meaning that it
should attempt to create a "dual stack" socket which will respond to both
IPv4 and IPv6 traffic.  This only makes sense if there is no specific
address given.  We verify this at runtime, but it would be nicer if we
could enforce it structurally.

For sockets associated specifically with a single flow we already replaced
sock_l4() with flowside_sock_l4() which avoids those problems.  Now,
replace all the remaining users with a new pif_sock_l4() which also takes
an explicit pif.

The new function takes the address as an inany *, with NULL indicating the
dual stack case.  This does add some complexity in some of the callers,
however future planned cleanups should make this go away again.

Signed-off-by: David Gibson

flow: Common address information for target side

2024-07-19T16:32:37+00:00

Require the address and port information for the target (non
initiating) side to be populated when a flow enters TGT state.
Implement that for TCP and ICMP.  For now this leaves some information
redundantly recorded in both generic and type specific fields.  We'll
fix that in later patches.

For TCP we now use the information from the flow to construct the
destination socket address in both tcp_conn_from_tap() and
tcp_splice_connect().

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

flow: Record the pifs for each side of each flow

2024-05-22T21:21:03+00:00

Currently we have no generic information flows apart from the type and
state, everything else is specific to the flow type.  Start introducing
generic flow information by recording the pifs which the flow connects.

To keep track of what information is valid, introduce new flow states:
INI for when the initiating side information is complete, and TGT for
when both sides information is complete, but we haven't chosen the
flow type yet.  For now, these states don't do an awful lot, but
they'll become more important as we add more generic information.

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