Sonos - broadcasting between different subnets

I think you should start by testing if the discovery is still working with S2 when devices are in the same network as the OH server.

@epicurean - yes, I’m running Avahi and pimd. And that worked great until I switched to S2.
@Lolodomo - I also thought about that, but tbh. it’s not worth the effort (I don’t have time for this right now so I’ll guess I’ll continue /wo the Sonos binding).

If there’s anyone who’d like to try out things - here are my findings;

  • Classic Sonos app + Sonos-binding + pfSense /w the settings above + Sonos devices in differnt VLAN: worked fine
  • S2 app + Sonos-binding + pfSense /w the settings above + Sonos devices in differnt VLAN: doesn’t work

It’s still possible to work /w S2 app, but not with the binding (in that specific case that someone runs controller(s) and devices in different subnets/VLANs).

Actually I read about another pfsense package - NOT avahi and pimd. I need to find the name of this package
@csi_oh can you share your pimd settings?

Update - its call updbroadcastrelay

I know this is quite an old thread and probably the original issue is resolved.

Just wanted to share my experience with OH and Sonos in different subnets:
I have my OH instance running in a Kubernetes (K3s to be exact) cluster which ‘automatically’ leads to OH running in a different logical network than my Sonos speakers do. And as described many times by others I experienced exactly the issue that is mentioned on the Sonos binding webpage (“COMMUNICATION_ERROR/not registered”).

What finally helped me was a small tool by Alsmith written in Python which he called ''multicast-relay", see Github. Here are the steps I followed:

  • Download the tool from Github and unzip it on one of the Kubernetes nodes. Must be one that has a connection to the local subnet which the Sonos speakers run in. Python needs to be installed on that machine.
  • Call ‘ip addr’ and find out the network interfaces for the two subnets: One is the subnet of the Sonos speakers and the other one is the subnet that the OH service (meaning the Kubernetes service that serves the OH pod) creates. In my case these were called enp1s0 and cni0.
  • Call sudo ./multicast-relay.py --interfaces enp1s0 cni0

Done! :slight_smile:

After a while in the OH log my Sonos speakers finally showed up magically with a message like “Added new thing 'sonos:PLAY1:RINCON_…” and in the OH UI there were not marked with a communication error anymore but instead with a status ‘online’.

2 Likes

Hi folks,

with Unifi you can put your controllers on a vlan, Sonos devices on another vlan, and enable mDNS globally and UPnP per subnet, and you are good to go. It works for controllers. BUT it doesn’t work for OH.

I don’t understand why. Who is the owner of the Binding, to try to collect more info about the implementation?

thanks
Andrea

Hi Andrea,

I also have Unifi in place, but my gateways are handled via pfSense. I have my mobile phone (with S2 app) and OH in VLAN1 and my Sonos speakers in VLAN2. Everything works fine with my mobile phone, but I can’t manage to get OH discovering the speakers.

I had a solution once with the first Sonos-app, but after upgrading to S2 it doesn’t work anymore.

I think this binding is maintained by @Lolodomo and there was also a request to add devices via IP where a workaround via MQTT is presented.

Well, I should create a docker with sonos2mqtt, but to me is another layer of complexity here. Why Sonos S2 is working and OH not, this is the question :slight_smile:

The UPnP implementation should be the same … but it is not for sure. I see some upnp datagrams coming from the router on controllers/OH vlan interface, apparently with source not in the same subnet (upnp is working with uuid, so I’m not totally sure). But rejected by OH.

mmmm investigating …

Troubleshooting …

I’ve added a second interface in OH in the VLAN where I have the SONOS devices. It seems the JUPnP is working properly in listening mode on all the interfaces, so now I can see my SONOS devices in OH.

What is still unknown @Lolodomo is why this configuration is working with Sonos controllers, but not with JUPnP library in OH:

  • vlan x for Sonos controller and OH
  • vlan y for Sonos devices

controllers (S2) can reach the devices, OH not.

Any idea?
If you need any log, please let me know. I’ve enabled mDNS and UPnP on my UNifi USG.

Andrea

Sorry I have no VLAN in my network and I am still using Sonos S1.
I an not the one who can help, I am not very familiar with these advanced network concepts.

perhaps someone that can clarify how the JUPnP works? or where I can find some docs to try to understand what is happening?

@jwiseman perhaps you can help me here? It seems there is a strange JUPnP behaviour to be investigated here.

Yes, JUPnp has issues with this OH 2.4 & 2.5. There has been attempts to fix it (via gitHub) last year but it was unsuccessful. There’s also an issue with the Samsung binding with the JUPnP combination also.

I’m running OH 2.4 with these versions of the bindings your mention around Sonos. I’ve been running these versions for over a year now with 15 Sonos devices on the network ( on a flat subnet ).

