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
jwiseman
(Mr. Wiseman (OH 4.2 Snapshot on Pi4))
40
Install this though the karaf console. You will 1000% have to restart openhab for this to work properly once you install it. It also has a tendency to stall/fail if the system has been up for a while so it may take a few attempts.
Go into services/runtime.cfg and paste the following:
You’re going to want to paste that config in after you load the new jar, while the OH service is shutdown.
This in theory should help if not completely resolve the issue. This works on both OH2.5 and OH3.
Please let me know if it helps, or completely does not so we can track as part of the PR above.
EDIT: To be clear, this only resolves some of the issues specific to JuPnP. The issue of the device being on a seprate VLAN may or may not be resolved by this. That is due to the fact that you aren’t repeating UPnP messages across the VLANs as well as some funny business Sonos did.
well basically that is exactly what i’m doing with that multicast-relay. again, all of this already worked already. i’m also fully aware that the binding-desc states that this might be an issue, because it was coded for the setup that both OH and the sonos devices are within the same subnet. but (!) we are already at that point where OH reaches the speakers in another subnet, but can’t discover them, even though the speaker “talks back”. what @ariela did is just to add another interface and voila, it seems to work for OH. so actually (if you ask me) the issue should be somewhere between receiving the package and interpreting it.
Sorry, should have read the thread more before replying. There are a few things here that could be causing the issues. I’ve done mDNS/UPnP across subnets before, but it’s never been clean. @Lolodomo please keep me honest about the way the Sonos binding works with my thoughts here. The Sonos binding is getting it’s basic data from jupnp obviously. JuPnP establishes a registry internally of all devices that it sees. So the fact that you’re seeing them is a byproduct of that. You mention that you grabbed some pcap and that the OH host is ignoring the reply packet. Can you check the TTL on the return packet? I vaguely remember somewhere that the Sonos packets all had a TTL of 1 which is causing them to get dropped when it gets decremented.
hi! took me some time, because i’ve set up opnsense in parallel to see if it’s a routing issue on the firewall itself. answer is plain simple; yes.
i just installed an opnsense plugin called “os-udpbroadcastrelay” (same as @pstoermer was mentioning here) with the most basic config (it literally tells you the sonos params in the help), that’s all… re-run oh’s discovery, all speakers instantly in my inbox.
Pay attention with a multicast-relay, my friend. I’ve tried this in my environment (all Ubiquiti), and there were some crazy behaviours …I preferred to add a new interface on OH much easier, and still acceptable from security point of view.
Nothing complex … depending on your implementation. I’ve added a new interface in my openhabian vm hosted by Synology … a leg in the vlan where I have all my Sonos devices … and voilà, everything’s working
Not 100% sure you convinced me … I have this implementation:
vlan 3: sonos devices (and other media devices that use UPnP, like Denon …)
vlan 10: sonos controllers
vlan 17: OH3
Sonos controllers are working correctly, and they see all Sonos devices.
OH3 can discover automatically Denon, but not Sonos
OH3 is able to discover Sonos only adding a new interface on vlan 3 in my vm
vlan1 <-> vlan3 worked until sonos s2
vlan2 <-> vlan3 always worked, even after sonos s2 (as you said: “sonos controllers are working correctly, and they see all sonos devices.”)
the settings in opnsenses’ “udp-broadcast relay” are quite simple (if anyone wants to give it a try);
relay port: 1900
relay interfaces: the ones you need to broadcast between (in my example from above vlan1, vlan2, vlan3)
broadcast address: 239.255.255.250
additionally, i added a very simple firewall rule on vlan3 that allows traffic between “sonos speakers” (= alias) to "sonos controllers (= alias).
after a few day of testing, i can’t find any anomalies in my unifi controller that are bound to upnp or multicasting.
if i was asked to sum that whole thread up for anyone joining in late;
it is not possible /wo additional “implementations” to get the sonos binding to work if oh3 and the sonos speakers are in different subnets
though, there are 3 different approaches that lead to working results;
A) @pstoermer approach by running a python-based multicast-relay in kubernetes is described here
B) @ariela approach by adding a new interface in openhabian is described here and here
C) my approach (non-kubernetes and non-openhabian), by using the “os-udpbroadcastrelay” plugin for opnsense is described right above
I’m quite interested on how you implemented opnsense in a unifi environment I’m using USG, that is not a firewall indeed … and I would add an additional layer of security. Perhaps we can discuss this topic offline
Hi Christian,
I use pfsense instead of opnsense. Can you detail how you implemented the udp-broadcast relay as I do not see this plugin. is it a command line install in pfsense?
i started with an USG4pro, but was not happy at all and sold it after only a few weeks. my next step was installing pfsense on a ci323 (because of the needed 2 nics [wan/lan]) - with the goal to have dns/firewall/dhcp/… all at one place. what i kept were the unifi ap’s, because - hands-down- they’re awesome.
i then changed the ci323 to a protectli appliance (also with pfsense). at that time i was already thinking about switching to opnsense, but due to time issues, i decided to still go with pfsense (just imported the old config after applying the necessary changes [ci323 has two nics, protectli fw4b has 4]).
for failover, i decided to buy another fw4b few months ago, but this time i wanted to (finally) give opnsense a try, so i set it up in a seperate subnet so that two firewall appliances won’t interact with each other.
i’m really happy now with opnsense (went live last week) and i will stay with it (no plans to change back - also because of the late “news” of pfsense and their way back to closed source).
all in all i have my opnsense in place that is connected to my modem and my managed switch (to apply vlan tags). opnsense is solely responsible for firewalling/rules, providing dhcp and also serves as dns. of course there are some additional features like ntp and that broadcast-relay…
from time to time i fire up the unifi controller (hosted in a vm) if i need to change things - but this is very rare.
hi buddy. pfsense doesn’t have a pre-built package for that broadcast-relay. the only thing you can do is to follow peter’s approach.
the latest pfsense distros come with pre-installed python, but please keep in mind that there’s no symlink from python to the installed pkg. so if you want to call a python-script (and we’re talking here about a python-based relay), you would need to call it with e.g. python3.X <your_script>.py.
please also note that the relays’ description says “multicast-relay.py requires the python ‘netifaces’ package.” so you will also need to install pip on your pfsense to get that needed ‘netifaces’ package installed on your machine.
again, i never installed that relay on pfsense, so unfortunately i can only try to point you into the right direction.
Hi @epicurean,
I would definitely give it a try with the approach @csi_oh mentioned. In my description I talk about Kubernetes a lot and that may sound a bit over the top. But the part that you may need is way simpler: Very roughly speaking you need to have a (virtual) machine that has two network interfaces, one for each network. In my case the network interfaces have the names enp1s0 and cni0. You find ‘your’ names by calling ip addr and then looking for familiar IP addresses. This command might help you on this, e.g. if one of the networks is starting with 192.168:
Thank you Christian and Peter for responding. All this info appears to be way over the top for me so i will endeavour to read up to understand. Really makes me wonder if all this effort is worthwhile just to be able to control Sonos devices with OH
This might not be relevant because I don’t use the OpenHAB plugin for Sonos. Instead I use SONOS2MQTT.
I’ve just implemented VLANS and after fiddeling a bit with my firewall rules I got it working without the need for shuffling broadcasts between my VLANS.
My Sonos speakers reside in the IOT VLAN and OpenHAB together with the SONOS2MQTT service resides in my SERVERS VLAN.
I set the env variable SONOS2MQTT_DEVICE pointing at my SonosZP in my IOT VLAN so no need for any broadcasts. Also, the sonos-tts-polly service works great. I feel it’s a “clean” solution, and I’m happy to have expelled yet another gadget to my IOT VLAN.
Below is my Vyatta zone based firewall rule that I use on my EdgeRouter in case someone is interested.
name IOT_TO_LAN {
default-action drop
description "IOT IPv4 traffic to LAN"
rule 1 {
action accept
description "Established and related"
log disable
protocol all
state {
established enable
related enable
}
}
rule 2 {
action drop
description "Drop invalid state"
log disable
protocol all
state {
invalid enable
}
}
rule 210 {
action accept
description "Allow traffic to TTS Server from Sonos ZP"
destination {
group {
address-group TTS_SERVER
}
port 5601
}
log disable
protocol tcp_udp
source {
group {
address-group SONOS_ZP
}
}
}
rule 220 {
action accept
description "Allow traffic to SONOS2MQTT from Sonos speakers"
destination {
group {
address-group SONOS2MQTT
}
port 6329
}
log disable
protocol tcp
source {
group {
address-group SONOS_SPEAKERS
}
}
}
rule 250 {
action accept
description "Allow traffic to MQTT Servers"
destination {
group {
address-group MQTT_SERVERS
}
port 1883
}
log disable
protocol tcp
}
rule 600 {
action accept
description DNS
destination {
group {
address-group DNS_SERVERS
}
port 53
}
log disable
protocol udp
}
}
much easier, and still acceptable from security point of view.
I’m using USG, that is not a firewall indeed … and I would add an additional layer of security. Perhaps we can discuss this topic offline