Failed to add 2nd fabric from 2nd chiptool - Commissioning discovery failed

[kean-apple]

Problem

Failed to add 2nd fabric from 2nd chiptool - Commissioning discovery over BLE failed

This with both 2 CHIPtools on same device and 2 CHIPtools on separate devices

1. Pair M5 board using CHIPTool1
2. Enable pairing mode using CHIPTool1
3. From CHIPTool 2, either on same device or separate device..try to pair M5 board using the PIN code provided by CHIPtool 1

In step 3, fails to discover and add M5 board on CHIPTool 2. No logs seen on M5 board after opening commissioning window to see pairing attempt happening

//start discovery
-04-04 16:11:19.169245-0700 localhost CHIPTool[5276]: (CHIP) [com.zigbee.chip:all] � [1649113879169] [5276:286428] CHIP: [CTL] Starting commissioning discovery over BLE

//fails to discover ove BLE
2022-04-04 16:12:19.178722-0700 localhost CHIPTool[5276]: (CHIP) [com.zigbee.chip:all] � [1649113939178] [5276:294468] CHIP: [CTL] Commissioning discovery over BLE failed: ../../../../../../../../../../../connectedhomeip/src/platform/Darwin/BleConnectionDelegateImpl.mm:111: Ble Error 0x0000040D: Application closed BLE connection
2022-04-04 16:12:19.178978-0700 localhost CHIPTool[5276]: (CHIP) [com.zigbee.chip:all] � [1649113939178] [5276:294468] CHIP: [-] ../../../../../../../../../../../connectedhomeip/src/platform/Darwin/BleConnectionDelegateImpl.mm:111: Ble Error 0x0000040D: Application closed BLE connection at ../../../../../../../../../../../connectedhomeip/src/

Attaching logs from attempts with CHIPtool on separate devices

CHIPtool2.txt
M5.txt
CHIPtool1.txt

[kean-apple]

Logs with Chiptool on same device
chiptool-2nd-pairing-not-started-chiptool-logs.txt
chiptool-2nd-pairing-not-started-M5-logs.txt

[bzbarsky-apple]

This is on SHA 7ab6653

[bzbarsky-apple]

.try to pair M5 board using the PIN code provided by CHIPtool 1

So this is using the PIN code, not the QR code, right? And the one that the CHIPTool shows, not the one the device itself shows?

[kean-apple]

Correct. using the PIN code that CHIPtool provides (not the default setup code)

[bzbarsky-apple]

//fails to discover over BLE

This part is expected, since the device is not advertising over BLE.

The more relevant part of the log is:

2022-04-04 16:11:19.169668-0700  localhost CHIPTool[5276]: (CHIP) [com.zigbee.chip:all] � [1649113879169] [5276:286428] CHIP: [CTL] Starting commissioning discovery over DNS-SD
2022-04-04 16:11:19.171657-0700  localhost CHIPTool[5276]: (CHIP) [com.zigbee.chip:all] � [1649113879171] [5276:294921] CHIP: [DL] Mdns: OnBrowseAdd  name: AFA82751C5E91D88, type: _matterc._udp., domain: local., interface: 16
2022-04-04 16:11:19.172880-0700  localhost CHIPTool[5276]: (CHIP) [com.zigbee.chip:all] � [1649113879172] [5276:294921] CHIP: [DL] Resolved interface id: 16
2022-04-04 16:11:19.174784-0700  localhost CHIPTool[5276]: (CHIP) [com.zigbee.chip:all] � [1649113879174] [5276:294921] CHIP: [DL] Mdns: OnGetAddrInfo hostname:1E51C6B759B18748.local.

but then I don't see any logs indicating we got an IP for that hostname....

[kean-apple]

Tried the following scenario with SHA 1fb5900

1. Paired with CHIPTool CLI running on Mac
2. Enable commissioning window on CHIPTool CLI
3. Use iOS chiptool, enter code provided from CHIPTool CLI -> do not see any pairing attempt on M5 board

CHIPtool-CLI_attempt-to-add-2nd-fabric.txt
M5-adding-attempt-to-add-2nd-fabric.txt
CHIPTool-iOS-1st-fabric-open-commissioning-window.txt

[phonnakasturi-apple]

Attaching the iOS logs and M5 stack logs for chip tool app 2 failing to pair.

iosLogs.txt

M5 stack logs.txt

[kean-apple]

@bzbarsky-apple Based on re-testing, Looks like c98d871 broke this behavior. it worked with f733995

[dhrishi]

@wqx6 PTAL ^

[wqx6]

Looks like the platform mDNS of ESP32 has some issues. Can you test again enabling minimal mDNS Component config->CHIP Core->General Options->Use the minimal mDNS implementation shipped in the CHIP library?

[kean-apple]

@wqx6 Thanks. yes after enabling that option I was able to pair 2nd fabric using CHIPtool with today's SDK. Should we always use that option moving forward?

[bzbarsky-apple]

Ah, that's why I could not reproduce: the default changed and sdkconfig is cached outside the build dir.... I should remember to just remove it as part of my builds.

Anyway, the specific bug here is that the ESP32 implementation of ChipDnssdPublishService ignores service.mSubTypes. So it's trying to advertise a thing with discriminator 3840, but does not advertise anything for _L3840._matterc_.udp, which means that commissioning discovery that uses a manual code or QR code and searches for only things with the right discriminator will fail. Observe:

%  dns-sd -B _matterc._udp
Browsing for _matterc._udp
DATE: ---Mon 11 Apr 2022---
14:53:59.402  ...STARTING...
Timestamp     A/R    Flags  if Domain               Service Type         Instance Name
14:53:59.403  Add        2   9 local.               _matterc._udp.       B547AE8902014C18
14:54:20.525  Add        2   9 local.               _matterc._udp.       28403D12B536F657

and

%  dns-sd -B _L3840._matterc._udp 
Browsing for _L3840._matterc._udp
DATE: ---Mon 11 Apr 2022---
14:54:57.621  ...STARTING...
Timestamp     A/R    Flags  if Domain               Service Type         Instance Name
14:54:57.622  Add        2   9 local.               _matterc._udp.       28403D12B536F657

That's showing a chip-all-clusters-app on an m5stack using platform mdns (B547AE8902014C18) and minimal mdns (28403D12B536F657).

[bzbarsky-apple]

Fixed by #17269.