SkyQ and Sonos interfering with each other

[Mad+Sweeney]

@Rhonny 

That's the most optimal way to do things really in my mind too but hard/expensive for many people (refered to as option c later on).

The underlying  issue with Sky Q provided Wifi is less to do with how the mesh network works between all Sky Q equipment. That often works fine whether they're connected wired or wirelessly.

In either case think of that network as the backhaul network of the Sky Q system.

Usually when deciding to provide WiFi from a backhaul network one would imagine that the network in the access point device regardless of it's uplink type would simply be bridged/repeated and made available.  In this sense an entire LAN would be one layer 2 network.

This is not what is done by Sky Q.  Instead the Wifi provided by Sky Q acts more like what would be a called a guest network (It's probably like a tagged VLAN or something under the hood).  That guest network is serviced via the Sky Q router. This is why it is said one can't use Sky Q TV boxes as Wifi access points unless your broadband is provided by Sky because they explicitly don't just bridge the network they're uplinked to themselves but rely on services of the Sky Q router.  This will have been done so that traffic for video streams can be prioritized most likely, so the client device Wifi provision is secondary in some respects.

Conversely, the ethernet ports on the back of the Sky Q router can be considered to be what would be a private network (not a tagged VLAN like what appears over Wifi).  Obviously everyone having trouble with Sonos doesn't want two networks and the terms guest and private could be swapped for anything really but I've used them because the overall effect is similar to such a setup if it were wanted.

Technicaly speaking we can event think of 3 networks or pseudo VLANs, guest, private and TV.

Now the difference between the guest and private networks is not full isolation which would make them pretty useless to let wired and wireless LAN devices talk to each other over ethernet.  There is some attempt to bridge them inside the Sky Q router but not a very good one.  This is is a bit like trying to undo the separation that done earlier to make the TV distribution work well in many respects but undo it all out of the way inside the router so to speak.  tl;dr - Sky Q provided Wifi is much more complicated than one might think and will throw some knowledge of networking out the window and confuse even very knowledgeable engineers.

One can easilly test bridging ability between the two networks easilly enough. Obviously ARP works fine, allowing the same IP subnet accross both netwoks.  You can use tools like fing from a device on one network and see devices on the other.

Several other protocols fall down however.  Things I've tested that do not work if a client is on one network whilst a service is on the other.

• Sonos
• Chromecast
• Elgato Key Lights
• Oculus Quest video stream back to PC for recording.

So for all of these cases to work,  one must have client devices (phones, laptops) and the services (Sonos speakers  etc) on the same network (guest/wifi vs private/router ethernet port).

So the options to do that are plenty and many people will have just ended up lucky and gotten it right first time, others less so.  In order of most normal to most hard, there are 5 solutions:

a) Don't use Sonosnet - Connect Sonos via Wifi (Do not plug in any ethernet jack at all). Since clients connect to the same Wifi all is good.

b) Use Sononet but connected to the guest/wifi network. Slinging a cable between a Sky TV box (not the router) and a Sonos speaker will achieve that as the NICs in these are bridged into this guest like network.  If one does this though connect only ONE Sonos speaker (if another is left connected to the wired/private side then it won't work).  This does involve removing the plastic cap from the back of the Sky TV box and Sky would probably say that this was unsupported.

As a variant, one can also use a cheapo wifi client access device too, some people may still have the old "Wireless Connector" from a previous Sky Plus install that would do the job if reconfigured.

c) Use Sononet but provide all clients Wifi using one's own equipment and not Sky Q. This way the wired and wireless networks will be one network, not this kind of broken guest vs private scenario.

Note that one can disable Sky's Wifi entirely in this case but if you did that, you'd need to connect each TV box up with WPS again.  When asked to press a button on Sky equipment, instead press the WPS button on your own router/access point or trigger WPS via it's management interface/App if it has no button.

d) Wait for Sky to fix the way they provide Wifi by fixing the broken bridging in the router firmware.  I'd bet it is a bug in allowing IGMP forwarding between the two networks or something of that nature.

e) Wait for Sonos to write a different discovery protocol that uses more common / older protocols as it's basis or as a fallback. This way client devices could find Sonos devices in a broken network like the one Sky Q provided.

Talk about BSSIDs and stuff in the rest of here is likely a red (ish) herring.  They are relevant in scenarios where people might have augmented Sky Q's Wifi with their own access points backhauled onto the private/wired port of the Sky Q router.  That's what I did in my premisis originally and it was from doing that and finding things were always broken that I was able to figure out how the Sky Q boxes separate the wired (from the router) and wireless networks.

[Mad+Sweeney]

One thing I forgot to say was that at least for Sonos specically the bug in the Sky Q router only affects functionality in a particular direction.

The table feature of this forum does not work so here's it shown as a table with a key:

|     | CR | CW   |

|-----|----|------|

| SR  | OK | FAIL |

| SW  | OK | OK   |

CR = Client device on wired Sky Q router port

(includes case where device is on one's own Wifi AP that is plugged into Sky Q router)

CW = Client Device on Sky Q Wifi

SR =Sonos on wired Sky Q router Port

(includes case where Sonos is on one's own Wifi AP that is plugged into Sky Q router)

SW = Sonos connected via Sky Q Wifi

(normally without Sonosnet or plugged in point-to-point into a TV box making it be on Sky Q Wifi that way)

That is to say discovery attemps (I can't say packets) from clients on Sky Q Wifi to Sonos devices connected via the wired router ports get unfullfilled but do work the other way around if the client is connected via the Sky Q router port and the Sonos connects via Sky Q Wifi.  Of course it might actually be that either the requests or replies are getting lost, so the direction when spoken of in terms of packets could be either way around.

However the segmentation is asymetric in nature at least.

A Sonos engineer who know's their discovery protocol who had Sky Q equipment in their lab would probably be able to pinpoint the exact flaw in a matter of moments.

I may play with Wireshark later today to reverse engineer the protocol or see if there is more data on the Internet that explains how it works.

Debugging some of the other device connection isues I know about also might be easier too as given that so many local network services (gadgets on Wifi) get broken by Sky Qs Wifi infrastructure it may show a pattern.

[Mad+Sweeney]

My last post appears to have gone but in a nutshell Sky Q is mangling http connections that originate from client devices on Sky Q Wifi to Sonos devices connected via the wired router port.

Given a url like below (not in URL form as I think that is what blocked my prior post)

PROTOCOL: http

IP: That of any Sonos speaker on your network

PORT: 1400

PATH: /xml/device_description.xml

If you try this in a web browser it will not work when your computer is on SkyQ Wifi and the Sonos is wired.  If you connect your computer to the back of the router and put the URL in a browser again then it works.

Note however that port 1400 isn't fully blocked.  If you look in Wireshard you can see a partial response does come back and then it just fails from there.  This was the exact same thing I saw with video stream data coming back from an Oculus Quest 2 headset.

Here is Wireshark showing what's going on whilst a copy of wget is trying to pull the description from a Sonos speaker.

So, there is something nasty about traffic where Wifi based clients try to pull data from wired services on one's network for sure here.

[Rhonny]

@Mad+Sweeney

My, that's a lot to read! Leave it with me..!

[woodchal]

@Mad+Sweeney 

Thank you for your very thorough and thoughtful and thought-provoking post.

What version of SkyQ box are you using - I ask because you say, “This does involve removing the plastic cap from the back of the Sky TV box and Sky would probably say that this was unsupported.”  My box installed early 2020 and never had black caps and I think this might have been a feature of earlier models of SkyQ boxes.

For comparison my SkyQ is

• Hardware version is 32B206
• Software version Q15.000.2605L  (it was Q14, until recently)
• UI version 15.202.152.09
• Network version 2.0

It appears from your work that my BSSID comments were a symptom rather than a cause. 

I had eventually landed on your option a).  SkyQ and Sky mini connected by ethernet and Wifi on SkyQ and Sky mini Wifi turned off and Sonos only on Wifi (Nb in order to establish the Sonos network you do have to wire one Sonos device initially).   

However, I have just discovered, whilst writing this, that the system appears to have broken (was it the sky upgrade to Q15?) and the controller app will only see the Sonos system with one speaker connected by ethernet.  Obviously, I need to start a new round of investigation - I will try your option b).  @dingers05 appears to have successfully implemented option c).

As for option d) - there are rumours of a fix in Q16.

As for option e) and your comment “A Sonos engineer who knows their discovery protocol who had Sky Q equipment in their lab would probably be able to pinpoint the exact flaw in a matter of moments.  I do absolutely agree and as I said, “I would just like Sonos and Sky to talk together (digitally and physically) and resolve this (mesh) issue for customers - there should be no turf wars.”  This is harming both their reputations.

Note Sky are my broadband supplier, and this does not to seem to help.

There are other threads elsewhere about Wifi network bandwidth being flooded by SSDP traffic from both SkyQ and Sky mini.  The recommended solution is not to let the boxes go into standby modes.  I assume that this must be connected to your analysis as well.

[Mad+Sweeney]

@woodchal 

My Sky Q installation was done about a year after it became available so  the mini box with the plastic cap is hardware version 32D006. Currently running S150.000.27.00L.

After more digging yesterday into exactly was broken when I had a topology that should work but didn't was that SSDP was working fine.  What was going wrong were TCP (HTTP in this case) streams containing speaker device info going back to the Sonos App.  The Sky Q router appeared to be dropping packets that made up these streams with only some packets arriving on the laptop running the Sonos controller app.

In theory the Sky Q router should just be forwarding these packets on.  I did find however if I changed which device was the gateway into Sonosnet away from my Playbar to a Playbase in another room then what was in effect the same topology began to work.  I don't think the packets from the playbar were dropped close to the playbar, but perhaps the interface card in playbar is a little different from the one in the playbase and different packet sizes are used or something very low level like that.

I think a good test for people do to when things are broken is to take their phone or laptop that can't talk to a Sonos device and try to pull up the device info from a Sonos speaker manually themselves. This can be done by:

1. Finding an IP address of a Sonos speaker by either logging into the Sky Q router and looking at the /sky_attached_devices.html page for IP addresss of devices with the name SonosZP. Network scanning apps like Fing or Analiti will also let one find IP address and names of devices on a network.
2. Use a web browser and enter a url (do not include the + symbols) of http:// +  <found ip address> + :1400/xml/device_description.xml
3. See if they get anything back or an error.

If an XML document is returned but the Sonos App still does not work then the problem won't be the packet forwarding problem that I saw in my network.  It could be that there is more than one issue going on.

Now all this will do is just add data points into forums like this.

I suspect though that since connecting Sonos via Wifi rather than wire is always an option, that will just be pushed as the prefered soluction.  Getting Sky Q's Wifi close to a Sonos device if it is not already close enough is relatively easy either by adding booster devices from either Sky or Sonos's own Boost afterall.

[woodchal]

@Mad+Sweeney Happy to try and help crack this - So in my current configuration I have

Play1 - connected by ethernet to broadband (sky) modem/router/hub

Play1 - Wifi

Sonos 5 - Wifi (located near Sky mini)

TVBeam - Wifi, but connected to TV by HDMI arc,  The TV is connected to network by Ethernet.  This colocated next to the SKYQ.

SkyQ and Sky mini boxes are connected to the network by Ethernet

Sonos is configured like this because if I do not have one device cabled then the controller app fails to find the Sonos system (it was entirely Wifi based before Q15)

I have wifi turned off on SkyQ and Sky mini. (forcing all devices back to the Sky modem/router/hub).  I think since Q15 I may have started to experience the sound loss on the TV when replaying recorded material (There are many threads about this problem as well)  - I will report more

When I send the xml/device_description.xml call to the 4 speakers 3 respond, but silence from the TVBeam. If I pull the cable on the connect Play1, then the app fails to find the Sonos system and I have just checked and the xml call returns nothing from all of the Sonos devices.

[Mad+Sweeney]

For the Sonos devices that can be seen what does the Sonos app say for the 'WM:' value

WM: 0 This product is in a wired setup.

WM: 1 This product is in a wireless setup.

WM: 2 This product is bonded as a surround speaker or Sub to a Sonos home theater speaker in a wireless setup.

I'm going to guess that it will be 0, as my experience has been that even if a Sonos device has been used to connect to Wifi (given the SSID and password) that when there is a wired connection that everything else just follows suit.  Also it tallies with what you say about pulling the cable.

So given you've found the IP address of the Beam to be able to ask for its device description (and presuming there is nothing special about the Beam) but can't get the description back, its fair to say that it is on the network.

Given the sound loss from the Beam and that it is not responding to get its device details it sounds like part of it has crashed so I'd see what happens after rebooting it. Out of curiosity, I'd then  try making it the gateway into the Sonosnet instead of the first Play 1 as  I suspect that Sonos isn't using the Wifi.  Another thing to try might be to add the Beam as a new product again.  If you wanted to be more adventurous, before rebooting it you could try using a computer to access it's device describtion URL and use Wireshark filtered just for http, to see if anything at all is coming back.

It could also be that the Wifi setup you had before will work fine now but just needs redoing, so I'd have a go add removing the Wifi setting in the network part of the Sonos app and adding them back again.

I've certainy gotten things working in the past by setting it all up again but not really any differently from how it alreday was.

As an aside, I've had a Playbar for years and various times since havng Sky Q it has also lost sound from the optical input.  It appeared as if the Playbar was busy doing stuff and dropping samples coming in over the optical input. I think it got itself out of sync in some respects and would need a reboot.  One quirk was that it was possible to get the sound back sometimes by just scanning the LAN. There used to be a URL you could use to reboot Sonos devices remotely but now I think you have to power cycle them.

Sky Q + Sonos appears to go through phases of working well together and then one or the other will apply a software update and then it all goes to pot. Re-setting bits of it up, either logically or phsically appears to be par for the course, but usually you'll get a good few months of it working OK once you get it all working again.   Probably just being persistent will get things working but it may be impossible to tell exactly what it was that fixed things.

[Mad+Sweeney]

Note that for wired connections to the Sonos uplink node a poster in another thread mentioned that setting the Sky Q router to say its ports were fast ethernet (100Mbps) fixed the problem.  Given that plus my experience that changing the Sonos uplink node to a different speaker also can fix things, I bet that only some older Sonos models are affected.

The wired ethernet interfaces in Sonos devices are part of the system on chip. For example some older products use the MPC8247 for sure.

https://datasheet.octopart.com/MPC8247CVRTIEA-NXP-Semiconductors-datasheet-11553514.pdf

(Ever wondered why some Sonos products have 2 ethernet ports = because they can, it doesn't really cost more)

Anyhow, if I were able to raise a ticket directly into the correct bug queue for the Sky firmware developers my ticket would like this.

Subject: "Some but not all ethernet frames that have originated from or passed through a 100 Mbps network device that arrive at a wired ethernet port on a Sky Q hub are not forwarded/bridged correctly onward to clients on the wireless network but rather dropped if the wired port is set to Gigabit ethernet."

Hub Models: Please test all hub models with current firmware.  Certainly seen on ER110 running 2.22.2898.R.

100 Mbps devices to test:

Focus on older NXP (Formerly Freescale) MX based devices with embeded ethernet such as the MPC8247.  Older Sonos products such as the Playbar would be suitable candidates to start with.

If a regression can be confirmed through manual testing, please consider procuring a development board utilising matching SoCs (e.g https://www.nxp.com/design/qoriq-developer-resources/application-development-system-for-mpc8272:MPC8...) and using that to host a simple set of test services that simulate consumer products on it and add it to the automated test rig used for firmware update testing in order to avoid future regressions.

Packet types affected: Those making up an IPv4 TCP stream response. Focus on HTTP.

Notes: In the field devices who's packets have been dropped have been consumer devices on the wired network that host a web server over HTTP that are replying to a request made by a client on the wireless network.  As part of diagnostic testing, setting up a port forwarding rule from the external address to such a service and having the client device on the wireless network access via the external address and port yielded a working stream and response to the client.  This shows that the ethernet frames are arriving safey into the hub via the wired port and can leave it too if higher level forwarding is used. Low level ethernet forwarding looks to be the issue therefore.

I also got side tracked today and started reading some of the extensions to ethernet bridging inside the Linux kernel that Sonos add to their devices - http://www.sonos.com/documents/gpl/12.2/sonos-kernel.txz

It may be the case that the vendor who builds the Sky Q routers is obliged to publish some of their special sauce too under the GPL or something like that which might help all the other types of problem relating to Sky Q + Sonos with STP that I think still exist for peope using managed switches.

If that is the case it will be available under here:

http://www1.sky.com/opensourcesoftware/

[woodchal]

@Mad+Sweeney Following your 1:59am post - The TVBeam is within the Sonos network and I can share a sound stream between it and any of the other speakers.

Currently the speakers are all WM0.  Previously if you pulled the plug from the “establishing” device then the system did switch over to Wifi and they went over to WM1 - but not now!  The Sonos system just gives up.  I have tried setting it up from scratch and it still drops out when cable pulled.

I tried using the TVBeam as the establishing Sonos connection.  TVBeam comes up and can be seen as a connected device.  Then on powering up one of the other Sonos devices (no cable) it can also be seen as a connected device, but cannot be seen on the Sonos controller app.  I assume the Sonosnet is not established

I have no idea why the TV Beam might be different - I have mused if somehow the link to the TV, which is in itself is connected to the network, might be providing an unexpected network routing.  (Am I right in thinking that HDMI has the potential to carry network traffic via HDMI eArc?).  Of course, the TV Beam also has two sources of the sound - the TV and the network, so there must be some internal switching - I have successfully streamed the TV sound via the other speakers.

The sound dropouts do seem to be a SkyQ issue, rather than a Sonos issue.  The forum is red hot with people complaining about sound, glitches and picture pixilation (which I have now also experienced) since the move to Q15.

You said “Sky Q + Sonos appears to go through phases of working well together and then one or the other will apply a software update and then it all goes to pot. Re-setting bits of it up, either logically or phsically appears to be par for the course, but usually you'll get a good few months of it working OK once you get it all working again.   Probably just being persistent will get things working but it may be impossible to tell exactly what it was that fixed things”

This is so true, although not everyone’s experience it seems.  These are both consumer devices and this discussion will be beyond most consumers (it’s on the edge of my understanding!) - surely SkyQ and Sonos are such a common pairing that this should be part of both companies’ testing programmes.  (A point you make in your subsequent post)

In this subsequent post you say “Note that for wired connections to the Sonos uplink node a poster in another thread mentioned that setting the Sky Q router to say its ports were fast ethernet (100Mbps) fixed the problem”.  I assume this doesn’t mean the SkyQ TV box, rather the Sky Modem/router/hub (or perhaps another vendor).

[Mad+Sweeney]

@woodchal 

It does sound as if your Beam is considered to be in a somewhat different Sonos setup from all the rest of your speakers.  I know that when I visit the home of somebody else with Sonos that the app will just show their system if they give me their Wifi credentials, so it could be that it's like you have two different premesis as far as Sonos is concearned.  If bits of the network looked different or were segmented somehow then perhaps that could be a thing.

I doubt that ethernet over HDMI will be involved.  You're correct that it can be done but I don't think many TV's support it and that the Beam does not either.

Regarding the "Fast Ethernet" setting, yes this was talking about the setting on the Sky Hub at in the Ethernet section at /sky_eth_setup.html.  It couldn't do any harm in trying it out in your case as it can always be set back again.  Unless your broadband is faster than 100 Mbps or there is more than 100Mps of Wifi traffic heading into the wired part of the network or vice-versa, then having it set to 100 Mbps wouldn't really be much of big deal if it made Sonos work for now.

I'm 50:50 as to whether chaning Sky hub settings will help you out or that somehow the fix will be to fix something that's become misaligned with Sonos itself.  I'm convince though that you'll be able to fix it as your topology as explained does not look weird.

[woodchal]

@Mad+Sweeney Tried Fast ethernet but this didn’t seem to change the situation.

This is what wireshark shows for the call and response, evaluating this is beyond my experience though.

You say, “so it could be that it's like you have two different premises as far as Sonos is concerned.” - I don’t think this is true in the current set up, as once the Sonosnet is established using a different device as the gateway then the TVBeam is seen in the Sonosnet.  These type of thoughts though are what drove me to identify that when SkyQ was allowed to provide a secondary access point to the wifi (I now have it switched off) that the Sonos controller app would not see speakers that were on a different access point (with different BSSID).

One difference is that the Play1 used as a gateway is plugged directly into the Sky modem/router/hub, whereas the TVBeam is beyond a couple of switches - unmanaged but old.  I do have a very long ethernet cable that I can try plugging the TVBeam directly into the Sky modem/router/hub, which would eliminate the switches.

Have you posted your thoughts on the Sonos Community pages?

[woodchal]

This didn't seem to make it into the last post

[woodchal]

[63johnw]

Hi @woodchal  pictures need moderating before they appear on the forum.