Homebridge, Docker, and Wake-on-Lan

Continuing on from the previous post in this series, I have been doing a bit more investigation into solving the issues I was having with the homebridge-samsung-tizen plugin. All the features of the plugin were functioning as expected, with the exception of powering on the TV. This depends on Wake-on-Lan, which by default only works in the same network subnet, something which is not true unless the docker container is ran in host network mode. I have now found how to configure this to work.

Listening for Broadcast Traffic

For the purposes of investigating this I did not want to be turning my TV on and off repeatedly, so I used tcpdump to inspect the network traffic that used the ports that can be used for Wake-on-Lan packets.

In this example I had attached tcpdump to the interface the docker container was in directly, just to verify the approach worked.

[email protected]ent:~$ sudo tcpdump -i br-b0695d90ec6a '(udp and port 7) or (udp and port 9)'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br-b0695d90ec6a, link-type EN10MB (Ethernet), capture size 262144 bytes
14:34:21.033509 IP 172.29.0.6.35290 > 172.29.255.255.discard: UDP, length 102
14:34:21.134265 IP 172.29.0.6.35290 > 172.29.255.255.discard: UDP, length 102
14:34:21.234811 IP 172.29.0.6.35290 > 172.29.255.255.discard: UDP, length 102

So broadcasting to the docker network subnet works fine, we just need to establish how to cross the subnet boundary.

For more isolated testing, I created a basic Docker container which used the python awake library for sending Wake-on-Lan packets.

FROM python:3-alpine  
RUN pip3 install awake

ENTRYPOINT ["awake"]

Once built (I called it “wol”), this takes in a few arguments when ran:

  • the broadcast IP address of the network to send the packet to
  • the mac address of the device to be woken
[email protected]:~ $ docker run --rm --network=core_traefik-backend wol -b 192.168.0.255 aa:bb:cc:dd:ee:ff
Sending magic packet to 192.168.0.255 with broadcast 192.168.0.255 MAC aa:bb:cc:dd:ee:ff port 9

Allowing Broadcast Traffic to be Re-Broadcast

The controls which prevent a broadcast packet received on one network interface being sent to another are part of the linux kernel. In our scenario one of these network interfaces is a docker bridge network as opposed to an external network, but the same controls apply.

These settings require to be set:

  • net.ipv4.icmp_echo_ignore_broadcasts=0
  • net.ipv4.conf.all.bc_forwarding=1
  • net.ipv4.conf.${interface}.bc_forwarding=1

This last setting requires “${interface}” to be replaced with the name of the network interface which relates to the docker network. Even though the setting before it is for “all”, it does not seem to work on its own and the specific interface setting also isn’t enough on its own.

I have put together a script configure_docker_networks_for_wol.sh, which for a specific docker network, configures these settings. These are configured using both “sysctl -w” and as a configuration file in “/etc/sysctl.d/” so they will be applied instantly and survive a reboot.

With this combination of settings configured, I can now use the test containing using awake and see the packet received by another device on the target network when using tcpdump.

[email protected]:~ $ docker run --rm --network=core_traefik-backend wol -b 192.168.0.255 aa:bb:cc:dd:ee:ff
Sending magic packet to 192.168.0.255 with broadcast 192.168.0.255 MAC aa:bb:cc:dd:ee:ff port 9


[email protected]:~ $ sudo tcpdump -i en0 '(udp and port 9)'
listening on en0, link-type EN10MB (Ethernet), capture size 262144 bytes
22:36:25.537328 IP devpi1.lan.46235 > 192.168.0.255.discard: UDP, length 102

Homebridge Plugin Configuration

The configuration for the homebridge-samsung-tizen plugin allows for an extra wol element to define the source IP for the Wake-on-Lan packet and the destination.

"platforms": [
    {
        "platform": "SamsungTizen",
        "devices": [
            {
                "name": "TV",
                "ip": "192.168.0.30",
                "mac": "AB:CD:EF:12:34:56",
                "wol": {
                    "from": "172.32.0.200",
                    "address": "192.168.0.255"
                }
            }
        ]
    }
]

This is passed directly to the wakeonlan library. If the from attribute is not set then the address will be ignored and the library will perform its default behaviour of calculating the broadcast address for each network interface. We need to change this to the broadcast address of the subnet the destination device for the Wake-on-Lan packet is in.

This from address has to be a valid IP address for the interface that is connected to our docker container, unfortunately this means the container needs to have a fixed IP address assigned to it.

Setting a Fixed IP Address for a Docker Container

In my use case, I have a number of containers linked to a docker network which traefik acts as a reverse proxy in front of. This is created as an external network that different docker-compose files reference. Step one in assigning a container a fixed IP address is to set a fixed subnet on this network.

docker network create --driver bridge --subnet=172.32.0.0/16 traefik-backend

As part of the docker-compose configuration for the container we can then set an IP address in the subnet defined for the network.

homebridge:
    image: oznu/homebridge:no-avahi
    restart: unless-stopped

    networks:
      traefik-backend:
        # Need a fixed IP here so we can use WOL from the Samsung Tizen plugin
        # without using host networking
        ipv4_address: 172.32.0.200

Conclusion

So we have now managed to successfully send Wake-on-Lan packets from within a docker container without needing to set the container in host network mode. However, this did require the container to be assigned a fixed IP address which does negate some of the benefits of being able to run software in a container like this.

As I am going through this journey of adding more smart devices, I do seem to hit more issues with running Homebridge in a container. The next issue revolves around getting a bluetooth LE device working.