WSL documentation suggestion not working for `networkingMode=mirrored` about robotology-superbuild HOT 3 OPEN

We did not investigate in depth the case of networkingMode=mirrored, but for a related use case @S-Dafarra @marcoforleo @dariosortino found that it was useful to set hostname and other related settings in wsl.conf (https://learn.microsoft.com/en-us/windows/wsl/wsl-config#network-settings). In particular to avoid confusion it is useful to ensure that the Windows side and WSL side use different hostname (I am not sure that is the case for networkingMode=mirrored, but it was anyhow worth to mention here in case anyone had similar problems.

from robotology-superbuild.

I would add that probably the mirroring mode affects how the Windows Firewall interacts with WSL

from robotology-superbuild.

We did not investigate in depth the case of networkingMode=mirrored, but for a related use case @S-Dafarra @marcoforleo @dariosortino found that it was useful to set hostname and other related settings in wsl.conf (https://learn.microsoft.com/en-us/windows/wsl/wsl-config#network-settings). In particular to avoid confusion it is useful to ensure that the Windows side and WSL side use different hostname (I am not sure that is the case for networkingMode=mirrored, but it was anyhow worth to mention here in case anyone had similar problems.

Just to add some further info, we noticed the following. Despite running the roscore on Windows with an explicit IP set in the ROS_MASTER_URI, and an explicit ROS_IP, when running rostopic info /some_topic on WSL, the IP of the publishers/subscribers of some_topic was automatically resolved to the hostname. If the hostname is the same between Windows and WSL, then when trying to connect to the same topic, a connection is made using the hostname as the destination address. But then, the hostname is substituted with localhost instead of the actual IP specified with ROS_IP on the Windows side. As a result, we were not able to connect to the topics opened on Windows as localhost on WSL is physically a different address.

When instead specifying a different hostname in WSL (through the parameter hostname in the [network] group of wsl.conf), this problem was solved. In fact, the publisher/subscribers of Windows kept the Windows original hostname in the address, while the publishers/subscribers of WSL use the hostname of WSL. The nice thing is that Windows itself takes care of the routing. In other words, if we do ping original_hostname on the WSL side (with original_hostname the Windows hostname), this gets automatically resolved.

from robotology-superbuild.