Is there an already existing issue for this?
Expected behavior
I want to allow the discovery server to listen over UDP on all network interfaces, including ones brought up after the server has been started.
To do this, I am running fastdds discovery --udp-address 0.0.0.0. I expect the server to start listening on the loopback interface, and also on new interfaces when they come up.
Current behavior
When using 0.0.0.0 as the UDP address when no external network connection is available, the server fails to start - even though this address can still apply to the loopback interface, which is available.
When using 127.0.0.1, though, the server launches correctly.
Steps to reproduce
- Make sure no non-loopback network interfaces are up
fastdds discovery --udp-address 0.0.0.0, observe the error.
fastdds discovery --udp-address 127.0.0.1, observe no error. The server listens on lo and no other interfaces.
- Bring up another network interface
fastdds discovery --udp-address 0.0.0.0, observe no error. The server listens on lo and all other interfaces (the expected behaviour).
Fast DDS version/commit
v3.2.2
Platform/Architecture
Other. Please specify in Additional context section.
Transport layer
UDPv4
Additional context
Observed on an embedded Linux distribution. I'd imagine the issue is present on Ubuntu as well, though.
The issue can be reproduced using the CLI commands given, but if XML configuration is preferred, an equivalent is included below.
XML configuration file
<?xml version="1.0" encoding="UTF-8"?>
<profiles xmlns="http://www.eprosima.com/XMLSchemas/fastRTPS_Profiles">
<participant profile_name="server" is_default_profile="true">
<rtps>
<builtin>
<discovery_config>
<discoveryProtocol>SERVER</discoveryProtocol>
</discovery_config>
<metatrafficUnicastLocatorList>
<locator>
<udpv4>
<address>0.0.0.0</address>
<port>11811</port>
</udpv4>
</locator>
</metatrafficUnicastLocatorList>
</builtin>
</rtps>
</participant>
</profiles>
Relevant log output
[RTPS_PARTICIPANT Error] Discovery Server wasn't able to allocate the specified listening port. -> Function createParticipant
[RTPS_DOMAIN Error] Unable to create the participant -> Function createParticipant
[DOMAIN_PARTICIPANT Error] Problem creating RTPSParticipant -> Function enable
[CLI Error] Server creation failed with the given settings. Please review locators setup. -> Function fastdds_discovery_server
Network traffic capture
No response
Is there an already existing issue for this?
Expected behavior
I want to allow the discovery server to listen over UDP on all network interfaces, including ones brought up after the server has been started.
To do this, I am running
fastdds discovery --udp-address 0.0.0.0. I expect the server to start listening on the loopback interface, and also on new interfaces when they come up.Current behavior
When using
0.0.0.0as the UDP address when no external network connection is available, the server fails to start - even though this address can still apply to the loopback interface, which is available.When using
127.0.0.1, though, the server launches correctly.Steps to reproduce
fastdds discovery --udp-address 0.0.0.0, observe the error.fastdds discovery --udp-address 127.0.0.1, observe no error. The server listens onloand no other interfaces.fastdds discovery --udp-address 0.0.0.0, observe no error. The server listens onloand all other interfaces (the expected behaviour).Fast DDS version/commit
v3.2.2
Platform/Architecture
Other. Please specify in Additional context section.
Transport layer
UDPv4
Additional context
Observed on an embedded Linux distribution. I'd imagine the issue is present on Ubuntu as well, though.
The issue can be reproduced using the CLI commands given, but if XML configuration is preferred, an equivalent is included below.
XML configuration file
Relevant log output
Network traffic capture
No response