The error code is not returned in case of an error initializing UDP transport with whitelist

[i-and]

Is there an already existing issue for this?

• I have searched the existing issues

Expected behavior

The client software is notified of the inability to transmit data over Ethernet

Current behavior

A UDP transport initialization error does not result in an error code being returned to the client software

Steps to reproduce

In the whitelist Participant settings, set an address that does not match any local IP. The console displays "[TRANSPORT Error] All whitelist interfaces are filtered out -> Function UDPv4Transport". However, the process of creating and enabling a Participant will be completed successfully. At the same time, the transmission and reception of data over the Ethernet channel for this created Participant is blocked by the error described above.

Fast DDS version/commit

2.13.0

Platform/Architecture

Ubuntu Focal 20.04 amd64

Transport layer

UDPv4

Additional context

I suggest in this situation not to create/enable a Participant, but to return the appropriate error sign. Possible solution:

diff --git a/src/cpp/rtps/transport/UDPTransportInterface.cpp b/src/cpp/rtps/transport/UDPTransportInterface.cpp
index 820056e26..95d8ffd6f 100644
--- a/src/cpp/rtps/transport/UDPTransportInterface.cpp
+++ b/src/cpp/rtps/transport/UDPTransportInterface.cpp
@@ -119,6 +119,11 @@ bool UDPTransportInterface::DoInputLocatorsMatch(
 bool UDPTransportInterface::init(
         const fastrtps::rtps::PropertyPolicy*)
 {
+    if (interfaces_filtered_out_)
+    {
+        return false;
+    }
+
     if (configuration()->sendBufferSize == 0 || configuration()->receiveBufferSize == 0)
     {
         // Check system buffer sizes.
diff --git a/src/cpp/rtps/transport/UDPTransportInterface.h b/src/cpp/rtps/transport/UDPTransportInterface.h
index 287aa5b32..043699efe 100644
--- a/src/cpp/rtps/transport/UDPTransportInterface.h
+++ b/src/cpp/rtps/transport/UDPTransportInterface.h
@@ -290,6 +290,7 @@ protected:
             bool return_loopback = false);
 
     std::atomic_bool rescan_interfaces_ = {true};
+    bool interfaces_filtered_out_ {false};
 };
 
 } // namespace rtps
diff --git a/src/cpp/rtps/transport/UDPv4Transport.cpp b/src/cpp/rtps/transport/UDPv4Transport.cpp
index 2d1b1e0e4..b8c4e8608 100644
--- a/src/cpp/rtps/transport/UDPv4Transport.cpp
+++ b/src/cpp/rtps/transport/UDPv4Transport.cpp
@@ -122,6 +122,7 @@ UDPv4Transport::UDPv4Transport(
         {
             EPROSIMA_LOG_ERROR(TRANSPORT, "All whitelist interfaces were filtered out");
             interface_whitelist_.emplace_back(ip::address_v4::from_string("192.0.2.0"));
+            interfaces_filtered_out_ = true;
         }
     }
 }

XML configuration file

No response

Relevant log output

No response

Network traffic capture

No response

[elianalf]

Hi @i-and,
thanks for using Fast DDS.
Actually, this is the desired behavior. In this situation, we do not want the DomainParticipant creation to fail. Even if one transport is not properly configured and fails due to whitelist issues, there can be other locators from different transports through which communication can be established. I am going to close this issue because the current design is correct. However, if you have any further questions or doubts, please feel free to open a discussion in this section.

[i-and]

Hi @elianalf,
The idea of using successfully initialized transports is clear. But still, I propose to implement the above-mentioned initialization error handling in the case when the initialization of all Participant transports ended with an error (i.e., in fact, the Participant does not have at least one working transport).