We observed a similar issue and I found setting up specific/custom transport protocols seemed to fix it for us.

I set up a UDP and TCP transport interface (omitting shared memory transport) which may suggest that the collision/hang occurs in setting up the shared memory space which I assume is probably enabled by default.

So create this DDS profile (fastdds_profiles.xml)

<?xml version="1.0" encoding="UTF-8" ?>
<profiles xmlns="http://www.eprosima.com/XMLSchemas/fastRTPS_Profiles">
    <transport_descriptors>
        <transport_descriptor>
            <transport_id>CustomTcpTransport</transport_id>
            <type>TCPv4</type>
            <interfaceWhiteList>
                <address>127.0.0.1</address>
            </interfaceWhiteList>
        </transport_descriptor>
        <transport_descriptor>
            <transport_id>CustomUdpTransport</transport_id>
            <type>UDPv4</type>
            <interfaceWhiteList>
                <address>127.0.0.1</address>
            </interfaceWhiteList>
            <non_blocking_send>false</non_blocking_send>
        </transport_descriptor>
    </transport_descriptors>

    <participant profile_name="CustomTransportParticipant" is_default_profile="true">
        <rtps>
            <useBuiltinTransports>false</useBuiltinTransports>
            <userTransports>
                <transport_id>CustomTcpTransport</transport_id>
                <transport_id>CustomUdpTransport</transport_id>
            </userTransports>
        </rtps>
    </participant>
</profiles>

and then make it available before launching nodes

set FASTRTPS_DEFAULT_PROFILES_FILE=fastdds_profiles.xml

Note: this profile also limits discoverability to loopback/localhost (127.0.0.1) more network adapters can be added)

We observed a similar issue and I found setting up specific/custom transport protocols seemed to fix it for us.

I set up a UDP and TCP transport interface (omitting shared memory transport) which may suggest that the collision/hang occurs in setting up the shared memory space which I assume is probably enabled by default.

So create this DDS profile (fastdds_profiles.xml)

<?xml version="1.0" encoding="UTF-8" ?>
<profiles xmlns="http://www.eprosima.com/XMLSchemas/fastRTPS_Profiles">
    <transport_descriptors>
        <transport_descriptor>
            <transport_id>CustomTcpTransport</transport_id>
            <type>TCPv4</type>
            <interfaceWhiteList>
                <address>127.0.0.1</address>
            </interfaceWhiteList>
        </transport_descriptor>
        <transport_descriptor>
            <transport_id>CustomUdpTransport</transport_id>
            <type>UDPv4</type>
            <interfaceWhiteList>
                <address>127.0.0.1</address>
            </interfaceWhiteList>
            <non_blocking_send>false</non_blocking_send>
        </transport_descriptor>
    </transport_descriptors>

    <participant profile_name="CustomTransportParticipant" is_default_profile="true">
        <rtps>
            <useBuiltinTransports>false</useBuiltinTransports>
            <userTransports>
                <transport_id>CustomTcpTransport</transport_id>
                <transport_id>CustomUdpTransport</transport_id>
            </userTransports>
        </rtps>
    </participant>
</profiles>

and then make it available before launching nodes

set FASTRTPS_DEFAULT_PROFILES_FILE=fastdds_profiles.xml

Note: this profile also limits discoverability to loopback/localhost (127.0.0.1) more network adapters can be added)

Background: Even with the hanging nodes I observed that the ports for all nodes were created which may suggest why they can still be observed from a linux machine, but the nodes didn't completely start which would suggest the nodes are likely to still be non-functional.