I originally configured my Roon ROCK with a static IP address. I forgot I had done this.
Having just connected this ROCK to a new LAN with a different IP address range, all of my Roon devices no longer “see” the ROCK. The only work-around I can think of is to create a temporary VLAN with the same address range of the original LAN and then change the ROCK back to DHCP. Is there a simpler way to solve this problem?
If it is not easy to attach a monitor and keyboard to the NUC, then there is another solution - but it is more involved.
You can use whatever non-routable ip address range you like for your local network so, as an alternative to resetting the network on the NUC/ROCK, you could just set the LAN ip address of you new router to be the same as that of the old router (assuming you can remember it). Also make sure that you set the DHCP ip address pool on the router to a range that does not include the static ip address of the NUC/ROCK Roon server.
The NUC/ROCK will then become visible.
Then you can the do either:
Note: When you change the LAN ip address of your router to an ip address in a different subnet (which is what you would have to do here), it will suddenly become impossible to connect to devices that received DHCP ip address leases when the router was set to the old address. To resolve this, you will have to force the devices to obtain a new DHCP lease by powering off if no other method is available unless you are prepared to wait for the DHCP lease to expire (may be many hours). Since the NUC/ROCK Roon server was on a static ip address, this will be the one device that will not need to be power cycled.
Note2: This is exactly the reason that, rather than using static ip addresses, I use DHCP reservations in the router so that the device uses DHCP to get a dynamic ip address - but it just so happens that the DHCP server in the router always issues the same ip address - as configured in the router. This is a best of both worlds. The device is effectively on a static ip address - but if you change your router to one that employs a different subnet, since all devices are configured to use DHCP, they will all get valid ip addresses from the new router.
Thank you for your input. Fortuately, the approach from BlackJack worked. Grateful for everyone’s support.
Nice and elegant. Very much appreciated.
I’m glad this is solved.
A question for @BlackJack and @Wade_Oram.
I wonder what would have happened had @Tim_Brown given a Mac or PC a static address in the same range as the ROCK and then directly connected the two together.
In the old days, you needed a crossover cable to make a direct connection like this work. In the modern era, though, ethernet ports are all auto-sensing and can support direct connections with standard cables. If he’d done this, he might have been able to access the ROCK via a web browser on the Mac/PC and simply changed the network back to DHCP?
The approach that @BlackJack linked to is easy and reliable. I’m just wondering if this is another option and I’m too lazy to test it out 
I believe (never tried it) that it would work after a fashion provided the PC and the ROCK were connected by wired ethernet to the same ethernet switch (or LAN ports of the Router).
There would be no name resolution. You would have to access the NUC from the PC using direct ip addresses.
The following is my reasoning based on my (not necessarily complete) understanding of how this could work.
The reason I believe that this would work is that switches maintain a table of associations between the ethernet ports and a set of MAC addresses of devices accessed on that port so that when they receive a packet, they can look at the destination MAC address and know which port to forward the packet on to. This may be a bit more complicated for managed switches.
The switch builds up a routing table by looking at the ‘Source MAC address’ of each packet received and then creating an association between that MAC address and the port on which the packet was recieved. This is a many to one relationship. Because of the possible presence of other switches, there may be many MAC addresses associated with each port of the switch.
Now, when you send a packet to an ip address, the sending device determines the MAC address associated with that ip address (or the ip gateway if it is not in the same subnet). If the device does not know the MAC address assocated with the ip address, it sends out a broadcast ARP (Address Resolution Protocol) packet effectively saying “respond if you are assigned this ip address”. If it gets a reply, then an entry is added to the ARP table in the device to associate the ip address with the MAC address.
Since the switch, at least if it is unmanaged, is a pretty dumb device, this should all work irrespective of the ip addresses involved. The multiple LAN ports in a domestic router are effectively ports of an unmanged switch built into the router.
I don’t think you need a switch. Just a direct connection and static IPs on the same range on both devices. You used to need a crossover cable to do this but not anymore.
Here’s an example of what I’m talking about. This example illustrates two Windows devices but that shouldn’t matter - this isn’t specific to Windows.
The switch is already there - either explicitly or implicitly in the router.
When you asked the question, you specifically mentioned the point to point case - which, as you suggest, used, once upon a time, to require a crossover cable but doesn’t any more - so I was just addressing the in situ case.
Assuming the Rock is connected to the same Layer 2 network as everything else and it’s just the IP address that’s the issue, you can create a secondary address on one of your PCs or Macs with an address consistent with your old IP range to temporarily reach it. Just google how to do that for your OS.
This topic was automatically closed 36 hours after the last reply. New replies are no longer allowed.