There is no interaction on UDP transport if the host IDs are the same

[i-and]

Is there an already existing issue for this?

• [X] I have searched the existing issues

Expected behavior

Robust interaction is provided

Current behavior

Depending on the IPv4 address values on the hosts, communication between them over DDS may be broken.

Steps to reproduce

The example HelloWorld needs to be modified as follows:

1. Simulate a host-ID match on two different hosts by returning a constant 16-bit value from the method uint16_t Host::compute_id(const fastdds::rtps::LocatorList& loc).
2. Set a whitelist in the HelloWorldPublisher/HelloWorldSubscriber.

NOTE The probability of this situation in real life is quite high because the hash value containing the host id is only 16 bits in size. In addition, this value may change from launch to launch of the host, since it is calculated as MD5 for IPv4 interface addresses with physical links up.

Fast DDS version/commit

v2.14.1

Platform/Architecture

Ubuntu Focal 20.04 amd64

Transport layer

UDPv4

Additional context

Apparently, the problem is related to the erroneous filtering of the received Locator by the method: https://github.com/eProsima/Fast-DDS/blob/1925a6bde9c56b15a7395412138b66b1d236acbc/src/cpp/rtps/network/NetworkFactory.cpp#L281-L286 Possible correction: return (is_locator_supported(locator) && !is_fastdds_local) || is_locator_remote_or_allowed(locator);

XML configuration file

No response

Relevant log output

No response

Network traffic capture

No response

[elianalf]

Hi @i-and, thanks for your contribution.

Depending on the IPv4 address values on the hosts, communication between them over DDS may be broken.

Yes, this can happen but we actually don't think the probability of this situation occurring is really high.

In addition, this value may change from launch to launch of the host, since it is calculated as MD5 for IPv4 interface addresses with physical links up.

We will try to take the time to evaluate it and possibly improve it.