robotology-superbuild
robotology-superbuild copied to clipboard
WSL documentation suggestion not working for `networkingMode=mirrored`
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 .
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.
I would add that probably the mirroring mode affects how the Windows Firewall interacts with WSL
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 sethostname
and other related settings inwsl.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 fornetworkingMode=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.