Problems with mDNS across VLANs

Problems with mDNS across VLANs

Problems with mDNS across VLANs
Problems with mDNS across VLANs
2024-06-09 15:49:33 - last edited 2024-06-09 15:57:39
Model: ER707-M2  
Hardware Version: V1
Firmware Version: 1.2.2

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.

  0      
  0      
#1
Options
3 Reply
Re:Problems with mDNS across VLANs
2024-06-09 18:17:57

For what it's worth, I believe it's an issue with how the NSEC records are created.

 

I got curious about it, so I manually "fixed" the binary offsets for the "next domain name" values (i.e. to point to values for valid aliases) and now Wireshark can parse the responses correctly. I obviously can't actually test that on the router though :) so I can't say for sure if it fixes the problem. However, having a completely valid response seems like a good start.

 

Only NSEC records seem to be problematic. The rest of the records parsed completely fine. This is consistent with the "it sort of works, but not really" I've seen in my network, and explains why some clients (i.e. `avahi-browser`) can still see the rest of the records, based on different parsing strictness.

 

I suspect the root cause is due to records being _copied exactly_ from one VLAN's announcement to be used on the other VLAN, but the "alias" fields no longer point to the same offset within a new record. And the fix would involve parsing the records to ensure the aliases point to valid offsets before forwarding on another VLAN.

  1  
  1  
#2
Options
Re:Problems with mDNS across VLANs
2024-06-10 15:23:35

Another small follow-up. Assuming you're using Avahi (or a fork of it), it seems that NSEC reordering causes malformed packets over there too: https://github.com/avahi/avahi/issues/379.

 

However, I have an Avahi reflector on my network at the moment which works perfectly. However it doesn't do the network segmenting with as much fine-grained control like Omada, so I'd still like to see it fixed on your end eventually :)

  0  
  0  
#3
Options
Re:Problems with mDNS across VLANs
2024-06-11 03:02:31

Hi @notjosh 

Thanks for posting in our business forum.

In my local test with Spotify, well, I don't have a Sonos, and there was no issue with Spotify at all.

 

Malformed is the cache and no specified service. I don't see it as a packet from Spotify.

Best Regards! If you are new to the forum, please read: Howto - A Guide to Use Forum Effectively. Read Before You Post. Look for a model? Search your model NOW Official and Beta firmware. NEW features! Subscribe for the latest update!Download Beta Here☚ ☛ ★ Configuration Guide ★ ☚ ☛ ★ Knowledge Base ★ ☚ ☛ ★ Troubleshooting ★ ☚ ● Be kind and nice. ● Stay on the topic. ● Post details. ● Search first. ● Please don't take it for granted. ● No email confidentiality should be violated. ● S/N, MAC, and your true public IP should be mosaiced.
  0  
  0  
#4
Options

Information

Helpful: 0

Views: 592

Replies: 3

Related Articles