Feature Request: Provide CLI to retrieve IP address a node runs on

I recently was in the situation, that two nodes were publishing on the same topic, and I thought it might have been helpful if there was a command to find the IP address of each node in the system.

To reproduce you can run something like the following in two shells:

docker run --rm -it osrf/ros:humble-desktop ros2 run demo_nodes_cpp talker --ros-args --remap __node:=talker_1
docker run --rm -it osrf/ros:humble-desktop ros2 run demo_nodes_cpp talker --ros-args --remap __node:=talker_2

Then, we can see two nodes with different GID publish on the same topic:

$ ros2 topic info -v /chatter
Type: std_msgs/msg/String

Publisher count: 2

Node name: talker_2
Node namespace: /
Topic type: std_msgs/msg/String
Endpoint type: PUBLISHER
GID: 01.0f.70.b7.2d.00.a6.f6.01.00.00.00.00.00.12.03.00.00.00.00.00.00.00.00
QoS profile:
  Reliability: RELIABLE
  History (Depth): UNKNOWN
  Durability: VOLATILE
  Lifespan: Infinite
  Deadline: Infinite
  Liveliness: AUTOMATIC
  Liveliness lease duration: Infinite

Node name: talker_1
Node namespace: /
Topic type: std_msgs/msg/String
Endpoint type: PUBLISHER
GID: 01.0f.eb.7d.2c.00.3b.5a.01.00.00.00.00.00.12.03.00.00.00.00.00.00.00.00
QoS profile:
  Reliability: RELIABLE
  History (Depth): UNKNOWN
  Durability: VOLATILE
  Lifespan: Infinite
  Deadline: Infinite
  Liveliness: AUTOMATIC
  Liveliness lease duration: Infinite

Subscription count: 0

We can query info about the nodes, which isn’t really helpful to find the host the node runs on though (did I miss a verbose option?).

$ ros2 node info /talker_1
/talker_1
  Subscribers:
    /parameter_events: rcl_interfaces/msg/ParameterEvent
  Publishers:
    /chatter: std_msgs/msg/String
    /parameter_events: rcl_interfaces/msg/ParameterEvent
    /rosout: rcl_interfaces/msg/Log
  Service Servers:
    /talker_1/describe_parameters: rcl_interfaces/srv/DescribeParameters
    /talker_1/get_parameter_types: rcl_interfaces/srv/GetParameterTypes
    /talker_1/get_parameters: rcl_interfaces/srv/GetParameters
    /talker_1/list_parameters: rcl_interfaces/srv/ListParameters
    /talker_1/set_parameters: rcl_interfaces/srv/SetParameters
    /talker_1/set_parameters_atomically: rcl_interfaces/srv/SetParametersAtomically
  Service Clients:

  Action Servers:

  Action Clients:

We can find the IP addresses participating in the system by examining the discovery messages, which is helpful, but only tells part of the story:

$ sudo tcpdump -i any udp port 7400
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes
09:41:55.548303 IP 172.17.0.3.47847 > 239.255.0.1.7400: UDP, length 308
09:41:55.548323 IP 172.17.0.3.47847 > 239.255.0.1.7400: UDP, length 308
09:41:55.548327 IP 172.17.0.3.47847 > 239.255.0.1.7400: UDP, length 308
09:41:57.362414 IP 172.17.0.2.35195 > 239.255.0.1.7400: UDP, length 308
09:41:57.362447 IP 172.17.0.2.35195 > 239.255.0.1.7400: UDP, length 308
09:41:57.362454 IP 172.17.0.2.35195 > 239.255.0.1.7400: UDP, length 308
09:41:58.548465 IP 172.17.0.3.47847 > 239.255.0.1.7400: UDP, length 308
09:41:58.548491 IP 172.17.0.3.47847 > 239.255.0.1.7400: UDP, length 308
09:41:58.548504 IP 172.17.0.3.47847 > 239.255.0.1.7400: UDP, length 308
09:42:00.362493 IP 172.17.0.2.35195 > 239.255.0.1.7400: UDP, length 308
09:42:00.362517 IP 172.17.0.2.35195 > 239.255.0.1.7400: UDP, length 308
09:42:00.362522 IP 172.17.0.2.35195 > 239.255.0.1.7400: UDP, length 308
^C
12 packets captured
16 packets received by filter
0 packets dropped by kernel

Is there a way to query that info already (from the DDS maybe)? If not, I’d like to feature request it for some kind of ros2 node info --verbose output (maybe with a query by GID in case node names collide). I already skimmed through ros2cli but I didn’t find any obvious approach to add this myself.

Any suggestions, remarks or opinions regarding this feature?

For reference:

1 Like

