Hacker News new | past | comments | ask | show | jobs | submit login

They form a tunnel mesh over that private “Sonosnet” wireless network and each player announces an internal bridge interface via STP, including over any regular wifi they’ve joined and any fixed wire network they’re connected to. That could be fine if it was contained to their private mesh, but it isn’t. Worse, they do it with pre-rSTP weights. Consequently electing their own low-bandwidth wireless mesh tunnels as a forwarding path in any nontrivial switched network. If they’re plugged into a hierarchy of unmanaged/non-STP-enabled switches, this will also form a forwarding loop. Either way, they get congested and start to flap, spewing endless topology change BPDUs, and now your network is kaput.

Despite wanting to act as an active layer 2 device there is almost no configurability, management, or monitoring available. A couple of years ago, in a spectacular product management insult, Sonos also intentionally removed much of the built-in port 1400 interface that provided device-level insight such as log messages revealing this misbehaviour.

The solution is to treat them like hostile guests and shove all Sonos players into a wholly private broadcast domain just for them, to avoid fucking up the rest of your network. And don’t let them join your regular SSIDs.

I am almost certain that there is no-one left at Sonos who understands their own network stack.

Compounding all this is a general smug attitude of “our customers are idiots” which is pervasively apparent from the CEO, through their product management, to their frontline support staff. If this fiasco tanks the company, it’s ultimately due to their own shitty, arrogant culture.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: