Bonjour Conformance Test does not pass

[lathiat]

Balaji X. Srinivas bxsrinivas@... writes:

I figured out why avahi-0.6.31 package fails the apple bonjour conformance test(v1.3.0) for test case SRV PROBING/ANNOUNCEMENTS.

The Bonjour conformance test requires that the hostname and service name on the device be resolved at the same time during one point.However avahi package waits until the hostname is resolved before resolving the service names.

And also noticed one thing that when device in the state of resolving the hostname,device could not probe service with new name though it logged info message as service name conflict.

And so the bonjour test logs following,

"SRV Probing: Device didn't send a new probe after test issued a probe denial in response to device's previous query".

And also verified on more case like, when device gets locked to hostname and then device should be able to probe SRV successfully.

I am yet to figure out the actual requirement of this with RFC document.

ref also: https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/1409872

[rajesh-anandalai]

We are facing the same issue. Would appreciate if this gets fixed.

[prabhachn]

Is this issue resolved? I am facing same issue even with avahi 0.6.32. Is it anything to do with configuration?

[lathiat]

It's not a configuration issue, basically we just haven't updated against the newest conformance tests. PRs would gladly be accepted for this.

[rheumess]

Sorry for my stupid question what is a PR. Is this problem still on the agenda?

[ViToni]

@rheumess A PR is a Pull Request.

[Ks89]

Damn I need also to pass the conformance test, but it isn't working. Do you have suggestions or a fix?

[lathiat]

Unfortunately not someone would need to work on it. No one has done the work to pass the test for some time but it did originally pass many years back so in theory shouldn’t be that difficult.

[Ks89]

Unfortunately I'm not an expert c programmer able to work on the source code of this lib, but I'm happy to test, if someone want to work on this issue.

[stack]

I've been researching this issue for my company. We specifically need to pass the mDNS portion of the BCT, so our scope is limited, but I do have some insights.

1. There is a definitely an issue if you are broadcasting a service with the "%h" wildcard as the service name. During the service collision portion, this falls down, but, if you are broadcasting under any other static name, you can get much further.

2. Newer versions of the test seem to require that specific services need to be broadcasted. This is not mentioned in the documentation anywhere, but, if I simple broadcast the _smb._tcp. service with any static name (e.g. "Living Room" or "SMB"), then the mDNS test does pass for BCT 1.5.0.

3. Technically we have to pass the mDNS portion of the test on BCT 1.3.1. With the set up above, we fail one test, and that's because one reply comes back from Avahi too quickly. Interestingly enough, BCT 1.3.3 seems to have addressed the timing issue, allowing slightly better tolerances. I believe the response in question needs to come in between the 250ms and 750ms window, and Avahi appears to come in slightly before that window. In the newer versions of BCT, this isn't an issue. I imagine either BCT 1.3.1 has too tight of tolerances, or isn't sampling improperly.

4. There are actually very strict instructions on setting up the test environment, and I even found that with the strict network set up, it could still potentially fail. You need an AirPort Extreme set up to act as an access point and that is it. No DHCP, no network connection, and crucially, no SMB broadcast if you're using a Time Capsule (this can break the test). The test machine was a MacBook Air running macOS 10.12 and connected via ethernet. The Avahi machine was an Asus laptop running Ubuntu 18.10 (Avahi 0.7) connected via wifi. Everything is link local. This all comes from the "Bonjour Conformance Test for Wi-Fi Alliance Version 0.1" document.

We're exploring whether we can actually use the 1.5.0 test, as this would make Avahi simply work in the mDNS portion of the test.

[lathiat]

1. There is a definitely an issue if you are broadcasting a service with the "%h" wildcard as the service name. During the service collision portion, this falls down, but, if you are broadcasting under any other static name, you can get much further.

Can you detail this further, what specifically falls down? It would be helpful to include the avahi debug log for the time period showing what it renames too and what the output from the conformance test is.

3. Technically we have to pass the mDNS portion of the test on BCT 1.3.1. With the set up above, we fail one test, and that's because one reply comes back from Avahi too quickly. Interestingly enough, BCT 1.3.3 seems to have addressed the timing issue, allowing slightly better tolerances. I believe the response in question needs to come in between the 250ms and 750ms window, and Avahi appears to come in slightly before that window. In the newer versions of BCT, this isn't an issue. I imagine either BCT 1.3.1 has too tight of tolerances, or isn't sampling improperly.

Can you share the log showing which reply comes back and what the time to the reply was?

[stack]

I will re-run the test as passing and not passing to get you the details, as well as packet captures. It will take me a couple days to get that together, but hopefully it's helpful.

