Phantom IP connections in Roon logs

Roon Core Machine

Mac Mini (2020 M1), 16GB RAM, internal IP address 10.1.1.140

Networking Gear & Setup Details

Ubiquiti DreamMachine pro and several Ubiquiti switches and APs

Connected Audio Devices

Devialet Phantom I Gold pair
Escape Audio P6
PSAudio DirectStream with internal bridge
2x Bluesound Flex 2i (both wired)
Note: I powered down all the devices except the Phantoms (which I just rebooted) to get the log snippet below

Number of Tracks in Library

28,000 tracks

Description of Issue

Roon seems to be looking for devices that aren’t – and have never been – anywhere near my network. Their names are always the same: DNSSecondary, DietPi and MuckleroyNAS (names I’ve never used on my network). It does this a lot and I’m trying to figure out where it’s finding their names. My internal network is 10.1.1.0/24. The mystery devices always show up with the same IP addresses on completely different subnets from anything I’ve ever used at this site. Roon keeps trying to connect to them and failing, then it tries again later. Here’s a snip of the log where they first show up (during startup):

07/22 14:03:55 Trace: [SOOD] Adding User IP 10.1.1.140
07/22 14:03:55 Trace: [SOOD] Adding User IP 192.168.0.113
07/22 14:03:55 Trace: [SOOD] Adding User IP 192.168.0.114
07/22 14:03:55 Trace: [SOOD] Adding User IP 10.0.5.1
07/22 14:03:55 Trace: [SOOD] Adding User IP 10.0.7.1
07/22 14:03:55 Trace: [SOOD] Adding User IP 192.168.0.150
07/22 14:03:55 Trace: [rnet/RnetJsonClient] GOT NONFINAL {"status": "Success", "devices": [{"device_id": "BuiltInSpeakerDevice", "name": "Mac mini Speakers", "type": "coreaudio", "vendor": "Apple Inc."}, {"device_id": "default", "is_system_output": true, "name": "System Output", "type": "coreaudio", "config": {"external_config": {}, "unique_id": "0b273c0a-0392-d26e-408d-1b9403448be2", "output": {"name": "System Output", "type": "coreaudio", "device": "default"}, "volume": {"type": "coreaudio", "device": "default"}}}]}
07/22 14:03:55 Trace: [devicedb] [autodetect] No Match for DeviceAutodetectData[Type=Local Vendor=Apple Inc. Model=Mac mini Speakers]
07/22 14:03:55 Info: [raatserver] GOT DEVICE b50146d5-d92a-43a4-b142-93d07ba05071::BuiltInSpeakerDevice Type=coreaudio Name=Mac mini Speakers Vendor=Apple Inc.
07/22 14:03:55 Trace: [devicedb] [autodetect] No Match for DeviceAutodetectData[Type=Local Model=System Output]
07/22 14:03:55 Info: [raatserver] GOT DEVICE b50146d5-d92a-43a4-b142-93d07ba05071::default Type=coreaudio Name=System Output 
07/22 14:03:55 Trace: [rnet/RnetJsonClient] GOT NONFINAL {"devices": [{"type": "wasapi", "device_id": "default", "name": "System Output", "is_system_output": true}, {"type": "wasapi", "device_id": "{0.0.0.00000000}.{8944580f-1bc2-44df-88ca-294e333a530d}", "name": "HD Audio Driver for Display Audio"}, {"type": "wasapi", "device_id": "{0.0.0.00000000}.{b5f1b86c-b506-4c09-a628-dd082d880b22}", "name": "Realtek(R) Audio"}], "status": "Success"}
07/22 14:03:55 Info: [raatserver] GOT DEVICE 8cebbe25-30a2-466f-8fbd-2dd1f18f5571::default Type=wasapi Name=System Output 
07/22 14:03:55 Trace: [devicedb] [autodetect] No Match for DeviceAutodetectData[Type=Local Model=HD Audio Driver for Display Audio]
07/22 14:03:55 Info: [raatserver] GOT DEVICE 8cebbe25-30a2-466f-8fbd-2dd1f18f5571::{0.0.0.00000000}.{8944580f-1bc2-44df-88ca-294e333a530d} Type=wasapi Name=HD Audio Driver for Display Audio 
07/22 14:03:55 Trace: [devicedb] [autodetect] No Match for DeviceAutodetectData[Type=Local Model=Realtek(R) Audio]
07/22 14:03:55 Info: [raatserver] GOT DEVICE 8cebbe25-30a2-466f-8fbd-2dd1f18f5571::{0.0.0.00000000}.{b5f1b86c-b506-4c09-a628-dd082d880b22} Type=wasapi Name=Realtek(R) Audio 
07/22 14:03:55 Trace: [raat] RAATServer discovered: RaatServer DNSSecondary @ 192.168.0.113:9200
07/22 14:03:55 Info: [raatserver] GOT SERVER 49efbbb6-8df1-08b4-57d1-d4e3e6684668::7d08512f-04dd-4a63-b23e-fb28a9a9ba5d @ 192.168.0.113:9200 DNSSecondary PROTOVER=1 RAATVER=1.1.38 
07/22 14:03:55 Trace: [raatserver] [RaatServer DNSSecondary @ 192.168.0.113:9200] connecting (attempt 1)
07/22 14:03:55 Trace: [music/query] performing track query
07/22 14:03:55 Trace: [raat] RAATServer discovered: RaatServer DietPi @ 192.168.0.114:9200
07/22 14:03:55 Info: [raatserver] GOT SERVER 886d2e03-d4a7-febf-7697-5625e77e2cb5::d977a4f6-14af-451f-9812-88fb525c5f20 @ 192.168.0.114:9200 DietPi PROTOVER=1 RAATVER=1.1.38 
07/22 14:03:55 Trace: [raatserver] [RaatServer DietPi @ 192.168.0.114:9200] connecting (attempt 1)
07/22 14:03:55 Trace: [raat] RAATServer discovered: RaatServer MuckleroyNAS @ 10.0.5.1:9200
07/22 14:03:55 Info: [raatserver] GOT SERVER f10cfa63-ee6e-7662-7e79-e4459f489399::12a79afa-ae74-4f93-8f6b-2ae8bda9ee06 @ 10.0.5.1:9200 MuckleroyNAS PROTOVER=1 RAATVER=1.1.38 
07/22 14:03:55 Trace: [raatserver] [RaatServer MuckleroyNAS @ 10.0.5.1:9200] connecting (attempt 1)
07/22 14:03:55 Trace: [Devialet Phantom I Gold Stereo @ 10.1.1.150:41471] [raatclient] RAAT Session initialized in 100ms
07/22 14:03:55 Trace: [Devialet Phantom I Gold Stereo @ 10.1.1.150:41471] [raatclient] SENT [2]{"request":"info"}
07/22 14:03:55 Trace: [Devialet Phantom I Gold Stereo @ 10.1.1.150:41471] [raatclient] SENT [3]{"request":"set_client_type","client_type":"Roon"}
07/22 14:03:55 Trace: [Devialet Phantom I Gold Stereo @ 10.1.1.150:41471] [raatclient] GOT [2] {"source_selection":{"is_supported":true,"info":{}},"flags":{"has_write_chmap":true},"transport":{"is_supported":true,"is_update_artwork_supported":true,"is_update_status_supported":true,"info":

You have two subnets?

Also, there is a member with a Qnap NAS and the aforementioned name.

Do you possibly use VPN, Docker, VMWare products or other virtualization solutions?

No, I have only one subnet. I just typed the wrong address in my original message. I’ve edited it now.

1 Like

None of those

Aren’t there four subnets showing in the logs? 192.168.0.x, 10.1.1.x, 10.0.5.x, and 10.0.7.x?

There’s only one actual subnet, 10.1.1.x. Roon somehow thinks the others exist and tries to connect 3 different devices I’ve never had in any network.

I’ve noticed that every time I launch a Roon client the coretries to connect to all 3 of the unreachable devices 5 times with slightly increased wait-time between each successive try, then it gives up. Until I connect another client (this is the case with at least the Windows and iOS clients anyway).

Thanks David. Have to ask as I haven’t use Ubiquiti’s interface in a very long time (work-related, not home use), but what does the Unifi OS Console show for connected devices?

I’ve scoured my network, and there’s no trace of those devices or IP’s anywhere. All the Unifi connections are known to me.

Obviously very odd. Have you tried to log out of your Roon Core, shut it down, shut down your Core server, and reboot your network from scratch, then restart your Core and Roon? It seems, again guessing here, there is a cache holding something somewhere.

Yeah, I’ve rebooted everything except all the network switches (guess I’ll try that next). It feels like there’s a config file somewhere that’s somehow asking for these weird clients.

1 Like

Hi @David_Roberts ,

I checked your account and it looks like the 192.168.0.XYZ IPs are coming from a Rev A Nucleus+ Core. Did you by any chance sign into a Nucleus+ Core recently? Perhaps at a dealer’s shop?

I do have a Nucleus rev A, but in another location with a different IP address.

We discovered that it was related to StarLink. There was another member (Profile - Scott_Muckleroy - Roon Labs Community) located 50 miles or so from my place who also used StarLink. The best guess is that we were both being served by the same ground station and somehow his configuration was advertised to my Roon Core.

I disabled UPNP on my Unifi router/firewall and rebooted the StarLink router. After that, I stopped seeing the messages. But I’m not sure if that’s simply because I was now being served by a different ground station.

Please contact Scott if you would as he was concerned that Roon was somehow advertising his configuration to the broader Internet. It’s not clear I could actually get to his setup since all I saw were inaccessible private IP’s.

—Dave

2 Likes

David, thank you for the update. I’m in the middle of looking at satellite systems for a client and this information may be helpful.

Doesn’t sound like you have (much of) a firewall if the connections are making it all the way to your Roon Core. You should only have inbound ports allowed for stuff you need to allow through - nothing else.

UPNP is notoriously leaky, and I assume it was the reason on my side anyway. My firewall is pretty locked down, but something let those messages in. It might have been Roon behaving badly, or some weird coincidence since the advertised Roon location and my Roon setup are both behind the same model Ubiquiti UDM Pro routers. Since both routers were presumably in the same subnet at the Satellite ground station, the UPNP messages could have gotten through once I opened my own router up to receiving them. I’ve also wondered if Roon coincidentally used the same protocols that Ubiquiti uses for discovery in a given subnet.

We’re way above my depth in understanding UPNP though, so I’m pretty much guessing. :slight_smile:

I’m not familiar with the Unifi routers (I do have a couple Edgerouters though) but after a quick search I think you will be fine now that UPNP is off. I think I’ve only ever seen any UPNP options (at least those that were on by default) on consumer gear. I think I last turned off such an option on maybe an Asus router? What kind of logs does the Unifi router have? Any indication in them that is was allowing traffic through because of UPNP?

I looked through the logs and couldn’t find anything, but I have the log levels set to default and it’s not clear whether UPNP events would be logged with that setting.

Hi @David_Roberts ,

Thanks for that information!

What does your Mac’s network settings look like when this issue is happening? Can you please share a screenshot?

So you are saying that the Nucleus is not playing a part here?

How were you able to determine this?

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