Comissioning a device times out

[LennyPenny]

Heyo,
thanks for this project!

I'm trying to add one of the matter devices that is already in my apple home to the example controller from this.

./target/debug/examples/demo ca-bootstrap
/target/debug/examples/demo ca-create-controller 100
# turn on pairing mode in apple home
./target/debug/examples/demo discover commissionable --timeout 3 
remaining time: 3.00sec
remaining time: 2.50sec
remaining time: 2.00sec
remaining time: 1.50sec
remaining time: 1.00sec
remaining time: 0.49sec
MatterDeviceInfo {
    service: "xxx",
    device: "xxx",
    ips: [
        xxx,
    ],
    name: None,
    vendor_id: Some(
        "xxx",
    ),
    product_id: Some(
        "xxx",
    ),
    discriminator: Some(
        "xxx",
    ),
    commissioning_mode: Some(
        WithPasscode,
    ),
    pairing_hint: Some(
        "xx",
    ),
    source_ip: "192.168.2.y:5353",
    port: Some(
        5540,
    ),
}
MatterDeviceInfo {
    service: "xxx",
    device: "xxx",
    ips: [
        xxx,
    ],
    name: None,
    vendor_id: Some(
        "xxx",
    ),
    product_id: Some(
        "xxx",
    ),
    discriminator: Some(
        "xxx",
    ),
    commissioning_mode: Some(
        WithPasscode,
    ),
    pairing_hint: Some(
        "36",
    ),
    source_ip: "[xxx]:5353", 
    port: Some(
        5540,
    ),
./target/debug/examples/demo decode-manual-pairing-code xxx                                                                                             
discriminator: xxx
passcode: xxx
/target/debug/examples/demo commission 192.168.2.y:5540 100 300 xxx --verbose                                                                          
[2026-02-04T18:03:26.904Z DEBUG /home/lenny/gits/rust-matc/src/controller.rs:241 matc::controller] start auth_spake
[2026-02-04T18:03:26.904Z DEBUG /home/lenny/gits/rust-matc/src/controller.rs:245 matc::controller] send pbkdf request
[2026-02-04T18:03:26.905Z TRACE src/retransmit.rs:35 matc::retransmit] send msg counter:2659449743
[2026-02-04T18:03:29.906Z TRACE src/retransmit.rs:53 matc::retransmit] retransmit counter = 2659449743
[2026-02-04T18:03:32.907Z TRACE src/retransmit.rs:53 matc::retransmit] retransmit counter = 2659449743
[2026-02-04T18:03:35.908Z TRACE src/retransmit.rs:53 matc::retransmit] retransmit counter = 2659449743
[2026-02-04T18:03:38.909Z TRACE src/retransmit.rs:53 matc::retransmit] retransmit counter = 2659449743

thread 'main' (52355) panicked at examples/demo.rs:205:14:
called `Result::unwrap()` on an `Err` value: retransmit timeout exceeded
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

I made sure UDP 5555 is open on my machine.

Is there anything I'm missing? Does the discriminator that gets printed when decoding the pairing code matter? It doesn't mach the discovered commissionable device.

[LennyPenny]

When I'm using the IPv6 address of the device and listen on ipv6 using --local-address [::]:5555 I'm getting some more logs:

...
[2026-02-04T18:17:10.591Z TRACE src/retransmit.rs:39 matc::retransmit] received ack counter:359027115
[2026-02-04T18:17:10.591Z TRACE /home/lenny/gits/rust-matc/src/retransmit.rs:133 matc::retransmit] sending ack for exchange:47886 counter:145050636
[2026-02-04T18:17:10.591Z DEBUG /home/lenny/gits/rust-matc/src/controller.rs:324 matc::controller] auth_spake ok; session: 9195
[2026-02-04T18:17:10.591Z TRACE src/retransmit.rs:35 matc::retransmit] send msg counter:359027117
[2026-02-04T18:17:11.446Z DEBUG /home/lenny/gits/rust-matc/src/retransmit.rs:84 matc::retransmit] can't decode incoming message session id mismatch. expected:0 got:1
[2026-02-04T18:17:11.633Z DEBUG /home/lenny/gits/rust-matc/src/retransmit.rs:84 matc::retransmit] can't decode incoming message session id mismatch. expected:0 got:1

[tom-code]

For ipv4 it seems no response comes from device.
You can investigate using tcpdump or wireshark whether there are some data coming from device or not.

For ipv6 it is my fault. Refactor which I pushed today did break commissioning. I pushed temporary fix - you can try it now.

[LennyPenny]

Oh wow it worked with the ipv6 fix! Thank you. I'll try and use this now and report any further issues.

[LennyPenny]

So demo discover commissioned exits immediately, just showing my matterbridge instance, not the device I just paired. Nothing to see in verbose logs. I never paired matterbridge to this demo controller btw, so it's odd that it's showing.

Controlling the device like this works fine:
demo command invoke-command-off --local-address [::]:5555 --device-address [<lamp ipv6>]:5540
I can even omit the --controller-id 100 --device-id 300 mentioned in the readme.
I can also read the endponts/cluster/attributes with list-attributes

[tom-code]

discover commissioned shall display all commissioned devices in network using mdns - even ones commissioned by someone else.
which os do you use?
there is one more thing I did break today in discover area - I pushed fix now, so you can try again.

[LennyPenny]

I'm using nixos 25.11
Maybe it's because they are all ikea thread devices using the apple tv as the border router - which are ipv6 only I guess?
All the other commands only worked when I manually set --local-address [::]:5555, however I don't think that flag exists for commissioned.

When I use avahi-browse --all --resolve --ignore-local I can see a realistic amount of _matter._tcp devices with only an ipv6 address, so I don't think it's an ipv6 misconfig on my side.

Sadly the new fix didn't help

[tom-code]

do I understand correctly that
./target/debug/examples/demo discover commissionable --timeout 3
waits for 3 secs and reports all devices
while
./target/debug/examples/demo discover commissioned --timeout 3
stops quickly?
(they shall behave same - just list different services)
can you share verbose logs with latest version?

[LennyPenny]

Yes, commissionable waits, commissioned exits quickly.

./target/debug/examples/demo discover commissioned --timeout 3 --verbose                                                                                        cargo rustc 
remaining time: 3.00sec
[2026-02-04T21:22:59.625Z WARN  src/mdns.rs:294 matc::mdns] mdns discover error: Network is unreachable (os error 101)
[2026-02-04T21:22:59.948Z WARN  src/mdns.rs:306 matc::mdns] mdns discover error: failed to fill whole buffer
[2026-02-04T21:22:59.948Z WARN  src/mdns.rs:294 matc::mdns] mdns discover error: failed to fill whole buffer
[2026-02-04T21:22:59.948Z WARN  src/mdns.rs:294 matc::mdns] mdns discover error: failed to fill whole buffer
[2026-02-04T21:22:59.948Z WARN  src/mdns.rs:294 matc::mdns] mdns discover error: failed to fill whole buffer
[2026-02-04T21:22:59.948Z WARN  src/mdns.rs:294 matc::mdns] mdns discover error: failed to fill whole buffer
[2026-02-04T21:22:59.948Z WARN  src/mdns.rs:294 matc::mdns] mdns discover error: failed to fill whole buffer
[2026-02-04T21:22:59.948Z WARN  src/mdns.rs:294 matc::mdns] mdns discover error: failed to fill whole buffer
[2026-02-04T21:22:59.949Z WARN  src/mdns.rs:294 matc::mdns] mdns discover error: failed to fill whole buffer
[2026-02-04T21:22:59.949Z WARN  src/mdns.rs:294 matc::mdns] mdns discover error: failed to fill whole buffer
[2026-02-04T21:22:59.949Z WARN  src/mdns.rs:294 matc::mdns] mdns discover error: failed to fill whole buffer
[2026-02-04T21:22:59.949Z WARN  src/mdns.rs:294 matc::mdns] mdns discover error: failed to fill whole buffer
MatterDeviceInfo {
    service: "<>",
    device: "<>
    ips: [
        lots
        of 
        ips
    ],
    name: None,
    vendor_id: None,
    product_id: None,
    discriminator: None,
    commissioning_mode: None,
    pairing_hint: None,
    source_ip: "xxx:5353",
    port: Some(
        5540,
    ),
}
MatterDeviceInfo {
    service: "<>",
    device: ">?
    ips: [
        lots
        of 
        ips
    ],
    name: None,
    vendor_id: None,
    product_id: None,
    discriminator: None,
    commissioning_mode: None,
    pairing_hint: None,
    source_ip: "[xxx]:5353",
    port: Some(
        5540,
    ),
}

Here are my addresses in case case that could explain that error:

ip addr show                                                                                                                                                    cargo rustc 
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute 
       valid_lft forever preferred_lft forever
2: enp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/etherxxx brd ff:ff:ff:ff:ff:ff
    altname xxx
    inet 192.168.2.x/24 brd 192.168.2.255 scope global dynamic noprefixroute enp4s0
       valid_lft 27581sec preferred_lft 27581sec
    inet6 xxx/128 scope global dynamic noprefixroute 
       valid_lft 42982sec preferred_lft 42982sec
    <lots more>
3: wlp5s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether xxx brd ff:ff:ff:ff:ff:ff permaddr xxx
    altname xxx
4: tailscale0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1280 qdisc fq_codel state UNKNOWN group default qlen 500
    link/none 
    inet xxx/32 scope global tailscale0
       valid_lft forever preferred_lft forever
    inet6 xxx/128 scope global 
       valid_lft forever preferred_lft forever
    inet6 xxx/64 scope link stable-privacy proto kernel_ll 
       valid_lft forever preferred_lft forever

[tom-code]

maybe there is some problem with parsing of these messages
can you run it like this?
RUST_BACKTRACE=1 ./target/debug/examples/demo discover commissioned --timeout 3 --verbose
are you able to capture and share pcap of these mdns messages using tcpdump or wireshark?

if you want you can use different tools or library for discovery.
discovery functionality is currently not tied to any matter features.
it is needed only in case you don't know ip of device and need to find it out.

[LennyPenny]

Same logs with RUST_BACKTRACE=1 :/
I'll see if I can try wireshark this week!