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

Mobile Apps Android App
1

I originally posted this in the general help section, but I think it could be an app issue, so posting here as well.

Reproduces on current platform (2.5.0.159), with Android app version of 2.1.4.07. 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