[1.3] [Linux] [minimal mDNS] Only the first record that match with the QRCode is used

[caipiblack]

I found a way to reproduce the issue with Chip-Tool (from matter v1.3.0.0) + EVE socket on Linux (but maybe any device should works).

The idea is to commission and OCW of a device twice using the same discriminator, (with a reset of the device between each) to produce a discriminator collision during mDNS browsing. Then when we want to commission the device the stack is supposed to "try" with the two records that match, but seems to try only one.

Reproduction steps

1. Commission the device with chiptool using code-thread command and open the commissioning window:

NODE_ID=1
./chip-tool pairing code-thread ${NODE_ID} hex:0e08000000000001000035060004001fffe002085b3a06d9fbaae9740708fddf7fea3db37d6d0510a4c522c99aa12d3dee4dda0a9d84180a030f4f70656e5468726561642d3864343501028d45041094ac0ee42500349f077635b7b7897df50c0402a0f7f8000300000f MT:-AM14IAN168JW.5W310 --bypass-attestation-verifier 1
./chip-tool pairing open-commissioning-window ${NODE_ID} 1 300 10000 1234

2. Reset the device
3. Do the same as step1 with a new NODE_ID and get the SetupQRCode! Example: MT:-AM14UC112US.I7TE00
4. At this point you can check avahi-browse -r _matterc._udp and you will see the same discriminator is used by "two devices".

root@hubmz-pu551:~# avahi-browse -r _matterc._udp
+   eth0 IPv6 E35631F10FD8EE54                              _matterc._udp        local
+   eth0 IPv6 D0F37589FCF9FA5A                              _matterc._udp        local
+   eth0 IPv4 E35631F10FD8EE54                              _matterc._udp        local
+   eth0 IPv4 D0F37589FCF9FA5A                              _matterc._udp        local
+     lo IPv4 E35631F10FD8EE54                              _matterc._udp        local
+     lo IPv4 D0F37589FCF9FA5A                              _matterc._udp        local
=   eth0 IPv6 E35631F10FD8EE54                              _matterc._udp        local
   hostname = [AEEF4DD7FABE72AA.local]
   address = [fd81:93b1:d692:1:3c62:9b41:33f:d330]
   port = [5540]
   txt = ["PI=" "PH=36" "CM=2" "D=1234" "T=0" "SAI=300" "SII=5000" "DN=Eve Energy" "DT=266" "VP=4874+80"]
=   eth0 IPv6 D0F37589FCF9FA5A                              _matterc._udp        local
   hostname = [86131472D2A7456D.local]
   address = [fd81:93b1:d692:1:cfab:18f9:11ac:ee1e]
   port = [5540]
   txt = ["PI=" "PH=36" "CM=2" "D=1234" "T=0" "SAI=300" "SII=5000" "DN=Eve Energy" "DT=266" "VP=4874+80"]
=   eth0 IPv4 E35631F10FD8EE54                              _matterc._udp        local
   hostname = [AEEF4DD7FABE72AA.local]
   address = [fd81:93b1:d692:1:3c62:9b41:33f:d330]
   port = [5540]
   txt = ["PI=" "PH=36" "CM=2" "D=1234" "T=0" "SAI=300" "SII=5000" "DN=Eve Energy" "DT=266" "VP=4874+80"]
=   eth0 IPv4 D0F37589FCF9FA5A                              _matterc._udp        local
   hostname = [86131472D2A7456D.local]
   address = [fd81:93b1:d692:1:cfab:18f9:11ac:ee1e]
   port = [5540]
   txt = ["PI=" "PH=36" "CM=2" "D=1234" "T=0" "SAI=300" "SII=5000" "DN=Eve Energy" "DT=266" "VP=4874+80"]
=     lo IPv4 E35631F10FD8EE54                              _matterc._udp        local
   hostname = [AEEF4DD7FABE72AA.local]
   address = [fd81:93b1:d692:1:3c62:9b41:33f:d330]
   port = [5540]
   txt = ["PI=" "PH=36" "CM=2" "D=1234" "T=0" "SAI=300" "SII=5000" "DN=Eve Energy" "DT=266" "VP=4874+80"]
=     lo IPv4 D0F37589FCF9FA5A                              _matterc._udp        local
   hostname = [86131472D2A7456D.local]
   address = [fd81:93b1:d692:1:cfab:18f9:11ac:ee1e]
   port = [5540]
   txt = ["PI=" "PH=36" "CM=2" "D=1234" "T=0" "SAI=300" "SII=5000" "DN=Eve Energy" "DT=266" "VP=4874+80"]

4. Re-commission the device using chiptool but using code command instead of code-thread using the QRCode from OCW:

NODE_ID=3
./chip-tool pairing code ${NODE_ID} MT:-AM14UC112US.I7TE00

The commissioning will fail because there is a discriminator colision and it seems that it only takes the first record that match. And the first one is the "older/bad one".

Bug prevalence

100%

GitHub hash of the SDK that was being used

5bb5c9e (v1.3.0.0)

Platform

other

Platform Version(s)

No response

Type

Platform Issue

Anything else?

Logs of the first commissioning with chip-tool (+ OCW):
chip_tool_1.txt

Logs of the second commissioning with chip-tool (+ OCW):
chip_tool_2.txt

Logs of avahi-browse after the device announce OCW 2 times:
avahi-browse.txt

Logs of the last commissioning with chip-tool when we try to commission the OCW device on-network:
chip_tool_3.txt

[bzbarsky-apple]

Looks like minimal mdns stops the browse as soon as it gets a single result... It shouldn't do that.