avahi-0.6.31 doesn't pass Apple conformance test

Bug #1409872 reported by balaji
26
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Avahi
New
Unknown
avahi (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

We are working on to support Apple bonjour conformance test-1.3.0 and test fails with avahi version 0.6.31 for test case - SRV PROBING/ANNOUNCEMENTS. This test fails both on IPV4 and IPV6. And the configured network package - dhcpcd-6.6.4.

After parsing all logs(wireshark, apple PC and linux PC syslogs), and looks like avahi does not support a particular scenario in which Apple bonjour conformance test looks for. And also confirmed Apple test is inline with the RFC 6762 document for a special use-case(resolving SRV names on power up).

Below is the bug description,

setup:
Apple MAC with Bonjour conformance test - 1.3.0 (latest OS x)
Apple airport (latest version)
Linux device(PC) (ubuntu 14.04)

Configure all above devices to communicate on link local mode.

1) Start avahi bonjour conformance test on APPLE PC and Power ON linux device with avahi-0.6.31 and with _ssh._tcp.local service file

2) First Linux device sends SRV initial probe message on link and followed by apple test sends same SRV (Linux device) question on link,
       example:(commands on wire shark)
        Linux Device sends -> Who has "SSH" SRV QM question?
        Apple Bonjour Conformance Test -> Who has "SSH" SRV QM question?

3) Then after this there is no message from Linux device on network and Apple test expecting new SRV probe message from device.
      And so conformance test failed, since device couldn't able to send new SRV probe message with new name for service "SSH"

4) After parsing log files found that,
   avahi-daemon logged service with new name ("SSH #2") in log file and could not publish/probe SRV message on network.

  Linux device syslog messages,
      Loading service file /etc/avahi/services/ssh.service
      Service name conflict for "SSH" (/etc/avahi/services/ssh.service), retrying with "SSH #2).

balaji (whoisbalu)
affects: libvirt (Ubuntu) → avahi (Ubuntu)
information type: Private Security → Public
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in avahi (Ubuntu):
status: New → Confirmed
Revision history for this message
Stefano Cappa (stefano-cappa-ks89) wrote :

The same for avahi 0.7 also with bonjour conformance test 1.4.0

Revision history for this message
Stephen H. Gerstacker (sgerstacker-airsquirrels) wrote :

I posted this on the Avahi Github issue, but I felt it was appropriate here as well:

---

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.

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.

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.

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.

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.

Changed in avahi:
status: Unknown → New
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.