Roon on Windows 11 uses the wrong network adapter

Support
1

Roon Core Machine

Roon Core in Debian 10 VM, Intel(R) Core™ i7-6700 CPU @ 3.40GHz, 12GB RAM
Roon Core 2.0 (build 1300)

Networking Gear & Setup Details

Windows box in one VLAN, Roon Core in another VLAN.

Connected Audio Devices

Roon application running on Windows 11, with Schiit Modi Multibit 2 connected via USB.

Number of Tracks in Library

31,958 tracks

Description of Issue

I have the Windows Subsystem for Linux and Docker Desktop installed on my Windows 11 Pro machine. I use neither WSL or Docker with Roon.

The WSL and Docker installation adds a “HyperV” network adapter to my system, which is used by WSL and Docker. It has a private IP address that is not in the subnet associated with the one connected Ethernet adapter.

So, I have two network adapters. An Ethernet adapter with a usable IP address, and a HyperV network adapter that cannot be used to talk on the network, but is used for WSL and Docker.

My problem is that when I start Roon on this computer, it sometimes decides to use the HyperV network adapter instead of the main Ethernet adapter. When this happens, the Roon Core does not see any of the audio devices connected to the Windows machine.

I’d like a way to specify the network adapter to use for Roon, so I can have it use the Ethernet adapter when Docker/WSL is enabled.

1 Like
2

@David_Rothenberger, I’ve moved your post to #tinkering since Roon neither supports VLANs, separate subnets nor virtual machines.

3

I don’t think this has anything to do with the Roon Core configuration. It appears to be a problem with the Roon program running on Windows, and I would have the same problem even if the Roon Core were running on a “supported” configuration.

Or are you saying Roon is not supported on Windows with WSL or Docker Desktop installed? If so, that should be made clear in the installation instructions and requirements.

1 Like
4

AFAIK binds Roon itself to all available networks (VLANs, multiple adapters, virtual adapters, …). There is no way to configure Roon to not do that (but there is potentially a blacklist for very specific network {adapters} built-in?). So if at all, you may have a routing and or firewall problem IMHO.

Notes: What is not supported?

You should be able to use the Windows machine as a remote GUI to control Roon if you allow the relevant tcp traffic to flow between the two VLANs. It is normal though that the audio device detection, based on zeroconf multicast packets, is not traversing network boundaries. So if you didn’t take that into account and implemented a solution for that problem, then I’m actually more concerned about the cases where you say it works anyway, than about the cases it doesn’t.
Maybe you just missed (to tell us) some vital parts about your network configuration?

PS: This is based on forum posts but also on my own experience with multi-homed Linux based Roon Cores and Windows Roon Remotes.

5

The GUI on the Windows machine connects fine to Roon Core. Audio device discovery also worked fine before I enabled WSL.

In The RaatServer log on the Core, I see messages like this:

[raatserver] [RaatServer TELA @ 172.17.16.1:9200] lost client connection. Retrying
[raatserver] [RaatServer TELA @ 172.17.16.1:9200] connecting (attempt 1)

My issue is that 172.17.16.1 is for the WSL Hyper-V adapter and not the Ethernet adapter. Disabling WSL fixes this issue, since it removes that adapter, leaving only the Ethernet adapter enabled.

The WSL Hyper-V adapter is only for communication between Windows and the WSL environment; the rest of the network does not know about that subnet.

I do have mDNS and SSDP reflectors running across the subnets containing the Windows box and the Roon Core. But as I said, discovery was not an issue until I enabled WSL.

Sniffing the traffic received by the Core, I find this 172.17.16.1 address in the packets from the Windows box to the Core, port 9332.

I need a way to get the GUI to ignore the Hyper-V network adapters when it decides which address to send to the Core.

6

You can utilize the Windows firewall. Use the default Roon.exe and RAATServer.exe rules to restrict the two applications to the network you want. I think it’s called scope (Bereich in German), put in network addresses (10.0.0.0/8 for example {input and output}). This worked for me.

7

Thank you for the suggestion, but this did not work for me.

The problem is not that the Windows machine is sending network traffic to the Core with the wrong source IP address (e.g., a 172.16/12 address). The addresses associated with the Hyper-V adapters are not part of my main network, so any traffic sent from those addresses would be rejected by the router, but this is not what is happening.

