search

project-chip / connectedhomeip

Matter (formerly Project CHIP) creates more connections between more objects, simplifying development for manufacturers and increasing compatibility for consumers, guided by the Connectivity Standards Alliance.
https://buildwithmatter.com
Apache License 2.0
7.43k stars 1.99k forks source link

[Test Failed] chip-tool is failing operational DNS-SD discovery #36040

Closed MaxPayne86 closed 6 days ago

MaxPayne86 commented 1 week ago

Test commissioning of Matter device via Ble using chip-tool

Hello, I am using project-chip v2.3.0-1.3 from SiliconLabs

I have packed the solution (otbr-agent/ot-ctl & chip-tool) in a docker compose app. The docker images are public so you can test them on any arm64 platform

docker-compose.yml

version: '3.8'
services:
  otbr:
    image: arduino/otbr:latest
    container_name: otbr
    privileged: true
    cap_add:
      - NET_ADMIN
      - SYS_ADMIN
    restart: unless-stopped
    ports:
      - "8080:80"  # Web interface
    devices:
      - "/dev/ttyACM0:/dev/ttyACM0"
    volumes:
      - "/run/dbus/system_bus_socket:/run/dbus/system_bus_socket"
    environment:
      - DBUS_SYSTEM_BUS_ADDRESS=unix:path=/run/dbus/system_bus_socket
      - CHANNEL=${CHANNEL:-15}
      - PANID=${PANID:-0x1234}
      - NETWORKKEY=${NETWORKKEY:-00112233445566778899aabbccddeeff}
    stdin_open: true
    tty: true
    entrypoint: otbr-agent -I wpan0 -B eth0 spinel+hdlc+uart:///dev/ttyACM0 -v trel://eth0
    networks:
      my_ipv6_network:
        ipv6_address: "fd12:3456:789a:bcde::2"

  chip-tool:
    image: arduino/chip-tool:latest
    container_name: chip-tool
    volumes:
      - "/run/dbus/system_bus_socket:/run/dbus/system_bus_socket"
      - "/var/run/docker.sock:/var/run/docker.sock"
    environment:
      - DBUS_SYSTEM_BUS_ADDRESS=unix:path=/run/dbus/system_bus_socket
    stdin_open: true
    tty: true
    depends_on:
      - otbr
    restart: unless-stopped
    networks:
      my_ipv6_network:
        ipv6_address: "fd12:3456:789a:bcde::3"

networks:
  my_ipv6_network:
    enable_ipv6: true
    ipam:
      config:
        - subnet: "fd12:3456:789a:bcde::/64"

in order for otbr to access dbus, you need to place this file in your system

/etc/dbus-1/system.d/otbr-agent.conf

<!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
 "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
<busconfig>
    <policy user="root">
        <allow own_prefix="io.openthread.BorderRouter"/>
        <allow send_interface="io.openthread.BorderRouter"/>
        <allow send_interface="org.freedesktop.DBus.Properties"/>
        <allow send_interface="org.freedesktop.DBus.Introspectable"/>
    </policy>
    <policy group="root">
        <allow send_interface="io.openthread.BorderRouter"/>
        <allow send_interface="org.freedesktop.DBus.Properties"/>
        <allow send_interface="org.freedesktop.DBus.Introspectable"/>
    </policy>
</busconfig>

then you can start everything with

docker compose up -d

to trigger a commissioning, log into chip-tool service

docker exec -it chip-tool bash
mattertool startThread # Start open thread network
export THREAD_DATA_SET=$(docker exec -it otbr ot-ctl dataset active -x | sed -n 1p | sed -e "s/\r//g")
mattertool bleThread # Start commissioning of ext Matter device via Bluetooth

via docker-compose logs, is possible to follow the log during all the phases. At some point, I get the following error

[1728574246.553619][577:579] CHIP:DIS: OperationalSessionSetup[1:00000000000056EC]: operational discovery failed: src/lib/address_resolve/AddressResolve_DefaultImpl.cpp:119: CHIP Error 0x00000032: Timeout

in my understanding, chip-tool is not able to see the mDNS records published by avahi daemon running on host machine. However, a quick check using another client, avahi-browse, reveals that the records are accessible from within the very same service

apt update && apt install -y iproute2 iputils-ping avahi-utils
avahi-browse -d local _meshcop._udp --resolve -t

the output is truncated but is evident that the mDNS records are visible

