Silent metatraffic port mutation defeats unicast initial-peers discovery (ports in the OS dynamic range, Hyper-V exclusions on Windows): please log the move #6528

Is there an already existing issue for this?

• I have searched the existing issues

Expected behavior

When a participant cannot bind the metatraffic unicast port its domain and participant id imply and the "iterative mechanism" (RTPSParticipantImpl::createReceiverResources / applyLocatorAdaptRule) moves it to another port, something visible says so, because the move can make the participant undiscoverable by peers that rely on unicast initial peers.

Current behavior

The move is silent: the bind failure is EPROSIMA_LOG_INFO (UDPTransportInterface::OpenAndBindInputSockets, compiled out of Release builds), the successful retry logs nothing at any level, and only exhausting all mutation_tries (100) produces an EPROSIMA_LOG_WARNING. The participant id handed out by RTPSDomainImpl::getNewId (the smallest free index in the process) stays 0 / 1 while the port slot the peers will probe for it -- configureInitialPeerLocator expands a port-less initial peer to slots 0 .. maxInitialPeersRange - 1 -- no longer matches.

We hit this in CI on Windows: our tests draw a random domain in 1..200 per process, domains >= 167 map their ports (7400 + 250 * d + 10 + 2 * slot) into Windows' dynamic port range (49152+), and the GitHub Windows runners carry Hyper-V/WinNAT UDP port exclusion blocks of 200 consecutive ports there (netsh int ipv4 show excludedportrange protocol=udp: windows-2022 50034-50233, windows-2025 63695-63894). When such a block covers a domain's first 50 slots, both participants of one process (SO_EXCLUSIVEADDRUSE bind failures, 25+ silent retries each) end up on slots 50 and 51; with maxInitialPeersRange 50 and no multicast (loopback-whitelisted UDPv4, initialPeersList 127.0.0.1) neither ever probes the other, no DATA(p) is exchanged, and a test that normally matches in < 1 s times out after 15 s with nothing in any log. It reproduces deterministically on Linux by occupying the 50 slots by hand (participants bound at slots 50/51 -> no match; slots 0..30 occupied -> match in 0 ms).

Suggestion

1. Log the port move at EPROSIMA_LOG_WARNING in createReceiverResources when a mutation was needed and succeeded ("metatraffic unicast port X in use, listening on Y instead: peers using unicast initial peers must cover participant slot N"), since the consequence is a discovery failure the application cannot otherwise observe.
2. Optionally, have RTPSDomainImpl::getNewId / participant id allocation take the actually bound slot into account, or document in the initial-peers section that maxInitialPeersRange must cover the port slots participants can be pushed to, and that domain ids whose ports fall in the OS dynamic port range (>= 102 on Linux, >= 167 on Windows/macOS) are unreliable with unicast-only discovery.

We keep our own domains <= 100 now and warn at participant creation above the OS limit; a log line inside Fast-DDS would have made this attributable in minutes instead of days.

Fast DDS version/commit

v3.6.2 (createReceiverResources / applyLocatorAdaptRule unchanged on master).

Platform/Architecture

Windows 2022 / 2025 GitHub-hosted runners (x86_64); reproducible on Linux with occupied ports.

Transport layer

UDPv4 (interface whitelist 127.0.0.1, unicast initial peers, no multicast).

Additional context

Found while chasing #6502 and #6526 in the same test suite.