back to back pairing attempt with iOS chiptool fails

[kean-apple]

Problem

Back to back pairing attempt with iOS chiptool fails

SHA: 8e8f419

1. Pair M5 board using iOS chiptool using QR code- verify able to toggle light.
   2.Unpair M5 board using iOS chiptool (Unpair device option)
2. Reset M5 board using Setup->Reset to Factory4.
3. From iOS ChipTool app, launch QR code scanner, try to enter pin code to pair -> pairing doesn't start...not messages seen in M5 logs
4. Try to pair via QR code , pair doesnt start - app may crash

2022-03-04 10:26:52.732061-0800 localhost CHIPTool[402]: (CHIP) DevicePairingDelegate Pairing complete. Status ../../../../../../../../../../../connectedhomeip/src/controller/CHIPDeviceController.cpp:1365: CHIP Error 0x00000032: Timeout

Seen 100% of times

Other note:

• If I paired via chiptool CLI then reset the M5 board, I'm still able to immediately back with iOS chiptool
• Did not see this yesterday with 3b83461

Proposed Solution

<suggested fix, suggested enhancement>
pairing-2nd-attempt-failed-m5logs2.txt
2nd-pairing-attempts-fail-chiptool-log2.txt

[bzbarsky-apple]

@kean-apple Are you in a position to possibly bisect this to figure out which commit caused the problem?

[kean-apple]

unfortunately looks like ESP32 commissioning was broken for sometime yesterday. Tried 508f682 and I couldn't pair the M5 board..so all I know somewhere between 8e8f419 & 3b83461 it broke

[bzbarsky-apple]

Well, this is broken for me even on 3b83461 but basically the problem is that emberAfOperationalCredentialsClusterRemoveFabricCallback does:

    app::DnssdServer::Instance().StartServer();

which is broken, because it then starts advertising as commissionable (no fabrics, no arg) while we are not in fact commissionable.

Then we reset the device, which puts it into commissionable mode, but over BLE, not IP. And the stale advertisement is still hanging around, so when CHIPTool tries to browse for the commissionable node over both BLE and IP it finds the bogus IP thing and can't talk to it.

So:

1. We need to fix the commissioning flow to try the other transport when what it discovered fails. @cecille @sagar-apple
2. The StartServer() in removeFabric is just not doing the right thing. Looks like it was added in [DNS-SD] Refresh services on RemoveFabric command #10499 by @Damian-Nordic ... What we really want to do here is remove all operational (but not comissioning!) advertisements and then AdvertiseOperational. @andy31415 do we have an API for doing that?

[bzbarsky-apple]

Oh, and we could spot-fix this by calling StartServer with the "not in commissioning mode" value... but we might in fact be in commissioning mode and advertising that, independent of the RemoveFabric bit going on. So that would just cause a different sort of problem.

[sagar-apple]

Ah good catch, Boris.

Yeah this seems to indicate that the commissioning logic needs to better handle this.

But to be honest, all clusters app could also do a better job to cleaning up before killing itself.

That's obviously not the right fix though. Seems like we have to prefer BLE if it's available.

[bzbarsky-apple]

I have some ideas for fixing up the all-clusters-app bit here, actually. Will see if I can come up with a PR.

But yes, we really need to fix the commissioning logic.