Roam SL missing from AirPlay

Hi ​@imaginaldisk 

Welcome to the Sonos Community!

I am sorry to hear of this issue you are having with your Roam SL speaker not showing on the AirPlay picker of available devices to play AirPlay to.

We were tracking a similar issue, but it was resolved last month (February), and it did not affect Roam speakers.

So, given that, and given the steps you have already tried, I recommend you get in touch with our technical support team who have tools at their disposal that will allow them to give you advice specific to your Sonos system and what it reports.

I hope they are able to help.

Update:  
I contacted Sonos support and went through full troubleshooting with them (factory resets, Apple Home settings, diagnostics, etc.). After reviewing the logs and serial numbers, they told me the issue could be hardware-related and started a replacement process for the affected units.

What makes me unsure about this conclusion is that the speakers are online and working normally in the Sonos app, and the only thing missing is AirPlay discovery. The problem also started recently and affected multiple devices at the same time, which feels more like a firmware / AirPlay / network advertisement issue than an actual hardware failure.

Also, my Roam is older, but the Era speakers are very new (three months old), so I’m not sure hardware failure on multiple units at once is the most likely explanation.

I hope the returned devices are properly tested, because this behavior looks very software-related, and I would not be surprised if the same issue appears again after replacement.

I’ll post another update once I receive the replacements.

Is the Roam on same AP as the Homepod and Era?

I recall AirPlay discovery uses IPv4 & IPv6, and IPv6 Link-Local address for the stream.

Hi ​@imaginaldisk 

Thanks for the update. I have reviewed the case notes and I agree with you - it is very unlikely that 3 separate products developed the same hardware fault at the same time. In addition, I see no diagnostics proving the point - if there were an issue with the microchips needed for AirPlay functionality, it would have been reported in the diagnostics. I have left feedback for the agent you spoke to, and I recommend that you get back in touch with our support team to resume troubleshooting - I’d not consider replacing the units quite yet! Please quote your existing case number when you get back in touch (if you don’t have a record of your case number, please DM me).

I hope this helps.

Yes — same LAN/subnet, and direct IP reachability was good.

That said, your AP / IPv6 / discovery angle was the useful direction. I was able to make AirPlay usable again with a router-side fix, so this does appear to be in the discovery path rather than a speaker hardware failure.

What made this confusing is that they still looked “alive” from a protocol perspective:
- ping OK
- Sonos API OK
- AirPlay port 7000 OK

But it was not showing up in _airplay._tcp or _raop._tcp browse results, so clients had nothing to discover.

Thanks for checking the case notes and for confirming that replacement does not really fit the symptom pattern.

I’ve since made progress on the router side and AirPlay is usable again, which makes me even more confident this was not a hardware fault.

For reference, the technical signature I saw was:

- Roam SL was online and reachable by IP
- Sonos API on port 1400 responded normally
- AirPlay endpoint on port 7000 responded with valid AirPlay metadata
- but the speaker was not advertising _airplay._tcp or _raop._tcp over mDNS/Bonjour

On the same subnet, my Era 300 and HomePod were advertising normally, so the failure looked specific to discovery/advertisement rather than general connectivity.

At this point I do not think replacing the units is the right first step.

Hi ​@imaginaldisk 

I am glad to hear that you have AirPlay working again! What changes did you make to the router settings, out of interest?

I think you can just ignore the RMAs at this point - they will time-out eventually.

What specific change on OpenWrt did you make?

​@Corry P 

Hi,

Thanks — I dug into this pretty deeply and isolated two separate issues on my network.

First, there was a real LAN-side problem: bridge-level IGMP snooping on my OpenWrt router was silently filtering mDNS between Wi-Fi segments. Once I disabled IGMP snooping on the bridge device, AirPlay discovery immediately started working across bands again. So that part is resolved and no longer seems to be the main blocker.

However, even after fixing the network side, I’m still seeing what looks like a Sonos-side AirPlay/mDNS issue.

What happens now:

• the speakers are fully online and reachable by IP

• port 7000 is listening

• Sonos APIs on port 1400 respond normally

• unicast mDNS queries sent directly to the speakers return correct _airplay._tcp and _raop._tcp records

But after an AirPlay session ends, the speakers stop advertising _airplay._tcp via multicast, so they disappear from AirPlay browse results. They remain on Wi-Fi and otherwise healthy — they just stop announcing themselves properly.

I originally thought this was limited to my Era 300 stereo pair, but I’ve since seen the same behavior affect my Roam SL as well. A non-Sonos AirPlay device on the same LAN continues advertising normally, which makes me think this is specific to the Sonos mDNS/AirPlay advertisement state rather than a remaining network problem.

One especially interesting detail: the Sonos devices still respond when they receive multicast probes for their own AirPlay service names. That suggests the mDNS responder is still running, but unsolicited advertisement / re-announcement is broken. I’ve been able to mitigate it with a router-side Avahi keepalive/proxy that periodically triggers the speakers to respond and re-seed the records on the LAN.

Diagnostics submitted:

• Era 300 L: [redacted] 

• Era 300 R: [redacted] 

• Roam SL: [redacted]

Firmware on all three is:

• 94.1-75110 (displayed as 18.2)

So my current view is:

1. network-side multicast filtering was one issue, now fixed

2. Sonos speakers still appear to stop multicasting AirPlay advertisements after playback, which looks like a firmware bug

If helpful, I can also share a tighter repro sequence and the exact observations from dns-sd, packet captures, and direct unicast mDNS queries.

Moderator edit: Diagnostics numbers removed due to being personally identifiable.

​@craigski 

On my OpenWrt setup, the specific fix was disabling bridge-level IGMP snooping.

The misleading part was that the LAN interface setting already looked correct, but the actual bridge device still had IGMP snooping enabled, and that was filtering Bonjour/mDNS between Wi-Fi segments. Once I disabled IGMP snooping on the bridge and restarted the network, the Sonos `_airplay._tcp` / `_raop._tcp` advertisements immediately came back.

In OpenWrt terms, it was essentially:

uci set network.<bridge_device>.igmp_snooping='0'
uci commit network
/etc/init.d/network restart

So in my case it turned out to be multicast discovery getting filtered, not the speakers being unreachable.
 

OK, do you mean Wi-Fi bands, ie 2.4GHz & 5GHz?

Thanks for the info, ​@imaginaldisk - I shall flag it all with a colleague.

Incidentally, a single diagnostic covers all speakers in your system - no need for multiples. But thanks!