I'm using the following:
- mDNSResponder 1790.80.10
- Bonjour Conformance Test (BCT) 1.5.2
- Linux 6.1.y kernel
I'm testing an Airplay 2 speaker as part of our self certification.
When BCT gets into the mDNS tests mDNSResponder fails the subsequent conflict test with this message:
ERROR 2023-06-12 10:37:29.398711-0500 _sub_conflict 03570: Device did not complete its probing sequence for a new name after a subsequent conflict arose for its previously acquired name.
BCT then retries three times with each retry failing with the same message.
Am I missing something from my software that interacts with the mdns daemon? Is this a known issue with the posix build for mDNSResponder? What can I do to get this test to pass?
Any help would be appreciated.
Ethan
Taking Kevin's suggestion to inspect the network traffic during the failing test I found mdnsd to be sending out two defensive probes when it should have only been sending one. The change detailed below allows mdnsd to pass the mDNS subsequent conflict test.
--- a/mDNSCore/mDNS.c
+++ b/mDNSCore/mDNS.c
@@ -10959,7 +10959,7 @@ mDNSlocal void mDNSCoreReceiveResponse(mDNS *const m, const DNSMessage *const re
rr->ProbingConflictCount++;
rr->LastConflictPktNum = m->MPktNum;
if (ResponseMCast && (!intf || intf->SupportsUnicastMDNSResponse) &&
- (rr->ProbingConflictCount <= kMaxAllowedMCastProbingConflicts))
+ (rr->ProbingConflictCount < kMaxAllowedMCastProbingConflicts))
{
LogMsg("mDNSCoreReceiveResponse: ProbeCount %d; restarting probing after %d-tick pause due to possibly "
"spurious multicast conflict (%d/%d) via interface %d for %s",
--