Roon 2.70 update causes loss of AirPlay and Sonos devices detection (ref#U1SU07)

Support
1

Hi! What’s not quite right with Roon?

· None of the above quite fits

None of the above quite fits

· None of these quite match

Tell us what's going on

· Roon 2.70 caused lost AirPlay and Sonos devices

Tell us about your home network

· Roon Core wired, most audio zones as well.

2

Before the update i had my kitchen speaker (Sonos) as well as my AppleTV visible.
Now, Apple Store hasn’t released the latest Roon Remote yet, but that doesn’t really make sense.

3

Similar to you, I am on the latest Roon server build but with the old versions of the iOS Roon apps.

All my Sonos and AirPlay devices are still visible and work.

I would recommend a reboot of your router followed by the Roon server.

I hope that helps.

4

Thank you! But i am way ahead of you! :grin:

Still no luck unfortunately, even though:
A complete network reboot has been done, everything from incoming FMC through router (Asus RT-AX82) and switches involved.

Roon Server (Win 11 IoT Edt LTSC, headless, fanless) rebooted, firewall checked for notifications - no change…
Everything else works, all RAAT endpoints, and of course Airplay though my iPad to the AppleTV, as well as the native Sonos app for the kitchen speaker. Both missing devices are on wifi.

5

Started my alternate Roon Server, and switched to that one, running Roon 2.66 (also on Windows, though not fanless)

IMG3331
IMG33312732×2048 278 KB

This core is configured in a similar manner to main primary Roon Server, and it’s wired to the same switch.

6

And the Roon Server “FractalCore I7” was updated to Roon 2.70, and the Roon Tested endpoints are still available on that one?

So, i’d like to see what might be gathered from the logs on the “Streacom FC10”, thanks.:folded_hands:t2:

7

Hi @Mikael_Ollars,

Thanks for writing in and for sharing your report! Your Roon Server logs gave us a clear sign of the issue.

Here’s what we found. Your RAAT zones are unaffected, but on most 2.70 startups the multicast socket bind is failing, and that’s what takes AirPlay and Sonos discovery down together. The relevant piece from the log:

NetworkInformationException (10043): The requested protocol has not been configured…
 at SystemIPInterfaceProperties.GetIPv4Properties()
 at Sooloos.MulticastSocketHelper.Bind()
 at Roon.Audio.UPnP.DeviceTracker.Start() ← Sonos
 at Roon.Audio.Mdns.MdnsDiscovery..ctor() ← AirPlay

10043 is WSAEPROTONOSUPPORT, and it’s being thrown while Roon enumerates your network interfaces at startup. When the bind hits one of those it aborts, so UPnP (Sonos) and mDNS (AirPlay) never come up for that session, while RAAT/SOOD, which binds differently, keeps working. That lines up exactly with what you’re seeing.

Two things worth noting: this isn’t strictly new, the same exception appears on your 2.67 boots as well, and it’s intermittent (your first 2.70 start on the 8th actually bound cleanly and both devices appeared). So it’s tied to your interface configuration and startup timing rather than 2.70 removing anything.

Could you try the following on the FC10 and then send a fresh set of manualRoon Server logs to our uploader here?

  1. From an elevated command prompt, disable the unused IPv6 tunneling interfaces:

netsh interface teredo set state disabled

netsh interface 6to4 set state disabled

netsh interface isatap set state disabled

and disable “Microsoft IP-HTTPS Platform Interface” under Device Manager → View → Show hidden devices → Network adapters.

  1. If SOtMLink and/or Npcap aren’t actively in use on this machine, disabling them will help too, each adds extra no-IPv4 bindings to the enumeration.

  2. Restart Roon Server and grab a new log.

When the new log arrives we’ll confirm the MulticastSocketHelper.Bind / 10043 entries are gone at startup, that’s the reliable tell, more so than eyeballing whether the zones reappear, since the failure is intermittent.

Thanks again for the diagnostics on your end, it made this much faster to pin down. :+1:

8

I had a feeling this might be down to an issue we looked at earlier this year. Or to be more specific, Roons startup and config is disturbed by my configuration:
I have two network interfaces on this machine, one for remote control, internet and Qobuz duties as well as Roon controlling. This is configured to DHCP with a reserved lease and not fettled with.
The other interface is the one causing this confusion, a dedicated interface for Diretta communication only which has only one protocol bound to it, IPv6.

So, rather than the command line you provided, i simply activated IPv4 (static) on the Diretta link, which then fixes the 10043 err. A reboot later and i’m up running again.

So, thank you again Ben, this was very helpful and clear! I know how to adress this, and hopefully the Roon startup procedure can be tweaked to not drop airplay/sonos if an interface with no IPv4 is detected.