WSL documentation suggestion not working for networkingMode=mirrored

[traversaro]

Recent WSL provides a networkingMode=mirrored mode (see https://learn.microsoft.com/en-us/windows/wsl/networking#mirrored-mode-networking). I was quite entusiastic when I discovered it, as with the ROS1 communication work out of the box between Windows and Linux. However, for some reason yarpserver communication between Linux and Windows does not work when using it, even using the documentation in https://github.com/robotology/robotology-superbuild?tab=readme-ov-file#connect-to-a-yarp-server-on-a-windows-host-on-wsl .

[traversaro]

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.

[dariosortino]

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

[S-Dafarra]

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.