The `Socks5Server` utility handles multiple incoming connections,
which are handled in separate background threads.
The `stop()` method unblocks and waits for the main background thread
cleanly, but it doesn't attempt to wait for any handler threads.
This change stores handler threads and connections, and attempts
to shut them down before `stop()` returns.
Co-authored-by: vasild <vd@FreeBSD.org>
Co-authored-by: w0xlt <94266259+w0xlt@users.noreply.github.com>
On FreeBSD, the default ephemeral port range (10000-65535) overlaps
with the test framework's static port range (11000-26000), causing
intermittent "address already in use" failures when tests use dynamic
port allocation (port=0).
Add a helper function that sets the IP_PORTRANGE/IPV6_PORTRANGE socket
option to IP_PORTRANGE_HIGH before binding, which requests ports from
the high range (49152-65535) instead. This range does not overlap with
the test framework's static ports.
Constants from FreeBSD's netinet/in.h and netinet6/in6.h:
- IP_PORTRANGE = 19 (for IPv4 sockets)
- IPV6_PORTRANGE = 14 (for IPv6 sockets)
- IP_PORTRANGE_HIGH = 1
Fixes: bitcoin/bitcoin#34331
Co-Authored-By: Vasil Dimov <vd@FreeBSD.org>
Co-Authored-By: MarcoFalke <*~=\`'#}+{/-|&$^_@721217.xyz>
Use port=0 for dynamic port allocation in test framework components
to avoid "address already in use" errors from concurrent tests or
ports stuck in TIME_WAIT state from previous test runs.
Changes:
- socks5.py: Update conf.addr after bind() to reflect actual port
- p2p.py: Retrieve actual port after create_server() when port=0
- feature_proxy.py: Use port=0 for all SOCKS5 proxy servers
- feature_anchors.py: Use port=0 for onion proxy server
If requested, make the SOCKS5 Python proxy redirect each connection to a
given destination. Actually act as a real proxy, connecting the
client to a destination, except that the destination is not what the
client asked for.
This would enable us to "connect" to Tor addresses from the functional
tests.
The Socks5 server we use in the test framework would disconnect
by default immediately after the handshake and sometimes would
not register as a connected peer by bitcoind.
