[Bug Report] Matter multi-admin pairing: app abandons discovery after ~50ms, burns commissioning window

Get Help
1

Reproduces on current platform (2.5.0.159). Two other unresolved threads with
the same symptom across different vendors and transports:

Setup

  • Hub: C-8 Pro, platform 2.5.0.159 (current)
  • LAN: Ethernet, DHCP. Flat network, no VLANs. pfSense + Asus AP, IPv6 enabled.
  • Device: SwitchBot Hub 2 (Wi-Fi Matter), VID 0x1397 / PID 0x07E7

Ruled out before posting

  • ping6 to the device's link-local from a machine on the same segment: 24/24, 0% loss
  • Hub's own mDNS cache (/hub/mdnsDevices) resolves the device
  • dns-sd confirms the device advertising _matterc._udp with a matching short discriminator
  • Two eufy vacuums commissioned and operating normally on this hub over IPv6
  • Device commissions successfully to Google Home

Root cause

57.803  discoverCommissionableNodes()
57.815  getDiscoveredDevice(idx=0)   -> not found
  ...   idx=1..9                     -> not found
57.853  pairDeviceWithAddress(deviceId=3040,
          address=fe80::aabb:ccff:fedd:eeff, discriminator=0, ...)
58.360  Discovered device discriminator (2909)      <-- 507ms late

Discovery is polled ~50ms after being started and cannot complete in that
window. All ten indices miss, and the app falls back to
pairDeviceWithAddress() with discriminator=0 and an unscoped
link-local synthesized from the device MAC:

Msg TX ... [UDP:[fe80::aabb:ccff:fedd:eeff]:5540] --- PBKDFParamRequest

Working eufy traffic always carries a zone (...%eth0). Nothing answers;
4 retransmits; failure (max retries:4).

Meanwhile discovery succeeds and is refused, ~31x per attempt across
%eth0, %wlan0, and IPv4:

Discovered device ... matches one of our setup payloads
[CTL] Attempting PASE connection to UDP:[fe80::aabb:ccff:fedd:eeff%eth0]:5540
[-] CHIP Error 0x00000003: Incorrect state at SetUpCodePairer.cpp:464

Matter closes a commissioning window on a failed PASE attempt. The single
available attempt is spent on an address the app invented rather than one
discovery returned.

Credentials were verified correct beforehand

Google-issued code 05256823712 decodes to short discriminator 3,
passcode 38849880. Live window at that moment: CM=2 D=972
(0x3CC -> short 3). Match confirmed before entry.

dns-sd -B _matterc._udp local. during the attempt:

0:29:30  Rmv  6B34831D7F5D2B4D   (D=972, short 3)
0:29:34  Add  8AD0282BF894DEF5   (D=461, short 1, new RI)

The window rotated 4s later with new credentials. Later attempts reach Pake2
and fail with Failed to verify peer's MAC — correct passcode, rotated window.

Short-discriminator matching itself is fine; the hub logs
"matches one of our setup payloads" whenever the nibble lines up.

Secondary issue, same logs

mDNS broadcast had only partial success: 3 successes and 2 failures
OS Error 0x02000013: No such device
  at src/inet/UDPEndPointImplSockets.cpp:417

ENODEV — broadcasts attempted on nonexistent interfaces. Possibly related to
PASE being attempted over %wlan0 on a wired-only hub.

Questions

  1. Why is the discovery poll bounded at ~50ms, and why fall back to a
    MAC-derived unscoped address instead of waiting for the browse?
  2. Is SetUpCodePairer's Incorrect state caused by the in-flight PASE from
    that fallback?
  3. Should discovered _matterc addresses, which include a zone index, be
    authoritative?

image
image1920×1595 470 KB

2 Likes
[Bug Report] Matter multi-admin pairing: app abandons discovery and burns commissioning window