Hiya, I'm adding my situation to the list of mDNS issues. I've done some deeper digging though, so there's some newer information than I've seen in other threads.

 

First, a brief explanation of my network - it's fairly similar to many others though, so I won't go into too much detail here:

 

- Router (ER707-M2), switch (SG2016P), EAP (EAP650), controller (OC200) - all with latest stable firmware

- Two VLANs: Home, and IoT

  - IoT relevant devices: Sonos, LG TV

  - LAN relevant devices: computer, AirPod, Apple TV

 

Baseline, working as expected: When I'm on either VLAN (both wired and wireless), I see the expected mDNS entries correctly for the devices on the VLAN, such as `_airplay._tcp.local` (for all devices except computer), `_sonos._tcp.local` (for Sonos devices), `_display._tcp.local` (for LG TV).

 

As others have reported, the problem is getting the mDNS advertisements across the VLANs. Specifically, I want to advertise from "IoT" to "Home".

 

In my Omada controller, I've done the following, as your mDNS setup guide instructs:

 

- Profiles > Bonjour Service > Create:

  - Sonos: `_sonos._tcp.local`, `_spotify-connect._tcp.local`

  - Display: `_display._tcp.local`

- Services > mDNS > Create:

  - mDNS: enabled, "Gateway", services: "AirPlay, Sonos, Display", service network "IoT", client network "Home"

- ACL:

  - completely disabled

 

So far, everything seems "normal" - like other people have discussed on this forum before.

 

Then I (consistently) notice something weird: on my computer on "Home", I get advertisements for `_airplay._tcp.local` for "IoT" devices, but not for `_sonos` or the others.

 

At first I thought it might be to do with AirPlay being a built-in profile, and somehow my router wasn't able to use the custom ones I set up - I know some devices have low limits of the number of profiles/services/etc.

 

But then I fired up Wireshark to figure out what's happening, and I notice this:

 

 

The reflected advertisements (i.e. from the router at `192.168.10.1`) are often malformed for these services. In the above examples, we can see the `_airplay._tcp` advertisements are complete, but the subsequent advertisements get mangled. So, at the minimum, I'm able to AirPlay to my devices :)

 

I'm definitely no protocol expert on mDNS, but we can see in the 2nd screenshot some "valid" on the bottom right (i.e. the word "Bookshelf"), so it definitely appears to be sending data for the rest of the RRs. But there's evidently an error in how the data is constructed causing a failure to parse the data correctly.

 

(Interestingly, if I run `avahi-browse  _sonos._tcp -r -t -v` from within the "Home" VLAN, I can see references to the devices - perhaps their parser/decoder is more lenient than other parsers?)

 

My only positive takeaway here, is that because it's _trying_ to reflect the correct services, my ACL/services/profiles are configured correctly. I really think this is a bug within the Omada firmware.

 

Naturally, I'm happy to answer questions or provide you with more detail. I'd love this fixed, and to not have to run Avahi separately. Thanks!

 

Editing to add: I noticed in your tutorial (https://community.tp-link.com/en/business/forum/topic/620754), the screenshot near the bottom of the page which mentions Spotify also has "Malformed packet: mDNS". Very concerning.