Komisches Verhalten bei Musikbibliothek in 5GHz WLAN


Abzeichen
Hallo Sonos-Community,

ich habe ein Netzwerkproblem mit meiner Sonos-Installation bei dem ich für Hilfe dankbar wäre.

ich besitze einen Play:5, einen Play:1 und einen Sub. Der Play:1 hängt per Kabel an einer FritzBox 7490, die anderen Sonos-Geräte sind in SonosNET des Play:1. Im Controller werden alle Sonos-Geräte als "WM: 0" angezeigt.

Über das 5GHz-WLAN ist ein Raspberry Pi mit Samba mit der FritzBox verbunden, der die Musikbibliothek zur Verfügung stellt. Samba ist für SMBv1 konfiguriert, "ntlm auth" und "lanman auth" sind beide auf "yes". Zugriff auf die Musikbibliothek per Windowsrechner oder über andere Linuxrechner funktioniert perfekt.

Der Zugriff von Sonos aus scheint instabil. Zum Beispiel fehlen nach Indizieren der Musikbibliothek diverse Stücke bzw. Alben. Weiterhin gibt es beim Abspielen von Titeln manchmal Abbrüche oder das Abspielen startet gar nicht.

Sehr komisch ist nun, dass alle perfekt funktioniert, sobald ich den Raspberry Pi ins 2,4GHz-Netz hole. Dann werden alle Titel korrekt indiziert und es gibt keine Abbrüche beim Abspielen. Eigentlich sollte das doch keinen Unterschied machen. Sonos greift über LAN auf die FritzBox zu und für den Zugriff auf Samba sollten Broadcasts oder Multicasts irrelevant sein.

Den Raspberry Pi dauerhaft im 2,4GHz-Netz zu betreiben geht aus anderen Gründen nicht.

Versteht jemand, warum sich meine Installation so verhält und hat einen Tipp, wie ich Abhilfe schaffen könnte?

Vielen Dank und viele Grüße
Manuel

11 Antworten

Benutzerebene 6
Kann mir nur vorstellen, dass Du Aussetzer auf der 5G-Strecke zum PI hast und der Stream bzw. die SMB-Session dadurch von Zeit zu Zeit abreist !?
Btw. find ich es gewagt ein NAS via WLAN einzubinden. Ich würde da IMMER auf LAN gehen !
- aber Du wirst Deine Gründe für diese Experimente haben.
Hast Du die Strecke schon mal mit JPerf untersucht ?
- der Server-Demon dafür lässt sich auf der Fritte ja über "/support.lua" recht einfach aktivieren.
Vom PI über die Console kannst Du den dann ja mal mit allen möglichen Paketen via TCP und UDP auf Herz und Nieren penetrieren und siehst was die Verbindung her gibt.
Abzeichen
Vielen Dank für den Gedanken. Habe mir die beiden Netzt - 5 GHz und 2,4 GHz - angeschaut und kann keine Unterschiede feststellen, die die Probleme erklären könnten.

Habe etwas weiter experimentiert und bin noch mehr verwirrt: Wenn Sonos über einen "Proxy" im 2,4-GHz-Netz auf die Musikbibliothek auf Samba-Server im 5-GHz-Netz zugreift funktioniert alles prima.

Der Aufbau ist hier so, dass die Musikbibliothek weiter auf dem Raspberry Pi via Samba im 5-GHz-Netz zur Verfügung gestellt wird. Ein zweiter Raspberry Pi im 2,4-GHz-Netz, der über die FritzBox mit dem ersten Raspberry Pi verbunden ist, mountet die Freigabe des ersten Raspberry Pis und stellt sie selbst als eigene Samba-Freigabe wieder zur Verfügung. Sonos greift dann auf Samba auf dem zweiten Rasperry Pi im 2,4-GHz-Netz zu, der sich die Inhalte vom ersten Raspberry Pi holt. Das funktioniert prima. Es gibt keine Abbrüche bei der Wiedergabe und beim Indizieren der Bibliothek werden sämtliche Titel erfasst.

Das Problem muss damit für mich etwas damit zu tun haben, wie Sonos auf Samba zugreift, und das wiederum verursacht über 5-GHz-Transportstrecken Probleme.

Könnte das etwas mit MTU, MSS oder dergleichen auf Netzwerkebene zu tun haben?

Danke und Grüße
Manuel
Benutzerebene 6
Manuel123 schrieb:

Habe etwas weiter experimentiert und bin noch mehr verwirrt: Wenn Sonos über einen "Proxy" im 2,4-GHz-Netz auf die Musikbibliothek auf Samba-Server im 5-GHz-Netz zugreift funktioniert alles prima.
...
Das Problem muss damit für mich etwas damit zu tun haben, wie Sonos auf Samba zugreift, und das wiederum verursacht über 5-GHz-Transportstrecken Probleme.

Für mich ergibt sich da ein Problem im Routing / in der Datenübermittlung zwischen dem 2,4G- und 5G-WLAN.

Werden beide WLAN-Netze von ein und dem selben AccessPoint bereitgestellt oder betreibst Du eine logische Trennung und hast ggf. noch eine Firewall am Laufen, welche da evtl. ein paar Pakete / Ports blocken könnte ???
>> https://support.sonos.com/s/article/688?language=de
Ist die Kommunikation zwischen den Clients der beiden WLAN-Bereiche erlaubt oder wird die ggf. (wie auch immer) unterbunden ???
Werden die WLANs von der Fritte bereitgestellt oder hast Du separate APs (wenn ja was für welche) ???
Abzeichen
Beide WLANs werden von der selben FritzBox bereitgestellt. Der Übergang zwischen 2,4 GHz und 5 GHz findet damit tatsächlich in der FritzBox statt. Das Routing müsste Sonos (2,4 GHz) --> FritzBox (2,4 GHz) --> FritzBox (5 GHz) --> Samba (5 GHz) sein. Sämtliche involvierten Geräte sind im selben 192.168.178.XXX-Subnetz.

Mein Problem tritt wie im ersten Post beschrieben auch dann auf, wenn Sonos nicht über WLAN sondern über LAN mit der FritzBox verbunden ist, also Sonos (LAN) --> FritzBox (LAN) --> FritzBox (5 GHz) --> Samba (5 GHz).

Damit habe ich das Problem beim Übergang zwischen LAN und 5 GHZ und auch beim Übergang zwischen 2,4 GHz und 5 GHz.

Interessanterweise tritt beim Übergang LAN und 2,4 GHz kein Problem auf. Diese Konfiguration funktioniert: Sonos (LAN) --> FritzBox (LAN) --> FritzBox (2,4 GHz) --> Samba (2,4 GHz).

Grüße
Manuel
Benutzerebene 6
Wie mountest Du den Share genau auf dem 2,4er-PI ?
- läuft die Verbindung zwischen den PI's auch über SMB oder nutzt Du da NFS ?

Meine Überlegung geht dahin, das der Samba-Stack im 5G ja auch eine Macke haben könnte ?!
... denn wenn "Sonos (LAN) --> FritzBox (LAN) --> FritzBox (2,4G) --> Samba (2,4G)" funzt, aber "Sonos (LAN) --> FritzBox (LAN) --> FritzBox (5G) --> Samba (5G)" nicht, dann bleiben als mögliche Ursache ja immer noch "FritzBox (5G)" und "Samba (5G)" !?

Ich will die Fritte nicht per se ausschließen, aber die Wahrscheinlichkeit tendiert eher gegen Null als wie bei einer eher nicht so verbreiteten Samba (5G) auf RasPI :?

Wenn Dein Mount vom 1. PI zum 2. PI allerdings auch über SMB läuft, dann könnte man den PI als Ursache ausschließen und es müsste definitiv an der Fritte liegen ...
... wobei ich mich dann frage ob und warum das noch keinem Aufgefallen ist, gerade bei der Verbreitung dieser Kisten ?!
Abzeichen
Ich mounte mit "mount -t cifs -v -o guest,x-systemd.automount,x-systemd.idle-timeout=120 //nas/share5GHz /mnt/share24GHz/"

Damit sollte der 2,4-GHz-Pi via SMB auf den 5-GHz-Pi zugreifen. Das verwendete Protokoll dazu sollte zwischen den beiden Pis verhandelt werden - dazu weiter unten mehr.

Dass die FritzBox das Routing von 2,4 GHz und 5 GHz nicht sauber hinkriegt würde mich sehr überraschen. Wie du schon schreibst, dürfte ich ja nicht der erste sein, der das macht. Was meinen Fall vielleicht ein wenig besonders macht, ist dass mein 2,4 GHz WLAN eine andere SSID hat als das 5 GHz WLAN. Aber auch das sollten ja auch andere so machen.

