14
SONOS Lautsprecher über VPN steuern
Mahlzeit zusammen!
Ich weis nicht ob mein Vorhaben überhaupt funktionieren kann, aber ich frage trotzdem mal
Wir möchten in einer Filiale eine kleine Raumbeschallung laufen lassen. Da wir schon in einer größeren Filiale mit SONOS arbeiten (und top zufrieden sind), würden wir das für die kleine Filiale auch gerne nutzen.
Der Lautsprecher soll dabei in einem Kundenbereich aufgehängt werden der 24h zugänglich ist. Also muss der Lautsprecher oben in einer Ecke angebracht werden, wo man ihn nicht ohne Weiteres klauen kann. Problem dabei: Die Kollegen vor Ort kämen auch nicht mehr dran wenn sie den mal ausschalten wollen, bzw. lauter und leiser geht dann auch nicht (ohne Leiter)
Den Kollegen vor Ort extra dafür ein Smartphone oder einen PC hin zu stellen wäre übertrieben und daher nicht sinnvoll. Ein Kollege dort hätte zwar ein dienstliches Smartphone, aber der kann ja auch mal krank sein oder Urlaub haben.
Nun wäre meine Idee: Die Filiale ist per VPN (beide Standorte mit Fritzbox) mit der Hauptstelle verbunden, also könnte ich ja hier die SONOS-Software auf einen PC installieren um dann im Zweifelsfall von hier aus den Lautsprecher zu steuern. Das scheint aber nicht soooo einfach zu sein wie es sich anhört, zumindest bin ich aus dem offiziellen SONOS-Forum nicht schlau geworden - anscheinend wollen die Lautsprecher immer einen Controller in direkter Systemumgebung.
Hat von euch jemand eine Idee, oder vielleicht sogar schon ein ähnliches Szenario am laufen?
Ich weis nicht ob mein Vorhaben überhaupt funktionieren kann, aber ich frage trotzdem mal
Wir möchten in einer Filiale eine kleine Raumbeschallung laufen lassen. Da wir schon in einer größeren Filiale mit SONOS arbeiten (und top zufrieden sind), würden wir das für die kleine Filiale auch gerne nutzen.
Der Lautsprecher soll dabei in einem Kundenbereich aufgehängt werden der 24h zugänglich ist. Also muss der Lautsprecher oben in einer Ecke angebracht werden, wo man ihn nicht ohne Weiteres klauen kann. Problem dabei: Die Kollegen vor Ort kämen auch nicht mehr dran wenn sie den mal ausschalten wollen, bzw. lauter und leiser geht dann auch nicht (ohne Leiter)
Den Kollegen vor Ort extra dafür ein Smartphone oder einen PC hin zu stellen wäre übertrieben und daher nicht sinnvoll. Ein Kollege dort hätte zwar ein dienstliches Smartphone, aber der kann ja auch mal krank sein oder Urlaub haben.
Nun wäre meine Idee: Die Filiale ist per VPN (beide Standorte mit Fritzbox) mit der Hauptstelle verbunden, also könnte ich ja hier die SONOS-Software auf einen PC installieren um dann im Zweifelsfall von hier aus den Lautsprecher zu steuern. Das scheint aber nicht soooo einfach zu sein wie es sich anhört, zumindest bin ich aus dem offiziellen SONOS-Forum nicht schlau geworden - anscheinend wollen die Lautsprecher immer einen Controller in direkter Systemumgebung.
Hat von euch jemand eine Idee, oder vielleicht sogar schon ein ähnliches Szenario am laufen?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 284686
Url: https://administrator.de/contentid/284686
Ausgedruckt am: 22.11.2024 um 03:11 Uhr
14 Kommentare
Neuester Kommentar
Hallo,
was meinst du mit
Wenn die Boxen eingerichtet sind, kannst du theoretisch mit jedem Gerät im selben Netz die Boxen ansteuern.
Habs zwar nicht probiert, aber es spricht eigentlich nix dagegen.
Ich teste es heute Abend mal zu Hause und berichte dann gerne.
Aber ich denke, dem Lautsprecher ist es herzlich egal wie das steuerende Device mit dem Netz verbunden ist, solange es im selben Netz wie der Lautsprecher ist.
Gruß
was meinst du mit
anscheinend wollen die Lautsprecher immer einen Controller in direkter Systemumgebung.
?Wenn die Boxen eingerichtet sind, kannst du theoretisch mit jedem Gerät im selben Netz die Boxen ansteuern.
Habs zwar nicht probiert, aber es spricht eigentlich nix dagegen.
Ich teste es heute Abend mal zu Hause und berichte dann gerne.
Aber ich denke, dem Lautsprecher ist es herzlich egal wie das steuerende Device mit dem Netz verbunden ist, solange es im selben Netz wie der Lautsprecher ist.
Gruß
Kann man dem Kollegen michi1983 nur zustimmen. Es spricht nichts dagegen das über ein VPN zu machen solange die LS per IP erreichbar sind.
Manchmal liegt der Teufel aber im Detail. Beispiel: wenn die Sonos LS sich mit Bonjour nur lokal automatisch bekannt machen, dann brauchst du einen Bonjour Proxy. (Bonjour Multicast Gruppe ist nicht routebar da TTL auf 1 gesetzt ist) Aber all das ist auch mit einem kleinen RasPi als Workaround in Minuten erledigt.
Leider schreibst du recht wenig bis gar nichts zur Kommunikation vom Controller mit den LS und welche Techniken hier im LAN verwendet werden.
Lag das jetzt daran das du die Details im Sonos Forum nicht verstanden hast oder steht dazu nichts im Forum ? Wenn man das wüsste könnte man auch die Frage zielgerichtet beantworten. So bleibt uns leider auch nur raten oder die Kristallkugel
Ggf. sniffert Kollege michi1983 das mal mit einem Wireshark sofern du es nicht schon gemacht hast ?!
Manchmal liegt der Teufel aber im Detail. Beispiel: wenn die Sonos LS sich mit Bonjour nur lokal automatisch bekannt machen, dann brauchst du einen Bonjour Proxy. (Bonjour Multicast Gruppe ist nicht routebar da TTL auf 1 gesetzt ist) Aber all das ist auch mit einem kleinen RasPi als Workaround in Minuten erledigt.
Leider schreibst du recht wenig bis gar nichts zur Kommunikation vom Controller mit den LS und welche Techniken hier im LAN verwendet werden.
Lag das jetzt daran das du die Details im Sonos Forum nicht verstanden hast oder steht dazu nichts im Forum ? Wenn man das wüsste könnte man auch die Frage zielgerichtet beantworten. So bleibt uns leider auch nur raten oder die Kristallkugel
Ggf. sniffert Kollege michi1983 das mal mit einem Wireshark sofern du es nicht schon gemacht hast ?!
Moin zusammen und schonmal Danke für die schnellen Rückmeldungen.
OK, aus Sorge vor rhetorischen Ausschweifungen habe ich versucht mich kurz zu halten, da sind dann aber auch die wichtigeren Details flöten gegangen, sorry dafür!
Das Netz in der Hauptstelle (wo ich sitze und wo der Controller dann stehen würde) hat den IP-Bereich 192.168.0.xxx und die Filiale hat den Bereich 192.168.80.xxx
Ich kann z.B. den Access Point in der Filiale von hier aus per SSH konfigurieren, also das Routing passt. Von daher sollte das ja irgendwie machbar sein, aber wenn ich die SONOS-Foren durchlese wird diese Frage immer wieder gestellt und es heißt "VPN is nich". Zumindest nicht ohne den Controller vor Ort in der Filiale zu haben, aber das wollen wir nicht (wegen Geld und Platzmangel im LAN-Schrank).
Wenn es ohne weitere Hardware nicht geht wäre das mit dem RasPi noch eine gute Idee, damit könnte ich für kleines Geld den Controller vor Ort laufen lassen und mich per VNC drauf schalten. Oder eben den Bonjour-Proxy.
OK, aus Sorge vor rhetorischen Ausschweifungen habe ich versucht mich kurz zu halten, da sind dann aber auch die wichtigeren Details flöten gegangen, sorry dafür!
Das Netz in der Hauptstelle (wo ich sitze und wo der Controller dann stehen würde) hat den IP-Bereich 192.168.0.xxx und die Filiale hat den Bereich 192.168.80.xxx
Ich kann z.B. den Access Point in der Filiale von hier aus per SSH konfigurieren, also das Routing passt. Von daher sollte das ja irgendwie machbar sein, aber wenn ich die SONOS-Foren durchlese wird diese Frage immer wieder gestellt und es heißt "VPN is nich". Zumindest nicht ohne den Controller vor Ort in der Filiale zu haben, aber das wollen wir nicht (wegen Geld und Platzmangel im LAN-Schrank).
Wenn es ohne weitere Hardware nicht geht wäre das mit dem RasPi noch eine gute Idee, damit könnte ich für kleines Geld den Controller vor Ort laufen lassen und mich per VNC drauf schalten. Oder eben den Bonjour-Proxy.
Ich habs gestern nicht mehr geschafft es zu testen (zu spät nach Hause), werde das heute Abend nachholen.
Wenn deine Netzstruktur aber so aussieht, wird das nix, du musst zwingend im selben Netzwerksegment wie die Lautsprecher sein, dass das funktioniert.
Und meine Frage hast du mir aus meinem ersten Kommentar leider noch immer nicht beantwortet
Wenn deine Netzstruktur aber so aussieht, wird das nix, du musst zwingend im selben Netzwerksegment wie die Lautsprecher sein, dass das funktioniert.
Und meine Frage hast du mir aus meinem ersten Kommentar leider noch immer nicht beantwortet
wo ich sitze und wo der Controller dann stehen würde
Was ist dieser Controller?- Sonos Bridge?
- Sonos AMP?
OK, dann wird es auch nichts wenn ich zwingend im selben Netzwerksegment sein muss - dem ist ja nunmal nicht so.
Dann muss ich wohl den Umweg über irgendeinen Rechner (ggfs. RasPi) gehen.
Der Controller ist kein Controller aus dem SONOS-System, damit meine ich eigentlich nur den PC auf dem die Controller-Software drauf ist. Sorry für das Missverständnis.
Dann muss ich wohl den Umweg über irgendeinen Rechner (ggfs. RasPi) gehen.
Der Controller ist kein Controller aus dem SONOS-System, damit meine ich eigentlich nur den PC auf dem die Controller-Software drauf ist. Sorry für das Missverständnis.
@michi1983
Im Forum steht ja das es Multicast ist und mit den entsprechenden Multicast Konfigs auf dem Router wird das auch fehlerlos über Subnetze übertragen.
Kein Problem also...
https://en.community.sonos.com/home-theater-228993/sonos-across-multiple ...
du musst zwingend im selben Netzwerksegment wie die Lautsprecher sein, dass das funktioniert.
Warum muss das denn so sein ? Gibt es dafür einen triftigen Grund ?Im Forum steht ja das es Multicast ist und mit den entsprechenden Multicast Konfigs auf dem Router wird das auch fehlerlos über Subnetze übertragen.
Kein Problem also...
https://en.community.sonos.com/home-theater-228993/sonos-across-multiple ...
Also, ich habe das ganze zu Hause mal getestet.
Allerdings gleich vorweg, quick n dirty ohne mitsniffen. Das hole ich aber noch nach wenn ich mal Zeit finde ein paar Minuten.
Fakt 1:
Das Device, welches auf die Sonos LS zugreifen möchte, muss zwingend WLAN aktiv haben, zumindest schreibt das die Android App für Sonos so vor.
Fakt 2:
Mein Heimnetz hat das Netz 172.16.16.0/24
Wenn ich mit dem MacBook den Hotspots meines Smartphones nutze und dann eine VPN Verbindung (OpenVPN) auf meinen Heimrouter (Asus rt-ac66u, mit dessen WLAN auch die Sonos LS verbunden sind) aufbaue, habe ich eine IP aus dem 10.0.0.0/24 Netz.
Fakt 3:
Aus dem VPN Netz kann ich zwar die IP des Sonos LS (172.16.16.0/24) pingen und bekomme sogar eine Antwort, aber die Sonos Desktop Software für OSx findet die LS nicht.
Ob es jetzt an dem Billigrouter liegt oder an irgendwelche Protokollen wird hoffentlich der Mitschnitt des Kabelhais zeigen. Sobald ich ihn habe, reiche ich ihn hier nach.
Gruß
Allerdings gleich vorweg, quick n dirty ohne mitsniffen. Das hole ich aber noch nach wenn ich mal Zeit finde ein paar Minuten.
Fakt 1:
Das Device, welches auf die Sonos LS zugreifen möchte, muss zwingend WLAN aktiv haben, zumindest schreibt das die Android App für Sonos so vor.
Fakt 2:
Mein Heimnetz hat das Netz 172.16.16.0/24
Wenn ich mit dem MacBook den Hotspots meines Smartphones nutze und dann eine VPN Verbindung (OpenVPN) auf meinen Heimrouter (Asus rt-ac66u, mit dessen WLAN auch die Sonos LS verbunden sind) aufbaue, habe ich eine IP aus dem 10.0.0.0/24 Netz.
Fakt 3:
Aus dem VPN Netz kann ich zwar die IP des Sonos LS (172.16.16.0/24) pingen und bekomme sogar eine Antwort, aber die Sonos Desktop Software für OSx findet die LS nicht.
Ob es jetzt an dem Billigrouter liegt oder an irgendwelche Protokollen wird hoffentlich der Mitschnitt des Kabelhais zeigen. Sobald ich ihn habe, reiche ich ihn hier nach.
Gruß
zumindest schreibt das die Android App für Sonos so vor.
OK, Smartphones haben in der Regel ja auch keinen RJ-45 Anschluss für ein LAN in so fern ist diese Vorgabe ja ein Lacher... Bei der PC oder laptop App siehts da sicher anders aus und da dürfte es wohl herzlich egal sein obs die IP Pakete über Draht oder Luft kommen.aufbaue, habe ich eine IP aus dem 10.0.0.0/24 Netz.
Ääähhhh, ja ! Die hast du ja wohl auch SELBER auf deinem OVPN Server mit dem server 10.0.0.0 255.255.255.0 Statement in deiner server.conf Konfig Datei eingestellt !!Logisch das er dann eine 10er Client IP hat !
aber die Sonos Desktop Software für OSx findet die LS nicht.
Da stellt sich dann nun die Frage WIE kommunizieren die über IP ??OK, wenn das Multicasting ist musst du PIM Routing auf dem OVPN Router aktivieren. Ist das ein Broadcast muss man einen UDP Helper konfigurieren.
Eigentlich ist das alles mit wenig Aufwand lösbar...
Fazit wie immer: Wireshark anschmeissen....!!
Wir sind auf deinen Trace gespannt !
Zitat von @aqui:
Ääähhhh, ja ! Die hast du ja wohl auch SELBER auf deinem OVPN Server mit dem server 10.0.0.0 255.255.255.0 Statement in deiner server.conf Konfig Datei eingestellt !!
Logisch das er dann eine 10er Client IP hat !
Nicht wirklich, das macht der Asus Router automatisch, aber man kann es natürlich von Hand dann anpassen Ääähhhh, ja ! Die hast du ja wohl auch SELBER auf deinem OVPN Server mit dem server 10.0.0.0 255.255.255.0 Statement in deiner server.conf Konfig Datei eingestellt !!
Logisch das er dann eine 10er Client IP hat !
Aber spielt ja hier mal keine Rolle.
Wir sind auf deinen Trace gespannt !
Hier mal ein Trace (bin mir nicht sicher wie ich den am lesbarsten exportiere, kann ich gerne im Nachhinein noch editieren) wo ich nur die Kommunikation zwischen meinem Macbook (172.16.16.100) und dem Sonos LS (172.16.16.8) gefiltert habe.No. Time Source Destination Protocol Length Info
396 16.592072000 172.16.16.8 172.16.16.100 UDP 408 Source port: 42161 Destination port: 1901
No. Time Source Destination Protocol Length Info
397 16.593098000 172.16.16.8 172.16.16.100 UDP 408 Source port: 39119 Destination port: 1901
No. Time Source Destination Protocol Length Info
399 16.593711000 172.16.16.8 172.16.16.100 UDP 408 Source port: 49141 Destination port: 1901
No. Time Source Destination Protocol Length Info
402 16.603379000 172.16.16.8 172.16.16.100 UDP 408 Source port: 37312 Destination port: 1901
No. Time Source Destination Protocol Length Info
403 16.607398000 172.16.16.100 172.16.16.8 TCP 78 49925→1400 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=32 TSval=400240559 TSecr=0 SACK_PERM=1
No. Time Source Destination Protocol Length Info
404 16.608948000 172.16.16.8 172.16.16.100 TCP 74 1400→49925 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 SACK_PERM=1 TSval=8036237 TSecr=400240559 WS=4
No. Time Source Destination Protocol Length Info
405 16.609007000 172.16.16.100 172.16.16.8 TCP 66 49925→1400 [ACK] Seq=1 Ack=1 Win=131744 Len=0 TSval=400240560 TSecr=8036237
No. Time Source Destination Protocol Length Info
406 16.609055000 172.16.16.100 172.16.16.8 HTTP 208 GET /xml/device_description.xml HTTP/1.1
No. Time Source Destination Protocol Length Info
407 16.610753000 172.16.16.8 172.16.16.100 TCP 66 1400→49925 [ACK] Seq=1 Ack=143 Win=5792 Len=0 TSval=8036237 TSecr=400240560
No. Time Source Destination Protocol Length Info
408 16.614566000 172.16.16.8 172.16.16.100 TCP 1514 [TCP segment of a reassembled PDU]
No. Time Source Destination Protocol Length Info
409 16.614914000 172.16.16.8 172.16.16.100 TCP 1514 [TCP segment of a reassembled PDU]
No. Time Source Destination Protocol Length Info
410 16.614977000 172.16.16.100 172.16.16.8 TCP 66 49925→1400 [ACK] Seq=143 Ack=2897 Win=129600 Len=0 TSval=400240564 TSecr=8036238
No. Time Source Destination Protocol Length Info
411 16.615927000 172.16.16.8 172.16.16.100 TCP 578 [TCP segment of a reassembled PDU]
No. Time Source Destination Protocol Length Info
412 16.616004000 172.16.16.100 172.16.16.8 TCP 66 49925→1400 [ACK] Seq=143 Ack=3409 Win=130560 Len=0 TSval=400240565 TSecr=8036238
No. Time Source Destination Protocol Length Info
413 16.617415000 172.16.16.8 172.16.16.100 TCP 1514 [TCP segment of a reassembled PDU]
No. Time Source Destination Protocol Length Info
414 16.619300000 172.16.16.8 172.16.16.100 TCP 1514 [TCP segment of a reassembled PDU]
No. Time Source Destination Protocol Length Info
415 16.619370000 172.16.16.100 172.16.16.8 TCP 66 49925→1400 [ACK] Seq=143 Ack=6305 Win=129600 Len=0 TSval=400240567 TSecr=8036239
No. Time Source Destination Protocol Length Info
416 16.620379000 172.16.16.8 172.16.16.100 TCP 1514 [TCP segment of a reassembled PDU]
No. Time Source Destination Protocol Length Info
417 16.620486000 172.16.16.100 172.16.16.8 TCP 66 49925→1400 [ACK] Seq=143 Ack=7753 Win=131072 Len=0 TSval=400240568 TSecr=8036239
No. Time Source Destination Protocol Length Info
418 16.621143000 172.16.16.8 172.16.16.100 TCP 1514 [TCP segment of a reassembled PDU]
No. Time Source Destination Protocol Length Info
419 16.621732000 172.16.16.8 172.16.16.100 HTTP/XML 121 HTTP/1.1 200 OK
No. Time Source Destination Protocol Length Info
420 16.621812000 172.16.16.100 172.16.16.8 TCP 66 49925→1400 [ACK] Seq=143 Ack=9257 Win=131008 Len=0 TSval=400240569 TSecr=8036239
No. Time Source Destination Protocol Length Info
421 16.621876000 172.16.16.100 172.16.16.8 TCP 66 49925→1400 [FIN, ACK] Seq=143 Ack=9257 Win=131072 Len=0 TSval=400240569 TSecr=8036239
No. Time Source Destination Protocol Length Info
422 16.622885000 172.16.16.100 172.16.16.8 TCP 78 49926→1400 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=32 TSval=400240570 TSecr=0 SACK_PERM=1
No. Time Source Destination Protocol Length Info
423 16.623611000 172.16.16.8 172.16.16.100 TCP 66 1400→49925 [ACK] Seq=9257 Ack=144 Win=5792 Len=0 TSval=8036241 TSecr=400240569
No. Time Source Destination Protocol Length Info
424 16.624404000 172.16.16.8 172.16.16.100 TCP 74 1400→49926 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 SACK_PERM=1 TSval=8036241 TSecr=400240570 WS=4
No. Time Source Destination Protocol Length Info
425 16.629747000 172.16.16.100 172.16.16.8 TCP 66 49926→1400 [ACK] Seq=1 Ack=1 Win=131744 Len=0 TSval=400240571 TSecr=8036241
No. Time Source Destination Protocol Length Info
426 16.629748000 172.16.16.100 172.16.16.8 HTTP 295 SUBSCRIBE /ZoneGroupTopology/Event HTTP/1.1
No. Time Source Destination Protocol Length Info
427 16.629890000 172.16.16.100 172.16.16.8 TCP 78 49927→1400 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=32 TSval=400240575 TSecr=0 SACK_PERM=1
No. Time Source Destination Protocol Length Info
429 16.631769000 172.16.16.8 172.16.16.100 TCP 66 1400→49926 [ACK] Seq=1 Ack=230 Win=6864 Len=0 TSval=8036243 TSecr=400240571
No. Time Source Destination Protocol Length Info
430 16.632657000 172.16.16.8 172.16.16.100 TCP 74 1400→49927 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 SACK_PERM=1 TSval=8036243 TSecr=400240575 WS=4Da ich kein Profi bin, bin ich auf deine Einschätzung gespannt @aqui
Ich erkenne nur, dass über einige verschiedene Ports offenbar kommuniziert wird.
Michi, mal ne doofe Frage: Wie man Capture Filter aufsetzt beim Wireshark weisst du schon, oder ?
Der Trace ist doch sinnfrei. Von der Länge mal nicht zu reden... Das ist HTTP bzw. XML und das ist natürlich routebar.
Es geht doch lediglich darum WIE sich die Komponenten bekannt machen ! Streame also KEINE Musik erstmal und setze einen Filter auf die LS IP oder dessen Controller und sniffer ggf. Broad- oder Multicast Frames mit die die Geräte Signalisierung machen.
Der Trace ist doch sinnfrei. Von der Länge mal nicht zu reden... Das ist HTTP bzw. XML und das ist natürlich routebar.
Es geht doch lediglich darum WIE sich die Komponenten bekannt machen ! Streame also KEINE Musik erstmal und setze einen Filter auf die LS IP oder dessen Controller und sniffer ggf. Broad- oder Multicast Frames mit die die Geräte Signalisierung machen.
So nach Durchsicht des Traces vom Kollegen michi1983 findet man dort auch die relevanten Frames. Leider hat er uns genau die oben vorenthalten (Er hat aber versprochen beim nächsten Mal sinnvoll zu filtern )
Nach dem Trace sieht es so aus also ob die Signalisierung mit SSDP gemacht wird:
https://en.wikipedia.org/wiki/Simple_Service_Discovery_Protocol
Wie man sieht nutzt SSDP UDP Frames und eine Multicast Adresse. 239.255.255.250 als Destination.
Da das keine nicht routebaren 224er MC Adressen sind (local Subnet, wie Bonjour)
https://en.wikipedia.org/wiki/Multicast_address#Local_subnetwork
wären sie per se routebar mit PIM.
Sieht man sich allerdings im Trace oben mal ein Paket detailiert an, sieht man das der TTL Wert im Layer 3 Header von Sonos auf 2 gesetzt ist.
Maximal ist es also über 2 Routehops routebar.
Für die entsprechende Anwendung des TO über einen VPN Hop würde es aber vollkommen ausreichen. Fragt sich nur ob sein Router das erforderliche Multicast PIM Routing supportet ?!
(Er hat aber versprochen beim nächsten Mal sinnvoll zu filtern )Nach dem Trace sieht es so aus also ob die Signalisierung mit SSDP gemacht wird:
https://en.wikipedia.org/wiki/Simple_Service_Discovery_Protocol
Wie man sieht nutzt SSDP UDP Frames und eine Multicast Adresse. 239.255.255.250 als Destination.
Da das keine nicht routebaren 224er MC Adressen sind (local Subnet, wie Bonjour)
https://en.wikipedia.org/wiki/Multicast_address#Local_subnetwork
wären sie per se routebar mit PIM.
Sieht man sich allerdings im Trace oben mal ein Paket detailiert an, sieht man das der TTL Wert im Layer 3 Header von Sonos auf 2 gesetzt ist.
Maximal ist es also über 2 Routehops routebar.
Für die entsprechende Anwendung des TO über einen VPN Hop würde es aber vollkommen ausreichen. Fragt sich nur ob sein Router das erforderliche Multicast PIM Routing supportet ?!
Nach Aufklärung von Kollege @aqui gibt es noch 2 Workarounds für das Problem des TO.
1. Ethernet bridging:
https://openvpn.net/index.php/open-source/documentation/miscellaneous/76 ...
2. Man konfiguriert den OpenVPN Server so, dass die Clients IP Adressen aus dem selben Netz bekommen in welchem sich die Sonos LS befinden.
Nachteil: Der gesamte Broad- und Multicast Traffic beider Teilnetze muss durch den Tunnel und kostet natürlich Bandbreite.
Edit:
Hier auch noch die korrekten Traces damit man das schön sieht
1. Ethernet bridging:
https://openvpn.net/index.php/open-source/documentation/miscellaneous/76 ...
2. Man konfiguriert den OpenVPN Server so, dass die Clients IP Adressen aus dem selben Netz bekommen in welchem sich die Sonos LS befinden.
Nachteil: Der gesamte Broad- und Multicast Traffic beider Teilnetze muss durch den Tunnel und kostet natürlich Bandbreite.
Edit:
Hier auch noch die korrekten Traces damit man das schön sieht
No. Time Source Destination Protocol Length Info
1748 19.054595000 172.16.16.8 239.255.255.250 SSDP 454 NOTIFY * HTTP/1.1
2056 19.361744000 172.16.16.8 239.255.255.250 SSDP 402 NOTIFY * HTTP/1.1
2059 19.371266000 172.16.16.8 239.255.255.250 SSDP 458 NOTIFY * HTTP/1.1
2077 19.668586000 172.16.16.8 239.255.255.250 SSDP 451 NOTIFY * HTTP/1.1
2097 19.975864000 172.16.16.8 239.255.255.250 SSDP 457 NOTIFY * HTTP/1.1
Principally it is easy to get SONOS players running via VPN (I use openVPN embedded in my router).
As we know, the Sonos controller does not allow multicast.
Conclusion: the SONOS controller is not designed for that purpose. Technically it is no problem not to rely on a WLAN connection and address the devices directly via IP.
So we need an alternative: a) another controller app, that was designed with regards to home automation. OK so use "iHome" from Appstore, it´s free and allows to play your music, start and stop rooms or group them and select music from the library via VPN. But: no Spotify. Works great.
b) use scripts written in php, works fine, too, but only is for nerds. If you need more information, let me know (kram@cool.ms).
But you may ask: what is the purpose of playing music if you are not at home ?
Tell ya:
Use case: i have a home automation solution (rwe smarthome) that works with motion detectors and cameras. If someone not authorized enters my home, all SONOS devices are turned on, grouped, and a VERY LOUD Alarm ist played and I´m notified.
USE CASE 2: you have a subnetted enterprise network (several rooms \ stores) and you want to control your SONOS devices centrally.
Works great. SONOS really hast to improve.
As we know, the Sonos controller does not allow multicast.
Conclusion: the SONOS controller is not designed for that purpose. Technically it is no problem not to rely on a WLAN connection and address the devices directly via IP.
So we need an alternative: a) another controller app, that was designed with regards to home automation. OK so use "iHome" from Appstore, it´s free and allows to play your music, start and stop rooms or group them and select music from the library via VPN. But: no Spotify. Works great.
b) use scripts written in php, works fine, too, but only is for nerds. If you need more information, let me know (kram@cool.ms).
But you may ask: what is the purpose of playing music if you are not at home ?
Tell ya:
Use case: i have a home automation solution (rwe smarthome) that works with motion detectors and cameras. If someone not authorized enters my home, all SONOS devices are turned on, grouped, and a VERY LOUD Alarm ist played and I´m notified.
USE CASE 2: you have a subnetted enterprise network (several rooms \ stores) and you want to control your SONOS devices centrally.
Works great. SONOS really hast to improve.
The main problem is the use of multicasts. From a manufacturer perspective it is easy and definitely not wrong to do it, but in routed environments it can cause problems if endcustomers use cheap home equipment.
In general such hardware is not capable of routing multicast with PIM. In terms of VPNs you need to switch to a bridged tunnel which is really bad in terms of performance and requires tweaking the tunnel endpoints with filters to keep away unwanted traffic from the tunnel.
Usually its possible with the right hardware but definitely not for an average home user who has no clue about networking.
In general such hardware is not capable of routing multicast with PIM. In terms of VPNs you need to switch to a bridged tunnel which is really bad in terms of performance and requires tweaking the tunnel endpoints with filters to keep away unwanted traffic from the tunnel.
Usually its possible with the right hardware but definitely not for an average home user who has no clue about networking.
