Using fast-dds across an SSH tunnel [14034]

[mec-irobot]

Is there an already existing issue for this?

• I have searched the existing issues

Expected behavior

I am trying to use fast-dds between two devices that do not have direct IP connectivity, but can be connected via intermediary machines via an ssh tunnel. This is not my whole use case, but for now I am trying to just get HelloWorldExampleTCP to work in such a setup. I have read https://fast-dds.docs.eprosima.com/en/latest/fastdds/transport/tcp/tcp.html#wan-or-internet-communication-over-tcpv4 but it's unclear what IP address to use in this case. I have tried various options, and in no configuration can I get the subscriber to receive the publisher's messages.

My network configuration looks like this:

A <--LAN--> B <--VPN--> C

Machine B can see both A and C - it reaches A over a direct LAN connection, and it reached C via a VPN.

Not that it's relevant, but just to make it bit easier to grasp the reasoning for this: A is a local embedded device I am developing running ROS2, B is my primary laptop, and C is a fast development build machine in my company's office.

A has IP address 172.16.0.99, B has 172.16.0.87 on LAN and 10.70.238.92 on the VPN, and machine C has IP address 10.70.26.32 on the corporate network.

I would expect to be able to do the following and that the subscriber is seeing data:

On B: ssh -R 4444:172.16.0.99:4444 <username>@10.70.26.32
On A: HelloWorldExampleTCP publisher -a 127.0.0.1 -p 4444
On C: HelloWorldExampleTCP subscriber -a 127.0.0.1 -p 4444

The first line sets up a tunnel so that a TCP connection to port 4444 on C will be redirected over the tunnel to port 4444 on A. This setup works for many other protocols I use, but I cannot get it to work for fast-dds.

Current behavior

Currently the subscriber sees no data.

I also see a strange back-connection being attempted from the subscriber. Prior to starting the subscriber, this is what I see for sockets being used on A:

root:~# netstat -nap | grep Hello
tcp        0      0 0.0.0.0:4444            0.0.0.0:*               LISTEN      18222/HelloWorldExa

After I start the subscriber as I described above, I see this on machine A:

root:~# netstat -nap | grep Hello
tcp        0      0 0.0.0.0:4444            0.0.0.0:*               LISTEN      18222/HelloWorldExa
tcp        0      1 172.16.0.99:40691       10.70.26.32:17050       SYN_SENT    18222/HelloWorldExa
tcp        0      0 172.16.0.99:4444        172.16.0.87:61526       ESTABLISHED 18222/HelloWorldExa

On the subscriber machine C I see this:

mcross@mcross-desktop:~$ sudo netstat -nap | grep Hello
tcp        0      0 127.0.0.1:53442         127.0.0.1:4444          ESTABLISHED 17050/./HelloWorldE 

It seems that the subscriber has successfully connected to the publisher, but no data seems to be passing. Also, and this is strange and unexpected, it looks like the publisher is attempting to connect to the IP address of the subscriber, using a port number that is the PID of the subscriber process. The subscriber does not have any such port open in a listening fashion.

Steps to reproduce

See expected behavior for reproduction steps.

I have tried using the loopback address 127.0.0.1 and the IP address of C 10.70.26.32 with the same results. The subscriber should be able to connect to port 4444 at either of those addresses to reach the publisher.

Fast DDS version/commit

2.3.3

Platform/Architecture

Other. Please specify in Additional context section.

Transport layer

TCPv4

Additional context

Machine A is a 32-bit ARM running embedded Linux.

Probably not relevant, but Machine B is a Macbook Pro running MacOS 11.6.4. It is not running any fast-dds software and is only providing a tunnel to connect A and C indirectly.

Machine C is an x86_64 Linux desktop running Ubuntu 18.04.

My eventual goal is to be able to interact with a product running ROS2 on my local network (machine A) by running ROS2 commands on my development machine (machine C).

XML configuration file

No response

Relevant log output

No response

Network traffic capture

No response

[JLBuenoLopez]

This is not a Fast DDS malfunction but a user case support. I am going to move the issue to the proper forum according to the CONTRIBUTING guidelines

[mec-irobot]

Some members of the team reached out to me and informed me about https://github.com/eProsima/DDS-Router which is designed to support use cases like this. From a quick read it looks very likely to handle my situation; I will try it out and let you know.