-
Notifications
You must be signed in to change notification settings - Fork 765
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error initializing Fast-DDS when the Ethernet link is not up #4371
Labels
triage
Issue pending classification
Comments
not_run_ifc_1.patch:
|
not_run_ifc_2.patch:
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is there an already existing issue for this?
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
The text was updated successfully, but these errors were encountered: