Sonos provider (S2) fails discovery in routed multi-VLAN setup where S1 and HA Core Sonos integration works

[outofsight]

Environment:

• Music Assistant 2.7.11 as HAOS add-on (network mode: host)
• HA Core 2026.3.2
• Sonos players on a dedicated "Sound" VLAN (e.g. 192.168.31.x)
• HAOS/HA/MA on a "Services" VLAN (e.g. 192.168.50.x)
• MikroTik router with PIM-SM multicast routing active between VLANs

Observed behavior:

• The Sonos S2 provider apparently generates no SSDP traffic at startup and no players are discovered. Monitoring ss -ulnp filtered by MA's PID shows only mDNS (port 5353) listeners — apparently no other socket is opened at any point during the discovery phase.
• The Sonos S1 provider behaves differently: it sends M-SEARCH via SSDP, receives unicast 200 OK replies from players across the routed VLAN boundary, and successfully adds players.
• HA Core Sonos integration discovers the same players without issues, using SSDP over the same network path.

What packet capture shows:

• MA (S2 provider): apparently no SSDP discovery
• MA (S1 provider): M-SEARCH sent from ephemeral UDP port, replies received, players added
• HA Core: M-SEARCH sent, replies received, players discovered

Note:
I'm aware that multi-VLAN setups are not officially supported. We are reporting this specifically because HA Core discovery works correctly over the same network path, which confirms multicast routing (PIM-SM) is functional and inter-VLAN unicast replies are delivered correctly.

Question:
Is this behavior by design? Could it be changed? In my environment Sonos apps have been working reliably across VLANs for a long time, precisely because SSDP is routable and multicast routing is properly configured. If mDNS is the only discovery mechanism supported by the S2 provider, that is by definition not routable, and, even with an mDNS reflector in place, it does not appear to be as flexible and as reliable as SSDP. Being able to rely on SSDP — as S1 and HA Core already do — would allow us to stay on a proven and stable network architecture.

[marcelveldt]

Sonos is moving away from SSDP (which is a fragile, outdated and insecure protocol) and now uses Websocket and mDNS in their new API.

Best solution is to place HA/MA in the same network as your players

[outofsight]

Thanks for the explanation.
I understand the direction, but placing everything in the same VLAN is not really an option in a big network — we start with speakers and HA/MA but by the same logic we end with everything related including desktop and mobile clients, IoT devices and so on.
Worth noting: the official Sonos apps on Windows, Android and iOS all work fine cross-VLAN in my setup via SSDP and PIM-SM multicast routing — so the protocol still works at present. MA is actually the odd one out here.
On the firewall side, SSDP is also easier to control than mDNS (with reflectors currently available), which requires DPI to filter by service type.
I already have my workaround, but the lack of SSDP discovery has a real impact in some environments.

[outofsight]

In the current versions of

Home Assistant OS: 17.1
Home Assistant Core: 2026.4.1
Home Assistant Supervisor: 2026.03.2
Music Assistant Application: 2.8.1

SONOS S2 Discovery by DLNA started to works by itself.

SONOS S2 are discovered by 4 protocols: SONOS, AirPlay, Sendspin, DLNA