ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A

No communication if no gateway is set

I ran into trouble with a simple network setup consisting of two computes connected via a switch. I noticed ros2 will only send data in case a gateway is set (the gateway address doesn’t need to be reasonable - for example I just set it to the ip of the switch).

This leads me to the question. Why do I need to set a gateway?

1 Like

What version of ROS2 are you using?

I’m on the current master branches.

Any ideas someone ?
This issue isn’t that fatal but I’d like to know if I’m doing anything wrong or got a wrong understanding of the system.

Could anyone of the ros2 team say if this is intended behaviour (or at least determined by the middleware) or if this is a bug?

Maybe nobody else has answered since nobody knows the answer to your question out of the head. I quick Google search seems to indicate that a gateway might be required for udp multicast which are being used for the DDS discovery.

Slightly related to this, you may want to make sure that multicast is
enabled on your NIC. I’ve noticed that on some Linux machines even the
local communication doesn’t work wo/ the multicast being explicitly
activated on the loopback adapter.
See here:

Thanks for your answers.
@dirk-thomas Sry didn’t wanted to sound rude.
As a user it is at the moment quite hard to tell if some behaviour is intented, a bug, or if I’m simply using it the wrong way

Regarding the gateway behaviour:
I was just really irriated because this kind of setup might occur sometimes in robotic systems.

@karsten Some of these phenomenas I already noticed myself. The loopback interface communication without having any other interfaces activated never worked for me regardless of using FastRTPS or OpenSplice.

Just to make sure, this is not necessarily a problem of Fast-RTPS. I was
giving the link to the issue because it also shows you the steps needed to
enable multicast on the lo device.

With ros2 bouncy, using fastrtps, we are unable to get two computers talking directly without setting a default gateway. Enabling multicast on localhost as @karsten said to try did allow it to at least talk locally, but it did not help with two machines talking to eachother.

We can’t always have a default gateway in our configurations. Any ideas?

This exact problem was fixed with Crystal; see, which was superceded by . I highly recommend upgrading to Crystal; there are only a couple of small API breakages between Bouncy and Crystal, so the upgrade is fairly painless.

Thanks for the reply. I downloaded crystal for arm64 and on my Ubuntu 16.04 machine, I don’t see a complete fix.

Here are my tests:

  • Localhost
    1. With networking completely disabled, a talker and listener work on localhost.
    2. With networking enabled (but no default gateway), a talker and listener do not work on localhost.
    3. With networking enabled (with default gateway set, but nonexistent on the network), a talker and listener work on localhost.
  • Two machines connected directly via ethernet cable
    1. With networking enabled (but no default gateway on either machine), a talker and listener do not work
    2. With networking enabled (default gateway configured on one machine, but not both), a talker and listener do not work
    3. With networking enabled (default gateway configured on both machines, but nonexistent on the network), a talker and listener work

So one thing changed from bouncy, and that’s the results of test 1 on Localhost, previously, that didn’t work either. I read the links you gave and they only claimed to fix the localhost with no network interfaces. I was hopeful that the default gateway problem would go away as well, but looks like it didn’t, unfortunately.

With other dds versions (we use twinoaks coredx principally) these tests do work without a default gateway. Is there anything we can do to make that happen for fastrtps?

I would suggest to open a ticket in the FastRTPS repository.

Thanks @dirk-thomas - I’ve been posting on this one: