HomeKit Discovery + Docker + MACVlan

Installation
1

Sometime over the past 3 or so months, my homekit integration stopped responding. I attempted to delete/readd the integration, and iOS would time out when trying to connect to HomeKit.

I used apk add tcpdump and ran tcpdump -i all -n host 224.0.0.251 and port 5353 to listen for all mdns packets, and then restarted Home Assistant via the server controls page. This led me to discover that all mDNS packets were not flowing out of my MACVlan, but instead out of a bridge interface I configured for Traefik reverse proxying.

Long story short - docker doesn’t have an intentional method for prioritizing networks attached to a container. A solution for me was to rename my MACVlan interface to aaa_macvlan from macvlan. This gave it the highest priority on the docker container, and thus the mDNS packets began flowing out of the correct interface.

Figured I’d write this up to help others who may have issues.

5 Likes
2

Old post I know, but I have the same setup and I’m experiencing the same problems.

I would like to rename my macvlan interface, but how do I do that?

I am using Portainer, but I can also do it through CLI.

Thanks.

3

Old post that never got a further reply, but I figured that others may still well run into this; I know I did.

You don’t change the name of the interface itself per se, rather of the attached docker network; make sure the macvlan network name is alphabetically earlier than the bridge one/s.

If you use compose, there are some gotchas well outlined in Docker container network interface ordering - blog::weyl.io

1 Like
4

I hate to necro but I ran into this issue as well and I would like to add an example for anybody else coming across this post:

services:
  homeassistant:
    (....)
    networks:
      lan:
        ipv4_address: 192.168.0.150
      ingress:

networks:
  ingress:
    external: true
  lan:
    name: a_lan
    driver: macvlan
    driver_opts:
      parent: eno1
    ipam:
      config:
        - subnet: 192.168.0.0/24

Just setting name: a_lan was enough to fix the issue, and in the container ip ro shows that the default route goes to the lan network.