Wired speaker drops out in Mixed Mode


I have a Mixed Mode setup with Wired and WiFi connected speakers.I don't use SonosMesh as the WiFi space is so crowded that you can't run a single channel (1,6 or 11) clearly through out the setup.



Somehow the wired (!) office keeps dropping out.

Any idea why this would happened?
(and also I have STP undefined in my network matrix, to unknown devices..?!)

This topic has been closed for further comments. You can use the search bar to find a similar topic, or create a new one by clicking Create Topic at the top of the page.

23 replies

MDST,

I notice that you partially obscured MAC addresses for security. Note that the portion you obscured is the manufacturer's segment. This is relatively easy for a hacker to guess. (given that this is a SONOS forum)
A bit more info please:
- kindly list the WM parameters for each node
- kindly confirm which nodes have their radio disabled
- what WiFi setup do you have (router, APs, meshed WiFi, etc) and channel usage?
Sure!

Network mode
Play 5 (Office) and AMP (Small Bedroom) have WiFi Disabled and are running WM:0
SUB (Living Room) have WM:2
Master Bathroom, Master Bedroom, Kitchen and Living Room have WM:1

Wifi Setup
The network runs with several APs.
WiFi network no.1 is running 5G only. It has all clients, except SONOS.
WiFi network no.2 is running 2G only. It has all SONOS clients, nothing else.

Why not Sonos Mesh?
The 2G WiFi is running on different channels per AP, as the area is heavily congested with other 2G networks. (I wish I could run a single channel 2G, but it's sadly right down impossible)
I shall basically leave this to @ratty's greater expertise. But it is strange that the Sub is acting as Root Bridge. I would power off router, APs and Sonos, power back in that order. When you power back Sonos do wired units first
The matrix is rather meaningless in this context, other than indicating ambient noise levels and potential peer-to-peer signal strengths for grouping.

WM1/2 nodes should have their STP disabled, so the Sub just looks like it's confused. I would check behind its '/usr/sbin/brctl showstp br0' link to confirm this.

'Undefined' columns are a side-effect of nodes being in WiFi mode, or disabled radios, or a HT speaker's 5GHz interface. The matrix gets a bit messed up.

---

As for the original problem of the wired Office dropping out, I'd suspect a plain old wiring fault. Resocket the cables. If possible run some sustained ping tests using Nirsoft's PingInfoView or ping bursts from the Android/iOS Fing app.
One afterthought: I take it that the wired Office player was dropping out when played on its own. If it was grouped with wireless players, and was not the group coordinator (the first room), there could be wireless issues in play.
Thanks.

OFFICE
I checked the wiring. It's brand new. Running PING for about 2-3 minutes shows no single PING above 1ms.

STP
/usr/sbin/brctl showstp br0 shows wired speakers using STP and also the SUB

SUB
Don't know why it's acting fishy. Perhaps it's acting default as a root bridge if I connect satellites (surround) and therefor have STP enabled. /proc/ath_rincon/status still shows it's running in INFRA mode (Satellite)

Group Coordinator
This sounds like something I should dig deeper into. I though that one of the wired speakers would be group coordinator and since both are wired, there wouldn't be an issue. (Assuming they are part of same group)

Edit: "OK, I read up on the GC a bit. it clearly sounds like this is the issue" Now how to resolve it without manually choosing a wired player first...:?
"INFRA (satellite)" doesn't sound right for the Sub. And it definitely shouldn't think it's root. I suggest you factory reset it and add it again.

The GC is the first room in the group, to which other rooms are added. If that room is a pair, then the left unit is GC. Because the GC fetches the stream, and distributes it to the others, its connection is more stressed.
Thanks for the input Ratty,
I did a reset. First it looks normal, but then when I pair it with the Soundbar it becomes Root Bridge once again. I think it does have something to do with pairing Soundbars and Satellites
May I just check one thing - you did have actual problems with interference when trying SonosNet? I ask because I have run Sonos without problems in very congested WiFi environments. I realise every situation is different, but just wanted to make sure there were performance issues, not just a presumption that there would be such issues.
Thanks for the input Ratty,
I did a reset. First it looks normal, but then when I pair it with the Soundbar it becomes Root Bridge once again. I think it does have something to do with pairing Soundbars and Satellites


We do not recommend using the Sub or surround speakers as the wired products.

https://support.sonos.com/s/article/3209?language=en

If the SUB's WiFi card is enabled, then disable it as well, and enable the Playbar's(?) WiFi card instead.

P.S. Router and Access Points require to be set on the same channel, regardless whether Sonos is running over WiFi or SonosNet.
The Living Room's main speaker is on WiFi with WM:1, and the Sub is supposedly wireless with WM:2. Neither's radio can be disabled.

In any case a wired Sub, with a disabled radio, and a main speaker on WiFi is not going to work well owing to latency fluctuations. Mixed mode is risky enough between grouped rooms; using mixed mode within a home theatre setup is really asking for trouble.

---

I confess I've limited experience of Sonos home theatre setups in WiFi mode, so I'll have to put the Sub's behaviour down to mysterious idiosyncrasy. I don't think it's relevant to the original problem, though, which sounds like it's related to the choice of GC. If it's one of the WiFi'd players and the Office wired unit is grouped with it, the latency fluctuations between the two could be breaking the sync.
May I just check one thing - you did have actual problems with interference when trying SonosNet? I ask because I have run Sonos without problems in very congested WiFi environments. I realise every situation is different, but just wanted to make sure there were performance issues, not just a presumption that there would be such issues.

Yes. Thanks for considering John B. I've done a wifi survey also. It's not really ideal running 2G on a single channel in the environment.



We do not recommend using the Sub or surround speakers as the wired products. https://support.sonos.com/s/article/3209?language=en


If the SUB's WiFi card is enabled, then disable it as well, and enable the Playbar's(?) WiFi card instead.



I do agree. SUB and playbar are both running on Wifi. None are wired.

P.S. Router and Access Points require to be set on the same channel, regardless whether Sonos is running over WiFi or SonosNet.


Well... I don't really agree on this. (I don't see how this could even be a requirement). Each unit only communicate with their own Access Point. So this would be irrelevant. Same channels in a multi AP environment is though not recommended.

I confess I've limited experience of Sonos home theatre setups in WiFi mode, so I'll have to put the Sub's behaviour down to mysterious idiosyncrasy. I don't think it's relevant to the original problem, though, which sounds like it's related to the choice of GC. If it's one of the WiFi'd players and the Office wired unit is grouped with it, the latency fluctuations between the two could be breaking the sync.


I agree. GC is probably the issue. I'm gonna try to put Office on GC and see if it drops out. If it doesn't, at least the issue is identified. Thank you for taking time and help
Well... I don't really agree on this. (I don't see how this could even be a requirement). Each unit only communicate with their own Access Point. So this would be irrelevant. Same channels in a multi AP environment is though not recommended.
See this for example.
P.S. Router and Access Points require to be set on the same channel, regardless whether Sonos is running over WiFi or SonosNet.


Well... I don't really agree on this. (I don't see how this could even be a requirement). Each unit only communicate with their own Access Point. So this would be irrelevant. Same channels in a multi AP environment is though not recommended.

Sonos state that, for a system in WiFi mode using multiple access points, the channels should be the same.
https://support.sonos.com/s/article/126

This is to enable efficient grouping. Where they can, Sonos units will talk to each other directly within a group. If two players are attached to different APs, on different channels, they're unable to establish a peer-to-peer connection. The group may still work, but sub-optimally.
Well... I don't really agree on this. (I don't see how this could even be a requirement). Each unit only communicate with their own Access Point. So this would be irrelevant. Same channels in a multi AP environment is though not recommended.

See this for example.


That looks like a SonosNet feature, related to the spanning tree protocol. Not a 2G WiFi feature.

I expect that to be valid if you have a SonosNet, that is a mesh network. In that case having mesh-AP and SonosNet both fighting over 2G Channels with broadcasting, would create a noisy wireless environment.

In this case, there is neither a WiFi mesh or SonosNet present.
That looks like a SonosNet feature, related to the spanning tree protocol. Not a 2G WiFi feature.No, Keith N was discussing the same point I made above, namely that for a system attached to multiple APs in WiFi/"wireless" mode (i.e. not SonosNet) the APs need to share the same channel for "direct routing" between grouped nodes to function.
I don't really get it.

The SONOS connects with a standard 802.11g to the access point. 802.11g is not a SONOS standard but IEEE.

Direct routing lets one player bridge to another one (It's surely not a 802.11g feature). The only way I can see it being used, is outside 802.11g. The only network I can see where it being featured is in SonosNet. If SonosNet is disabled, where would that be?!!
A valid scepticism.

In fact in WiFi mode the peer-to-peer tunnels are still there, and you can inspect their signal strengths in the Network Matrix. They only get used as a direct path for the live audio stream between grouped nodes. For all other purposes -- playback commands, pings, http requests, etc -- the nodes talk via the AP as normal. In other words the direct routing topology is overlaid on the normal WiFi hub/spoke connections. So, yes, "outside 802.11g" is one way to describe it.

Sonos has patents in this area. You can google for them if you're interested.
I'm turning from sceptic to rather convinced this is not relevant when SonosNet is turned off.

If Direct Routing is through a tunnel in the 802.11g, then it is inside through a higher layer. Hence, channel choice have zero effect. It's just technically not possible.

If Direct Routing is outside, then it's running on another setup, communicating in the 2G spectrum, depending on channel choice. Then it must run on a separate protocol. The only one I can see that exist is SonosNet.

I did google it and found this one: http://www.patentsencyclopedia.com/app/20140098713. This is clearly not IEEE 802.11g. (And also impossible, as a patent wouldn't be able to change an industry standard).

I can only see this as SonosNet and related to the STP.

If there isn't a third WIFI network?!!!
I'm turning from sceptic to rather convinced this is not relevant when SonosNet is turned off. [...]
Nothing whatsoever to do with SonosNet.


Wireless setup requirements

The following requirements and limitations apply to a Sonos system operating in a wireless setup. If your network does not meet these requirements, we recommend configuring your system in a wired setup.

Your router must broadcast a 2.4GHz signal for Sonos products to connect to. If you have a dual band router (i.e., 2.4GHz and 5GHz), do not disable the 2.4GHz signal.
Wireless-N and Wireless-AC routers should work with Sonos as long as they are still broadcasting over B and G WiFi. Most Wireless-N and AC routers should do this unless manually configured not to.
The network must not contain enterprise access points that have been configured to require certificates or other forms of enterprise authentication. If you are using multiple access points, make sure they are all set to the same 2.4GHz wireless channel.
Sonos cannot connect to guest networks or networks that use a portal page to login.
Networks using wireless range extenders are known to cause issues with Sonos systems that are configured in a wireless setup.

https://support.sonos.com/s/article/126?language=en_US
If Direct Routing is through a tunnel in the 802.11g, then it is inside through a higher layer. Hence, channel choice have zero effect. It's just technically not possible.
It's perfectly possible. The channel is a shared medium. Layer 2 frames carry a destination address. There's nothing to stop a station having a 'side conversation' with a peer device. Remember that Sonos controls the entire networking stack on its own devices.

Sonos (Keith N) outlined how it works, and indeed I've seen it working by studying diagnostic pages that, regrettably, are no longer available to users.

I can only see this as SonosNet and related to the STP.

It's not SonosNet as such, but it does exploit the same L2 direct peer-to-peer tunnels. STP gets overlaid onto the L2 SonosNet mesh in order to sort out the multiple possible bridged paths and break loops. Direct Routing exists "outside" of both WiFi and SonosNet (STP) modes. In the latter case it bypasses the STP topology, creating a shortcut between 'leaves' of the tree.