[BUG] [ESP32] TC-OPCREDS-3.6 device is discoverable even after removing fabric

[VaishaliAvhale]

Reproduction steps

• Tested on Te1.1 commit
• After removing fabric device is still descoverable over TCP
• esp32 and chip-tool logs attached below
  chip-tool.txt
  esp32.txt

Bug prevalence

Everytime

GitHub hash of the SDK that was being used

7e69c66

Platform

esp32

Platform Version(s)

No response

Anything else?

No response

[bzbarsky-apple]

So the esp-32 log has:

[0;32mI (37628) chip[FP]: Fabric (0x1) deleted.�[0m
�[0;32mI (37628) chip[ZCL]: OpCreds: Fabric index 0x1 was removed�[0m
�[0;32mI (37628) chip[DIS]: Updating services using commissioning mode 0�[0m
�[0;32mI (37638) chip[DIS]: CHIP minimal mDNS started advertising.�[0m

but this does not seem to be removing the PTR record pointing _matter._tcp to 25360332D3C029DF-0000000000000001 or the SRV and TXT records, for that matter. This looks like a minimal mdns bug.

[andy31415]

I do not currently have the bandwidth to debug this.
This could be a minmdns bug or minmdns may just do what it is being told to do and some implementation details in advertisement logic are wrong.

[bzbarsky-apple]

I just tried building chip-all-clusters-app on Mac with minimal mdns, like so:

 scripts/examples/gn_build_example.sh examples/all-clusters-app/linux out/debug/standalone is_asan=true chip_mdns='"minimal"' && rm -rf /tmp/chip* && ./out/debug/standalone/chip-all-clusters-app

and then running the chip-tool commands to do commissioning followed by fabric removal:

./out/debug/standalone/chip-tool pairing code 17 34970112332 && ./out/debug/standalone/chip-tool operationalcredentials remove-fabric 1 17 0

and the PTR records at least seem to be removed correctly, at least as far as the Mac mdns subsystem is concerned:

% dns-sd -B _matter._tcp
Browsing for _matter._tcp
DATE: ---Thu 09 Feb 2023---
10:03:31.528  ...STARTING...
Timestamp     A/R    Flags  if Domain               Service Type         Instance Name
10:04:48.562  Add        3  14 local.               _matter._tcp.        9B736E04C6E52C30-0000000000000011
10:04:48.562  Add        3   4 local.               _matter._tcp.        9B736E04C6E52C30-0000000000000011
10:04:48.562  Add        3   5 local.               _matter._tcp.        9B736E04C6E52C30-0000000000000011
10:04:48.562  Add        2   6 local.               _matter._tcp.        9B736E04C6E52C30-0000000000000011
10:04:50.424  Rmv        1   4 local.               _matter._tcp.        9B736E04C6E52C30-0000000000000011
10:04:50.424  Rmv        1   5 local.               _matter._tcp.        9B736E04C6E52C30-0000000000000011
10:04:50.424  Rmv        1   6 local.               _matter._tcp.        9B736E04C6E52C30-0000000000000011
10:04:50.424  Rmv        0  14 local.               _matter._tcp.        9B736E04C6E52C30-0000000000000011

And checking dns-sd -L 9B736E04C6E52C30-0000000000000011 _matter._tcp shows the SRV record is removed too.

This needs debugging to see how much is minmdns, how much is avahi, how much is something else.

[andy31415]

For easier read, here are the test steps I see in the original test description:

./chip-tool pairing code 1 34970112332 --trace_decode 1
./chip-tool operationalcredentials remove-fabric 1 1 0

then it looks like esp32 contains:

avahi-browse -rt _matter._tcp

[bzbarsky-apple]

@VaishaliAvhale I think what would be most useful here is logs from avahi showing what it thinks is going on....

[wqx6]

I cannot reproduce the issue on ESP32-C3. Here are my steps:

# pairing the device
./chip-tool pairing ble-wifi 1 ssid password 20202021 3840

avahi-browse -rt _matter._tcp
# I got results and I can see mdns query and response in wireshark.

# remove fabric
./chip-tool operationalcredentials remove-fabric 1 1 0

avahi-browse -rt _matter._tcp
# I got no result and I can see only mdns query and no mdns response in wireshark.

[VaishaliAvhale]

It was an avahi cache issue.
It worked fine when we clear the avahi cache.

[bzbarsky-apple]

Well, hold on. Shouldn't the goodbye packets from the device clear the avahi cache? Why is that not happening?

[wqx6]

@bzbarsky-apple I have checked on wireshark. The goodbye packets are sent by ESP32 after remove-fabric command.

The goodbye packets should be sent after #23661

[cjandhyala]

@VaishaliAvhale closing the issue, pls re-open If you think this is still an issue