I’d suggest you build this using a ROS 2 (actually, DDS/RTPS) networking package dissector. You’ll need to build a bit of logic since the dissector doesn’t understand about ROS 2 abstractions but if you know the Node name it should be fairly easy:

See this walkthrough for a small tutorial on how to use the dissector. The RTPS dissector has been integrated upstream in scapy. You can easily wrap these Python pieces as yet another ROS 2 CLI tool that lives independently (e.g. see ros2acceleration) and make it available for others to use.

Resources for you:

If you find any issues with the dissector please contribute back.

3 Likes

Perhaps another solution to your problem, as far as I understand, is to make a custom message which includes a “sender” field, where each node is responsible for filling in. That would also make it nicer to test your packages.

I’ve trying to push the ROS 2 TSC to work on ROS ergonomics, which would include things like improvements to the ROS 2 CLI.

Would you be so kind as to file this as a feature request on the correct repository? I can’t promise it will be addressed, but I want to get these sorts of usability concerns noted. I would really like to find resources to make these sorts of improvements happen in the near future.

2 Likes

Sure! Do you mean the ros2cli repo, or another one?

Thanks for the input!

I had another look at this page about examining the network traffic. I found that there in the example the node name seems to be contained in plain text in the RTPS section. With my configuration this doesn’t seem to be the case actually:

10:44:48.915774 IP 172.17.0.2.35136 > 239.255.0.1.7400: UDP, length 308
    0x0000:  4500 0150 c406 4000 0111 1883 ac11 0002  E..P..@.........
    0x0010:  efff 0001 8940 1ce8 013c 9d61 5254 5053  .....@...<.aRTPS
    0x0020:  0203 010f 010f eb7d 2c00 bb7e 0100 0000  .......},..~....
    0x0030:  0901 0800 8a77 8863 09a7 1c6a 1505 1001  .....w.c...j....
    0x0040:  0000 1000 0001 00c7 0001 00c2 0000 0000  ................
    0x0050:  0100 0000 0003 0000 1500 0400 0203 0000  ................
    0x0060:  1600 0400 010f 0000 5000 1000 010f eb7d  ........P......}
    0x0070:  2c00 bb7e 0100 0000 0000 01c1 3200 1800  ,..~........2...
    0x0080:  0100 0000 f41c 0000 0000 0000 0000 0000  ................
    0x0090:  0000 0000 ac11 0002 3200 1800 1000 0000  ........2.......
    0x00a0:  f41c 0000 55eb 7d00 0000 0000 0000 0000  ....U.}.........
    0x00b0:  0000 0000 3100 1800 0100 0000 f51c 0000  ....1...........
    0x00c0:  0000 0000 0000 0000 0000 0000 ac11 0002  ................
    0x00d0:  3100 1800 1000 0000 f51c 0000 55eb 7d00  1...........U.}.
    0x00e0:  0000 0000 0000 0000 0000 0000 0200 0800  ................
    0x00f0:  1400 0000 0000 0000 5800 0400 3f0c 3f0c  ........X...?.?.
    0x0100:  6200 0800 0200 0000 2f00 0000 2c00 1000  b......./...,...
    0x0110:  0b00 0000 656e 636c 6176 653d 2f3b 0000  ....enclave=/;..
    0x0120:  5900 2800 0100 0000 1100 0000 5041 5254  Y.(.........PART
    0x0130:  4943 4950 414e 545f 5459 5045 0000 0000  ICIPANT_TYPE....
    0x0140:  0700 0000 5349 4d50 4c45 0000 0100 0000  ....SIMPLE......

Do you have any hints where I could look up the actual protocol used there for me to decode the info?

ROS2CLI repo would work great!

Hi @moooeeeep

You can check this information on eProsima ROS 2 Monitor tool. It has many functionalities available and among them the one you are asking for. From the node information panel you can see the host, user and process running each of your ROS 2 nodes.

This is because the latest versions of Fast DDS already implement this functionality and report this information, but for now there is no way to extract it with the existing RMW API.

In order to see this information you have several options:

  1. Upgrade to the latest version of Fast DDS and rmw_fastrtps.
  2. Enable statistics in Fast DDS by recompiling this package from sources with the CMake option FASTDDS_STATISTICS=ON.
  3. Use ROS 2 from Vulcanexus which comes with the latest version of Fast DDS, installed, statistics enabled and the Monitor ready to use.

Thanks for mentioning this! I noticed that GUI in the other recent post (just after preparing this request), and wanted to try it out some time too. Seems really useful.

I just think, such a feature should be available via a CLI tool too.

1 Like

FWIW: I created a feature request here: Feature Request: Provide CLI to retrieve IP address a node runs on · Issue #781 · ros2/ros2cli · GitHub

1 Like