Thread (Sonoff EFR32MG21 NCP) - Matter - Docker problem on debian host - ICMPv6 message Drop?

Since 4 days I try to get my Sonoff Dongle E to work with Thread and my Thread over Matter devices.

My Hass run as a docker My env:

  • debian system, intel based, kernel 6.6.13+bpo-amd64
  • homeassistant as docker
  • z2m as docker
  • matter as docker (Package python-matter-server · GitHub)
  • openthread/otbr official docker
  • Sonoff ZBDongle-E what is based on the EFR32MG21 Multiprotocol SoC chip (same like SkyConnect is using) on /dev/ttyACM0
  • Zemismart Thread/Matter curtain driver
  • Nuki Pro 4 lock Thread/Matter
  • slae.sh cc2652rb Zigbee stick on /dev/ttyUSB0

For notice. I already test a lot the Silabs-Multiprotocol-Docker from b2un0. But it seemed in the end that Multiprotocol is still to buggy. The logs never show a lot like my openthread docker did. So it seems that it was not really able to talk with the stick. Idk why.

I flashed OpenThread Firmware on the stick (Sonoff ZBDongle-E what is based on the EFR32MG21), from this site with the webflasher:

The openthread docker noticed this stick also as a NCP stick:
Apr 12 10:14:03 debian-nas otbr-agent[152]: 50d.03:39:38.425 [D] P-RadioSpinel-: Received spinel frame, flg:0x2, iid:0, tid:2, cmd:PROP_VALUE_IS, key:NCP_VERSION, version:SL-OPENTHREAD/2.3.1.0_GitHub-e6df00dd6; EFR32

Setup with hass-docker worked.

  1. add otbr and type in: http://localhost:8081 as adress
  2. add the poped-up Thread device. Then I can see the thread network and the logs from otbr-docker gets talky
  3. add matter (beta) addon with adress ws://docker-host:5580/ws

Whatever I do. When I add nuki thread lock or zemismart thread curtain drivers, they always complain about a missing thread border router.
I have read a lot about ICMPv6 in Linux. It seems that this is really my last problem.

When I grep the logs for the keyword “Failed” I always got this:

Apr 12 10:05:02 debian-nas otbr-agent[151]: 09:30:51.460 [D] P-InfraNetif--: Failed to handle ICMPv6 message: Drop
Apr 12 10:05:02 debian-nas otbr-agent[151]: 09:30:51.460 [D] P-InfraNetif--: Failed to handle ICMPv6 message: Drop
Apr 12 10:06:22 debian-nas otbr-agent[151]: 09:32:11.847 [D] P-InfraNetif--: Failed to handle ICMPv6 message: Drop
Apr 12 10:06:22 debian-nas otbr-agent[151]: 09:32:11.848 [D] P-InfraNetif--: Failed to handle ICMPv6 message: Drop
Apr 12 10:07:43 debian-nas otbr-agent[151]: 09:33:32.484 [D] P-InfraNetif--: Failed to handle ICMPv6 message: Drop
Apr 12 10:07:43 debian-nas otbr-agent[151]: 09:33:32.484 [D] P-InfraNetif--: Failed to handle ICMPv6 message: Drop
Apr 12 10:09:03 debian-nas otbr-agent[151]: 09:34:53.128 [D] P-InfraNetif--: Failed to handle ICMPv6 message: Drop
Apr 12 10:09:03 debian-nas otbr-agent[151]: 09:34:53.128 [D] P-InfraNetif--: Failed to handle ICMPv6 message: Drop
Apr 12 10:09:49 debian-nas otbr-agent[151]: 09:35:38.180 [D] P-InfraNetif--: Failed to handle ICMPv6 message: Drop
Apr 12 10:09:49 debian-nas otbr-agent[151]: 09:35:38.180 [D] P-InfraNetif--: Failed to handle ICMPv6 message: Drop
Apr 12 10:10:24 debian-nas otbr-agent[151]: 09:36:13.508 [D] P-InfraNetif--: Failed to handle ICMPv6 message: Drop
Apr 12 10:10:24 debian-nas otbr-agent[151]: 09:36:13.508 [D] P-InfraNetif--: Failed to handle ICMPv6 message: Drop
Apr 12 10:11:44 debian-nas otbr-agent[151]: 09:37:33.892 [D] P-InfraNetif--: Failed to handle ICMPv6 message: Drop
Apr 12 10:11:44 debian-nas otbr-agent[151]: 09:37:33.892 [D] P-InfraNetif--: Failed to handle ICMPv6 message: Drop

This is the only mysterious failing lines I see really often in the logs. The matter-server logs are not talking a lot.

This is what I run once (allways after reboot) of my debian docker host:

sudo modprobe ip6table_filter
sudo sysctl -w net.ipv6.conf.eno1.accept_ra=2 net.ipv6.conf.eno1.forwarding=1 net.ipv6.conf.eno1.accept_ra_rt_info_max_plen=64 net.ipv6.conf.all.forwarding=1 net.ipv4.conf.all.forwarding=1 net.ipv6.conf.eno1.mtu=1500 net.ipv6.conf.all.disable_ipv6=0

The openthread docker create a lot of virtual-network adapters. So it seems this is working too.

I try:

  • different networkmanager (default debian one) | network-manager and networkd (current one)
  • a lot of different docker settings
  • a lot of different ip’s or hostnames to integrate matter-server or otbr into hass
  • different kernel 6.1.0-18-amd64 & 6.6.13+bpo-amd64 (current one)
  • some iptable settings to try to fix the ICMPv6 message Drop

