Update – I have left the below in place for archive/interest purposes, but since the introduction of firmware 1.8.0 for the UDM-Pro there is a simpler solution. If the
UPnP service is activated on the controller then (silently, and in an undocumented way) a
ssdp service is also started! So no need for a podman container any more
My Sonos system is getting a bit old now. It has served me well for more than 10 years, and will – I hope, now that Sonos changed their mind about long term support – keep me going for a few years more. But old age does come with its own set of problems, and in particular, many of the older Sonos’s (and even some of the newer ones) have issues working with my Unifi Dream Machine Pro (or UDM-Pro) networking hub across vlans.
Why won’t my controller work?
The issue first arose for me back when I was using the old USG, before I got gigabit broadband. It was a REALLY solid piece of equipment – uptimes were regularly in the many-month category. Its real strength (and perhaps weakness, when it came to supporting it) was the immense customisability it offered, Sure, it offered this by the editing of an obscure
config.json file, but hey – who doesn’t like to geek?
But time passes, and it was pretty obvious that the USG just wasn’t going to able to cope with the throughput that I wanted from my new shiny broadband earlier this year. So now I have put it in a drawer waiting to be sold and my affection is focussed on the the UDM-Pro.
Now, I – like quite a few people – am pretty distrustful of IoT equipment. Lots of it ships from countries with a less-than-enviable record of privacy protection, it gets old and doesn’t get updated and become vulnerable, and sometimes things like to have a snoop around. So I keep all my non-personal network items on a dedicated IoT vlan. This includes all my Sonos players. But not, importantly, their controllers, which these days are on the family phones which live on the main vlan.
Back in the good old USG days, getting the Sonos to speak to the controllers on the trusted vlan was just a matter of a little judicious editing of the old
config.json. But that file has no equivalent in the shiny UDM-Pro and – though many users reported no problems with getting things working – it just didn’t happen for me.
How old is old?
The reason why the UDM-P works out of the box for some people (after having enabled mDNS, at least) but not for me remains obscure. I think the reason is to do with my Sonos kit. As I mentioned, it is of a certain age, and I haven’t bought any new for a long time. In particular, none of my kit is Airplay 2 compatible.
So my suspicion is that people who are not having problems have at least one Airplay 2 compatible Sonos device. I guess that they are connecting directly to their Unifi network (as opposed to using SonosNet, which I use).
EDIT – A reader who has 100% Airplay 2 compatible devices has reported having the same issue. So there goes that theory.
Whatever. My guess is that it’s the age of my Sonos kit which is the problem here. And given its longevity, my guess is that many of us share this problem.
Old age is no barrier to success
So what is it about the older kit that makes it an issue? And what exactly was going on in that
config.json that solved the problem?
Well, the issue is that Sonos (at least in its pre-Airplay 2 devices) uses a slightly obscure protocol called SSDP to cross vlans to discover devices. Back in my USG days I could allow that traffic to cross vlans by using an implementation of
igmp-proxy. But no such service is available for the UDM-Pro.
(Of course, this is only for discovery, not for communication. So I still have to open firewall ports for any solution to work.)
The solution to the discovery problem that I came across was – unlike the USG – simple and elegant.
Welcome to the future
The UDM-Pro’s (and it’s smaller sibling, the UDM‘s) are based on a container, that is to say they use a system related to
docker to run virtual machines. What is needed to solve this particular issue is to have a container running something that will successfully relay the SSDP multicast packets between vlans – just like @alsmith‘s
multicast-relay program does.
Now the UDM-Pro does not run Docker. Instead it runs a close relative called Podman, identical in all practical respects for the basic user. So in order to get all that multicast goodness running, all that I need to do is to run a simple command on the UDM-Pro.
On my system I chose to have my main (untagged) vlan as #98 and my IoT vlan as #99. (I use slightly obscure numbers for my main vlan. Then I don’t have difficulty with IP clashes if I am “phoning home”. For example, hotel networks often have addresses in the 192.168.1.xxx range.) And I decided to use the native mDNS support offered by the UDM-Pro, rather than the one in the container.
So in my case the command I needed to run (interactively) to download and launch the podman container was:
podman run --rm -it --network=host -e OPTS="--verbose --noMDNS" -e INTERFACES="br0 br99" docker.io/scyto/multicast-relay
(Of course, you will want to change the
99 to match your own case. And if you use a tagged vlan as your trusted network or use multiple vlans then you will need to add some more interfaces.)
When this is up and running go and check that the controller can see the Sonos’s. Then marvel at just how easy that was.
Running the same thing daemonised is easy. I just run:
podman run -d --restart=always --network=host -e OPTS="--noMDNS" -e INTERFACES="br0 br99" docker.io/scyto/multicast-relay
And then forget about it.
There’s always a but …
Well, almost forget about it.
podman instances like this will not survive reboots or firmware updates, So I keep a small shell scrip in
mnt/data/nerdygeek/afterboot.sh to lauch this command, which I run manually every time I restart. It’s easy to see whether the container is running or not with a quick
Or, there is always a method for surviving reboots (though not firmware updates). I haven’t implemented this, as I don’t reboot my UDM-Pro often enough to make it worthwhile.