Multicast DNS (Bonjour, HomeKit, AirPrint, etc.) not working with bridge



  • I've been using pfSense for around four years quite happily.

    I recently added a 10Gb NIC to support a new server. In order for mDNS to work for connection to the new server (e.g. Time Machine backups), I created a Bridge and put both the old 1Gb LAN NIC and the new 10Gb NIC in it, setting LAN to the new Bridge.

    Following randomly-googled internet wisdom, I've enabled the Avahi package.

    Based on traffic I was seeing be blocked, I added a rule to allow ipv6 fe80::/10 to ff02::/16. For the LAN entry, this is successfully matching. (Just in case, I made the same rules for the two NICs and those aren't matching.)

    Now I have no problem seeing the server from the old LAN NIC side. However, HomeKit has trouble seeing our Phillips Hue bridge, which is connected to the same switch as our wifi and that traffic shouldn't be making it to the firewall at all.

    Looking at the entire state of mDNS with an older app called Bonjour Browser, I see that the Hue bridge has cloned itself over 100 times with a number suffix. I'm seeing number suffixes added to our Apple TVs. It's a mess.

    The Avahi package is very unclear as to what exactly it's doing in this case and there's no log integration. I'm wondering if there aren't some ipv4 link local multicast rules I should be adding to cause proper reflection of each physical part of the Bridge to talk to the others.



  • I experienced the exact same behavior from Avahi. It's not the most elegant solution, so I removed it entirely. Avahi was forcing renames of all of my devices because it would register one, and then for some reason it would see the name conflict and force the device to rename. This was true even for devices with a static IP address.

    I believe Avahi creates a list of mDNS devices on each side of the subnets you want to bridge. It provides the broadcast across subnets using that database. The renaming of devices is due to a naming conflict Avahi is detecting. Can't tell you why that is, but that's symptom you're seeing.

    I too have a Phillip Hue Bridge. My "fix" was to consolidate all of the MacOS devices onto the same LAN and keep them there. mDNS works within the scope of the subnet it lives on, so it worked perfectly that way.

    Avahi isn't the most elegant workaround, and it's not a silver bullet. I'm not entirely sure if there is still active development on it. But for simple things it works great. Once you get a little more complicated, you run into the issues you're seeing.



  • This is the thread on the new package. Did you update to the latest version? It addresses some local database issues, possibly the issue you are experiencing.

    https://forum.netgate.com/topic/134339/new-avahi-package



  • @tim-mcmanus said in Multicast DNS (Bonjour, HomeKit, AirPrint, etc.) not working with bridge:

    This is the thread on the new package. Did you update to the latest version? It addresses some local database issues, possibly the issue you are experiencing.

    https://forum.netgate.com/topic/134339/new-avahi-package

    I'm running 2.4.4 and installed Avahi from the Package Manager this past weekend. It appears to have installed 1.13! ಠ_ಠ

    I just uninstalled it and reinstalled it to 2.0.0.

    I'll update here if there's a behavior change.


  • Netgate Administrator

    You only need Avahi if you need connectivity between subnets. It sounds like you don't from your description. The Hue bridge and wireless clients are on the same subnet. The server and old LAN devices are on the same subnet because they are bridged.
    You only need Avahi if you need two connect between those two subnets.

    Steve



  • Installing 2.0.0 seems to have eliminated the duplication of mDNS entries. However, HomeKit still often can't see the Hue bridge.

    Although I may not need Avahi in the current setup, I intend to rearrange in such as way as to need it later.



  • The name duplication is documented and the fix is to set the cache period to 0 (disable)

    That said, I see the new v2.0 package sets this by default to stop the name problems.