13

I have a docker container running a python uwsgi app. The app sends a wake on lan broadcast packet to wake a pc in the local network.

It works fine without the use of docker (normal uwsgi app directly on the server), but with docker it won't work.

I exposed port 9/udp and bound it port 9 of the host system.

What am I missing here? Or with other words, how can I send a wake on lan command from a docker container to the outside network?

jazz
  • 349
  • 3
  • 13
  • 2
    Does it work with `--net=host`? – Adrian Mouat Oct 13 '15 at 11:36
  • @AdrianMouat - that will work. So I cannot use privileged ports in the default bridged mode? – jazz Oct 13 '15 at 11:50
  • It will be to do with the bridged network, but not privileged ports. I suspect it's to do with broadcast, but I don't know anything about your "magic packet", so I can't say anything more. – Adrian Mouat Oct 13 '15 at 12:55
  • @AdrianMouat it is a wake on lan broadcast packet - commonly named magic packet – jazz Oct 13 '15 at 13:43
  • Yeah, so I think you need to look into the details of how the Docker bridge is implemented to get that to work. You have to remember that containers are effectively on their own LAN, but maybe you just need to twiddle the IP tables settings. Otherwise use `--net=host` to use the host's LAN. – Adrian Mouat Oct 14 '15 at 08:29
  • FYI to anyone user docker on a mac, `--net=host` does not work on a mac and silently will not work as expected. https://github.com/docker/for-mac/issues/2716 – Greg Hilston Jan 23 '20 at 21:59

2 Answers2

3

It seems that UDP broadcast from docker isn't being routed properly (possibly only broadcasted in the container itself, not on the host).

You can't send UDP WoL messages directly, as the device you're trying to control is 'offline' it doesn't show up in your router's ARP table and thus the direct message can't be delivered.

You may try setting (CLI) --network host or (compose) network_mode: host.

If you feel this may compromise security (since your container's/host network are more directly 'connected') or otherwise interferes with your container; you may create/use a separated 'WoL' container.

Paul
  • 675
  • 1
  • 5
  • 26
0

There's a mix of partially correct answers in the above comments. You do want to send your packet to port 9 on the host but:

  • It's the NIC that listens on port 9, not the OS. In other words, you need to configure the system's NIC to listen for magic packets. When the NIC receives the packet (on port 9, containing its own MAC address), the NIC will start the system by sending a signal via the PCI bus.
  • You don't need need to set up a service to listen on port 9. That's built into most NICs instead.
  • The "sender" of the magic packet needs to be on the same network segment as the target. This means that your Docker container will need to be built with "--network host". This makes your host machine the sender (even though it's coming from a Docker container) and the Docker host must be in the same network segment as the target (i.e., their broadcast addresses match).
  • There's no need to map port 9 between the container and the host. That said, you may run into issues with "--network host" and accessing the app if it tries to use a port that another service is already using. Experimentation is needed. You might need to configure the web server to listen on a different port.
joat
  • 129
  • 6
  • Oh, and, of course, using "--network host" is considered a security issue. It's fine for a home lab but you'll probably not want to use it in a production environment. – joat Nov 20 '22 at 16:20