Sonos speakers and applications on different subnets (VLAN's)

stephenw10 · Jan 28, 2020, 1:13 AM

To be clear were you all previously using a conf file with these lines in?:

bsr-candidate priority 5

# Smaller value means "higher" priority
rp-candidate time 30 priority 20

# Switch to shortest-path tree after first packet, but only after 100 sec.
spt-threshold packets 0 interval 100

...and now you're not setting that in the package?
The only thing you can't set exactly like that is the rp-candidate value which required a group prefix in the package:

🔒 Log in to view

Maybe it shouldn't or maybe that should just be all addresses.....

##################### DO NOT EDIT THIS FILE! ######################
###################################################################
# This file was created by an automatic configuration generator.  #
# The contents of this file will be overwritten without warning!  #
###################################################################
spt-threshold packets 0 interval 100
phyint igb2 enable
phyint igb0 enable
bsr-candidate priority 5
rp-candidate priority 20 time 30
	group-prefix 224.0.0.0/4

Steve

wanabe · Jan 28, 2020, 1:59 AM

@stephenw10 said in Sonos speakers and applications on different subnets (VLAN's):

To be clear were you all previously using a conf file with these lines in?:
bsr-candidate priority 5

# Smaller value means "higher" priority
rp-candidate time 30 priority 20

# Switch to shortest-path tree after first packet, but only after 100 sec.
spt-threshold packets 0 interval 100
...and now you're not setting that in the package?

I can confirm that when pimd is manually configured using the command line installation described by Qinn at the start of this thread that these lines were listed in the conf file exactly as you have listed. I too was wondering if these lines explained the difference in behavior.

The only thing you can't set exactly like that is the rp-candidate value which required a group prefix in the package:

🔒 Log in to view

Maybe it shouldn't or maybe that should just be all addresses.....

I also initially tried to replicate these values in the package and came across the need for a "Group Prefix". Given that my knowledge about this topic is so limited I abandoned my attempt.

I remain convinced that there are additional values that need to be set in the package other than the current default values to replicate the manual installation described by Qinn. I have installed and reinstalled both ways multiple times now with the same result. The manual installation works and the package does not (at least for my set-up). I would prefer and look forward to eventually being able to use the official package.

JeGr · Jan 28, 2020, 9:11 AM

@Deviant0ne said in Sonos speakers and applications on different subnets (VLAN's):

@JeGr Here is my configuration file (generated by the GUI package):
##################### DO NOT EDIT THIS FILE! ######################
###################################################################
# This file was created by an automatic configuration generator.  #
# The contents of this file will be overwritten without warning!  #
###################################################################
phyint igb0 enable
phyint igb0.35 enable
rp-address 10.0.1.210
rp-address 10.0.1.211
rp-address 10.0.1.212
rp-address 10.0.1.213
rp-address 10.0.1.214
I have all of my Sonos devices using DHCP reservations on my main LAN (10.0.1.0/24) and I am accessing the Sonos devices from a workstation that is hardwired to my network on a VLAN (35). All devices on the VLAN are using DHCP addresses in the 172.16.35.0/24 subnet and I have a firewall rule that allows access on the associated VLAN interface to access all Sonos-related LAN IP's (10.0.1.210-214). For what it's worth, every time I made a setting change and tested my Sonos vs. VLAN configuration, I would first stop/disable the PIM daemon, make my changes and then start/enable the PIM daemon again from the GUI.

Maybe try using a hardwired connection on another device as a proof of concept and then work backwards?

Could you have a look into your logs? If I add RP addresses to my Sonos devices I get a log line like

10:07:52.441 For src 172.27.3.31, iif is 5, next hop router is 172.27.3.31: NOT A PIM ROUTER

for every one of them (.30-.33) and only see the last one (.33) in the Status tab's Multicast Routing Table. Also only see the pfSense IPs (.3.1) and the calling IP in it (.1.128) but still nothing that works even remotely.

And all communication only seems to happen with .33, none of the other devices are popping up. Doesn't seem right to me.

Qinn · Jan 28, 2020, 3:59 PM

Preliminary testing gives that this works for me:

🔒 Log in to view
🔒 Log in to view

I did not add the Interfaces tab, as it will be different for all, but here I added all interfaces accept:
one interface that has the Sonos devices (in my case 5 speakers)
two interfaces that have phones/tablets/pc's that have Sonos applications

I hope it helps,

Cheers Qinn

Deviant0ne · Jan 28, 2020, 4:00 PM

@Qinn

I just reconfigured my installation from scratch using your screens as a template (i.e. I have removed all of the static LAN IP addresses for my Sonos devices from the RP Addresses section) and I can confirm this is working on a wired VLAN connection.

##################### DO NOT EDIT THIS FILE! ######################
###################################################################
# This file was created by an automatic configuration generator.  #
# The contents of this file will be overwritten without warning!  #
###################################################################
phyint igb0 enable
phyint igb0.35 enable
bsr-candidate priority 5
rp-candidate priority 20 time 30
        group-prefix 224.0.0.0/4

vacquah · Jan 28, 2020, 4:17 PM

What is the significance of the group prefix? Why is it required in the official package and why set it to group-prefix 224.0.0.0/4 ?

jimp · Jan 28, 2020, 4:25 PM

@vacquah said in Sonos speakers and applications on different subnets (VLAN's):

What is the significance of the group prefix? Why is it required in the official package and why set it to group-prefix 224.0.0.0/4 ?

It isn't required if you update to pimd pkg v 0.0.2 which I just put up this morning.

Deviant0ne · Jan 29, 2020, 6:09 PM

@jimp

I can confirm that after updating to v0.0.2 and removing the group-prefix setting via the GUI, this works in a wireless scenario. The only oddity is that I still have to wait for the connection to my Sonos devices to fail, disable the wireless on my iOS device and then re-enable it to get my Sonos app to work.

##################### DO NOT EDIT THIS FILE! ######################
###################################################################
# This file was created by an automatic configuration generator.  #
# The contents of this file will be overwritten without warning!  #
###################################################################
phyint igb0 enable
phyint igb0.35 enable
bsr-candidate priority 5
rp-candidate priority 20 time 30

It should also be noted that I was unable to use this method for setting-up a new Sonos application on a wired device installed behind a VLAN. For some reason, the Sonos application was unable to locate any of my Sonos devices on the main LAN with the above configuration settings.

Update 1: I think the only reason this is working on my VLAN'ed workstation is because that machine was originally part of the same network that the Sonos devices were attached to. Once I connected the workstation to the VLAN and cleared the Sonos application configuration data (controller reset), I was unable to regain access to my Sonos devices from the VLAN. The Sonos application data must have contained the LAN IP address(es) of at least one of my Sonos devices and since the workstation is allowed to access the Sonos devices via firewall rules, the application just picked-up where it left off. Once the configuration data is cleared, the Sonos application is not able to locate the Sonos devices on my VLAN. Back to the drawing board.

Update 2: After enabling "Allow IP options" in the firewall rules on both interfaces (VLAN, LAN) allowing access to my Sonos devices, I can confirm that I am able to configure the Sonos application from my workstation from scratch, indicating that PIMD is working normally.

stephenw10 · Jan 28, 2020, 6:20 PM

You could try also adding back spt-threshold packets 0 interval 100 which was in the original config. On the General tab:

🔒 Log in to view

Steve

edz · Jan 28, 2020, 7:47 PM

Can anyone help with my issue? I have a seemingly standard setup, pfSense 2.4.5 RC and pfblockerNG.

Installed v0.0.2 and followed Quinn's setup but I still see the below in my system log. 121.209.127.254 is my WAN gateway

Jan 29 06:45:53	pimd	31011	For src 169.254.0.1, iif is 0, next hop router is 121.209.127.254: NOT A PIM ROUTER
Jan 29 06:45:53	pimd	31011	Sendto to 224.0.0.1 on 192.168.50.1: Permission denied
Jan 29 06:45:53	pimd	31011	Sendto to 224.0.0.1 on 192.168.20.1: Permission denied

wanabe · Jan 29, 2020, 3:49 AM

I am happy to report that the new pimd pkg v0.0.2 works for me when it is configured to match the manual settings!! Here are screen shots of my settings:

🔒 Log in to view

Here is the config file that is produced which matches the file I obtained with the manual installation:

🔒 Log in to view

Finally here is the status output:

🔒 Log in to view

In the above status report: 192.168.6.1 is the interface that contains all of my Sonos devices, 192.168.2.8 is a computer which is wired to my LAN interface, 192.168.4.107 is my iphone wirelessly connected to my AP with the address of 192.168.4.2.

Both my wired computer on the LAN interface and my iphone on the WIFI interface can now recognize all my Sonos devices on the SONOS interface using the Sonos apps. I have not experienced the need to turn off/on the Wifi on my iphone as has been described by others. BTW, all my Sonos devices and my wired computers have statically assigned IP's. My wireless devices all receive DHCP leases.

Although this configuration finally works, I can't help but be curious about which of the above settings are really the most critical. I plan to selectively delete each setting until I can identify the one(s) that are really needed to make this work.

Thanks again to Qinn for all the time he has spent in getting this matter the attention it deserved. Also a big thank you to the developers for listening!

JeGr · Jan 29, 2020, 8:24 AM

@wanabe I'm happy for you that it works. Seriously. But I actually added the settings exactly like you. My only change is the "bind to none", "allow interface" approach which results in the same status (only three interfaces enabled).

Besides that I tried every setting combo like @stephenw10 or @jimp recommended but nothing so far. My Sonos speakers (4) are living in 172.27.3.30-33. That interface (VLAN 273) as well as the Guest Wifi I'm trying this on (VLAN 123) are in the status list. The only thing I have popping up in the status are

Virtual Interface Table ======================================================
Vif  Local Address    Subnet              Thresh  Flags      Neighbors
---  ---------------  ------------------  ------  ---------  -----------------
... (all disabled)
  5  172.27.3.1       172.27.3/24              1  DR NO-NBR
...
  8  10.20.30.1       10.20.30/24              1  DR NO-NBR
...
 10  172.27.3.1       register_vif0            1 

 Vif  SSM Group        Sources             

Multicast Routing Table ======================================================
----------------------------------- (S,G) ------------------------------------
Source           Group            RP Address       Flags
---------------  ---------------  ---------------  ---------------------------
10.20.30.144     239.255.255.250  172.27.3.1       SG
Joined   oifs: ...........         
Pruned   oifs: ...........         
Leaves   oifs: ...........         
Asserted oifs: ...........         
Outgoing oifs: ...........         
Incoming     : ........I..         

TIMERS:  Entry    JP    RS  Assert VIFS:  0  1  2  3  4  5  6  7  8  9  10
             0     0     0       0        0  0  0  0  0  0  0  0  0  0  0
--------------------------------- (*,*,G) ------------------------------------
Number of Groups: 1
Number of Cache MIRRORs: 0
------------------------------------------------------------------------------

That's the only thing that will pop up in "Status" when I launch the Sonos App on the smartphone connected to the WiFi. Nothing is found of course. Besides that my config looks exactly the same.

##################### DO NOT EDIT THIS FILE! ######################
###################################################################
# This file was created by an automatic configuration generator.  #
# The contents of this file will be overwritten without warning!  #
###################################################################
spt-threshold packets 0 interval 100
phyint igb2.273 enable
phyint igb2.123 enable
bsr-candidate priority 5
rp-candidate priority 20 time 30

As for the firewall rules they are in "debug" mode so access from/to media<->wifi is unrestricted ATM. I even added a pass rule for the sonos multicast address and see hits to it on the media and guest interface. But no traffic to the other network segment. Curious as to how to proceed in debugging.

wanabe · Jan 29, 2020, 12:47 PM

@JeGr Sorry this hasn't yet worked out for you. I'm not sure I can be of much assistance in helping you debug your setup. Until three months ago I had a consumer grade router and a layman's knowledge of networking. But, I am certainly willing to help in anyway I can .

A few details about my setup. I am using three physical interfaces and not VLANS. Don't know why this should make any difference but just letting you know. I took Qinn's advice and placed all my Sono's devices on a separate interface labeled SONOS. My wired computers are on the LAN interface and my wireless devices connect to an AP which is on the WIFI interface.

The only thought that comes to mind is have you enabled "Allow packets with IP options to pass" on the interface that contains your Sonos devices? I know that there has been conflicting experience with this, but I have discovered that it is necessary for my setup. The only firewall rule which I currently have is one that allows all traffic out of my SONOS interface and I have enabled the "Allow packets.." on this rule. This option does not appear to be necessary on my other two interfaces nor have have I had to create any additional rules

The only other thing I can suggest is to try the "bind to all" then selectively disable approach. I know it shouldn't make any difference but this is how pimd is configured by default on the manual installation. Worth a try if you haven't already.

hispeed · Jan 29, 2020, 6:19 PM

The setup from wanabe is working fine. I have only activated 2 interfaces where I want to route the traffic and this also works in WLAN and LAN.

Be aware that you have to allow promiscous mode on a ESXI if you have a setup with VM's as far as I know.

@jimp Thank you! Very nice work.

Deviant0ne · Jan 29, 2020, 6:23 PM

@JeGr

I removed all of my settings and then reconfigured PIMD from scratch using the exact same settings as @wanabe. I also enabled "Allow IP options" on the firewall rules allowing access to my Sonos devices (on both my LAN and my VLAN) per a suggestion by @PacketMan in another thread - only then was I able to fully access my Sonos devices across a VLAN, i.e. configure a new Sonos controller on a machine installed behind a VLAN. With just the PIMD settings configured, I was not able to get the multicast traffic to traverse the VLAN/LAN - enabling "Allow IP options" was the key for my configuration in the end.

wanabe · Jan 29, 2020, 10:27 PM

@Deviant0ne said in Sonos speakers and applications on different subnets (VLAN's):

@JeGr

enabling "Allow IP options" was the key for my configuration in the end.

I would like to additionally comment on this. I have tested this extensively on my system and can confirm that enabling "Allow IP options..." on your firewall rule seems to be critical in at least some set-ups. It certainly is in mine. There was some initial discussion that this might only be critical for android devices but I found it necessary for all the clients on my network both wired and wireless. Unlike DeviantOne, I have found it necessary only on the outgoing interface containing my Sonos devices. Remember, my setup may be different as I am not using VLANS but physical interfaces and all my Sonos devices are assigned to a dedicated interface. In testing this, I also found it critical to reboot my pfSense box before deciding whether any changes I made either were or were not successful. Simply restarting the pimd service doesn't always work. I have been fooled on multiple occasions in thinking that something was or was not working only to discover that rebooting changed everything. I have even resorted to concurrently rebooting all my test clients. It is a very laborious and time-consuming process but I strongly advise it.

stephenw10 · Jan 29, 2020, 11:22 PM

I would expect to need that to pass multicast traffic.
https://docs.netgate.com/pfsense/en/latest/book/firewall/configuring-firewall-rules.html#ip-options

johnpoz · Jan 30, 2020, 12:14 AM

Who wants to send me a couple of these sonos speakers? I want to test them out ;) but I sure don't want to spend the crazy prices for them.

A pair of these things go for 400$ And you people have these speakers but cant buy an actual real switch for like 200? Or real AP, and complain about a 350$ 3100?? WTF????

The pro set 2 speaker set is a freaking 1k.. And people balk and buying an actual full managed switch for 200.. WTF???

chpalmer · Jan 30, 2020, 12:23 AM

LOL johnpoz..

With Cisco we can pass multicast

With Vyos we can pass multicast..

Id like to test TNSR eventually to see if we can pass multicast.

There are use cases that make it necessary. If we (my company) cannot use pfsense for what we do we are fine with that. But it would be nice to do now with pfsense what the Cisco routers are doing just fine.

johnpoz · Jan 30, 2020, 12:45 AM

That is my point your spending 1k on couple of speakers but you have some shit 40$ switch and want your free router distro you put on some china box to do multicast routing because is too much of a pain to connect to the same L2 your freaking speakers are on with your $1k phone ;)

Your dropping 1k$ on a couple of speakers, how about get a real freaking switch is all I am saying ;)

This package just dropped, and the amount of posts on users that don't get it are lots of posts.. I can see way more of these how do I get pimd to work with XYZ in our future.. Not looking forward to it to be sure - so someone send me some of these overpriced toys so I can help these people! ;) Because you know connecting to ssid X when you want to play some music is so freaking difficult ;)