I also confirmed that we can use the 1.5.0 test, so the 1.3.1 test is a non-issue for us at this point. I can still get some logs if you want them, but 1.3.1 is no longer publicly available. Only 1.4.0 and 1.5.0 are available.

[Marc-AxisLabs]

I've been researching this issue for my company. We specifically need to pass the mDNS portion of the BCT, so our scope is limited, but I do have some insights.

1. There is a definitely an issue if you are broadcasting a service with the "%h" wildcard as the service name. During the service collision portion, this falls down, but, if you are broadcasting under any other static name, you can get much further.

2. Newer versions of the test seem to require that specific services need to be broadcasted. This is not mentioned in the documentation anywhere, but, if I simple broadcast the `_smb._tcp.` service with any static name (e.g. "Living Room" or "SMB"), then the mDNS test does pass for BCT 1.5.0.

3. Technically we have to pass the mDNS portion of the test on BCT 1.3.1. With the set up above, we fail one test, and that's because one reply comes back from Avahi too quickly. Interestingly enough, BCT 1.3.3 seems to have addressed the timing issue, allowing slightly better tolerances. I believe the response in question needs to come in between the 250ms and 750ms window, and Avahi appears to come in slightly before that window. In the newer versions of BCT, this isn't an issue. I imagine either BCT 1.3.1 has too tight of tolerances, or isn't sampling improperly.

4. There are actually very strict instructions on setting up the test environment, and I even found that with the strict network set up, it could still potentially fail. You need an AirPort Extreme set up to act as an access point and that is it. No DHCP, no network connection, and crucially, no SMB broadcast if you're using a Time Capsule (this can break the test). The test machine was a MacBook Air running macOS 10.12 and connected via ethernet. The Avahi machine was an Asus laptop running Ubuntu 18.10 (Avahi 0.7) connected via wifi. Everything is link local. This all comes from the "Bonjour Conformance Test for Wi-Fi Alliance Version 0.1" document.

We're exploring whether we can actually use the 1.5.0 test, as this would make Avahi simply work in the mDNS portion of the test.

I struggled for a bit to get BCT to pass, the first point mentioned here about "%h" wildcard is an important one and there is no mention of it anywhere else I could find. I did not find that any specific services had to be published, in my case just publishing ._http._tcp was enough. I also didn't find any timing issues to contend with thankfully. Last, I found that using publish-resolv-conf-dns-servers=yes breaks the test in the probe conflict section. Received conflicting record [_domain._udp.local IN SRV 0 0 0 ; ttl=60]. Resetting our record. BCT then waits for a response and fails on timeout. My setup is as follows: device being tested is a linux running OpenWRT fork, with Avahi 0.6.32 (0.7 has not been ported to openWRT yet). TP-Link router setup according to Apple's environment setup instructions and finally BCT1.5.0 running on macbook pro with OS 10.15. I haven't finished running all the tests continuously but at least now I can pass the mDNS section which was always the troublesome one.

[dellgreen]

Can still confirm, that replacing all the wildcard '%h' entries in my service units with static values get the conformance test past the mDNS checks.

BCT: 1.5.2

[dellgreen]

Under BCT 1.5.2, it doesn't look like avahi is performing UNIFORM RANDOM REPLY TIME DISTRIBUTION as per rfc6762 section 6. It isn't an outright failure but falls into the warning category.

https://datatracker.ietf.org/doc/html/rfc6762#section-6

Results of test:

START (SHARED REPLY TIMING)
NOTICE  2022-06-21 12:25:34.098288+0100: Using PTR record _ssh._tcp.local. for test queries.
NOTICE  2022-06-21 12:25:49.674444+0100: 
Shared reply response times: min = 54ms, max = 56ms, avg = 55.00ms
WARNING 2022-06-21 12:25:49.674537+0100: 
0 percent of the replies within the correct range fell 
in the interval 20ms and 46ms (should be close to 25%).
WARNING 2022-06-21 12:25:49.674634+0100: 
100 percent of the replies within the correct range fell 
in the interval 46ms and 72ms (should be close to 25%).
WARNING 2022-06-21 12:25:49.674651+0100: 
0 percent of the replies within the correct range fell 
in the interval 72ms and 98ms (should be close to 25%).
WARNING 2022-06-21 12:25:49.674662+0100: 
0 percent of the replies within the correct range fell 
in the interval 98ms and 124ms (should be close to 25%).
PASSED (SHARED REPLY TIMING)

ConformanceTestResults.log

BCT-debug.log

[evverx]

There is a definitely an issue if you are broadcasting a service with the "%h" wildcard as the service name. During the service collision portion, this falls down

Looks like it's https://github.com/lathiat/avahi/issues/166