# Dynamically handling network interfaces

**URL:** <https://discourse.openrobotics.org/t/dynamically-handling-network-interfaces/22068>\
**Category:** ROS General\
**Created:** [August 27, 2021, 5:52pm UTC](https://discourse.openrobotics.org/t/dynamically-handling-network-interfaces/22068 "2021-08-27T17:52:13Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![alsora](https://sea2.discourse-cdn.com/flex022/user_avatar/discourse.openrobotics.org/alsora/32/2514_2.png) [@alsora](https://discourse.openrobotics.org/u/alsora)\
**Post date:** [August 27, 2021, 5:52pm UTC](https://discourse.openrobotics.org/t/dynamically-handling-network-interfaces/22068/1 "2021-08-27T17:52:13Z")

</div>

Hi, I would like to present here a discussion originated in the ROS 2 Middleware Working Group.

While developing a simple ROS 2 robot setup, we noticed a few strange behaviors related to how ROS 2 and the underlying RMW implementation handled the available network interfaces.

Considering ROS 2 Galactic, we have that only the network interfaces that are present at startup of your ROS 2 application will be used for communication by the RMW.

This happens with both major RMW implementations fast-dds and cyclonedds.

Let’s examine some situations where this is a problem.

- You have a service that starts your ROS 2 application as soon as the system boots up. This may result in one or more network interfaces to not be ready yet: they will be ignored by ROS 2.
- You have a running ROS 2 application and then you decide to connect a new interface for debugging purposes (e.g. via usb). Your application will not send any message there.

Currently, the only solution in both cases consists in the user having to fully restart the ROS 2 application whenever it’s necessary to start using a new interface that just came up.  
This may be ok-ish in the first case, but it’s definitely not possible in the second one! You would lose all the state of your robot!

What do you think of these situations?  
They can definitely be handled at the system level, but it would be non trivial, requiring custom solutions depending on the architecture and a good amount of Linux knowledge.  
I think that these problems are relevant enough that they need an easily integrated solution at the application level.

Possibilities from a user perspective could be the following:

- Provide a “use all interfaces” default RMW mode. This mode will automatically use all available interfaces at startup and it will monitor for the creation of new ones. When a new interface is created, it will be used.
- Provide RMW reset APIs. This could be used by the user to send a signal to restart the RMW since a new interface is now available. Restarting the RMW would not require to restart the application.

FYI @wjwwood @Jaime_Martin_Losa @MiguelCompany @joespeed@eboasson @asorbini_rti

---

<div class="post-metadata">

**Author:** ![tomoyafujita](https://sea2.discourse-cdn.com/flex022/user_avatar/discourse.openrobotics.org/tomoyafujita/32/6097_2.png) [@tomoyafujita](https://discourse.openrobotics.org/u/tomoyafujita)\
**Post date:** [January 14, 2022, 11:04pm UTC](https://discourse.openrobotics.org/t/dynamically-handling-network-interfaces/22068/2 "2022-01-14T23:04:19Z")

</div>

@alsora

I know this one is kinda old thread, but I am curious that if you find the reasonable work-around or method to address this situation.

thanks,  
Tomoya

---

<div class="post-metadata">

**Author:** ![alsora](https://sea2.discourse-cdn.com/flex022/user_avatar/discourse.openrobotics.org/alsora/32/2514_2.png) [@alsora](https://discourse.openrobotics.org/u/alsora)\
**Post date:** [January 15, 2022, 6:51am UTC](https://discourse.openrobotics.org/t/dynamically-handling-network-interfaces/22068/3 "2022-01-15T06:51:29Z")

</div>

No progress on this.  
However I saw that the new Fastdds 2.5.0 mentions that it allows detections of new networks at runtime

> **[Version 3.3.0 (latest) - 3.3.0](https://fast-dds.docs.eprosima.com/en/latest/notes/notes.html)**

Maybe @MiguelCompany can provide more details on it?

---

<div class="post-metadata">

**Author:** ![tomoyafujita](https://sea2.discourse-cdn.com/flex022/user_avatar/discourse.openrobotics.org/tomoyafujita/32/6097_2.png) [@tomoyafujita](https://discourse.openrobotics.org/u/tomoyafujita)\
**Post date:** [January 15, 2022, 5:31pm UTC](https://discourse.openrobotics.org/t/dynamically-handling-network-interfaces/22068/4 "2022-01-15T17:31:45Z")

</div>

@alsora  
CC: @MiguelCompany

thank you so much for introducing [15.11. Dynamic network interfaces - 3.3.0](https://fast-dds.docs.eprosima.com/en/latest/fastdds/use_cases/dynamic_network_interfaces/dynamic_network_interfaces.html#dynamic-network-interfaces), which looks good.

the use cases that we have is the following.

 ![image](https://us1.discourse-cdn.com/flex022/uploads/ros/original/2X/3/3203894495ee09bbca9739d1e65c16695299f83c.png)

- the above situations are so likely to happen **after application started.**
- cannot expect the help from user like smartphone, it should be able to self-healing function.

I was considering a few ideas,

- use linux interfaces. (man 7 netlink NETLINK\_ROUTE) application can listen on socket to receive network interface create/delete/up/down events.
- [NetworkManager](https://wiki.gnome.org/Projects/NetworkManager) DBus event
- App service depends on [systemd device units](https://www.freedesktop.org/software/systemd/man/systemd.device.html)

ROS 2 / DDS ability would be really nice, so that we do not need reset the whole application.