Having read multiple topics that relate to UDP traffic, I have not found a solutions for my (Wake-on-LAN) broadcast issue.
Inside a container I want to send WoL magic packets (UDP broadcasts) to devices on an external network (the network subnet that the Docker host is also part of). Obviously, when using network_mode: host it works, but using either the default Docker bridge or creating a bridge of my own, the broadcast doesn’t get forwarded from the Docker network to to host network.
From a network perspective that makes sense, since it is a different subnet after all.
So, basically my question is: how can I forward UDP broadcast messages from a Docker bridge network to the host local network?
I have the same question. I’ve setup Home Assistant docker on my Openmediavault server. When I run it in host mode I can send WOL command to my LG WebOS tv with no issues. However I’m struggling to get this to work on my custom docker bridge network (I need the Home Assistant docker on this bridge, host mode isn’t an option)
Also hoping there is a solution to this. I have apps that need to discover network devices using UDP broadcast but the app containers are in their own Docker network, so using hostmode is not possible.
Broadcast/Multicasts can not leave the boundaries of a bridge network.
You will either need to use --network=host or MACVLAN (hint: the forum search should provide plenty working examples on how it’s used and what limitations apply)
Is there a solution available for this at least now that docker has added host networking as an experimental feature from 4.29.1,
I have tried the above but the ip of the container is still not same as the host instead it gets an ip from the docker default subnet 192.168.65.0/24, therefore making it inaccessible from the host network,
I dont want to go with a WSL docker installation because i intend to publish the image to dockerhub and allow the user to use the image without any prerequistes,
if you guys have found a solution or workaround that would be much appreciated.
I have a work-around solution for the WOL case, and a similar analogous solution could be put together for the other UDP cases as well.
To summarize: I created a very basic service running in a container on the host network that listens for network connections on a particular port, expecting to receive the MAC address of a machine to wake. Then, any container running on the same machine on the bridge network can connect to that service and request that it wake a machine by MAC address. This let’s me, for instance, run Home Assistant on the bridge network while still issuing WOL requests.
Hey Dan, Thanks
I also found a simple similar work around for the udp case , my use case required a broadcast to the host network which is blocked by the docker bridge network, the network_mode :host on most linux machines except for mac and other systems where docker runs as a vm( windows).
What i did was remove the broadcast itself from the container , i attached a volume to the container ( a simple text file) and my container would write my broadcast messages to this file i had a script running on the host (powershell/bash) that would monitor changes from the attached file in volume and then broadcast it on the host network, in case of windows i used the the powershell inbuilt object (udpclient ) to broadcast messages however i couldnt find a similar alternative for mac which is why i had to install an external package (nmap) and used ncat in my broadcast script .
Creating a service on the host to receive messages didnt work in my case because both the container and the host service would be listening on the same port which might result in race conditions and by default port sharing isnt allowed in mac.
Any input to better my approach is much appreciated.
I’m not really familiar with Docker on Mac or Windows, so unfortunately I don’t have much to offer on the volume-based approach. Sounds pretty clever though… Hopefully someone else can weigh in.
As for the service running on the host approach (I’m assuming not in a container), why does it need to run on the same port as your bridge-mode container service? Maybe I’m misunderstanding the setup.