If someone have knowledge to this. Please tell me.
It felt sooo close. It just seems that only the ICMPv6 message Drop is my last problem.

Here is my docker-compose.yml (not everything, but everything necessary):

services:
  otbr:
    container_name: otbr
    image: openthread/otbr
    privileged: true # don't change this !
    network_mode: host # don't change this !
    cap_add:
      - SYS_ADMIN
      - NET_ADMIN
    volumes:
      - ./myconfigs/otbr/:/data
      - /dev/ttyACM0:/dev/ttyACM0
      - /etc/localtime:/etc/localtime:ro
    environment:
      NAT64: 1
      NAT64_SERVICE: openthread
      #source: https://openthread.io/codelabs/openthread-border-router-nat64?hl=en#1
    command: --radio-url spinel+hdlc+uart:///dev/ttyACM0?uart-baudrate=460800 --backbone-interface eno1
    dns:
      - 127.0.0.1
    depends_on:
      - homeassistant
    restart: unless-stopped
  matter-server:
    container_name: matter-server
    image: ghcr.io/home-assistant-libs/python-matter-server:stable
    restart: unless-stopped
    privileged: true # don't change this !
    security_opt:
      - apparmor=unconfined
    volumes:
      - ./myconfigs/matter-server:/data
      - /run/dbus:/run/dbus:ro
      - /etc/localtime:/etc/localtime:ro
    network_mode: host
    cap_add:
      - SYS_ADMIN
      - NET_ADMIN
    depends_on:
      - homeassistant
  homeassistant:
    image: ghcr.io/home-assistant/home-assistant:stable
    container_name: homeassistant
    network_mode: host
    privileged: true
    volumes:
      - ./myconfigs/homeassistant/:/config
      - /etc/localtime:/etc/localtime:ro
      - /run/dbus:/run/dbus:ro
      - /dev/ttyACM0:/dev/ttyACM0
    environment:
      - TZ=Europe/Berlin
  zigbee2mqtt:
    container_name: zigbee2mqtt
    restart: unless-stopped
    image: koenkk/zigbee2mqtt
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - ./myconfigs/zigbee2mqtt:/app/data
      - /run/udev:/run/udev:ro
    devices:
      - :/dev/ttyUSB0:/dev/ttyUSB0
    ports:
      - 9002:8080
    environment:
      - TZ=Europe/Berlin

Greetings by JamieME

Your host should have IPv6 enabled and a fe80 defined.
You can probably not have multiple NICs, because there seems no way to make sure the right fe80 network is used then and in IPv6 that network will be on every interface, even though it is not the same network physically.

Then you also needs to make sure that your commissioning device have the right thread credentials stored.
There is section in the HA Matter video meetup about this and I have posted a description on the step a few times here on the forum too, but where I am now I am not able to make an easy search for the posts.

I got a lucky hit.

Did you mean the one from my eno1:

eno1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.0.0.16  netmask 255.255.255.0  broadcast 10.0.0.255
        inet6 2002:5cce:6d54:0:2035:350d:6e0e:bfc2  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::f0d5:4b32:3bff:a3a8  prefixlen 64  scopeid 0x20<link>
        inet6 fd00::8cd5:XXXXXXXXX  prefixlen 64  scopeid 0x0<global>
        inet6 fd00::aaa1:XXXXXXXXX  prefixlen 64  scopeid 0x0<global>
        inet6 2002:XXXX:XXXX:0:XXXXX prefixlen 64  scopeid 0x0<global>
        ether a8:a1:59:54:ab:47  txqueuelen 1000  (Ethernet)
        RX packets 1546398  bytes 582215940 (555.2 MiB)
        RX errors 0  dropped 1026  overruns 0  frame 0
        TX packets 1244891  bytes 262858616 (250.6 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 16  memory 0xdf200000-df220000

Where can I find this meetup video? Was it from hass official?

Very cool.

On the Android Companion App open Settings → Companion App → Troubleshooting (I think that is what it is called in english, but it list logfiles and other tools to diagnostics as description of the item).
In this next window click the Sync Thread Login Credentials (Again it might not be named exactly that, but close to and there should not be that many options and it should be in the bottom) It should say either something with “Added …” or “Already using the same credentials”. The trick here is to run it again and make sure that it does not say “Added …” the second time.

That bring me a step closer. Now when I am adding a new thread matter device it takes a longer and does not stop with an missing otbr error.
My log from the otbr docker still say something about:

Apr 12 17:31:55 debian-nas otbr-agent[152]: 07:17:51.550 [D] P-InfraNetif--: Failed to handle ICMPv6 message: Drop
Apr 12 17:31:58 debian-nas otbr-agent[152]: 07:17:54.918 [N] MeshForwarder-: Failed to send IPv6 UDP msg, len:195, chksum:4858, ecn:no, to:72bdb185aadffb11, sec:yes, error:NoAck, prio:net
Apr 12 17:32:00 debian-nas otbr-agent[152]: 07:17:56.070 [W] Mle-----------: Failed to process Parent Request: Duplicated
Apr 12 17:32:09 debian-nas otbr-agent[152]: 07:18:05.677 [D] P-InfraNetif--: Failed to handle ICMPv6 message: Drop

It was just a general thing.
I do not look at your setup at all.