passt, branch 2025_12_15.b40f5cd

tcp: Use less-than-MSS window on no queued data, or no data sent recently

2025-12-15T07:11:54+00:00

We limit the advertised window to guests and containers to the
available length of the sending buffer, and if it's less than the MSS,
since commit cf1925fb7b77 ("tcp: Don't limit window to less-than-MSS
values, use zero instead"), we approximate that limit to zero.

This way, we'll trigger a window update as soon as we realise that we
can advertise a larger value, just like we do in all other cases where
we advertise a zero-sized window.

By doing that, we don't wait for the peer to send us data before we
update the window. This matters because the guest or container might
be trying to aggregate more data and won't send us anything at all if
the advertised window is too small.

However, this might be problematic in two situations:

1. one, reported by Tyler, where the remote (receiving) peer
   advertises a window that's smaller than what we usually get and
   very close to the MSS, causing the kernel to give us a starting
   size of the buffer that's less than the MSS we advertise to the
   guest or container.

   If this happens, we'll never advertise a non-zero window after
   the handshake, and the container or guest will never send us any
   data at all.

   With a simple 'curl https://cloudflare.com/', we get, with default
   TCP memory parameters, a 65535-byte window from the peer, and 46080
   bytes of initial sending buffer from the kernel. But we advertised
   a 65480-byte MSS, and we'll never actually receive the client
   request.

   This seems to be specific to Cloudflare for some reason, probably
   deriving from a particular tuning of TCP parameters on their
   servers.

2. another one, hypothesised by David, where the peer might only be
   willing to process (and acknowledge) data in batches.

   We might have queued outbound data which is, at the same time, not
   enough to fill one of these batches and be acknowledged and removed
   from the sending queue, but enough to make our available buffer
   smaller than the MSS, and the connection will hang.

Take care of both cases by:

a. not approximating the sending buffer to zero if we have no outboud
   queued data at all, because in that case we don't expect the
   available buffer to increase if we don't send any data, so there's
   no point in waiting for it to grow larger than the MSS.

   This fixes problem 1. above.

b. also using the full sending buffer size if we haven't send data to
   the socket for a while (reported by tcpi_last_data_sent). This part
   was already suggested by David in:

     https://archives.passt.top/passt-dev/aTZzgtcKWLb28zrf@zatzit/

   and I'm now picking ten times the RTT as a somewhat arbitrary
   threshold.

   This is meant to take care of potential problem 2. above, but it
   also happens to fix 1.

Reported-by: Tyler Cloud 
Link: https://bugs.passt.top/show_bug.cgi?id=183
Suggested-by: David Gibson 
Signed-off-by: Stefano Brivio 
Reviewed-by: David Gibson

conf, fwd: Move initialisation of auto port scanning out of conf()

2025-12-12T21:38:56+00:00

We call fwd_scan_ports_init() at (almost) the end of conf().  It's a bit
odd to do actual work from a function that's ostensibly about getting our
configuration.  It's not the only instance of this, but to make things a
bit clearer move the call to main(), right after flow_init().

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

tcp: Remove extra space from TCP_INFO debug messages (trivial)

2025-12-12T21:38:53+00:00

Debug messages about which tcp_info fields are supported contained an
extra space, always ending with "  supported".

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

pasta: Clean up waiting pasta child on failures

2025-12-12T21:23:14+00:00

When pasta is invoked with a command rather than an existing namespace to
attach to, it spawns a child process to run a shell or other command.  We
create that process during conf(), since we need the namespace to exist for
much of our setup.  However, we don't want the specified command to run
until the pasta network interface is ready for use.  Therefore,
pasta_spawn_cmd() executing in the child waits before exec()ing.  main()
signals the child to continue with SIGUSR1 shortly before entering the
main forwarding loop.

This has the downside that if we exit due to any kind of failure between
conf() and the SIGUSR1, the child process will be around waiting
indefinitely.  The user must manually clean this up.

Make this cleaner, by having the child use PR_SET_PDEATHSIG to have
itself killed if the parent dies during this window.  Technically
speaking this is racy: if the parent dies before the child can call
the prctl() it will be left zombie-like as before.  However, as long
as the parent completes pasta_wait_for_ns() before dying, I wasn't
able to trigger the race.  Since the consequences of this going wrong
are merely a bit ugly, I think that's good enough.

Suggested-by: Paul Holzinger 
Signed-off-by: David Gibson 
Reviewed-by: Paul Holzinger 
Signed-off-by: Stefano Brivio

treewide: Introduce passt_exit() helper

2025-12-12T21:20:02+00:00

In d0006fa78 ("treewide: use _exit() over exit()"), we replaced use of
the normal exit(3) with direct calls to _exit(2).  That was because glibc
exit(3) made some unexpected futex() calls, which hit our seccomp profile.

We've since had some bugs due to missing the extra cleanup that exit(3)
implemented, for which we've added explicit cleanup calls.  Specifically,
we have fflush() calls in some places to avoid leaving incomplete messages
on stdout/stderr, and in other places fsync_pcap_and_log() to avoid
leaving incomplete log or pcap files.

It's easy to forget these when adding new error paths, so instead,
implement our own passt_exit() wrapper to perform vital cleanup then call
_exit(2).  This also provides an obvious place to add any additional
cleanups we discover we need in future.

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

tcp: Suppress new instance of cppcheck bug 14191

2025-12-12T21:19:46+00:00

ee9b2361d ("cppcheck: Suppress a buggy cppcheck warning") added a
a suppression for a cppchec bug, since filed (and fixed) in upstream
cppcheck as https://trac.cppcheck.net/ticket/14191.  9139e60fd ("tcp:
Acknowledge everything if it looks like bulk traffic, not interactive")
introduced a new point which triggers the same cppcheck bug.

Add a suppression for the new instance.  This is a revision of Laurent's
earlier patch, updating the comments to make the connection between the
two instances clear, and adding unmatchedSuppression so it doesn't cause
a bogus warning with unaffected cppcheck versions.

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

pif: Correctly set scope_id for guest-side link local addresses

2025-12-10T07:37:29+00:00

pif_sockaddr() is supposed to generate a suitable socket address, either
for the host, or for the guest, depending on the 'pif' parameter.  When
given a link-local address, this means it needs to generate a suitable
scope_id to specify which link.  It does this for the host, but not for the
guest.

I think this was done on the assumption that we won't ever generate guest
side link local addresses when forwarding connections.  That, however, is
not the case, at least with the recent extensions to "local mode".  Fix the
problem by properly populating the scope_id field for guest addresses.

Link: https://bugs.passt.top/show_bug.cgi?id=181
Signed-off-by: David Gibson 
Signed-off-by: Stefano Brivio

tcp: Correct timer expiry value in trace message

2025-12-10T07:37:06+00:00

000601ba8 ("tcp: Adaptive interval based on RTT for socket-side
acknowledgement checks") added (amongst other things) a new trace message
showing the expiry time for the TCP timer in ms rather than s.

Unfortunately there were some arithmetic errors in the message, meaning it
will print incorrect numbers.  Correct them

Fixes: 000601ba86da ("tcp: Adaptive interval based on RTT for socket-side acknowledgement checks")
Link: https://bugs.passt.top/show_bug.cgi?id=182
Signed-off-by: David Gibson 
Signed-off-by: Stefano Brivio

tcp_splice, flow: Add socket to epoll set before connect(), drop assert

2025-12-09T00:27:24+00:00

...otherwise, if we have a real error on connect() (that is, not
EINPROGRESS), we'll return early from tcp_splice_connect() and later
try to fetch the epoll file descriptor:

  ASSERTION FAILED in flow_epollfd (flow.c:362): f->epollid < ((1 << 8) - 1)

which is still (correctly) EPOLLFD_ID_INVALID.

Replace the ASSERT() in flow_epollfd() with a warning, as it looks
like there might be harmless cases where the socket is not in the
epoll set yet, and we'll just crash for nothing. We can turn this back
to an ASSERT() once we audit these paths in more detail.

Link: https://bodhi.fedoraproject.org/updates/FEDORA-2025-93b4eb64c3#comment-4473411
Signed-off-by: Stefano Brivio 
Reviewed-by: David Gibson

fedora: Fix build on Fedora 43, selinux_requires_min not available on Copr builders

2025-12-08T10:17:14+00:00

For some reason, on Copr:

  Building target platforms: aarch64
  Building for target aarch64
  error: line 42: Unknown tag: %selinux_requires_min
  Child return code was: 1

Use %selinux_requires_min starting from current Rawhide / Fedora 44,
there it works.

Signed-off-by: Stefano Brivio