Sonos speakers and applications on different subnets (VLAN's)
-
Thank you Qinn for posting this! PIMD worked for me after hours and hours of work trying to get my HEOS (Denon's version of "Sonos") working across VLANs.
Is there anything that I need to do to ensure that PIMD loads with the correct settings everytime my pfSense restarts or is updated?
-
@nick13 PIM isn't needed (or desired) for HEOS. All that is needed for HEOS is Avahi with reflection enabled. Following discovery, which is mdns based, HEOS is point to point rather than multicast.
-
@dennypage I've had Avahi installed with reflection enabled and have been unable to get it to work until I also turn on PIMD. When I kill PIMD the HEOS app quits recognizing my receivers on the other vlan.
Do you have any thoughts why that might be?
As a side note, I figured out the answer to my question that I posted by adding the PIMD start command to the config.xml file.
-
Check these things:
You have firewall interfaces in both the client subnet (where your iPhone is) and the server subnet (where the HEOS device is).
You have Avahi (2.0.0_2) with the allowed interfaces set to include both the client subnet and the server subnet.
You have "Enable" and "Enable reflection" checked in the Avahi configuration.
You do not have "Disable IPv4" checked in the Avahi configuration.
You do not have anything defined in the "Advanced settings" section of the Avahi configuration.
You have added rules to allow ptp packets from the clients to the HEOS device you are trying to control.
You have restarted or disconnected/reconnected both HEOS clients and servers after changing the any of the above.
-
@nick13 said in Sonos speakers and applications on different subnets (VLAN's):
Thank you Qinn for posting this! PIMD worked for me after hours and hours of work trying to get my HEOS (Denon's version of "Sonos") working across VLANs.
Is there anything that I need to do to ensure that PIMD loads with the correct settings everytime my pfSense restarts or is updated?
Nice that it helped you, the config file that PIMD is using will probably be removed once you update pfSense.
-
2 questions...
I have PFsense running in an esxi environment and I don't have my network adapter in promiscuous mode. I have the pcie ethernet adapter as a directpath i/o dedicated device. Essentially vmware doesnt even see the device anymore and it as if it's native to the pfsense host machine. This should be good from my understanding?
question 2: Has anyone tried this with a network cablecard tuner? I'm trying to get my hdhomerun to work with igmpproxy and pfsense doesnt seem to be sending any of the multicast traffic.
-
First of all, huge thanks to Qinn and others for figuring this out and providing instructions!
Second, I've read and followed all the instructions here and in other threads w/o any success. So, after days of trials and errors I'd like to ask for some help.
My configuration is slightly different - I need to traverse multicast for Sonos between a real no-VLAN subnet and a dedicated VLAN subnet within. I.e. there's a regular LAN where no-VLAN devices live (it's actually a Default VLAN 1 on the switch, but untagged), bound to "igb1" interface. That's where controller resides in the form of an Android app. And there's a dedicated tagged VLAN 10 for Sonos devices, bound to "igb1.10" interface. LAN on igb1 is 192.168.0.0/24 and VLAN10 on igb1.10 is 192.168.10.0/24. pfSense is 192.168.0.1 and 192.168.10.1 on each interface. Both subnets have DHCP server, both are fully open in Firewall - I can ping and send unicast traffic between those 2 subnets fine.
Now, when I configure PIMD on igb1 and igb1.10, it reports that subnet for the second one is 192.168.10, while subnet for the first one is 192.168. Which leads me to believe that PIMD somehow considers VLAN10 to be "shadowed" inside LAN, not a separate subnet and refuses to retransmit multicast between them.
I tried different combinations of "altnet" configuration specified w/o much success. After a while I see some other Android devices joining multicast groups reported by PIMD, but Sonos still doesn't work - an Android controller app on LAN can't find any Sonos device on VLAN10.
I'd like to avoid the need to tag everything on LAN to make it a dedicated VLAN subnet. Essentially that would mean VLAN 1 as a real subnet, start tagging everything, create "igb1.1" interface for it and close LAN "igb1" down. Supposedly, that would work, as reported by others - VLAN1 <-> VLAN10, igb1.1 <-> igb1.10. Unfortunately, that means extra work, lots of gear configuration and some downtime to my network.
So, I would appreciate any suggestions and ideas for how to make it work with the setup I have right now - LAN <-> VLAN10, igb1 <-> igb1.10. Thanks in advance and please let me know what you think!
-
@denix Could you post the messages you receive from PIMD and could you post the config file of PIMD
A VLAN that is not tagged is not a VLAN ;) , but tagging or not should not really matter as tagging happens when it leaves the subnet and traverses the switch.
-
@Qinn sorry if my explanation wasn't very clear. Yes, I was trying to say that LAN carries both VLAN-tagged traffic, as well as untagged.
Originally I had all Sonos speakers in a separate VLAN10 tagged subnet, while other devices including Android controller app in untagged LAN.
Tired of trying to make it work, I ended up placing WiFi devices into own VLAN40 tagged subnet. Now testing PIMD with VLAN10 <-> VLAN40 and still no luck.
VLAN10 = 192.168.10.0/24 (Sonos speakers)
VLAN40 = 192.168.40.0/24 (Android control app)pfSense has IP of x.x.x.1 on each interface. Both subnets are fully open to each other for unidirectional traffic.
Here's my config (tried many different variants of enabling/disabling different options):
phyint igb0 disable phyint igb1 disable phyint igb2 disable phyint igb3 disable phyint igb1.10 enable phyint igb1.20 disable phyint igb1.30 disable phyint igb1.40 enable bsr-candidate priority 5 rp-candidate time 30 priority 20 group-prefix 224.0.0.0 masklen 4 spt-threshold packets 0 interval 100
Starting pimd -d:
debug level 0xffffffff (dvmrp_detail,dvmrp_prunes,dvmrp_routes,dvmrp_neighbors,dvmrp_timers,igmp_proto,igmp_timers,igmp_members,trace,timeout,packets,interfaces,kernel,cache,rsrr,pim_detail,pim_hello,pim_register,pim_join_prune,pim_bootstrap,pim_asserts,pim_cand_rp,pim_routes,pim_timers,pim_rpf) 22:58:33.455 pimd version 2.3.2 starting ... 22:58:33.455 Got 262144 byte send buffer size in 0 iterations 22:58:33.455 Got 262144 byte recv buffer size in 0 iterations 22:58:33.455 Got 262144 byte send buffer size in 0 iterations 22:58:33.455 Got 262144 byte recv buffer size in 0 iterations 22:58:33.455 Getting vifs from kernel 22:58:33.455 Installing igb0 (x.x.x.x on subnet x.x.x/24) as vif #0 - rate 0 22:58:33.455 Installing igb1 (192.168.0.1 on subnet 192.168) as vif #1 - rate 0 22:58:33.455 Installing igb2 (192.168.13.1 on subnet 192.168.13) as vif #2 - rate 0 22:58:33.455 Installing igb3 (192.168.255.1 on subnet 192.168.255) as vif #3 - rate 0 22:58:33.455 Installing igb1.10 (192.168.10.1 on subnet 192.168.10) as vif #4 - rate 0 22:58:33.455 Installing igb1.20 (192.168.20.1 on subnet 192.168.20) as vif #5 - rate 0 22:58:33.455 Installing igb1.30 (192.168.30.1 on subnet 192.168.30) as vif #6 - rate 0 22:58:33.455 Installing igb1.40 (192.168.40.1 on subnet 192.168.40) as vif #7 - rate 0 22:58:33.455 Getting vifs from /var/etc/pimd.conf 22:58:33.455 Local Cand-BSR address 192.168.40.1, priority 5 22:58:33.455 Local Cand-RP address 192.168.40.1, priority 20, interval 30 sec 22:58:33.455 spt-threshold packets 0 interval 100 22:58:33.455 Local static RP: 169.254.0.1, group 232.0.0.0/8 22:58:33.455 IGMP query interval : 12 sec 22:58:33.455 IGMP querier timeout : 41 sec 22:58:33.455 Interface igb0 is DISABLED; vif #0 out of service 22:58:33.455 Interface igb1 is DISABLED; vif #1 out of service 22:58:33.455 Interface igb2 is DISABLED; vif #2 out of service 22:58:33.455 Interface igb3 is DISABLED; vif #3 out of service 22:58:33.455 Interface igb1.10 comes up; vif #4 now in service 22:58:33.456 query_groups(): Sending IGMP v3 query on igb1.10 22:58:33.456 Send IGMP Membership Query from 192.168.10.1 to 224.0.0.1 22:58:33.456 SENT 36 bytes IGMP Membership Query from 192.168.10.1 to 224.0.0.1 22:58:33.456 SENT 46 bytes PIM v2 Hello from 192.168.10.1 to 224.0.0.13 22:58:33.456 Interface igb1.20 is DISABLED; vif #5 out of service 22:58:33.456 Interface igb1.30 is DISABLED; vif #6 out of service 22:58:33.456 Interface igb1.40 comes up; vif #7 now in service 22:58:33.456 query_groups(): Sending IGMP v3 query on igb1.40 22:58:33.456 Send IGMP Membership Query from 192.168.40.1 to 224.0.0.1 22:58:33.456 SENT 36 bytes IGMP Membership Query from 192.168.40.1 to 224.0.0.1 22:58:33.456 SENT 46 bytes PIM v2 Hello from 192.168.40.1 to 224.0.0.13 22:58:33.456 Interface register_vif0 comes up; vif #8 now in service Virtual Interface Table ====================================================== Vif Local Address Subnet Thresh Flags Neighbors --- --------------- ------------------ ------ --------- ----------------- 0 x.x.x.x x.x.x/24 1 DISABLED 1 192.168.0.1 192.168 1 DISABLED 2 192.168.13.1 192.168.13 1 DISABLED 3 192.168.255.1 192.168.255 1 DISABLED 4 192.168.10.1 192.168.10 1 DR NO-NBR 5 192.168.20.1 192.168.20 1 DISABLED 6 192.168.30.1 192.168.30 1 DISABLED 7 192.168.40.1 192.168.40 1 DR NO-NBR 8 192.168.10.1 register_vif0 1
And here's a sample output from running pimd with -d option when there's a traffic:
Candidate Rendezvous-Point Set =============================================== RP address Incoming Group Prefix Priority Holdtime --------------- -------- ------------------ -------- --------------------- 192.168.40.1 8 224/4 20 50 169.254.0.1 0 232/8 1 65535 ------------------------------------------------------------------------------ Current BSR address: 192.168.40.1 22:37:31.848 Cache miss, src 192.168.40.10, dst 239.255.255.250, iif 7 22:37:31.848 create group entry, group 239.255.255.250 22:37:31.848 create source entry, source 192.168.40.10 22:37:31.848 move_kernel_cache: SG 22:37:32.326 Cache miss, src 192.168.10.16, dst 239.255.255.250, iif 4 22:37:32.326 create source entry, source 192.168.10.16 22:37:32.326 move_kernel_cache: SG 22:37:32.340 Cache miss, src 192.168.10.15, dst 239.255.255.250, iif 4 22:37:32.340 create source entry, source 192.168.10.15 22:37:32.340 move_kernel_cache: SG 22:37:32.660 Cache miss, src 192.168.10.14, dst 239.255.255.250, iif 4 22:37:32.660 create source entry, source 192.168.10.14 22:37:32.660 move_kernel_cache: SG 22:37:32.916 Cache miss, src 192.168.10.13, dst 239.255.255.250, iif 4 22:37:32.916 create source entry, source 192.168.10.13 22:37:32.916 move_kernel_cache: SG 22:37:33.005 Cache miss, src 192.168.10.21, dst 239.255.255.250, iif 4 22:37:33.005 create source entry, source 192.168.10.21 22:37:33.005 move_kernel_cache: SG 22:37:33.185 Cache miss, src 192.168.10.17, dst 239.255.255.250, iif 4 22:37:33.185 create source entry, source 192.168.10.17 22:37:33.185 move_kernel_cache: SG 22:37:34.274 Cache miss, src 192.168.40.10, dst 239.255.255.250, iif 7 Virtual Interface Table ====================================================== Vif Local Address Subnet Thresh Flags Neighbors --- --------------- ------------------ ------ --------- ----------------- 0 x.x.x.x x.x.x/24 1 DISABLED 1 192.168.0.1 192.168 1 DISABLED 2 192.168.13.1 192.168.13 1 DISABLED 3 192.168.255.1 192.168.255 1 DISABLED 4 192.168.10.1 192.168.10 1 DR NO-NBR 5 192.168.20.1 192.168.20 1 DISABLED 6 192.168.30.1 192.168.30 1 DISABLED 7 192.168.40.1 192.168.40 1 DR NO-NBR 8 192.168.10.1 register_vif0 1 Vif SSM Group Sources Multicast Routing Table ====================================================== --------------------------------- (*,*,G) ------------------------------------ Number of Groups: 0 Number of Cache MIRRORs: 0 ------------------------------------------------------------------------------
The log above clearly shows some traffic where 192.168.10.13-17 are Sonos speakers and 192.168.40.10 is my Android phone with Sonos control app trying to find them. I still get "We can't connect to Sonos". And somehow Multicast Routing Table is empty anyway.
Any ideas? Thanks!
-
@denix I will try to look into it this weekend, btw the tagging should not matter, tagging is only there in the trunk and when it leaves the subnet, so LAN or VLAN should not matter.
I don't know why you used "enable" in the config file, as by default all interfaces are enabled and as you can see in my config I disabled all but the subnet that holds the Sonos speakers and the other subnet that holds the Sonos applications. -
@Qinn how do you have your Sonos speakers connected to the network? Do you use Bridge or Boost? Do you connect them Wirelessly or with Ethernet cable?
-
@denix said in Sonos speakers and applications on different subnets (VLAN's):
@Qinn how do you have your Sonos speakers connected to the network? Do you use Bridge or Boost? Do you connect them Wirelessly or with Ethernet cable?
Neither all Sonos devices connect to a AP, so by WiFi and there is no bridge or boost from Sonos. In total there are 3 Sonos Play:1, 1 Play:3 and a Sonos Connect:AMP. On this AP there are 5 SSIDs's each with it's own VLAN ID (so isolation) IP's are (as it is a AP) assigned by the DHCP server from pfSense.
-
@Qinn did you have to re-pair Sonos and the controller once you got your network and pfSense setup?
Nothing seems to work on my end. Unfortunately I don't have WiFi that can do VLAN, so isolation is done on a switch. WiFi connects to one of the ports that gets tagged, so everything wireless goes to that VLAN. I had most of my Sonos speakers wired, so once I isolated their ports to another VLAN, they dutifully got new IPs from pfSense's DHCP server for that segment. Running PIMD between those VLAN segments and the controller doesn't see the speakers.
I even ended up resetting the controller, and one of the spare Sonos:1 speakers. I paired them up, but the speaker got onto the the WiFi SSID and the same VLAN as the controller. That works, but the speaker now sits on the WiFi VLAN and refuses to connect with a cable to go into own dedicated VLAN... Tried pairing a Bridge, but since it's wired, it can never get detected by the controller, since they are in separate VLANs. PIMD doesn't seem to help a bit.
Can't get it to work, no matter what I try. Any help would be greatly appreciated! Thanks.
-
@denix Could you draw the setup of your network?
-
@denix Did you enable the "Allow packets with IP options to pass. Otherwise they are blocked by default. This is usually only seen with multicast traffic" rule in the advanced options in your Firewall rules?
-
@Rai80 bingo!
That was it. Once I enabled that option in Firewall Rules for each VLAN segment configured in PIMD, I started seeing a lot more traffic in PIMD debug.
One more thing - all the above works with existing setup. Creating new Sonos network or adding new speakers doesn't work, as I read somewhere that pressing Play/Pause and Volume+ buttons doesn't get propagated between segments over multicast.
Since I already reset the controller, I needed one more step: I brought up a temporary WiFi SSID on the same VLAN as Sonos speakers, connect my Android phone to that WiFi and setup the Controller. After that, moving it back to the main WiFi SSID works and it still sees and controls speakers on a separate VLAN with PIMD running.
Now I'm happy. Thanks everyone for all the help!
PS. Would be nice to figure out how to setup new Sonos speakers w/o using the temporary SSID...
-
Nice that it works, but then I have to adapt the how to, as I explicitly mentioned that "allow IP options" was not needed and I can confirm that here I don't need to allow it, but my Sonos applications are not running on Andriod. Well, personally I don't understand why this is needed be that as it may, but the proof is in the pudding.
I added a second note to file.
Note 2: below is reported that on Android devices "Allow IP options" in the Advanced Options of the firewall rules is needed to enable to make it work, so if you don't have success, please try to enable it.
@denix now that it is working, can you confirm that when you quit PIMD, you can still connect to the Sonos speakers?
-
@Qinn yes, seems to be still working w/o PIMD running.
I also need to lock down the firewall between VLANs - currently I have those completely open to each other. Need to close and punch holes according to this list:
https://support.sonos.com/s/article/688TCP/IP:
80 (Internet Radio, updates and registration)
443 (Rhapsody, Napster, and SiriusXM)
445 (CIFS)
3400 (incoming UPnP events - Sonos Controller App for Mac or PC)
3401 (Sonos Controller App for iOS)
3445 (OS X / Windows File Sharing)
3500 (Sonos Controller App for Android)
4070 (Spotify incoming events)
4444 (Sonos update process)UDP:
136-139 (NetBIOS)
1900 (UPnP events and device detection)
1901 (UPnP responses)
2869, 10243, 10280-10284 (Windows Media Player NSS)
5353 (Spotify Control)
6969 (Initial configuration) -
@denix That was my conclusion also, thanks you have tested it, it seems that the applications save the addresses of the Sonos speaker for unicast, it's been 3 months that PIMD has been running and I can still access the speakers.
-
I'm at a loss... I think my issue is related to the TTL being set as 1 coming from the device sending the SSPD multicast. PIMD is setup exactly how you have it above and I'm still not seeing the traffic get through.
Does anyone know if there is a way to change the TTL for this type of traffic?
-
@pr3dict said in Sonos speakers and applications on different subnets (VLAN's):
I'm at a loss... I think my issue is related to the TTL being set as 1 coming from the device sending the SSPD multicast. PIMD is setup exactly how you have it above and I'm still not seeing the traffic get through.
Does anyone know if there is a way to change the TTL for this type of traffic?
Why do think this and what does a debug or log show?
-
This post is deleted! -
I tried to follow your guide (which is very clear and detailed), but I can't get it to work (not seeing any traffic).
Do you think it could be related to this https://forum.netgate.com/topic/140596/multicast-routing (TL;DR No IPv4 MROUTING kernel support.)?
-
@alexbond93 can you see pimd is running and config it so that, the interfaces carreing the vlan's containing speakers and the one containing Sonos software, are not disabled? Btw did you take a look at the remark @denix Apr 2, 2019, 12:57 AM I personally not needed it, but it seems to help him?
-
unfortunately i couldn't get this to work. from my pfsense i have a wired vlan to a wireless AP to which all IOT including Sonos speakers are attached. main LAN VLAN goes to a unifi edgeswitch and then onto all other devices either wired or through another wireless AP.
i got pimd installed and configured it just to disable the WAN interface. i could see pimd in top but couldnt ever get the Sonos speakers to show up in the Sonos app on a pc on LAN.
i didn't set anything related to ip settings on the firewall rules as suggested. my guess is its something in the edge switch blocking it but i've given up for now. hopefully Sonos fix this in a future update
-
@pr3dict said in Sonos speakers and applications on different subnets (VLAN's):
m at a loss... I think my issue is related to the TTL being set as 1 coming from the device sending the SSPD multicast. PIMD is setup exactly how you have it above and I'm still not seeing the traffic get through.
If TTL is set to 1 it's because the packet is not intended to be routed. This is often the case with multicast. So, when that packet tries to go through a router, the TTL will decrement to 0 and the packet discarded.
-
Thanks for the work here everyone!
I have a couple of cases where I need to traverse multiple routers with multicast. There might be a way to use pfsense for this after all. Right now its Cisco.
Think simulcast audio. https://www.gatesair.com/products/transport/public-safety-govt-communications
There are at least a couple other systems in the radio world that utilize multicast across subnets to distribute ROIP.
-
@chpalmer Nice that you appreciate this thread, I hope it helps many, but I don't understand what's your question. The main thing here is, that I have seen, using Wireshark that the default IGMP proxy pfSense uses, does not traverse Multicast 239.255.255.250 (SSPD) across subnets and PIMD does, so it is a more reliable when you want to "spread" local multicast over subnets/VLAN's, when it's multicast that comes from internet I think the IGMP proxy, that's by default present in pfSense it will suffice.
-
This post is deleted! -
@Qinn said in Sonos speakers and applications on different subnets (VLAN's):
I don't understand what's your question.
No question. Just a statement. :)
-
@chpalmer clear ;)
-
Qinn
Happy to report I got it to work! Took me months to sit down and take a look at this. It turned out to be much easier and simpler to implement than I thought.
Some notes:
- l have a netgate sg-3100 box. So the amd64 pkg threw an error. but it prompted me to use the armv6 package
pkg add http://pkg.freebsd.org/FreeBSD:11:armv6/quarterly/All/pimd-2.3.2.txz
-
I didnt have to use Putty at all. I logged into the pfsense GUI and executed all the commands via diagnostics --> command prompt. This includes copying the pimd conf file over to /var/etc/ and starting it after editing.
-
To edit the conf file at /var/etc/pimd.conf, I used diagnostics ---> file edit. You can browse to it. very easy.
-
After starting pimd, it threw an error in the logs - permission denied. I figured it had something to do with the rules on my Iot vlan - where the sonos devices live. So i simply created the rule below, where home_devices is an alias of specific devices the sonos controller is running on - all assigned with static ips, of course. Dont know if I need ipv6 there or not but i added it in anyway. The, sonos_ports is a list of all the ports shown in the link you provided. I threw it all into one big bucket.
- I also enabled "allow ip options" under advanced options in the rule above.
Thats it!
Some issues:
-
I rebooted my pfsense box after I was done. When i logged back in, the pimd package in /var/etc/ was gone! I tried to start it but couldnt find it. So i copied it over again, edited it and started it. But haven't rebooted my box again! Not sure if I did something wrong the first time.
-
I'd like to clean up that list of sonos ports. I think some of them are intended for outbound to sonos servers and some jsut for the internal lan. No need to open all those ports to my internal lan devices. So, id like to identify which ones are outbound and which ones are for the devices on the lan only.
-
A bit of a pain to have to redo this everytime there is a pfsense upgrade. I hope pimd makes it as an official package.
-
I have upnp enabled. Not sure if turning it off will impact any of this.
Anyway ... thought i should check in to report my progress after your excellent work to get things started!
-
@vacquah Great, that you finally got it to work and thanks for reporting back and sharing the how you did it. Also, nice that you pointed out, one can also make use of the Command Prompt which is in the GUI of pfSense . I didn't know that, apart of the Amd64 version there is an Arm version, pointing it out will help many
As this thread is getting bigger, I would like to emphasis on something, I noticed that once the Sonos apps and speakers have found each other, there is no more need for running PIMP (maybe after a reboot, I have tested that) to be running. It seems the addresses are somehow stored and as these are closed source apps and devices, I have not much chance of finding out on the "how to". I just say this, not that I don't trust PIMD, but somehow introducing a not approved piece of software on a firewall/router, just doesn't feel right.
News:
https://forum.netgate.com/topic/139352/pimd-a-lightweight-standalone-pim-sm-ssm-v2-multicast-routing-daemon/2 -
This is a great little tool for testing of multicast streams.
https://support.singlewire.com/s/software-downloads/a17C0000008Dg7AIAS/ictestermulticastzip
Simply launch the program one on the transmit side and one on the receive side and set accordingly. If multicast is making it then you will see the packets on the screen.
-
I have also tried to enable multicast with pimd, but when I try to run the command
pimd -c /var/etc/pimd.conf
using Diagnostics-> Command Prompt, but in return I get
pimd: 09:35:36.449 Another multicast routing application is already running.
I don't know which application it is referring to. I have disabled imgp proxy. Avahi is running for Bonjour/Airprint.
This is the output of command
top
:PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 56564 root 1 23 0 100M 45504K piperd 2 0:14 1.56% php-fpm 342 root 1 52 0 125M 45056K accept 3 0:20 0.00% php-fpm 44824 root 1 52 0 98M 43360K accept 3 0:11 0.00% php-fpm 92301 root 1 20 0 6400K 2596K select 1 0:09 0.00% syslogd 13534 root 1 20 0 6600K 2384K bpf 2 0:08 0.00% filterlog 31176 root 5 52 0 6900K 2328K uwait 0 0:06 0.00% dpinger 343 root 1 52 0 96212K 40816K accept 2 0:05 0.00% php-fpm 7830 root 1 52 0 102M 46028K accept 3 0:04 0.00% php-fpm 10260 root 1 52 0 98196K 42616K accept 3 0:04 0.00% php-fpm 48403 root 1 20 0 23592K 8956K kqread 2 0:01 0.00% nginx 20083 root 1 52 20 6968K 2656K wait 2 0:01 0.00% sh 49387 nobody 1 20 0 11524K 5248K select 0 0:01 0.00% dnsmasq 48583 root 1 20 0 23592K 8540K kqread 1 0:00 0.00% nginx 49607 root 1 20 0 12396K 12500K select 1 0:00 0.00% ntpd 94937 squid 1 20 0 99928K 35228K kqread 0 0:00 0.00% squid 77963 root 1 20 0 6324K 2324K select 3 0:00 0.00% pimd 86583 dhcpd 1 20 0 12580K 8300K select 1 0:00 0.00% dhcpd 1370 squid 1 20 0 9948K 5088K select 0 0:00 0.00% pinger
How can I identify the conflicting application?
-
It seems to be the pimd itself… :-)
Ranpimd -q
and then
pimd -c /var/etc/pimd.conf
again.
Now there was noe error.
But I can still not get multicast between sonos vlan and app vlan (iphone).
So I'll come back as soon as I have given up... -
Has anyone been able to discover new SONOS devices across VLANs?
I can now connect to my Sonos system from my wireless VLAN (sometimes the iOS app needs the wifi turned off and on to detect the Sonos speakers but the desktop app is very stable).
What I have been unable to do is add a Sonos component (even when my phone is on the same Sonos VLAN). I have been attempting to add a Sonos Bridge but the app cannot detect it. I have tried with Avahi, PIMD and IGMP. Next attempt is turning on UPnP
-
@edz said in Sonos speakers and applications on different subnets (VLAN's):
Next attempt is turning on UPnP
How do you think that would work??
(even when my phone is on the same Sonos VLAN).
if your on the same vlan as the device and it doesn't work - how do you think its going to work across vlans? Look to problem with your wireless..
-
Sorry for reviving an old thread but my question still felt related to this topic.
@Qinn Thank you making this guide. I was able to get multicast working across vlans because of your guide and some others here.
So my question is has anyone narrowed down the exact ports/rules to have Sonos & multicast work across vlans while denying other traffic from their IOT vlan to 'production' vlan?
I tried a rule set that @vacquah mentioned but as soon as I enabled my Deny All rule at the bottom of the rule stack, everything stops working. Only difference is that I have the allow rule working for the entire net vs a single IP/device.
-
this is what my iot lan rules look like .... I am sure it can be improved, but this works for me.