The test "signal address, TCP-only listener on client" is a bit
particular: a TCP-only listening socket is created on the client side,
and the kernel will try to connect to this local IP.

To be able to understand what's going on in case of issues, it is
helpful to have a capture on the client side as well for this particular
test. This avoids some confusions.

Note that the 2nd tcpdump process will have its standard output
redirected to the same file after having truncated it. That's fine for
this test, this output file is not very important, no need to have an
exception there.

Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
---
 tools/testing/selftests/net/mptcp/mptcp_join.sh | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/tools/testing/selftests/net/mptcp/mptcp_join.sh b/tools/testing/selftests/net/mptcp/mptcp_join.sh
index b16e24418e73..690188b01a29 100755
--- a/tools/testing/selftests/net/mptcp/mptcp_join.sh
+++ b/tools/testing/selftests/net/mptcp/mptcp_join.sh
@@ -2413,7 +2413,10 @@ signal_address_tests()
 		extra_bind=$!
 		mptcp_lib_wait_local_port_listen "$ns2" "$port"
 
+		# there will be traffic on the client side only: MPJ to loopback
+		cond_start_capture ${ns2}
 		run_tests $ns1 $ns2 10.0.1.1
+		cond_stop_capture
 		join_synack_no_mpjoin=1 join_syn_tx=1 \
 			chk_join_nr 0 0 0
 

---
base-commit: 060af37701a3aca2c02cb5e874d740be6acbf1a2
change-id: 20260914-mptcp-sft-join-cap-ns2-a6ba4960ea23

Best regards,
--  
Matthieu Baerts (NGI0) <matttbe@kernel.org>

Hi Matthieu,

Thank you for your modifications, that's great!

Our CI did some validations and here is its report:

- KVM Validation: normal (except selftest_mptcp_join): Success! ✅
- KVM Validation: normal (only selftest_mptcp_join): Success! ✅
- KVM Validation: debug (except selftest_mptcp_join): Success! ✅
- KVM Validation: debug (only selftest_mptcp_join): Success! ✅
- KVM Validation: btf-normal (only bpftest_all): Success! ✅
- KVM Validation: btf-debug (only bpftest_all): Success! ✅
- Perf: Success! ✅
- Task: https://github.com/multipath-tcp/mptcp_net-next/actions/runs/34878489588

Initiator: Patchew Applier
Commits: https://github.com/multipath-tcp/mptcp_net-next/commits/6b5c56b662ba
Patchwork: https://patchwork.kernel.org/project/mptcp/list/?series=1164801


If there are some issues, you can reproduce them using the same environment as
the one used by the CI thanks to a docker image, e.g.:

    $ cd [kernel source code]
    $ docker run -v "${PWD}:${PWD}:rw" -w "${PWD}" --privileged --rm -it \
        --pull always mptcp/mptcp-upstream-virtme-docker:latest \
        auto-normal

For more details:

    https://github.com/multipath-tcp/mptcp-upstream-virtme-docker


Please note that despite all the efforts that have been already done to have a
stable tests suite when executed on a public CI like here, it is possible some
reported issues are not due to your modifications. Still, do not hesitate to
help us improve that ;-)

Cheers,
MPTCP GH Action bot
Bot operated by Matthieu Baerts (NGI0 Core)

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Nested calls to `cond_start_capture` overwrite the global `cappid` variable, causing a `tcpdump` process and its network namespace to leak.
--

commit 80defebd011f8ed71f8eb594afa6362cc8789eb8
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>

selftests: mptcp: join: capture on client side for test 020

The test "signal address, TCP-only listener on client" is particular, so
a capture on the client side is added to help understand what happens in
case of issues.

> diff --git a/tools/testing/selftests/net/mptcp/mptcp_join.sh b/tools/testing/selftests/net/mptcp/mptcp_join.sh
> index b16e24418e737..690188b01a29d 100755
> --- a/tools/testing/selftests/net/mptcp/mptcp_join.sh
> +++ b/tools/testing/selftests/net/mptcp/mptcp_join.sh
> @@ -2413,7 +2413,10 @@ signal_address_tests()
>  		extra_bind=$!
>  		mptcp_lib_wait_local_port_listen "$ns2" "$port"
>  
> +		# there will be traffic on the client side only: MPJ to loopback
> +		cond_start_capture ${ns2}
>  		run_tests $ns1 $ns2 10.0.1.1

[Severity: Medium]
Will this leak a tcpdump process by overwriting the global cappid variable?

In cond_start_capture(), cappid is set as a single global variable:

	ip netns exec "$ns" tcpdump -i any -s 128 -B 32768 $capuser -w "$capfile" > "$capout" 2>&1 &
	cappid=$!

Here, cond_start_capture is called for ns2, but run_tests() -> do_transfer()
also unconditionally calls cond_start_capture again for listener_ns:

	cond_start_capture ${listener_ns}

This second call overwrites the global cappid. When the inner cond_stop_capture
and the outer cond_stop_capture are called, they attempt to kill the same inner
process, leaving the first tcpdump process to run indefinitely in the
background.

> +		cond_stop_capture
>  		join_synack_no_mpjoin=1 join_syn_tx=1 \
>  			chk_join_nr 0 0 0
>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260914-mptcp-sft-join-cap-ns2-v1-1-2f48e4c5f9eb@kernel.org?part=1