Description
Is there an already existing issue for this?
- I have searched the existing issues
Expected behavior
The stack must be initialized successfully regardless of external conditions - in this case, the current state of the Ethernet link
Current behavior
The stack is not functional if the link was down during initialization.
Steps to reproduce
This error can be recreated using a physical Ethernet interface with its configuration in a state where the set IP address is not reset by the system when the link go down.
But it is more convenient to recreate the situation using the docker0 bridge (in my case, it has the address 172.17.0.1). As an application, you can use HelloWorldExample with the whitelist value set to 172.17.0.1. If you run the application on the host first and then in the container, then DDS interaction will not be performed. If in a different sequence, then everything will work successfully because launching the container will raise the link connected to docker0 from the host side.
Fast DDS version/commit
2.13.0
Platform/Architecture
Ubuntu Focal 20.04 amd64
Transport layer
UDPv4
Additional context
I offer two options for correction:
-
not_run_ifc_1.patch - The current default stack behavior does not change, i.e. UDPv4 transport uses only running interfaces. To activate the new feature, set the
allow_not_running_interfaces
field fromSocketTransportDescriptor
totrue
. -
not_run_ifc_2.patch - The current default stack behavior changes if whitelist is set in UDPv4 transport. In this case, the interfaces specified in the whitelist that are not running are also used. No new parameters are introduced at the
TransportDescriptor
level.
XML configuration file
No response
Relevant log output
No response
Network traffic capture
No response