Can't get AirPlay working across subnets although they are recognized by Roon Core

Tinkering
1

I have two subnets connected via a tap VPN interface (also tried ZeroTier). So there is subnet A (192.168.33.0/24) and subnet B (192.168.22.0/24).
The VPN clients/server are 192.168.22.230 with VPN-IP 10.9.0.1 and 192.168.33.10 with VPN-IP 10.9.0.2. All routes are set up correctly and each host can reach each other without firewall issues.

Using (GitHub - marjohn56/udpbroadcastrelay: UDP multicast/unicast relayer):

I have subnet A
./udpbroadcastrelay --id 1 --port 5353 --dev tap0 --dev eth0 -d --multicast 224.0.0.251 -s 1.1.1.1
and subnet B
./udpbroadcastrelay --id 2 --port 5353 --dev tap0 --dev eth0 -d --multicast 224.0.0.251 -s 1.1.1.1

With this MDNS traffic is flowing from subnet A to subnet B.

I have a Roon Core in subnet B and an AirPlay device in subnet A.
Roon finds the AirPlay device, but fails start streaming.

04/14 18:55:31 Warn: [Worker (3)] [airplay/clientV2] [192.168.33.15] Failed to connect: Result[Status=NetworkError]
04/14 18:55:31 Info: [Worker (3)] [airplay] AirPlay device connection failed to: AirPlayDevice[DeviceId=._raop._tcp.local, Name=.local, Model=AudioAccessory5,1, IPEndPoint=192.168.22.230:7000]

It gets the correct IP of the AirPlay device (192.168.33.15) but tries to start the streaming on the VPN device/MDNS relay (IPEndPoint=192.168.22.230:7000 → should be 192.168.33.15:7000) …

I tried to not override the source IP (without -s 1.1.1.1), then the MDNS packet gets into the VPN network 10.9.0.0 with source IP 192.168.33.15, but as the source address is not in the 10.9.0.0/24 range, the second relay in subnet B does not pick up the packets (but I can see the packets via tcpdump on both sides of the VPN client).

Using avahi daemon on both VPN endpoints the result was more or less the same. I always can see the client devices in Roon and the IP addresses in the MDNS messages are correct, but the IPEndPoint in Roon always resolves to the VPN client in subnet B.

I also tried to add a port forward from 192.168.22.230:7000 to 192.168.33.15:7000 but then it fails with

[airplay/clientV2] [192.168.33.15] SETUP failed: 520 Origin Error

Do you know any tricks to make this working?

2

Maybe look into the Tinkering category of the forum for other users working VPN setups.

3

Haven’t found a solution yet. Most of them are talking about port 9003. That’s no problem. It’s the MDNS which causes me headache.
It’s also much easier, if the VPN client could run the MDNS relay. But ideally I would join the second subnet and run the relay only once on the gateway, not every single client.
But as described above, this is a bit tricky … :smiley:

4

IDK, lookup the mDNS entries and check them for correctness. As you run different networks, you need a router to connect them. Chances are, the router already has avahi running (or is available as package) which allows for multicast reflection into other subnets (get rid of udpbroadcastrelay in favor of a likely more widespread tool for the job to increase the probability someone can help you). Also check your routing tables, make sure the AirPlay traffic can be and gets routed into the proper subnet.

Note: Roon requires all the participants (server, enpoints and controls) being part of the same subnet – all other setups are unsupported and belong into the tinkering realm (means users have to know what they are doing and how to troubleshoot if needed). Maybe someone knows the solution for you, but with that few details about your setup and prior troubleshooting done and posted here and not the tinkering category, you may not get a quick reply for a solution – if at all.

5

I’ve moved this post to the Tinkering section where you might get more traction. As Blackjack mentioned,

1 Like
6

I’ve tried all that and I have checked all of what you mentioned :slight_smile:
As I wrote, avahi does not solve the problem. That’s what I started with. But because of the limited configuration options of avahi, I used udpbroadcastrelay (there are also some more tools, udp-proxy-2020 for example).
Both subnets are connected with S2S VPN, routing and firewall is fine I checked that more than once with tcpdump. I think the problem is on the Roon implementation side, as the IP addresses are right in the MDNS packages. But somehow the IPEndPoint of Roon uses a different IP address than the on in the MDNS message.

I invested a lot of time in that topic :smiley:

I also have a response from Roon Labs:

Thanks for sharing your report - we don’t have any immediate next steps for you to try, but our development team is actively investigating SRC Discovery Packet handling across VLANs.

1 Like
7

Hey @Manuel_Gonnenwein,

Thanks for posting and sharing your experience on the Roon Community! I wanted to follow up and let you know that our development team has a potential fix in the works, which we expect to include in the next update.

I also saw that you’re interested in testing the fix ahead of the official release — that’s great to hear! We have an Early Access version of Roon available for situations just like this. You can learn more about it and how to get started in the Knowledge Base article below:

Thanks again for presenting your issue in such clear detail - it really helped our team! :raised_hands:

1 Like
8

Thanks for your response, that sounds great! Do you know, if the fix is already in the latest EA release? I will definitely try it :slight_smile:

9

It should go to EA in the upcoming weeks ( still working on few other items that were planned for the build). We will mention in the release notes ones it is out.

1 Like
10

@vova, @benjamin I installed the new early access version with fixes for AirPlay, unfortunately it still doesn’t work. I get more logging information and it seams to fix something, but not the actual playback.
Here are the new logs:

05/06 08:08:24 Trace: [zone TestHP] PlayPause
05/06 08:08:24 Trace: [zone TestHP] Selecting Source state=Stopped
05/06 08:08:24 Trace: [TestHP] [Inactive] [LOADING @ 0:00] ***
05/06 08:08:24 Trace: [musicpowerstate] music is playing, preventing idle sleep
05/06 08:08:24 Info: [TestHP] [zoneplayer] Playing: https://streaming-qobuz-std.akamaized.net/file
05/06 08:08:24 Info: [TestHP] [zoneplayer] Queueing: https://streaming-qobuz-std.akamaized.net/file
05/06 08:08:25 Info: [TestHP] [zoneplayer]     Open Result (Playing):Result[Status=Success]
05/06 08:08:25 Info: [TestHP] [zoneplayer] Starting playback
05/06 08:08:25 Trace: [airplay/clientV2] [192.168.33.15] Connecting to airplay server
05/06 08:08:25 Info: [zone TestHP] OnPlayFeedback Playing
05/06 08:08:25 Trace: [TestHP] [HighQuality, 24/96 QOBUZ FLAC => 16/44] [PLAYING @ 0:00] ***
05/06 08:08:25 Trace: [airplay/clientV2] [192.168.33.15] Requesting OPTIONS
05/06 08:08:25 Info: [airplay/clientV2] [192.168.33.15] REQUESTING OPTIONS *
05/06 08:08:25 Trace: [airplay/clientV2] [192.168.33.15] OPTIONS Succeeded
05/06 08:08:25 Trace: [airplay/clientV2] [192.168.33.15] Got good OPTIONS: ANNOUNCE, SETUP, RECORD, PAUSE, FLUSH, TEARDOWN, OPTIONS, GET_PARAMETER, SET_PARAMETER, POST, GET, PUT
05/06 08:08:25 Info: [airplay] AirPlay device connected: AirPlayDevice[DeviceId=***@***._raop._tcp.local, Name=***.local, Model=AudioAccessory5,1, IPEndPoint=192.168.22.230:7000]
05/06 08:08:25 Trace: [airplay] connected
05/06 08:08:25 Trace: [airplay/clientV2] [192.168.33.15] Sending SETUP #1 (session)
05/06 08:08:26 Info: 
--[ SignalPath ]---------------------------------------------
SignalPath Quality = HighQuality
Elements:
    Source Format=Flac 96000/24/2  Quality=Lossless
    UpgradeBitDepth FromBitsPerSample=24 ToBitsPerSample=64 Quality=Lossless
    SampleRateConversion FromSampleRate=96000 ToSampleRate=44100 Algorithm=HighQuality Quality=HighQuality
    Truncate FromBitsPerSample=64 ToBitsPerSample=16 Quality=HighQuality
    Output OutputType=AirPlay Quality=HighQuality SubType=2 Model=AudioAccessory5,1