avahi-browse -d local _meshcop._udp --resolve -t
+ (null) IPv6 OpenThread BorderRouter #DE33                 _meshcop._udp        local
+ (null) IPv6 OpenThread BorderRouter #DE33                 _meshcop._udp        local
+ (null) IPv6 OpenThread BorderRouter #DE33                 _meshcop._udp        local
+ (null) IPv4 OpenThread BorderRouter #DE33                 _meshcop._udp        local
+ (null) IPv4 OpenThread BorderRouter #DE33                 _meshcop._udp        local
+ (null) IPv6 OpenThread BorderRouter #DE33                 _meshcop._udp        local
+ (null) IPv4 OpenThread BorderRouter #DE33                 _meshcop._udp        local
+     lo IPv4 OpenThread BorderRouter #DE33                 _meshcop._udp        local
= (null) IPv6 OpenThread BorderRouter #DE33                 _meshcop._udp        local
   hostname = [dev-portenta-x8-142c1209dabc240b.local]
   address = [fe80::7c03:34ff:fe13:2cfc]
   port = [49154]
   txt = ["omr=@���Y��\000\001" "pt=�\010�\015" "at=\000\000\000\000\000\001\000\000" "sb=\000\000\0001" "xa=F��R�\004�3" "tv=1.3.0" "xp=_\013zu�\013��" "nn=OpenThread-5b04" "mn=BorderRouter" "vn=OpenThread" "id=�\005-_��*����(���" "rv=1"]

This commit seems promising

https://github.com/project-chip/connectedhomeip/commit/c6ad5b160b64c8b7d76a16d1dde169ed2c7ca175

however if you have any suggestion, greatly appreciated.

Platform

IMX8

Anything else?

No response

bzbarsky-apple commented 1 week ago

the output is truncated but is evident that the mDNS records are visible

Well, some sort of records are visible. Are the Matter records visible? At the point when you expect the operational node to be advertising, can avahi-browse inside the service see them @MaxPayne86 ?

MaxPayne86 commented 1 week ago

We didn't tried yet to keep avahi-browse going while commissioning, I guess we will be able to try since Monday, thx for the reply!

Ps: I was trying to understand if

chip-tool discover commissioners

could help us troubleshoot the issue better. This command returns

[1728639948.284168][593:593] CHIP:TOO: Run command failure: ../../examples/chip-tool/commands/discover/DiscoverCommissionablesCommand.cpp:74: CHIP Error 0x0000002D: Not Implemented

on the same setup.

bzbarsky-apple commented 1 week ago

The discover command stuff in chip-tool is only implemented on Mac, and has nothing to do with discovery during actual commissioning.

leonardocavagnis commented 6 days ago

Hi @bzbarsky-apple, Thanks for your reply! I'm working with @MaxPayne86 on this topic.

We solved the issue by removing networks field from the Docker Compose configuration file and adding network_mode: "host".

The first Docker Compose configuration creates a custom network with dedicated IPv6 addresses for each service, which seems to cause issues with the chip-tool. The second configuration uses network_mode: "host", sharing the host's network with the containers for easier communication.

docker-compose.yml

version: '3.8'
services:
  otbr:
    image: arduino/otbr:latest
    container_name: otbr
    privileged: true
    cap_add:
      - NET_ADMIN
      - SYS_ADMIN
    restart: unless-stopped
    devices:
      - "/dev/ttyACM0:/dev/ttyACM0"
    volumes:
      - "/run/dbus/system_bus_socket:/run/dbus/system_bus_socket"
    environment:
      - DBUS_SYSTEM_BUS_ADDRESS=unix:path=/run/dbus/system_bus_socket
      - CHANNEL=${CHANNEL:-15}
      - PANID=${PANID:-0x1234}
      - NETWORKKEY=${NETWORKKEY:-00112233445566778899aabbccddeeff}
    stdin_open: true
    tty: true
    entrypoint: otbr-agent -I wpan0 -B eth0 spinel+hdlc+uart:///dev/ttyACM0 -v trel://eth0
    network_mode: "host"

  chip-tool:
    image: arduino/chip-tool:latest
    container_name: chip-tool
    volumes:
      - "/run/dbus/system_bus_socket:/run/dbus/system_bus_socket"
      - "/var/run/docker.sock:/var/run/docker.sock"
    environment:
      - DBUS_SYSTEM_BUS_ADDRESS=unix:path=/run/dbus/system_bus_socket
    stdin_open: true
    tty: true
    depends_on:
      - otbr
    restart: unless-stopped
    network_mode: "host"