-
Notifications
You must be signed in to change notification settings - Fork 787
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
Comments
not_run_ifc_1.patch:
|
not_run_ifc_2.patch:
|
I also ran into this. I used to re-create the participant in case the network was not available, but with the introduced caching in #4241, this does not work anymore. As a work-around I'm now forcing the ip link add veth_dummy0 type veth peer name veth_dummy1
ip link set veth_dummy1 master docker0
ip link set veth_dummy0 up
ip link set veth_dummy1 up Would be good to have a better solution though, as neither of the 2 solutions proposed elsewhere work for me:
|
We have just released Fast DDS v3.1.0 which solves some issues regarding Dynamic Network interfaces. Could you please check if the issue persists with that ? |
Thanks for the quick reply. So with 3.1.0 I can just call |
Yes, it should also take the transport whitelisting into account. |
Ok thanks. I'll try to have a look, but I'm not sure how soon I'll get to it. |
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: