Yeah the Thread stack is only IPv6. It may be the case that the TBR is sending out device discovery on an IPv4 address (as well as IPv6), but I would think in general it should not be sending on IPv4.

Yeah I would have thought you would have this option regardless, but it maybe because the underlying IP stack has IPv6 disabled altogether.

My knowledge of compose is lacking, but let’s check to see what network “driver” the Docker container is using.
docker network ls should show some network that uses the host driver. For the moment let’s assume the name of the network is also “host”.
docker network inspect host should show that your container is using the host network (the network with a host driver).

In my HAOS based setup, it shows that the ha_core container is using the host network and the inspect host also shows that the “host” network’s settings are:
“Driver”: “host”,
“EnableIPv6”: false
What this all means is that the so called Docker network itself does not have to have IPv6 enabled as it is going to use the native “host”'s IP stack for IPv4 and IPv6.

If your setup looks to be correct, then I’m at a bit of a loss why your HA container doesn’t give you an IPv6 option.

Yep, my HA container is running in host which also has IPv6_enabled as false. I’ll have to spin up another VM and test some stuff out. Here’s a screenshot of what my Network settings page looks like.

There should be a couple of other cards above this one that shows the IPv4 and IPv6 settings … but since yours does not, it may be the case that HA Core does not support these other cards without HA Supervisor. I presume that you don’t have HA Supervisor, correct?

Rethinking this, its more of an issue with your Matter Server, since Matter/WiFi works, let’s confirm it is supporting IPv6, so in your HA UI, goto Settings->Devices->Device Tab find your Matter/WiFi device, and click on “Device Info” and see if shows an IPv6 address(es), if so is there one like “fdaf:blah-blah”? If it is just an “fe80:blah-blah”, then that may be the problem.

Yeah, there is no option to use Supervisor in HA-Container.

My Matter/WiFi device that I (re)paired does have two ipv6 addresses - one is an fe80 but the other starts with 2600.

This confirms that your Matter Server is using IPv6 as it should be. The fe80 is the typical link-local address that all devices will have, the 2600 is a global address which is fine.

OK so somewhere along the way, you have provided HA with the Thread dataset/credentials of your AppleTV and HomePod and this leads me to think that these two Thread network TBRs and both are on the same Thread network.

So far so good! It means a device on the Apple Thread network got the Thread dataset/credentials, presummably from your iPhone and successfully joined the Apple Thread network and started advertising availability for HA Core’s Homekit integration to see.

You may have to add some information on the steps you are taking to commission a Matter Thread device. If you are using iOS HA Companion App, to do the commissioning, you’ll need to use the same one that was used to add the Homekit device as the iOS device has the Thread credentials that are needed to give to the Matter/Thread device. That iOS device will also need to be on the same WiFi/Ethernet network as your HA Core and Matter Server are on as it needs to talk to at least the Matter Server…

Do you have the matter server installed?

Is your matter server in the same vlan as your appleTV that acts as a border router?

I run ha as a docket container. I had to run matter server (since not supervised) as a separate container and put it in same vlan as appleTV. It took me a while to get it all working but the trick was.

Matter server and appleTV in same vlan, when commissioning a device whether shared via appleTV or directly to HA ensure phone in same vlan as appleTV/matter server.

I don’t have any VLANs or complex networking stuff going on w/ my network, just one network that everything is connected to. I’ve got the python matter server running in a separate container in host mode along with HomeAssistant.

I’ve tried it in both browser and from my phone that I initially used to add them to my Apple Home and get tthe same results, sadly.

Can you post your docker compose for matter server?

Do you have any of these options set in compose:

Will need to use the right eth adapter name.

Necessary for the container to receive the routes from the remote Thread network managed by Apple TBR orGoogle Nest Hub.

sysctls:
net.ipv6.conf.eth0.accept_ra: 2
net.ipv6.conf.eth0.accept_ra_rt_info_max_plen: 64
net.ipv6.conf.eth0.forwarding: 1

Here’s the matter-server compose:

services:
  # python-matter-server
  matter-server:
    image: ghcr.io/home-assistant-libs/python-matter-server:stable
    container_name: matter-server
    restart: unless-stopped
    # Required for mDNS to work correctly
    network_mode: host
    security_opt:
      # Needed for Bluetooth via dbus
      - apparmor:unconfined
    volumes:
      # Create an .env file that sets the USERDIR environment variable.
      - ${USERDIR:-$HOME}/docker/appdata/matter-server/data:/data/
      # Required for Bluetooth via D-Bus
      - /run/dbus:/run/dbus:ro
    # If you adjust command line, make sure to pass the default CMD arguments too:
    #command: --storage-path /data --paa-root-cert-dir /data/credentials --bluetooth-adapter 0

This is just a copy of what was on the github, obviously having mapped the volume properly. I should also say that I can docker exec matter-server ping6 (Apple TV/Homepod IPv6) successfully, and the same for the HA container so it’s not like they can’t talk to each other at all.

I think you need to add the options i posted.

Here is a thread about it.

What network interface are you using on the docker host?

Eth0, br0, wlan0?

The host is using eth0 for the interface.

Try this for your compose.

services:
  # python-matter-server
  matter-server:
    image: ghcr.io/home-assistant-libs/python-matter-server:stable
    container_name: matter-server
    restart: unless-stopped
    # Required for mDNS to work correctly
    network_mode: host
    security_opt:
      # Needed for Bluetooth via dbus
      - apparmor:unconfined
    volumes:
      # Create an .env file that sets the USERDIR environment variable.
      - ${USERDIR:-$HOME}/docker/appdata/matter-server/data:/data/
      # Required for Bluetooth via D-Bus
      - /run/dbus:/run/dbus:ro
    # If you adjust command line, make sure to pass the default CMD arguments too:
    #command: --storage-path /data --paa-root-cert-dir /data/credentials --bluetooth-adapter 0

    sysctls:    # Necessary for the container to receive the routes from the remote Thread network managed by my Google Nest Hub.
      net.ipv6.conf.eth0.accept_ra: 2
      net.ipv6.conf.eth0.accept_ra_rt_info_max_plen: 64
      net.ipv6.conf.eth0.forwarding: 1

Here is my compose using a macvlan adapter so I could get my matter-server in same vlan as appleTV devices.

version: "3.8"

services:
  # python-matter-server
  matter-server:
    image: ghcr.io/home-assistant-libs/python-matter-server:stable
    container_name: matter-server
    restart: unless-stopped
    # Required for mDNS to work correctly
    networks:
      macvlan20:
        ipv4_address: 192.xxx.xx.x
        ipv6_address: xxxx:xx::xxxx:xxxx:xxxx:xxxx
    #ports:
    #  - 8080:8080
    environment:
      - TZ=America/Chicago
    security_opt:
      # Needed for Bluetooth via dbus
      - apparmor:unconfined
    volumes:
      # Create an .env file that sets the USERDIR environment variable.
      - /mnt/docker/matter-server/data:/data/
      - /run/dbus:/run/dbus:ro
      # Required for Bluetooth via D-Bus
      #- /run/dbus:/run/dbus:ro
    # If you adjust command line, make sure to pass the default CMD arguments too:
    #command: --storage-path /data --paa-root-cert-dir /data/credentials --bluetooth-adapter 0
    sysctls:    # Necessary for the container to receive the routes from the remote Thread network managed by my Google Nest Hub.
      net.ipv6.conf.eth0.accept_ra: 2
      net.ipv6.conf.eth0.accept_ra_rt_info_max_plen: 64
      net.ipv6.conf.eth0.forwarding: 1
      
  

networks:
  macvlan20:
    external: true
  
      

So I’m getting an error when trying to stand this new compose up:

Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: sysctl "net.ipv6.conf.eth0.accept_ra" not allowed in host network namespace: unknown

So, I’m not sure if this is an issue with host networking, but it doesn’t seem to like it much.

Not sure, I don’t use promox. Not sure if you need to set something similar at the promox level.

I’d already set the accept._ra to 1, but after changing it to 2 in the Proxmox LXC and on the bridge and interface on the Proxmox host itself it worked! I hope anyone else who has these issues finds this thread. At least for the first light bulb I tried.

glad you got it sorted

I really appreciate your help!

@bigdvette you will never know HOW much i love you ! you saved me ! i was searching for DAYS, and this settings helped me a lot <3

Same here! Thank you for claiming that it had to be run for all interfaces.