Sonos speakers and applications on different subnets (VLAN's)
-
I can confirm, that did the trick, strange that you have to add this, when using the GUI and it seems adding the ip of a Sonos device does the trick, but it should not be that way as the ip address of a multicast device should not be needed to make it work and it will not work when using DHCP and not static or reserved addresses.
-
This post is deleted! -
The difference between your working output and the package, at least when you were using default 'do not bind' appears to be that you were enabled on 172.16.10.1 in the manual method but disabled in the package status.
Hard to see how it could be any different otherwise though.
Maybe post the command lines and config files for comparison here from each method. There must be some difference.
Steve
-
@stephenw10 said in Sonos speakers and applications on different subnets (VLAN's):
That can sort of error can often be Snort blocking the traffic.
Steve
hmm, ok I'm not using snort but I am using pfblockerNG. Could this be the cause?
-
@Deviant0ne said in Sonos speakers and applications on different subnets (VLAN's):
I was able to get this working by adding an RP address, specifying the IP address of one of my Sonos speakers and
239.255.255.250for the multicast group. All of my other settings are identical to your screenshots above.Update: I was able to confirm using the GUI method is working after configuring all of my Sonos devices in the RP address section with nothing configured for multicast group.
Strange, neither one of those options is working for me. Tried out the PIMd package, configured it extremely basic:
- VLAN with media devices (Sonos et al)
- VLAN LAN
- VLAN Guest/Wifi
- allowed all VLANs access to each other
set up pimd with
- bind none
- added the three vlans as "allowed"
- default anywhere else
-> no function
- under "RP addresses" added my Sonos Beam IP with 239... as group address
-> still nope
- removed group address and added other Sonos devices
-> still nope (and many more errors like:)
For src 172.27.3.30, iif is 5, next hop router is 172.27.3.30: NOT A PIM ROUTERgot entries in status like
Source Group RP Address Flags --------------- --------------- --------------- --------------------------- 172.27.1.128 239.255.255.250 172.27.3.30 CACHE SG Joined oifs: ..........j Pruned oifs: ........... Leaves oifs: ........... Asserted oifs: ........... Outgoing oifs: ..........o Incoming : .I......... TIMERS: Entry JP RS Assert VIFS: 0 1 2 3 4 5 6 7 8 9 10 210 45 0 0 0 0 0 0 0 0 0 0 0 0 0 Source Group RP Address Flags --------------- --------------- --------------- --------------------------- 172.27.3.1 239.255.255.250 172.27.3.30 CACHE SG Joined oifs: ..........j Pruned oifs: ........... Leaves oifs: ........... Asserted oifs: ........... Outgoing oifs: ..........o Incoming : .....I..... TIMERS: Entry JP RS Assert VIFS: 0 1 2 3 4 5 6 7 8 9 10 185 10 0 0 0 0 0 0 0 0 0 0 0 0 0but still the android app on the phone won't find the sonos devices/network at all.
-
I was using an iOS device for testing and found that I was experiencing the same issue as some of the other users where my Sonos system could not be located at first - after disabling and re-enabling WiFi on my iOS device, I was able to access my Sonos system without issue. Otherwise, my configuration is nearly identical to what you're describing.
-
@Deviant0ne I have a second WiFi patched into the SONOS network VLAN - if I switch to that (obviously) all is fine. If I switch back to LAN (which should use PIM) it doesn't. Toggling Wifi doesn't do anything for my Androids around here. No one is finding the Sonos devices. Added all of them as RP addresses - nope. Removed all but one - nope. Don't know what's the key to get this to work yet. :/
-
@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.
