Sonos speakers and applications on different subnets (VLAN's)
-
@jimp said in Sonos speakers and applications on different subnets (VLAN's):
If it works differently then there is either a difference in your configuration or a difference in the command line the package is running. Check the config you are using with the FreeBSD package compared to the GUI, and look at the
ps uxaww | grep pimdoutput for both as well.The version of
pimdis the same, and there shouldn't be anything different about how it operates.@jimp In my original working setup with the manual install of the FreeBSD package, the only options enabled ( by default ), besides the interfaces I had to disable are:
bsr-candidate priority 5 rp-candidate time 30 priority 20 spt-threshold packets 0 interval 100I have since switched to the use of the recommended setup for the new package - "bind to none" and only enable interfaces needed. It seems to be working for me - but not anyone else in the house. Before, it all worked.
ps uxaww | grep pimdwith my current setup gives me :root 14572 0.0 0.1 6500 2276 - S 18:10 0:00.00 sh -c ps uxaww | grep pimd 2>&1 root 14782 0.0 0.0 388 272 - R 18:10 0:00.00 grep pimd root 57669 0.0 0.1 5996 1956 - S 04:09 0:01.05 /usr/local/sbin/pimd -c /var/etc/pimd/pimd.conf --disable-vifs -s notice -
Can we see the conf file the package generates compared to your manually created workinh one?
-
manualy conf file - only changes I add to this is the interface to disable :
# Exmaple configuration file for pimd, the original PIM-SM router # # See the pimd(8) man page for details on all the settings. This file # only gives very brief examples and is intended as a quick start. # # NOTE: The order of the settings matter! # ## # default-route-distance <1-255> # default-route-metric <1-1024> # hello-interval <30-18724> # # igmp-query-interval <SEC> # igmp-querier-timeout <SEC> # # phyint <local-addr | ifname> # [disable | enable] [igmpv2 | igmpv3] # [dr-priority <1-4294967294>] # [ttl-threshold <1-255>] [distance <1-255>] [metric <1-1024>] # [altnet <network> [/<masklen> | masklen <masklen>]] # [scoped <network> [/<masklen> | masklen <masklen>]] # # bsr-candidate [local-addr | ifname] [priority <0-255>] # rp-candidate [local-addr | ifname] [priority <0-255> ] [time <10-16383>] # group-prefix <group-addr>[/<masklen> | masklen <masklen>] # group-prefix <group-addr>[/<masklen> | masklen <masklen>] # . # . # group-prefix <group-addr>[/<masklen> | masklen <masklen>] # rp-address <local-addr> [<group-addr>[/<masklen> | masklen <masklen>] # # spt-threshold [rate <KBPS> | packets <NUM> | infinity] [interval <SEC>] ## # # By default PIM is activated on all interfaces. Use `phyint disable` # on interfaces where PIM should not run. You can also use the `-N, # --disable-vifs` command line option along with `enable` to get the # inverse behavior. # # The routing protocol admin distance (or metric preference per the RFC) # is used in PIM Assert elections to elect the forwarder of multicast. # Currently pimd cannot obtain distance and metric from the underlying # routing protocols, so a default distance may need to be configured per # interface. If left out, the default-route-distance is used for the # phyint. In PIM assert elections the router advertising the lowest # preference (distance) will be selected as forwarder (upstream router) # for that LAN. An admin distance of 101 should be sufficiently high so # that asserts from Cisco or GateD routers are prefered over poor-little # pimd. # # It is reccommended that preferences (admin distance) be set such that # metrics are never consulted. However, default metrics may also be set # and default to 1024. # # A phyint directive can use either the interface name, ifname, or the # IP address. The distance and metric settings define administrative # distance and metric, respectively, for PIM Assert messages sent on # that interface. Usually you do not need this, but if you do, think of # them like distance and metric defined on an inbound interface (iif), # but used by PIM Asserts on the outbound interfaces (oifs). # # If you want to add "alternative (sub)net" to a physical interface, # e.g., if you want to make incoming traffic with a non-local source address # to appear as it is coming from a local subnet, then use the command: # # phyint <local-addr | ifname> altnet <net-addr> masklen <len> # # NOTE: if you use this command, make sure you know what you are doing! # # If you want administratively scoped multicast filtering, use the # following command: # # phyint <local-addr | ifname> scoped <net-addr> masklen <masklen> # # This allows interfaces to be configured as an administrative boundary # for the specified scoped address, or address range. Packets belonging # to the scoped range will not be forwarded. Use `--enable-scoped-acls` # flag to the configure script to activate this at build time. # # Both rp-candidate and bsr-candidate are enabled in the default config, # below. Disabling them for all PIM capable routers is a bad idea. At # least one PIM router in the backbone must act as a bootstrap router. # The optional local-addr or ifname arguments after the rp-candidate and # bsr-candidate settings specify the local address to be used in the # Cand-RP and Cand-BSR messages. In case ifname is given as argument, # the first IPv4 address of that interface is used. If either is # unspecified, the largest local IP address will be used, excluding # phyint interfaces where PIM has been disabled. # # The time argument to rp-candidate specifies how often to send Cand-RP # messages. The default value is 30 seconds. Use smaller values for # faster convergence. # # The group-prefix setting is the prefix(es) advertised if rp-candidate. # It is possible to set up to 255 group-prefix records. # # Using the rp-address setting it is possible to set a static rendezvous # point. The argument can be either a unicast or a multicast address # followed by an optional group address and optional masklen to that. # # The spt-threshold specifies the minimum rate in kbps before the last # hop router initiates a switch to the shortest path. The `packets` # argument is an alternative notation, `infinity` means to never switch, # and `interval` specifies the interval for periodical testing of the # threshold. Currently, `interval` must be at least 5 (seconds) # # Interface defaults, like default-route-distance and -metric must be # set before the phyint section -- the .conf parser is not clever. #default-route-distance 101 # smaller is better #default-route-metric 1024 # smaller is better #hello-interval 30 # Don't set lower than 30 # The phyint settings currently *MUST BE* ordered after the default # source preference and metric settings, but before everything else. # By default, all non-loopback multicast capable interfaces are enabled. # If you want to use loopback, set the interface multicast flag on it. #phyint eth0 disable # IGMP default query interval and querier timeout. The latter should # per RFC always be (robustness * interval) + (query-response / 2), for # pimd this means: (3 * 12) + (10 / 2) = 41, we've rounded it up to # honor the late Douglas Adams. You can set it to a higher value, but # it is not recommended to set it lower. #igmp-query-interval 12 #igmp-querier-timeout 42 # Bigger value means "higher" priority bsr-candidate priority 5 # Smaller value means "higher" priority rp-candidate time 30 priority 20 # Candidate for being RP of complete IPv4 multicast range #group-prefix 224.0.0.0 masklen 4 # Static rendez-vous point #rp-address 192.168.10.1 224.0.0.0/4 # Switch to shortest-path tree after first packet, but only after 100 sec. spt-threshold packets 0 interval 100The conf file generated by the package I see at
/var/etc/pimd/##################### 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 mvneta1.1001 enable phyint mvneta1.1003 enable -
Without seeing what interfaces you add it's hard to say. I assume you disable everything except those two vlans though?
You should also match those priority and threshold settings in the package so they are in the generated conf file if that's what worked for you.
Steve
-
@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.214I 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?
-
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:
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/4Steve
-
@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:
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.
-
@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.214I 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 ROUTERfor 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.
-
Preliminary testing gives that this works for me:
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 applicationsI hope it helps,
Cheers 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 -
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? -
@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.
-
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 30It 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.
-
You could try also adding back
spt-threshold packets 0 interval 100which was in the original config. On the General tab:
Steve
-
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 -
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:
Here is the config file that is produced which matches the file I obtained with the manual installation:
Finally here is the status output:
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!
-
@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 30As 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.
-
@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.
-
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.
-
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.