openhab> list -s | grep upnp
216 │ Active   │  80 │ 2.5.2                  │ org.jupnp
223 │ Active   │  80 │ 0.11.0.oh250M1         │ org.eclipse.smarthome.config.discovery.upnp
257 │ Active   │  80 │ 0.11.0.oh250M1         │ org.eclipse.smarthome.io.transport.upnp
openhab> list -s | grep sonos
212 │ Active   │  80 │ 2.5.0.201903252254     │ org.openhab.binding.sonos

Best, Jay

hi andrea, could you please tell how you added a second interface within OHs’ network settings?

thank you @jwiseman

Do you know if also OH 3 is affected?

thanks again
Andrea

Hi Christian,

well, I’ve just added a new interface in the system (openhabian here). LAN1 is the primary address, in the same subnet as Sonos controllers (this is for test, then I’ll move this interface to a separate subnet when I’ll migrate to OH3), and LAN2 is the other interface, not visible in OH’s network settings, but as far as I can see the JuPnP is in listening mode on all interfaces. And it works.

In my setup this is working, as I have LAN2 only for media contents (Plex and Sonos, and of course some AV devices, like Denon) and it’s totally separated from “untrusted” networks (like IoT).

What I’m not understanding is why enabling mDNS and UPnP in my Unifi USG router, controllers and Sonos devices on different subnets can communicate each other, but JuPnP is not able to do the same as what are doing the controllers.

Hope this helps
Andrea

Thanks for coming back, now I got you - you have two different NICs / network ports available. I’m running OH3 in a Debian-VM.

Strange in my case is that if I run a Sonos discovery, I can see in pfSense that pimd is routing broadcast at 239.255.255.250 correctly from OH3 to my Sonos speaker(s), but I have no item in the inbox.

I see in my USG the key point was to enable mDNS (globally) and UPnP for the two subnets. But I don’t have at the moment any specific fw rule in between, and bot subnets are “Corporate” (it means, no isolation or guest mode at all)

Look at this thread, it’s quite informative:

are you seeing the UDP answer back from speakers? It seems you are facing the same issue with JuPnP. I resolved adding the interface on speakers vlan :frowning: but I know, it’s a workaround

wait … if you see the multicast from OH, so the problem is OH is not receiving the answer back (or just ignoring).

If I well understood, the answer is an UDP unicast flow to the original UDP port OH was using as source of the multicast flow … it would be good if we can see this flow back … and if that flow hits the OH interface

i have mdns enabled via avahi package (obv. for the needed vlans).
as for upnp - that is an out-of-the-box functionality of pfsense.

basically, i never changed my settings since i shared my approach earlier in that topic.

what i can see after triggering sonos discovery out of OH3;

  • pfsense/pimd sees OHs’ broadcast on 239.255.255.250 (this is an UDP broadcast on :1900)
  • pfsense/pimd forwards that broadcast to speaker2
  • pfsense/pimd sees a broadcast on 239.255.255.250 between speaker1 and speaker2
  • pfsense/rule allowing a state from OH to 224.0.0.22 (this is IGMP)
  • pfsense/rule allowing a state from OH to 224.0.0.13 (this is PIM)
  • pfsense/rule allowing a state from speaker1 to 224.0.0.22 (this is again IGMP)
  • pfsense/rule allowing a state from speaker2 to 224.0.0.22 (this is again IGMP)

what i can see after controlling my speakers with S2;

  • pfsense/rule allowing states from S2 to speaker1/speaker2 (this is TCP on :1400 / :1403)
  • pfsense/rule allowing states from speaker1/speaker2 to S2 (this is TCP on :3500)
  • pfsense/rule allowing a state from speaker1 to 224.0.0.22 (this is again IGMP)
  • pfsense/rule allowing a state from speaker2 to 224.0.0.22 (this is again IGMP)
  • pfsense/pimd sees S2s’ broadcast on 239.255.255.250
  • pfsense/pimd forwards that broadcast to speaker2

so basically it seems to me that OH/sonos-binding can’t establish the connection to the speakers, but its broadcast reach the target.

edit #1:
running tcpdump -i [IF] udp and src [PFSENSE] and dst [OH] sees that the pfsense-gateway is replying back to OH:41944 where it sent the UDP:1900 broadcast for discovery. that would confirm your assumption “the problem is OH is not receiving the answer back (or just ignoring).”.

@jwiseman @Lolodomo an issue with JuPnP? as far as I understand, the Sonos Binding is fully on top on JuPnP framework.

Where I can find how JuPnP works?

It seems (but I need to double check with Wireshark) OH is sending the right discovery request to SSDP address, and it’s routed properly to the Sonos vlan … the answer (Unicast UDP) is routed back, but it seems ignored by the OH host.

that is not happening if the Sonos device is on the same vlan as OH host. It seems like the OH is expecting a local answer, and not an answer by another subnet.

Andrea

JuPnP failing - causing devices to go offline · Issue #5892 · openhab/openhab-addons · GitHub

Best, Jay