I run an Ubuntu 22.04 Docker container with ROS2 installed, on a Windows 11 host. I am unable to perform a ros2 multicast send/receive operation successfully from a the Docker container to another natively installed Ubuntu machine connected to the same network via direct LAN connection to the Windows host. (Please note that this is not about ROS2 - Robot Operating System - but just a use-case for me which is failing. However, to clarify the context, ROS2 multicast send command sends one UDP multicast datagram which is received by the machines running ROS2 multicast receive.)
Interestingly, the ros2 multicast works if both (sender and receiver) are Ubuntu PCs. Also, multicast works if ROS2 is natively installed in Windows PC without Docker (this is an evidence that Docker on Windows is the root cause). However, for my need, I require to run ROS2 multicast in Docker on a Windows host.
On investigating further and comparing the Docker behavior between Ubuntu PC and Windows PC, when running ‘ifconfig’, the ip addresses present in Docker on an Ubuntu host takes the same ip addresses of the host machine (on running Docker with --net=host) which is as desired by my requirement, however, the ip addresses present in Docker (same image) on a Windows host takes different ip addresses than that of the Windows host. I am unable to figure out why (perhaps because it is managed by WSL?). Is it possible to make the behavior same as when Docker runs on an Ubuntu host ?
I have exactly the same problem (also trying to do ros2-on-docker-windows to ros2-on-linux communication), thanks for describing it so accurately. Any solution yet?
BTW did you find any easy way to install ros2 on windows? I see only very elaborate instructions.
The image is not responsible for the network configuration of the container. The problem originates in something else.
Docker Desktop simply does not support to use the host network the same way it does with docker-ce on Linux. Docker Desktop always runs in a utility vm, in case of Windows it’s the utility vm that runs the docker backend wsl2 distribution. When a container uses the host network, it is the host network of the utility vm, (which uses a private network subnet range) and not the host network of the Windows host. Devices from your lan are effectively not in the same lan as the wsl2 distribution.
Though, it should work if all those components run in containers, and all the containers are attached to the same container network.
So effectively docker desktop does not support --net=host? That is a bummer!
“it should work if all those components run in containers, and all the containers are attached to the same container network.”
You mean I should run my linux-ce containers in that same network as the docker desktop uses? Can I predict what that network will be? And how do I run my linux-ce containers in that network?
Sorry for not being more precise. Of course, all containers must run on Docker Desktop to achieve this. Same network as in docker network create my-container-network. All containers attached to such a network would share the same subnet and same collision domain within the utility vm.
docker-ce only exists for Linux. Your use case will only work on Windows, if you run docker-ce in a Linux vm that uses a network interface connected to your lan. It will not work if the network interface is NATed (like it is with WSL2, or default settings of VirtualBox).
Note: When Hyper-V is installed, virtualization solutions like VirtualBox or VMWare workstation will run painfully slow as they will run the vms in Hyper-V compatibility mode. The same is true, if the VM-Platform feature is enabled (required by WSL2), as it uses a slim Hyper-V layer, even though Hyper-V itself is not installed.
Personally, I would stay away from a vm solution, and would try to run every component as container in Docker Desktop. Of course the containers need to be in the same container network.
The steps mentioned here are elaborate, I agree, but they are not so much trouble if you take it step by step. You may face some issues if you are in a restricted network like in office, else its quite easy.
The above mentioned thread is remotely connected to the topic here - this one talks about achieving a successful communication between ros2 in docker container and docker installed on Windows host. If there is anyway we can forward this to the static ip of the other system connected to the network, then there is some hope I guess - not an expert, but thinking of a workaround.
The issue seems the way windows virtualizes its network connection: it presents a different IP address to the virtualized part.
What works for me now:
in windows, I run VMware player, running a Ubuntu image
An extra TP-Link USB ethernet adapter
VMWare configured to bridge this network adapter to the image (not using NAT)
now the Ubuntu has an IP address compatible with my other (Linux) machines on the (wired) network
I guess I could run ros2 directly on the VM-ed Ubuntu, but I want to use dockers everywhere, so I installed docker and built the same container I use on the other Linux boxes, and that works.
I might try using ros2 directly on windows some day, but for now this clumsy workaround is enough.