node-sonos-http-api icon indicating copy to clipboard operation
node-sonos-http-api copied to clipboard

Configuring different Discovery Subnet

Open paFFr opened this issue 3 years ago • 2 comments

Hello,

I was wondering if there has been any feature implemented to support discovery of Sonos speakers located within a different subnet since the last request for this feature I could find from 2016. Since we have a VM running on an ESXi Server to host the Sonos node components but need to control speakers located on another side it is currently not possible to setup the Sonos Node api in the same subnet as the speakers, but both subnets are connected via a permanent IPsec Tunnel.

Is there any way to tell the sonos http api to search for the Sonos speakers in a different subnet?

Thank you for your great work!

With regards, paFFr

paFFr avatar Jul 01 '21 13:07 paFFr

There is nothing implemented to bypass the normal ssdp discovery process right now, but there is also nothing that "prevents" SSDP from traversing subnet boundaries. However, you would have to add some sort of broadcast/multicast forwarder/relay and add the appropriate rules to allow traffic through.

Not sure why you have an IPSec tunnel between your VM and your network though, are the ESXi locate off-premises?

Here is another question about the same issue https://github.com/jishi/node-sonos-http-api/issues/266

It would be technically feasable to "pin" the discovery to a single Sonos player if you reserve an IP for it, but it hasn't been implemented. It also add extra points of failures, hence why I have avoided it.

jishi avatar Jul 02 '21 09:07 jishi

Hello jishi,

thank you for your reply, you are correct, the ESXi is located on a different site than the Sonos devices, so we have to cope with different subnets here. I was curious if there have been made any changes since the issue you linked was posted, but I guess this something that complicates the code by a lot while my situation is a rather rare use-case. I'll try and see if I can get this to work with multicast forwarding going forward.

Thanks for your support and the great work you do with this project!

With regards, paFFr

paFFr avatar Jul 02 '21 16:07 paFFr