Skip to content
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

ros_visualizer example throws errors when using IPv6 and OS dependent behavior #205

Open
JohannesProgrammiert opened this issue Jun 21, 2022 · 5 comments

Comments

@JohannesProgrammiert
Copy link

Great project, I consider using this at my company.
However, at one of my PCs I only have IPv6 available. When I run the ros_visualizer example with

cargo run --example ros_visualizer

About once a second I get

WARN rustdds::network::udp_sender - send_to_locator - send_to [<ipv6>]:<port> : 0s {code: 97, kind Uncategorized, message: "Address family not supported by protocol"}

On Manjaro (where the behavior from above was observed), the shapes_demo example works, also with the RTI Connext demo but not with OpenDDS. The OpenDDS demo does not seem to interact with any other interop example other than itself.

On Debian, rustDDS (and openDDS) do not work at all. There is simply no discovery and only HEARTBEAT messages are sent. Any ideas?

Another question, does this library support shared memory for IPC?

@jhelovuo
Copy link
Owner

IPv6 support has not been in the scope of RustDDS. If it works at all, it is only by accident. We have no immediate plans to add IPv6 support, but are willing to merge code if anyone submits a PR.

I have no idea why nothing works on Debian. We do most of our testing on Ubuntu. Does multicast work on your Debian box? You can try to find out what the problem is by configuring the root logging level to "info" (or greater) and then running the shapes demo. You should be able to compare the log outputs to the logging calls in the source code.

There is no shared memory support. RustDDS (as it is now) communicates always over UDP. AFAIK the shared memory protocols that some DDS libraries implement are not standardised and they only talk to the library from the same vendor. If some shared-memory protocol spec were openly available, we could consider implementing that, to be compatible with at least someone.

@JohannesProgrammiert
Copy link
Author

Thanks for the quick reply.

About IPv6

I started to mess around with that, if I get it to work I will make a PR. In the time being I suggest to not even try to connect to IPv6 interfaces and throw an error like "IPv6 not supported" - because now some features like socket creation work but some (e.g. multicast) don't. A developer then has to dig into the code of this library do understand the problem.

About Shared Memory

eProsima's FastDDS implementation is open source and uses shared memory. As far as I understood the shared memory feature is really only to improve internal IPC performance (?). So if you have different DDS on the same system, you'd still have to use UDP, no need to worry about compatibility.

About ROS2 and no colcon

In the end I want to have ROS2 on a A53 with openembedded linux (aarch64). With Rust, I wouldn't have to mess with colcon/catkin which only supports Ubuntu natively. Pure Rust cross compiling is so much easier. I am grateful for any hints you'd have on this.
Unfortunately neither the DDS example nor the ROS2 turlesim example work for me on Debian. They compile just fine but no communication is established (not even RustDDS to RustDDS).

@jhelovuo
Copy link
Owner

The suggestion of disabling IPv6 for now is a good one. Can you make on PR on that?

Did you check all the basic things on Debian, such as firewalling? Does ping work to multicast addresses, e.g. 224.0.0.1 ?

@flxo
Copy link

flxo commented Mar 13, 2024

Hello,

are there any updates regarding IPv6 on the roadmap? IPv6 is marked unimplemented here and here.

Thanks!

@jhelovuo
Copy link
Owner

are there any updates regarding IPv6 on the roadmap? IPv6 is marked unimplemented here and here.

Not really. It is still not on our internal roadmap. If there were some commercial interest, then that could change, but currently no-one else seems to be interested.

Pull Requests are still welcome.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants