Hi @Markus123 

Thanks for posting in our business forum.

Markus123 wrote

Thanks for the response!

I worked through the troubleshooting guide already. In all fairness I just did not wireshark the actual mDNS transmissions assuming that the information about Sonos when it comes to mDNS is already out there in the internet and presumably reliable.

 

My scenario:

• ER7212PC v1.0 (Firmware 1.1.1)
  • VLAN 10
    • EAP660 HD(EU) v1.0 (Firmware 1.2.9) (wired to Port 12)
  • VLAN 20 (Main)
    • Cellphone (connected through WLAN on EAP 660HD)
  • VLAN 50 (IoT)
    • Sonos Speakers (connected through WLAN on EAP 660HD)

 

=> When I open the Sonos app on my cellphone it says it cannot find the Sonos system.

When I change the cellphones VLAN for testing purposes into 50 (same than the Sonos) it immediately works.

So plain and simple that to me is verification that the crossing of the vlan causes the problem.

That is very well documented all throughout the internet.

So far so "expected".

 

To exclude any potential mishaps I deleted all ACLs.

 

I then added a Profile -> Bonjour Service by the name of "Sonos" with Service ID "_sonos._tcp.local"

 

Lastly I added the mDNS within the "Services":

 

 

 

And that's when I would expect it to work but unfortunately doesn't.

 

And just to be clear: Browsing through the internet Sonos seems to be a pain in the a**... So I am not entirely sure if I did something wrong, if Sonos is just to awkward or if the ER7212PC is not supporting a needed feature or whether there might be a bug.

 

 

So without ACL, this is my test result. Same ER7212PC 1.1.1 firmware with EAP245 V3. See the attached. 
So if you say you have followed the guide I told you, don't get frustrated because it should work. Take a second and test it out.

Your other reply said the ER7212PC does not support switch ACL. So it is not a switch and it cannot use switch ACL.

If you need the IP-Group GW ACL, wait for the future firmware update as we are aware of this.

Hi @Markus123 

Thanks for posting in our business forum.

Markus123 wrote

  @Clive_A First of all thank you very much for your ongoing support, I really appreciate it.

 

It may be, that you get AirPlay working the way you tested it.

 

But I am not talking about AirPlay, but Sonos.

 

And again: Right now for testing/setup purposes I have no ACL's whatsoever. So ACL's are not the issue.

 

I just WireShark'ed the packages flying around while my Client (on VLAN A 192.168.40.1/24) is failing on finding the Sonos System (on VLAN 192.168.20.1/24). Actually there were no MDNS-Packages, but tons of other stuff that was probably related... e.g.

 

192.168.40.21    239.255.255.250    SSDP    259    M-SEARCH * HTTP/1.1 

192.168.40.21    3.248.46.105    TLSv1.2    211    Client Hello (SNI=msmetrics.ws.sonos.com)

 

So again.. Browsing through the internet Sonos seems to be "extra" when it comes to it's discovery process. So if you have any advice when it comes to Sonos I'd appreciate it, but I am not very hopeful.

 

 

Different topic: To try further I actually tried to connect to my Logitech Harmony Hub. Also it does not work cross VLAN. Inside one VLAN it works perfect. Again: No ACL's.

192.168.20.29    255.255.255.255    UDP    108    46336 → 5224 Len=66

 

 

And #3: Also my Philips Hue Bridge did not work cross VLAN. Inside one VLAN it works perfect. Again: No ACL's.

 

 

==>

I think I'll just give up on IoT's in a separated VLAN. And probably deny the (then static) IPs for the IoT-devices within one VLAN via ACL. If I'm not mistaken the end result would actually be the same...?!

 

Edit: One more question: Please confirm that if there are no ACL's NOTHING is denied, per default everything "is open". That's how I understood it. Just want to make sure, not that I actually have to add my first and only ACL "Permit UDP"-Rule...

First, I don't have Sonos for the test. And Sonos would not be possible to return after the Internet connection(activation). So I will not buy one and test this for you. I am using something else to show that the mDNS works and this issue might be originated from your misconfiguration.

I can send a request to the test team for testing but there is no guarantee about having a Sonos for the test as well.

Which I hope you can take a second to digest the mDNS config and learn to troubleshoot yourself with the help from the community.

If you don't wanna take part in this, just contact the support team and reflect on the issue, and ask for a remote session or something like further diagnostics.

Second, if Sonos works in the same VLAN, you should try Wireshark based on the guide I pasted earlier. Find out the Bonjour Service of the mDNS your Sonos actually broadcasts.

Also, how does the Sonos work? Does it work like AirPlay? If so, it should work as expected like AirPlay.

If you believe this is related to the router or system, do a test with the AirPlay if you have anything that can do the AirPlay. If you test this and AirPlay works correctly, or Spotify, very simple for them to set up and test, and if they don't work, you can let me know. I'll do some further tests.

So the screenshot shows the Bonjour Service should be _logitech-reverse-bonjour._tcp.local, you add this one and test it out. And pay attention if there are other bundled strings need adding to the system.

  @Markus123 

Markus123 wrote

  @Clive_A Thanks again for your answer.

 

Logitech Harmony:

Of course I would have liked to try to add the service "_logitech-reverse-bonjour._tcp.local". But for some reason Omada restricts the length of this string to 32... Could you maybe report this to your dev team so they can extend it to maybe 100 chars?

 

 

Sonos:

Like I said: As far as I understood from googling and wiresharking myself Sonos apparently does not use mDNS. So again: I gave up on that topic, the Sonos speakers are in my main VLAN together with my cellphones.

 

 

About the max 32 characters, that'll be evaluated by the dev. See how they'll respond to that.

Sonos, the test team tried that and it can work. Sonos uses the domain: _sonos._tcp.local

And the test team can get it working.

Hi @Markus123 

In addition to my previous reply, SSDP is UPNP, and based on the analysis, we think this is a problem with the Sonos client connecting to its server(on WAN). It does not have a relation with the VLAN interface, or mDNS.

My colleague informed me that it does not have anything to do with the IGMP as well. This is UPnP.