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
Cannot communicate between nodes when only loopback is up #228
Comments
The interface must support multicast. That is simply a requirement. Have you tried to explicitly enable it (e.g. as described in https://answers.ros.org/question/300370/ros2-talker-cannot-communicate-with-listener/)? Other vendors might offer alternatives (like shared memory) but I don't think that can be expected from every rmw implementation. |
Given that this issue is reported multiple times, should we note this on the ros2 wiki on the tutorials page? Or is there a suitable place for it? |
A note that multicast needs to work for whatever network interface is used and a reference to |
duplicate of ros2/ros2#552 ? |
I went ahead and added https://github.com/ros2/ros2/wiki/Tutorials#troubleshooting to the tutorials page. I am happy to move the section to another better suited place. Let me know. |
@Karsten1987 Thanks for that. I edited that a bit, since the receive needs to be up for the test to work.
I tried the suggestions in that post plus the suggestions in ros2/ros2#552, and I still cannot communicate with only localhost.
Yeah, looks like the same thing. We can close this one if we want to concentrate on the other one, but we still need to figure this use case out. |
You might want to be a bit more specific what "still cannot communicate" means. Does the multicast test work after changing the settings? |
No, that test doesn't work. Both the
Additionally, I tried running |
I was receiving the same error, but found out that I had to enable multicast on
Example output:
|
Hm, OK. I did try that, but I'll give it another try a little later. |
It may be a false positive, that |
I just tried this again on my laptop, which doesn't have the bridge interface, and it seems to have worked there as well, it may be worth trying again @clalancette. |
@mjcarroll and I did some more experimentation here. With all networking down except for lo, I get the error messages as specified in #228 (comment) . If I follow the instructions at https://stackoverflow.com/a/30982079 , then
Both successfully start, and the talker continually publishes messages. But the listener never seems to receive them. More debugging is going to be needed here. @richiprosima Not sure if this is something you have seen/dealt with before in Fast-RTPS, but any thoughts you have may be valuable. |
After some more experimentation I found out that if I setup loopback with https://stackoverflow.com/a/30982079 and use opensplice, things work fine. That seems to point to a problem in Fast-RTPS, but I'll have to investigate more. |
Update: After some poking around, I found that Fast-RTPS wasn't always considering localhost as a valid device to send data on. I've opened up eProsima/Fast-DDS#267 which fixes the problem in my testing (along with the route and lo multicast changes). |
This was fixed by eProsima/Fast-DDS#303, so closing. |
@clalancette I still have this issue, Im wondering if my Fast_DDS library is behind, is there any way to check/update? |
This is a really old issue, so I don't know. I also don't know what setup you are using. I'll suggest opening a question over at https://answers.ros.org with lots of details about your environment and what you are trying to do. |
Bug report
Required Info:
Steps to reproduce issue
colcon build --event-handlers console_cohesion+
source install/setup.bash
ros2 run demo_nodes_cpp talker
in one terminal.ros2 run demo_nodes_cpp listener
in another terminalExpected behavior
The talker and listener can communicate over localhost.
Actual behavior
The talker and listener cannot communicate.
Additional information
When testing this with Opensplice, I saw an error message to the effect that there were no Multicast interfaces available (I can get the full message later). This leads me to expect that DDS/RTPS isn't doing any discovery because there is no multicast available. However, it still feels like communication in localhost should work in this scenario, hence the bug report.
Feature request
Feature description
Implementation considerations
The text was updated successfully, but these errors were encountered: