SkyQ and Sonos interfering with each other
Best Answers
I've proven some of the stuff I suspected was happening here actually is - tl;dr -
- Scenario is quite obscure - depends on topology.
- Sonos can drop data but Sky Q is passing data that standards would dictate that Sonos should drop.
- Other 100Mbps equipment like Sonos might do the same thing.
- Have not tested what happens if Sonos is made to bridge traffic between Sky Q boxes wirelessy. This might happen by accident in a mesh.
-- more detail --
It is a reasonably obscure scenario to get into either by wriring up a particular topology in your home, or perhaps if certain links are made to be up or down in the overall mesh of the two systems.
The problem occurs if a piece of Sonos equipment (perhaps any 100Mbps equipment) is used as a bridge to forward ethernet frames that use Sky's tunnelling protocol and that these frames are too big for Sonos to forward. What is in these frames un-tunnelled can ironicaly be the Sonos traffic that could have previously passed through that Sonos device before in the opposite direction. My broken topology did put this constraint on a Sonos device (a Playbar in this case).
So the Sonos is at fault? No.
In this case the Sky Main box is sending a frame to the Sky Hub (I think the laptop up there moved onto the Hub's Wifi AP different from my pictre above) that has a size of 1528.
This was gotten from Wireshark monitoring a mirrored switch port and setting the network interface in Mac OS to allow jumbo frames. Otherwise my computer itself would sillently have dropped these frames and I could not have shown them here 😃. Also to show the tunnelling you must add this configuration to Wireshark.
decode_as_entry: ethertype,29812,(none),Ethernet
decode_as_entry: ethertype,29920,(none),Ethernet
The maximum size that should appear to be more compliant is 1514. That is the MTU of 1500 and the 14 bytes that make up 2 x 6 byte MAC addresses and the 2 byte protocol.
So the Sky tunneling protocol is broken as it can not tunnel through devices that limit their frame size in a more standard way, and may be limited from allowing anything more by their hardware too.
If the inner frame were 14 bytes or more smaller then it would make it through, so pings and smaller TCP streams will make it through.
A a fix in this lab test like topology would be for the MTU as seen by the OS inside Sonos to be lowered by 14 bytes. This would make the tunnelled Sky Q frames smaller because the original Sonos frames before tunnelling would be smaller. It would only help Sonos traffic and not other traffic that got tunnelled. It would be a silly thing for Sonos to do really anyway.
What Sky will have done with their protocol is have been sneaky and tried to take advantage of the fact that newer equipment supports larger ethernet frame sizes in order to support things linke 802.1ax which gives an extra 22 bytes to play with, though these are supposed to be in the headers and not in the protocol data unit.
@woodchal Are your old switches that were/are sitting between Sky equipment only 100Mbps by any chance? If they are then swap them for Gigabit ones.
This discussion has been locked
Sorry, you can't reply to this discussion as it's been locked by our Community Managers.
This discussion has been locked
Sorry, you can't reply to this discussion as it's been locked by our Community Managers.
