qa: Intermittent failure in `p2p_private_broadcast_retry_v1.py` #36099

On OpenBSD:

2026-08-27T11:41:31.0063618Z 492/493 - p2p_private_broadcast_retry_v1.py failed (exit code 1), Duration: 481 s
2026-08-27T11:41:31.0064338Z 
2026-08-27T11:41:31.0064642Z stdout:
2026-08-27T11:41:31.0065325Z 2026-08-27T11:33:28.896760Z TestFramework (INFO): PRNG seed is: 5390872729751420807
2026-08-27T11:41:31.0070506Z 2026-08-27T11:33:28.950939Z TestFramework (INFO): Initializing test directory /home/test_runner_₿_🏃_20260827_111756/p2p_private_broadcast_retry_v1_23
2026-08-27T11:41:31.0071910Z 2026-08-27T11:33:29.403561Z TestFramework (INFO): Filling node0's addrman with addresses
2026-08-27T11:41:31.0073084Z 2026-08-27T11:33:29.428231Z TestFramework (INFO): Opening manual connections to all IPv4 addresses to add P2P_V2 flag to addrman entries
2026-08-27T11:41:31.0074528Z 2026-08-27T11:33:29.518324Z TestFramework (INFO): Waiting for all IPv4 addresses to get P2P_V2 as a result of peers advertising support
2026-08-27T11:41:31.0075732Z 2026-08-27T11:41:29.521891Z TestFramework.utils (ERROR): wait_until() failed. Predicate: ''''
2026-08-27T11:41:31.0076882Z         self.wait_until(lambda: all(a["services"] & NODE_P2P_V2 != 0 for a in node0.getnodeaddresses(count=0, network="ipv4")))
2026-08-27T11:41:31.0077684Z '''
2026-08-27T11:41:31.0078126Z 2026-08-27T11:41:29.522231Z TestFramework (ERROR): Unexpected exception:
2026-08-27T11:41:31.0078716Z Traceback (most recent call last):
2026-08-27T11:41:31.0079384Z   File "/home/bitcoin/test/functional/test_framework/test_framework.py", line 145, in main
2026-08-27T11:41:31.0080628Z     self.run_test()
2026-08-27T11:41:31.0080941Z     ~~~~~~~~~~~~~^^
2026-08-27T11:41:31.0081951Z   File "/home/build/test/functional/p2p_private_broadcast_retry_v1.py", line 165, in run_test
2026-08-27T11:41:31.0083294Z     self.wait_until(lambda: all(a["services"] & NODE_P2P_V2 != 0 for a in node0.getnodeaddresses(count=0, network="ipv4")))
2026-08-27T11:41:31.0084297Z     ~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2026-08-27T11:41:31.0085224Z   File "/home/bitcoin/test/functional/test_framework/test_framework.py", line 747, in wait_until
2026-08-27T11:41:31.0086502Z     return wait_until_helper_internal(test_function, timeout=timeout, timeout_factor=self.options.timeout_factor, check_interval=check_interval)
2026-08-27T11:41:31.0087830Z   File "/home/bitcoin/test/functional/test_framework/util.py", line 451, in wait_until_helper_internal
2026-08-27T11:41:31.0088895Z     raise AssertionError("Predicate {} not true after {} seconds".format(predicate_source, timeout))
2026-08-27T11:41:31.0090044Z AssertionError: Predicate ''''
2026-08-27T11:41:31.0090846Z         self.wait_until(lambda: all(a["services"] & NODE_P2P_V2 != 0 for a in node0.getnodeaddresses(count=0, network="ipv4")))
2026-08-27T11:41:31.0091668Z ''' not true after 480.0 seconds

This issue differs from #35508.

cc @vasild @andrewtoth

Does this only reproduce on OpenBSD?

Does this only reproduce on OpenBSD?

I haven't yet observed this issue on any other platforms.

Looks like the connection to one of the addresses (60.0.0.1) is just getting stuck for no apparent reason and never completes the handshake. I don't have an explanation, but as a wild guess: maybe related to 34bed0ed8c which introduced a workaround only for FreeBSD?

Looks like the connection to one of the addresses (60.0.0.1) is just getting stuck for no apparent reason and never completes the handshake. I don't have an explanation, but as a wild guess: maybe related to 34bed0e which introduced a workaround only for FreeBSD?

Thanks! Done in #36145.

Looks like the connection to one of the addresses (60.0.0.1) is just getting stuck for no apparent reason and never completes the handshake. I don't have an explanation, but as a wild guess: maybe related to 34bed0e which introduced a workaround only for FreeBSD?

Thanks! Done in #36145.

Unfortunately, that doesn't help: https://github.com/hebasto/bitcoin-core-nightly/actions/runs/33663232206/job/100358725821.

https://github.com/hebasto/bitcoin-core-nightly/actions/runs/35308609129/job/105485800263

https://github.com/hebasto/bitcoin-core-nightly/actions/runs/38116542849/job/114402442414#step:15:555

https://github.com/hebasto/bitcoin-core-nightly/actions/runs/38683604855/job/116253366657

Looks like the connection to one of the addresses (60.0.0.1) is just getting stuck for no apparent reason and never completes the handshake.

The following patch helps to get rid of such stuck connections:

--- a/test/functional/p2p_private_broadcast_retry_v1.py
+++ b/test/functional/p2p_private_broadcast_retry_v1.py
@@ -143,6 +143,7 @@ class P2PPrivateBroadcastRetryV1(BitcoinTestFramework):
                 f"-onion={self.tor_proxy.conf.addr[0]}:{self.tor_proxy.conf.addr[1]}",
                 "-test=addrman",
                 "-v2transport=0",
+                f"-peertimeout={int(10 * self.options.timeout_factor)}",
             ],
         ]
 

16. The following patch helps to get rid of such stuck connections:

But that is just hiding the symptom, not fixing the underlying cause?

The following patch helps to get rid of such stuck connections:

But that is just hiding the symptom, not fixing the underlying cause?

It seems that the root cause is a regression introduced in OpenBSD 7.8 together with parallel TCP input.

cc @theStack

It seems that the root cause is a regression introduced in OpenBSD 7.8 together with parallel TCP input.

Reported upstream:

• https://marc.info/?l=openbsd-bugs&m=179319933470109
• https://mail-archive.com/bugs@openbsd.org/msg24662.html