AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Informational 15 Bitcoin

test: extend FreeBSD ephemeral port range fix to P2P listeners

Public commit record

What the developer wrote

Authored by node

95/100 · Strong
test: extend FreeBSD ephemeral port range fix to P2P listeners

The previous commit added set_ephemeral_port_range() to
avoid port conflicts on FreeBSD by requesting ports from the high
ephemeral range (49152-65535) instead of the default range
which overlaps with the test framework's static port range.

That fix was applied to the SOCKS5 server but not to P2P listeners
created via NetworkThread.create_listen_server(). This commit extends
the fix to cover P2P listeners as well.

When port=0 is requested (dynamic allocation), we now:
1. Manually create a socket with the appropriate address family
2. Call set_ephemeral_port_range() to configure the port range
3. Bind and listen on the socket
4. Pass the pre-configured socket to asyncio's create_server()

This ensures that dynamically allocated ports for P2P listeners also
come from the high range on FreeBSD, avoiding conflicts with the test
framework's static port assignments.

Co-Authored-By: Vasil Dimov <vd@FreeBSD.org>
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Mentions testing or verification
The short version

What changed, and why it matters

This is a test-only change for Bitcoin Core's internal Python test framework. It fixes a port-conflict problem that could occur when running automated tests on FreeBSD, by making sure randomly chosen network ports for test P2P listeners come from a range that does not clash with the test framework's hard-coded ports. It does not affect the Bitcoin Core software that users run, does not change consensus or networking behavior, and has no security relevance for live Bitcoin nodes.

Recommended action

No security action required. Treat as a normal test-framework reliability improvement.

Security signals we found

No strong security signals were identified.

Risk score

Why this scored 15/100

Our methodology →
Potential impact 0/30
Exploitability 0/25
Stealth signal 0/15
Affected reach 0/15
Confidence 10/10
Evidence quality 5/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.