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

Binding to INADDR_ANY even when configured for loopback triggers the Windows firewall #2090

Open
aurelienrb opened this issue Sep 12, 2024 · 1 comment

Comments

@aurelienrb
Copy link

Hello,

We are using Cyclone DDS via ROS 2 on Windows. We use it for localhost only by defining ROS_LOCALHOST_ONLY.

We used to work with another DDS and doing so worked well to not trigger the firewall popup from Windows (to configure Inbound rules).

image

Switching to Cyclone DDS has made our life simpler on various topics, the only drawback so far is our incapacity to start our applications without triggering the Windows firewall. Working with ROS_LOCALHOST_ONLY and Cyclone DDS config is not enough.

I had a quick look in the code and did the following test:

  • I searched for all the occurrences of INADDR_ANY and replaced them with INADDR_LOOPBACK
  • By doing this, the firewall popup is no longer displayed but... ddsperf can no longer find the other instance 😅
  • I tried with both UDP4 and UDP6 and got the same results

It seems reception sockets need to listen on ANY to work properly. Have you any idea if it is feasible to make them work by binding to localhost only? Or any other strategy to not trigger the firewall popup?

@eboasson
Copy link
Contributor

Switch to macOS? 🤔 Ah no, bummer, ROS 2 doesn't support macOS anymore ... Joking aside, this is the sort detail where all platforms are completely different. On macOS, selecting "loopback" in Cyclone is sufficient to stop the firewall from interfering all the time ...

It seems reception sockets need to listen on ANY to work properly.

The thing with the address you bind a socket to is that it then only accepts packets destined for that specific address. So binding to 127.0.0.1 will prevent it from receiving multicasts directed to 239.255.0.1 even when you join that group using IP_ADD_MEMBERSHIP (at least that is what I remember from when I was trying some things). I suppose that is why it doesn't work. It could also be that it uses the Ethernet address, say 192.168.1.1, and then binding to 127.0.0.1 will also prevent it from working.

Looking at the code, I suspect that changing the bind_to_any to false at

bind_to_any = true;
(master) or
bind_to_any = true;
(releases/0.10.x) might well do the trick: that binds it to the address of the (first, if there are multiple) interface that Cyclone uses.

It could also be that binding the multicast sockets to INADDR_ANY is enough to trigger the firewall. You might get lucky there, though: those won't created with multicast disabled and I think ROS 2 configures it by default to avoid multicast.

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

2 participants