Windows is communicating with the Core using the correct IP addresses (10/8 subnet). I believe the problem is that Roon Remote enumerates the available adapters on the Windows machine and picks one to select the IP address to communicate to the Core. That communication is working (because it’s using the 10/8 subnet), but the IP address in the communication is wrong (172.16/12 subnet). This leads the Core to try to establish communication back to the Windows box for accessing the audio devices using the wrong IP address (172.16/12), which of course fails.

8

Yes I know that this can happen. I see this with one of my Cores too (reporting one of the {unused} Docker interfaces as IP-Address).

grafik grafik
Not the LAN network address (10.110.0.0/16) but a (virtual and unused by any VM) network address from Container Station running on the NAS. It is impossible to activate any of the associated audio devices. Luckily for me, I don’t use them anyway.

I already reported this once in the past – without resolve apparently.
Therefore, I move the thread back into #support.

Note: The Roon software is split into two parts. Let’s call them Roon and RAAT. Both are networked and therefore need to do network detection and some “clever” guessing about the “active” network in use. While in my experience the Roon part works reliable and robust, the RAAT part is a mess in this regard (may only work correctly in the most simple {networking} cases. :roll_eyes:

9

I just noticed this same message in my Settings / Audio page, so I’m having the same problem. Here’s hoping it gets resolved this time. Otherwise, I’ll need to buy a streamer for my desktop rig.

10

Hi, just read your post and wanted to report the same issue, about the message in the logs of constant lost of connection:

07/31 12:52:04 Trace: [rnet/RnetJsonClient] no data received for >10000ms. Killing connection.
07/31 12:52:04 Trace: [raatserver] [RaatServer DIERMINATOR-DSK @ 192.168.1.43:9200] lost client connection. Retrying
07/31 12:52:04 Trace: [raatserver] [RaatServer DIERMINATOR-DSK @ 192.168.1.43:9200] connecting (attempt 1)
07/31 12:52:04 Trace: [raatserver] [RaatServer DIERMINATOR-DSK @ 192.168.1.43:9200] connected
07/31 12:52:04 Trace: [rnet/RnetJsonClient] SENT {"request":"enumerate_devices","subscription_id":"0"}
07/31 12:52:10 Info: [stats] 12746mb Virtual, 2118mb Physical, 925mb Managed, 419 Handles, 68 Threads
07/31 12:52:14 Trace: [raatserver] [RaatServer DIERMINATOR-DSK @ 192.168.1.43:9200] lost client connection. Retrying
07/31 12:52:14 Trace: [raatserver] [RaatServer DIERMINATOR-DSK @ 192.168.1.43:9200] connecting (attempt 1)
07/31 12:52:14 Trace: [raatserver] [RaatServer DIERMINATOR-DSK @ 192.168.1.43:9200] connected
07/31 12:52:14 Trace: [rnet/RnetJsonClient] SENT {"request":"enumerate_devices","subscription_id":"0"}
07/31 12:52:24 Trace: [rnet/RnetJsonClient] no data received for >10000ms. Killing connection.
07/31 12:52:24 Trace: [raatserver] [RaatServer DIERMINATOR-DSK @ 192.168.1.43:9200] lost client connection. Retrying
07/31 12:52:24 Trace: [raatserver] [RaatServer DIERMINATOR-DSK @ 192.168.1.43:9200] connecting (attempt 1)
07/31 12:52:24 Trace: [raatserver] [RaatServer DIERMINATOR-DSK @ 192.168.1.43:9200] connected
07/31 12:52:24 Trace: [rnet/RnetJsonClient] SENT {"request":"enumerate_devices","subscription_id":"0"}
07/31 12:52:25 Info: [stats] 12762mb Virtual, 2118mb Physical, 939mb Managed, 421 Handles, 70 Threads
14

This topic was automatically closed 45 days after the last reply. New replies are no longer allowed.

17

Hi @David_Rothenberger,

I wanted to reopen this post to bring it to a conclusion - thank you for your patience.

Creating a UI mechanism by which to select a preferred network adapter is not a roadmap item for Roon at this time. Please create a request in Feature Suggestions where other users can vote and this gain more internal traction.