Processing of vendor specific ParameterId for PID_NETWORK_CONFIGURATION_SET caused interoperability fails.

[Zhurakovsky]

Is there an already existing issue for this?

• I have searched the existing issues

Expected behavior

Interoperability should be supported during the Simple discovery phase.
According to "9.6.2.2.1 ParameterId space" Vendor-specific ParameterId should not be recognized by other vendors’ implementations for the "PID_NETWORK_CONFIGURATION_SET".

Current behavior

Call to astdds::dds::ParameterSerializer<ParameterNetworkConfigSet_t>::read_from_cdr_message(p, msg, plength) function for PID_NETWORK_CONFIGURATION_SET parameter cannot properly process CDR message in case of message from the non-eProsima vendors and returns false instead of ignoring the vendor-specific parameter.

Steps to reproduce

Run a minimal interoperability demo with a Simple discovery with a second (non-eProsima) client.

Fast DDS version/commit

v2.13.1

Platform/Architecture

Ubuntu Focal 20.04 amd64, Ubuntu Focal 20.04 arm64

Transport layer

Default configuration, UDPv4 & SHM, Shared Memory Transport (SHM)

Additional context

This patch makes me able to fix the issue:

index d026ff843..bfd3f4ede 100644
--- a/src/cpp/rtps/builtin/data/ParticipantProxyData.cpp
+++ b/src/cpp/rtps/builtin/data/ParticipantProxyData.cpp
@@ -462,6 +462,11 @@ bool ParticipantProxyData::readFromCDRMessage(
                     }
                     case fastdds::dds::PID_NETWORK_CONFIGURATION_SET:
                     {
+                        if(m_VendorId != c_VendorId_eProsima)
+                        {
+                            EPROSIMA_LOG_WARNING(RTPS_PARTICIPANT, "Received PID_NETWORK_CONFIGURATION_SET vendor specific extension from non-Eprosima implementation");
+                            break;
+                        }
                         ParameterNetworkConfigSet_t p(pid, plength);
                         if (!fastdds::dds::ParameterSerializer<ParameterNetworkConfigSet_t>::read_from_cdr_message(p,
                                 msg, plength))

XML configuration file

No response

Relevant log output

No response

Network traffic capture

No response

[MiguelCompany]

This was already identified, and fixed in #4291, which has been released in v2.13.2