Arc Ultra Bug: Internes Sonos-WLAN (SonosNet) schaltet sich erst ein, wenn Haupt-SSID hinterlegt ist

Der “Bug” ist schlichtweg das fehlende SonosNet. Mit dem Wegfall des SonosNets fällt auch das letzte Alleinstellungsmerkmal weg, darüber hinaus bürdet man damit dem Kunden die Verantwortung für eine kompatible Netzwerktopologie auf.

Ein ehemaliger Mitarbeiter schrieb auf Reddit vor etlichen Monaten, dass die Architekten des SonosNets alle nicht mehr in der Firma wären und das jetzige Team damit überfordert sei.

Puh… die Theorien werden imo immer wilder. Nichts davon ist tatsächlich belegbar. Warum sollte das mit SonosNet besser laufen!? Falls das Router 5GHz Wlan das der Heimkinokomponente stört, spielt auch SonosNet keine Rolle. Und falls eine Wlan Verbindung zum Router trotz Lankabel Pflicht wäre (was ich mir nicht vorstellen kann), kann die imho eigentlich nicht stören, denn das Router Wlan an sich wäre ggf. die Störquelle und nicht die Verbindung. 
Aus meiner Sicht bleibt lediglich die Frage, warum Sonos für die Arc Ultra bei Lanverkabelung die Wlan Daten haben will. Absicht oder Bug…!? Falls Absicht, kann das für mich trotzdem keine Ursache für Störungen innerhalb des Surround Setups sein. 
Falls Bug, dann einfach ändern für diejenigen, die dann besser schlafen können. 
Hier werden die ganze Zeit zwei verschiedene Dinge in einen Topf geworfen… zum einen das reine Bestehen zweier Wlans im 5GHz Band, die sich natürlich stören können, aber zum anderen eine (egal ob notwendige oder nicht notwendige) aktive Verbindung des zweiten Wlan Moduls der Arc Ultra zum Router Wlan, welche aber imo nicht stören kann. Über ihre Notwendigkeit kann man natürlich trotzdem diskutieren. Aber ich sehe da keinen direkten Zusammenhang. 

Diese Überlegungen sind legitim, erlaubt und tun im Übrigen gut. Dafür ist das Forum da, obwohl es inzwischen eh praktisch leer ist.

Warum sollte das mit SonosNet besser laufen!?

Es geht um den konkreten Anwendungsfall von ​@Giftstaub.

das der bug das fehlende sonosnet ist würde ich so nicht unterschreiben. Es reicht in der SW nur das wenn lan on, startet das Gelumpe ohne weitere Informationen zu benötigen weil der Master, die Bar alles verwaltet 

… hat nix mit der aktuellen SW zu tun

…tja 🤔 bis auf ein paar unbeugsame 😅 (Bewohner des gallischen Dorfes) 

Womit Du den Threadkern herausgearbeitet hast. Im SonosNet fungiert die verkabelte Komponente als Netzwerkbrücke, im Surroundsystem übernimmt die Soundbar eine vergleichbare Aufgabe. Es wurden Eigenschaften des SonosNets in den WLAN-Modus portiert, weshalb ich beim Surroundverbund bzw. im WLAN-Betrieb von “Direct Routing” spreche, um Verwechslungen mit dem SonosNet entgegenzuwirken.

Natürlich hat es das, schließlich hat man als Konsequenz den SonosNet-Stecker gezogen.

Hier der Beleg: Die Speaker nutzen eben KEIN isoliertes SonosNet mehr, sondern hängen als ganz normale Clients im 2,4-GHz-WLAN meines Mesh-Systems. Jeder 'intelligente' Kanalwechsel des Routers schlägt also voll auf die Surround-Kommunikation durch. Und genau deshalb brauche ich morgen den ASUS, um diesen Kanal endlich festzunageln.

Wenn die Arc Ultra trotz LAN-Anschluss die Surround-Speaker (Rears/Sub) als gewöhnliche Clients in mein 2,4-GHz-Haupt-WLAN schickt, wozu brauche ich dann überhaupt noch das Kabel? Der Witz am LAN-Anschluss war früher, dass er das stabile SonosNet aufgespannt hat. Heute scheint das Kabel nur noch die Bar zu füttern, während der wichtigste Teil – die synchrone Kommunikation im Raum – schutzlos dem 'intelligenten' Kanal-Hoping moderner Mesh-Router ausgeliefert ist.

lg

Michael

​@Giftstaub, die Arbeitsweise des Surroundverbunds ist im WLAN-Betrieb und im SonosNet die gleiche.

"@Hedy L., da muss ich dir widersprechen. In der Theorie mag die Logik ähnlich sein, in der Praxis macht es einen massiven Unterschied:

Fakt LAN: Wenn alle 4 Speaker per Kabel angebunden sind, habe ich null Synchronisierungsprobleme. Warum? Weil die Latenz im Ethernet konstant bei <1ms liegt und es keine Paketkollisionen durch Kanalwechsel gibt.

Fakt WLAN: Sobald sich die Speaker (wie auf meinen Screenshots bewiesen) im Haupt-WLAN anmelden, fangen die Probleme an. Ein Mesh-System wie Deco wechselt "intelligent" die Kanäle oder scannt die Umgebung. In diesem Moment steigt der Jitter (Latenzschwankung), und die Funk-Synchronisation zwischen Bar und Rears reißt ab. 

Das ist der Beweis: Das WLAN-Modul der Arc Ultra ist extrem anfällig für instabile Kanäle. Dass die App die Bar trotz LAN nicht findet, wenn das WLAN fehlt, zeigt nur, wie schlecht das Fallback-Management programmiert ist.

lg

Michael

Die Arbeitsweise des Surroundverbunds ist im WLAN-Betrieb und im SonosNet die gleiche. Im SonosNet spielt sich halt alles innerhalb des proprietären Funknetzes ab. Ist das verständlicher?

Bezüglich TP Deco, vielleicht handelt es sich um eine Konfigurationssache. Hilft die “Beste Antwort”? Ersetzen Sie “Bridge” gedanklich durch “Arc Ultra”.

​@Giftstaub 

Du hast glaube ich noch nicht verinnerlicht, dass die Rearspeaker nur zur Konfiguration über das Router Wlan kommunizieren. Der Audio Datenstrom im Surround Setup erfolgt von der Soundbar über deren selbst erzeugtes 5GHz Wlan zu Sub und Rearspeakern. 

​@Hedy L. 

Theorien? Ja klar… die sollten in einem Forum unbedingt kontrovers diskutiert werden können. 
Nur hört sich bei dir selten etwas nach Theorie an… du behauptest teils Dinge mit einer Selbstverständlichkeit, für die es keine Beweise gibt. Und wenn man es dann mühevoll mit Argumenten als eben „nicht Fakt“ oder gar „falsch“ belegt, ignorierst du es.

Beispiel zu Beginn dieses Threads: „Verbindung mit Wlan muss zwingend sein, weil gehört zum Setup Prozess“. 
 

​@Giftstaub 

Von meiner Seite ist alles zur Problematik gesagt. Ich stimme zu, dass der Zwang zur Wlan Verbindung in einer Lan Verbindung als nicht notwendig erscheint. 
Dass daraus die von dir beschriebenen Probleme innerhalb der Surround Setup Wiedergabe entstehen, glaube ich persönlich aus den genannten Gründen nicht. 
 

Ich drücke die Daumen, dass es mit Asus besser für dich läuft. 

Es steht Dir frei bei Sonos eine Petition einzureichen, dass ich jeden Satz bzw. jede Formulierung belegen muss. Bis dahin ... 👋

Mir steht zum Glück wie jedem hier vieles frei…

“Bis dahin…“ !? …muss nicht sein. 

Dann hänge ich mal was an.

https://www.reddit.com/r/sonos/comments/1isqqsq/comment/mdlz76s/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

Correct. The Sub and the rear surrounds will switch to 2.4 GHz whenever the Arc is dormant as a power-saving measure. This primarily serves to wake the surround and sub when the Arc receives a signal (TV or music), activating the connected units. The 2.4 GHz will remain active and won't turn off when 5 GHz is enabled.

Hedy L., danke für den Link! Der Text bestätigt exakt meine Beobachtung: Das versteckte Sonos-Signal krallt sich wie ein Schatten an den Kanal des Routers.

Er zeigt das eigentliche Problem:

Wenn die Arc Ultra zwingend dem Router-Kanal folgen muss, ist sie in modernen Wi-Fi 7 Umgebungen fast schon eine Fehlkonstruktion.

Die Mehrheit der Nutzer wird genau wie ich vor diesem Problem stehen. Ein modernes Wi-Fi 7 Mesh-System scannt und optimiert ständig die Kanäle – das ist der Standard für Wi-Fi 7 Performance. Wenn Sonos aber eine Architektur baut, die bei jedem Scan oder Kanalwechsel die Synchronisation der Rears dauerhaft verliert, ist das System schlichtweg nicht 'Mesh-kompatibel'.

Dass ich das Problem heute durch das 'Festnageln' der Kanäle am ASUS-Router für mich löse, ist nur ein Workaround für ein tiefliegendes Software-Problem bei Sonos. Es kann nicht die Lösung sein, dass Kunden ihre High-End-Router kastrieren und Automatiken abschalten müssen, nur damit die Soundbar nicht die Orientierung verliert.

Für mich ist die Sache klar:

Sonos hat die Eigenstabilität (SonosNet) aufgegeben, ohne eine softwareseitige Lösung für moderne, dynamische Netzwerke zu liefern. Ich ziehe für mich die Konsequenz mit der Hardware – für alle anderen bleibt zu hoffen, dass Sonos hier massiv nachbessert.

Theorien sind gut, aber meine Ohren und die Netzwerk-Logs lügen nicht. Danke für die Unterstützung!

lg

Michael

​@Giftstaub, ich hatte den Thread vor über einem Jahr gesehen und erst gestern wieder durchgelesen.

Dabei ist mir Folgendes aufgefallen bzw. wieder in Erinnerung gerückt. Der TE (im Asus-Mesh) schreibt im Eingangsposting:

Well I am seeing something odd, now I see a hidden signal called Sonos:4C:F8:1D, not Sonosnet but it is not on the channel in the app (6) it is on the same channel my router is on. Even stranger is if I change the channel the router uses this Sonos signal jumps to the same channel.

Er beschreibt damit die Voraussetzung für “Direct Routing”. Im Surroundverbund springt das 2.4 GHz-Band des “Sonos-WLANs” automatisch auf den WLAN-Kanal des Router auf (im proprietären SonosNet regelt das der ‘SonosNet’-Kanal; das Router-WLAN bleibt außen vor).

Was bedeutet, dass “Direct Routing” im WLAN-Betrieb auch außerhalb des Surroundverbunds aktiv ist, sobald sich alle Access Points / Meshknoten denselben Funkkanal teilen. Ob das lediglich im 2.4 GHz so ist oder auch im 5 GHz weiß ich allerdings nicht.

@Hedy L., danke für diese exzellente technische Ergänzung! Du bestätigst damit genau meine Analyse:

Das 'Direct Routing' ist das Problem in modernen Mesh-Systemen. Wenn Sonos voraussetzt, dass sich alle Knoten denselben Kanal teilen, das Mesh-System (wie mein Deco BE65 WiFi 7) aber genau das dynamisch anpasst, um Performance-Einbußen zu verhindern, knallt es.

Aber mal ehrlich: Ein System, das 'Direct Routing' erzwingt und dabei die Synchronisation verliert, wenn der Router modern arbeitet, ist im Jahr 2026 einfach nicht mehr zeitgemäß. Danke für den tiefen Einblick!

lg

Michael

Wie im Reddit-Thread steht: Im Ruhemodus sollte der 2.4 GHz-Funkkanal keine Rolle spielen. Der Aufbau eines proprietären 5 GHz inkl. Direct Routing ist im Surroundverbund die einzige Möglichkeit einer synchronen und störungsfreien Übertragung innerhalb einer drahtlosen Verbindung. Je nach Mehrkanalsystem sprechen wir hier von bis zu 18.000 kBit/s.