------------------------------------------------------------
05/06 08:09:41 Warn: [airplay/clientV2] [192.168.33.15] Got exception connecting to device at 192.168.22.230,51804: System.Net.Sockets.SocketException (60): Operation timed out
   at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.ThrowException(SocketError error, CancellationToken cancellationToken)
   at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.System.Threading.Tasks.Sources.IValueTaskSource.GetResult(Int16 token)
   at System.Threading.Tasks.ValueTask.ValueTaskSourceAsTask.<>c.<.cctor>b__4_0(Object state)
--- End of stack trace from previous location ---
   at System.Net.Sockets.TcpClient.CompleteConnectAsync(Task task)
   at Sooloos.Audio.AirPlay.AirPlayClientV2.<>c__DisplayClass83_0.<<SetupAirPlay2Session>b__0>d.MoveNext()
05/06 08:09:41 Trace: [airplay/clientV2] [192.168.33.15] Sending RECORD
05/06 08:09:44 Info: [TestHP] [zoneplayer] Open result (Queueing): Result[Status=Success]
05/06 08:09:51 Warn: [airplay/rtsp] IOException in RTSP request: net_io_readfailure, Operation timed out
05/06 08:09:51 Info: [airplay] AirPlay device disconnected: AirPlayDevice[DeviceId=***@***._raop._tcp.local, Name=***.local, Model=AudioAccessory5,1, IPEndPoint=192.168.22.230:7000]
05/06 08:09:51 Trace: [airplay] disconnected
05/06 08:09:51 Warn: [airplay/clientV2] [192.168.33.15] RECORD failed: Result[Status=NetworkError]
05/06 08:09:51 Trace: [zone] TestHP received transport control from endpoint integration: suspend
05/06 08:09:51 Trace: [zone TestHP] TestHP received transport control from *** (Apple HomePod mini): suspend
05/06 08:09:51 Trace: [zone TestHP] Suspend
05/06 08:09:51 Info: [zone TestHP] OnPlayFeedback Stopped
05/06 08:09:51 Info: [zone TestHP] Canceling Pending Sleep
05/06 08:09:51 Trace: [TestHP] [HighQuality, 24/96 QOBUZ FLAC => 16/44] [STOPPED @ 0:00] ***

The client IP of the AirPlay device (192.168.33.15) is correct. But again, Roon wants to connect to the Gateway (for 192.168.33.0/24 network) instead of the client IP.

IPEndPoint=192.168.22.230:7000 and Got exception connecting to device at 192.168.22.230,51804 → 192.168.22.230 is the Gateway for the 33.0/24 network

It should have used here also the client IP 192.168.33.15 instead.

11

Hi-

Not sure if you can say, but does what’s upcoming address AirPlay specifically, or the existence of core & endpoint on different network segments / vlans?

I have two cores (one in each home) and would love to be able to at least try to use a single core for endpoints in both homes if they are connected by a rock solid site-to-site vpn. I realize that RAAT is fragile enough on a single LAN, but I remain optimistic that this can be done with a good enough connection!

12

Just Airplay as mdns works across subnets on a network if the router allows mdns routing. RAAT doesn’t use mdns for discovery.

1 Like
13

RAAT works perfectly across S2S VPNs, try something like udp-proxy-2020 or udpbroadcastrelay. They should both work (I use them for the same purpose). RAAT uses port 9003.
Only AirPlay devices will not work for the same reason I described in this topic.

1 Like
14

@vova , @Benjamin why can’t the IPEndPoint not just use the same IP as it logs in the first place? (The IP address it also gets from the MDNS content). In the current configuration this will not work with Avahi Daemon too, as Avahi also just repeats the MDNS messages on the second interface. So the source IP of the packet in this case is also the Gateway, like in my case.
The real client IP nevertheless is in the MDNS record, and this address should be used (and Roon has this address, as it’s everywhere in the logs :wink:).

15

@benjamin & @vova any news on this? Can you pass on the feedback to the developers? :slightly_smiling_face:

16

AFAIK multiple vlans is not supported configuration, which is why this thread is in Tinkering

People get lots of things working that are not supported, but not all things that we’d like to be supported are.

17

From these release notes:

  • Fixed cases where AirPlay was failing due to use of subnets

The mentioned fix got released with the latest update.

18

Please take a look at my update post to the release notes you mentioned :slight_smile:

19

I did not mention any release notes for early access. Did you test the behavior with the latest production version from the release notes I shared? Is it still not working?