Roon Client ALWAYS loses Roon Core when switching between WAPs

Core Machine (Operating system/System info/Roon build number)

Arch Linux

Network Details (Including networking gear model/manufacturer and if on WiFi/Ethernet)

  • Core wired via gigabit Ethernet to gigabit switch which is in turn wired to broadband router which provides DHCP services.
  • Core has fixed IP assigned in router config through MAC address reservation.
  • Wireless connectivity is provided by the broadband router and on the other end of the house by a wired WAP. Both share the same SSID and password so roaming on the property should be just about seamless.

Audio Devices (Specify what device you’re using and its connection type - USB/HDMI/etc.)

3 x Chromecast Audio for casual listening zones
1 x Roon Bridge running on Odroid C2, USB into Yggy DAC

Description Of Issue

Without fail, if I move a Roon Controller from one side of the house to the other it loses connectivity to the Room Core. Specifying it’s IP doesn’t make any difference, it just refuses to pick up the Core for the next 5-10 mins.

The Core is pingable and accessible via SSH from the very same Roon Controllers and at the same time that they refuse to see the bloody core. What is Roon doing in its Core detection code that makes switching between WAPs so problematic. This has been an issue for over a year now and I’m sick and tired of having to remember not to take my mobile with me to the other side of the house if want to be able to use it to control Roon from the side of the house I’m moving away from.

Why can’t we just hard code the damned IP into the Control devices and be done with it. Is there something about switching between different Wireless protocols that befuddles Roon?

Works flawless for me when I roam between my two AP’s.

Guess: Some multicast helper is active on your network and you have to wait for it to time-out before the packets reach your control again.

Hi @evand,

Generally, the use of WAPs seems to work without issue for a vast majority of users, so it sounds like there may be something specific to this particular setup.

Can you specify the exact networking hardware in use here?

Just to confirm — This happens with all remote devices, correct?

Does the IP address of the remote change when connecting to the WAP?

Hi @dylan

networking hardware in use
Operating system of core is 5.0.11-arch1-1-ARCH Linux. Networking hardware:
Netgear GS108 switches (x3). DHCP and primary wireless are provided by BT Infinity Smart Hub Firmware version SG4B1000B540 which is wired to a Netgear GS108 unmanaged switch. That same switch has a wired Gigabit Ethernet connection to another GS108 in study (on opposite end of house). Inside study there’s a Trendnet TEW-638APB / EU WAP configured with the same SSID and password as the BT Infinity Smart Hub

The Smart Hub has both 2.4GHz (Channel 11) and 5GHz (Channel 36) enabled.
image

The Trendnet is a Wireless N device with 2.4GHz (Channel 5) enabled. Its wireless config:

The issue is the same for iOS and Android devices. Connecting to Roon core on either side of the house means losing sight of Roon Core when moving to the opposite side of the house triggering a switch of WAP.

The IP address of the remote does not change when switching WAPs.

Thanks for the details here, @evand.

We are going to see if we can reproduce this behavior, but as mentioned previously this type of configuration seems to be working in most cases. So I can gather some additional data for the team can you reproduce this behavior and respond here with the time it occurs (along with the remote device you used)?

I’ll enable diagnostics so the team can take a closer look.

@dylan. My core is up and running as I type this and as soon as I’ve posted I’m taking my phone from the study to the TV lounge, at which point the iPhone will switch to the router AP and have lost connectivity with the Core.

It should all be there for your now.

@dylan

Now reconnected to Core.

Thanks @evand!

I’ve enabled diagnostics and once the diagnostics report comes through I’ll pass it to the team for analysis.

Update — The diagnostics report was received and is with the team for analysis.

Even pointing it to the correct IP makes no difference. @dylan, the logs reveal anything?

Hi @evand,

Apologies for the delay here. I have a meeting scheduled with the team to discuss this further. They’ve tried reproducing this behavior and we’ve done some searching around for other users with similar setups. We haven’t been able to reproduce and we haven’t seen any other reports from users with similar setups experiencing this exact issue, so it seems like there is something specific to this environment that is causing this to occur.

We have a meeting scheduled to discuss further with the team — I’ll be sure to reach out ASAP once we’ve discussed and have further feedback.

In the meantime, I was hoping you could provide some additional information here:

  • If you use a different Core machine temporarily, does the same behavior occur?
  • Are there any settings related to multicast on the router or WAP? If so, can you share screenshots of those settings?

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