Wenn es am Samba-Stack bei 5 GHz liegt, muss es aber an der Kombination Sonos und Samba bei 5 GHz liegen. Andere Clients, z. B. Windows oder Linux können ja fehlerfrei auf Samba bei 5 GHz zugreifen. Da kamen meine MTU- und MSS-Gedanken aus dem letzten Post her.

Ich bin beim Experimentieren noch an etwas anderem vorbeigekommen, das ich gerade nicht verstehe, das aber vielleicht eine Ursache jenseits des Samba-Stacks oder der FritzBox sein könnte.

Wenn ich so mounte wie oben geschrieben, müsste nach meinem Verständnis Sonos via SMB1 auf den 2,4-GHz-Pi zugreifen und dieser mit SMB2 auf den 5-GH-Pi. Zumindest sehen die Logs der beiden Pis so aus, als ob sie sich auf eine Variante von SMB2 einigen würden. Hier funktioniert alles prima, keine Abbrüche, vollständiges Indizieren.

In einem alternativen Versuche habe ich so gemountet, dass der 2,4-GHz-Pi mit SMB1 auf den 5-GHz-Pi zugreifen muss. Der dabei verwendete Befehlt ist: "mount -t cifs -v -o guest,x-systemd.automount,x-systemd.idle-timeout=120,vers=1.0 //nas/share5GHz /mnt/share24GHz/"

Hier müsste dann die Strecke Sonos via SMB1 auf 2,4-GHz-Pi und der via SMB1 auf den 5-GHz-Pi sein. Das zeigt dann interessanterweise ein ähnliches Fehlerbild als bei Zugriff von Sonos direkt auf den 5-GHz-Pi: Kein vollständiges Indizieren und Verbindungsabbrüche. Ob es das identische Fehlerbild ist oder nur ähnlich kann ich nicht so genau sagen. "ntlm auth" und "lanman auth" auf "yes" in den Konfigurationen von beiden Sambas ändern an den Fehlern auch nichts.
Benutzerebene 6
Was passiert eigentlich wenn Du einen Win7-PC/NB ins 5G hängst und dort dann eine SMB-Share bereitstellst ???
Abzeichen
Danke für den Tipp. Das mal mit einem Windows-Share auszuprobieren ist eine gute Idee, hätte ich selber draufkommen können.

In der Konstellation Windows10-Freigabe der gleichen Medien über SMB1 im 5-GHz-Netz funktioniert es. Der Aufbau ist jetzt
Sonos (2,4 GHz) --> FritzBox (2,4 GHz) --> FritzBox (5 GHz) --> Windows10 (5 GHz).

Dann liegt es wohl an der Kombination 5 GHz, Samba und Sonos. Kombination deshalb, weil ja andere Clients (außer Sonos) mit Samba im 5-GHz-Netz kein Problem haben.

Gibt es noch Ideen, wie ich dennoch weiterkomme? Oder ist der Dauerbetrieb meines Samba-Proxies der künftige Normalzustand.

Danke und Grüße
Manuel
Benutzerebene 6
Manuel123 schrieb:

In der Konstellation Windows10-Freigabe der gleichen Medien über SMB1 im 5-GHz-Netz funktioniert es. Der Aufbau ist jetzt
Sonos (2,4 GHz) --> FritzBox (2,4 GHz) --> FritzBox (5 GHz) --> Windows10 (5 GHz).

Hast Du das auch mal mit einem Win7-Client mit SMB-Freigabe probiert ?!

Manuel123 schrieb:

Gibt es noch Ideen, wie ich dennoch weiterkomme? Oder ist der Dauerbetrieb meines Samba-Proxies der künftige Normalzustand.

Mir fällt dazu dann auch nichts weiteres ein, außer dass mein "Normalzustand" definitiv der Anschluss des PIs via Gigabit-Interface direkt am Router / Switch wäre.
Abzeichen
Windows 7 hab ich nicht so leicht zur Hand.

Was wäre da anders als bei Windows 10?

Danke und Grüße
Manuel
Benutzerebene 6
der SMB-Stack ggf. ... !?

Antworten

    • :D
    • :?
    • :cool:
    • :S
    • :(
    • :@
    • :$
    • :8
    • :)
    • :P
    • ;)

    Cookie-Richtlinen

    Wir machen Gebrauch von Cookies um Ihr Erlebnis zu personalisieren und zu optimisieren. Wenn Sie zustimmen, stimmen Sie unseren Bestimmungen bzgl. Cookies zu. Klicken Sie hier um mehr über unsere Cookies zu erfahren.

    Akzeptieren Cookie-Einstellungen