ROCK Dual Ethernet - Primary Port Not Exposed [RESOLVED]

ok cool, let’s see what they say… it’s very strange to have a system that can’t have a static ip. maybe you have old firmware or they are working on it…

I was able to set static IP for SMS-200 in my router settings.

That sounds more like an IP reservation: handing out the same IP address to the SMS-200 every time, while your router is still doing DHCP. In this case, there is no DHCP server, so the IP needs to be set manually on the device.

1 Like

Edit: To fast to reply… :blush:

I wanted to do the same thing, but could get no answers other than interesting discussions about switches and cables and the lack of need to do this. I didn’t care about ROCK, just the Roon core running under Windows.

I do not endorse this setup because I’m not confident it will have a positive benefit on SQ, but here is the proper way to do what you want:

  1. plug your NUC into the router via ethernet and just make that all work properly with DHCP – get everything working with NUC/ROCK/Roon the everything normal.

  2. plug your ethernet adapter into the NUC, and connect that via an ethernet cable directly to the device you’d like to isolate (usually a network audio renderer).

  3. on the NUC’s second ethernet, setup static IP set like this:
    gateway: nothing
    dns: nothing

  4. on the isolated device (the audio renderer), setup static IP like this:
    gateway: nothing
    dns: nothing

This setup is better than the br0 setup because you aren’t actually linking the 2 networks – in fact, your renderer can’t even talk to the internet in the above setup, nor can it talk to your iPad, or anything else on the network EXCEPT RoonServer on the NUC. Complete IP traffic isolation.


Is there any sonic benefit in creating a virtual bridge of 2 physical Ethernet connections on the Roon Core server? I’m considering using my Mac’s Ethernet directly wired to my Roon ready device while another (Thunderbolt/Ethernet dongle) is connected to my switch (it’s wired to my Eero WAP). I know it will work, but I’m interested in if there is any benefit whatsoever in doing so.

The theoretical advantage of a bridging setup is to isolate the endpoint from electrical interference. Since the NUC in a setup like this is the middle man between two regular network segments, that is not achieved here.

Contrary to what some believe or claim to hear, there’s no poetry in networking.


Plenty of clouds though, certainly in diagrams when I did networking in my day job, retired now :wine_glass:


1 Like

Reason I ask is from the following:


"yet Mark Jenkins, owner and developer of the Antipodes line of music servers, had this to say about his latest generation Roon Ready DX music server. This excerpt is taken from John Darko’s review of this latest generation DX fserver:

"A third way to plumb Roon inside the DX is to have Roon Core talk to Roon Ready directly. Think of this scenario as Roon playing out the server-client model not on a LAN but inside a single computer.

Jenkins clarifies: “They [Roon Core and Roon Ready] talk using RAAT but when they are in the same device they do not need to use the not-so-good comms layers that sit underneath RAAT when the two apps talk across a network.”

This appears to be more about software


I thought that ROCK was about simplicity.

What you are suggesting is just taking away the simplicity and making it more confusing and complicated for those that want simple.

Audiophile paranoia might even lead some to think that they are missing out on a SQ improvement that might not be their in the first place.

IMHO This kind of idea belongs in the Tinkering section.

I had this idea in the tinkering section and nobody paid attention to it until it came here thru another poster. This probably isn’t for ROCK users who are into simplicity.:sunglasses:

1 Like

Aha! Thank you for article.

SQ aside, this will allow turn-key buyers to have Nucleus with its shiny Roon logo sit next to their $30,000 units with the added benefit of halving their cable length and instead of having it sit behind the closet with cheap routers and switches at the basement. :wink:

This is great! I didn’t know that typing “nothing” to the setup is possible. I would think this can only be possible if the music renderer (SOtM sMS-200 in this case) have static IP capability. Shout to @May_Park here. :slight_smile:

1 Like

I didn’t mean you can type “nothing”, I meant to leave the field blank

I really thought you put some scripts there because it does take “nothing”. :grin:

Anyway, I tried leaving them blank and it defaults to Errors ensued. Maybe I’m missing something?

I modified the network setting using your instruction at \server\rock\Data\MachineSettings\network. I was able to get in but it needs static ip on the music renderer. Dynamic ip will not work.

I also tried switching the ethernet ports to where the Intel ethernet port is directly connected to the music renderer. That didn’t work. Ideally, the Intel port connects to the music renderer directly to bypass the USB in the USB ethernet adapter.

Anyway, I got a message from Mr. Lee of SOtM that static IP is possible with the sMS-200. I’m waiting for further instruction how to set this in my unit.

Mark J quote: “do not need to use the not-so-good comms layers that sit underneath RAAT”

What does he mean by this @danny :cry:

I thought networked audio was Roon’s focus, even while they support legacy connections like USB and SPDIF at the moment. If networked audio is the future (and present for most of us) this isn’t the best compliment.

I guess we’ll never know what he means unless we ask him directly. And it’s just one person’s view/experience.

Still, I do wonder what issues in RAAT he’s referring to :cry:

They’re a Roon Partner too :cry:

Whatever issues he’s experienced, I hope as a Roon Partner he’s in close discussion with Roon to improve things :+1:

Be very wary when entering discussions like the CA-thread mentioned above – far-reaching statements are by be some that obviously don’t have a grasp at basic networking. That thread also handily touches on the audible differences of SATA-cabling and the use of Indian copper plates for grounding purposes. Not saying all of it is nonsense – but don’t believe everything that’s said there at face value.

As for Antipodes – they use a RoonReady implementation on top of Roon core. Not sure what to make of that – and since I’ve never seen or heard an Antipodes box I’ll withhold my opinion. AFAIK, underneath RAAT is a basic TCP stack – I would take that statement about ‘not-so-good comms layers’ with a pinch of salt (or a bucket, for that matter). Maybe @danny or @brian feels compelled to shed a bit more light on this.

If you feel the need to do so – by all means, tweak your heart out. But keep in mind most of this is networking and data transport – the usual fare of audiophile voodoo does not apply here.


I just tried this setting and it works fine. Thanks for the tip.