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

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

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.

You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to avahi in Ubuntu.

  avahi-0.6.31 doesn't pass Apple conformance test

Status in Avahi:
Status in avahi package in Ubuntu:

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,

  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).

To manage notifications about this bug go to:

Mailing list: https://launchpad.net/~touch-packages
Post to     : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to