Bonjour Conformance Testing - MDNS tests

Hey All,

I'm currently trying to use the BCT v1.5.3 to validate the avahi mdns implementation. This is not so much to validate the avahi implementation but to actually understand how the BCT works.

My setup is the following:

  • the testing machine, where the BCT runs, is a 13-inch MacBook Pro 2019
  • the DUT (Device Under test) where avahi runs is a Linux machine (arch) and avahi runs version 0.8

I've tried several connection between the two:

  1. they have been connected point-to-point by a single network cable and the IPs have been set statically
  2. they have been connected via a router (that's not connected to the interned) both by cable and with IPs statically set
  3. connected via a router where the BCT computer is connected via cable and the DUT is connected via WIFI.

My requirement is to run only the MDNS tests so the command I'm issuing on the BCT side is:

sudo ./BounjourConformanceTest -M -I en4 -DD -V -Aip None -Amac None

On the DUT side I start avahi as a daemon:

sudo avahi-daemon

And after that I also publish a service. I've done several tries but one that I think should be working is:

sudo avahi-publish -s "My HAP Service" _hap._tcp 3213 []

I can see the three packets that make up the probing packets spaced out at 250ms each on wireshark both on the DUT and on the BCT device and the BCT prints:

recv_packet 01997: received packet (96 bytes)
recv_packet 01997: received packet (96 bytes)
recv_packet 01997: received packet (96 bytes)

But the tests doesn't seem to finish correctly.

What am I doing wrong? Is my configuration incorrect/incomplete? Do I need to advertise a certain service?

Thanks for the response in advance.

Up vote post of radu_alx Down vote post of radu_alx
492 views
Posted by
radu_alx
Reply
Add a Comment

Replies

Hi,

BCT testing is a complicated topic, particularly when HomeKit is involved, so you may want to file a DTS incident if you want to really get into the details here.

However, what I immediately noticed looking over what you sent is this:

"...and with IPs statically set"

You weren't specific about which subtest you were starting with, but the first test the BCT does involves address self assignment which won't occur if your device has a statically assigned address. The packets here:

recv_packet 01997: received packet (96 bytes)
recv_packet 01997: received packet (96 bytes)
recv_packet 01997: received packet (96 bytes)

...are also small enough that they I think those are ARP packets, not mdns.

More broadly, I would STRONGLY recommend reading through and then following the instructions in the "Bonjour Conformance Test Guideline" document. The documentation in the BCT does a good job of describing what the test actually "does", but it doesn't really what you need to do. For example, here is what it says about the first test:

"I.1 Initial Probing The device is powered on. The test tool verifies that the device sends an ARP probe for its chosen address. For the details, please refer to "RFC3927 2.2.1. Probe details".

What that doesn't directly tell you (which the guidelines to) is that you actually start the BCT process by:

  1. Running BCT in the command line.
  2. THEN turning on the DUT

That's because all of the initial tests work by:

  • Listening for APR packets from the DUT*.
  • Responding to those ARP in ways that reproduce all of the various edge cases that the DUT is supposed to handle and verifying that they do what they were "supposed" to do.

*This is also why it's so important that you configure the underlying network correctly and don't involve other devices. You actually CAN have other devices on the same network, but unexpected ARP/MDNS traffic from those devices will distort/invalidate/break the BCT.

-Kevin Elliott
DTS Engineer, CoreOS/Hardware

Posted by
DTS Engineer
Up vote reply of DTS Engineer Down vote reply of DTS Engineer
Add a Comment