Why Roon Core constantly attempts outbound TCP traffic to 169.254.0.0/16

Roon Software Discussion
#1

I noticed some seemingly strange network behavior from my Roon core, and was hoping somebody could clear up what is happening here and why

Roon core is constantly sending packets to the link local IPv4 address space 169.254.0.0/16. This box has a static IPv4 address

Here is an example of netstat output. In this example, 10.1.10.13 is the local static IP address of the roon core. This behavior seems strange to me, because 169.254.0.0/16 is a link local scope. It’s usually only used to assign an IP address to an interface if DHCP fails.

Ultimately, roon is sending packets all day long to these 169.254.x.x addresses. The result is they are routed out to my ISP and subsequently dropped. It’s not causing an issue with Roon per say, I’m just at a loss for what is happening and why it is happening. Thanks

joe@roon:~$ sudo netstat -anp | grep 169.254
tcp6       0      1 10.1.10.13:44544        169.254.9.54:63444      SYN_SENT    1067/RoonAppliance
tcp6       0      1 10.1.10.13:59176        169.254.10.146:63444    SYN_SENT    1067/RoonAppliance
tcp6       0      1 10.1.10.13:34800        169.254.10.61:63444     SYN_SENT    1067/RoonAppliance
tcp6       0      1 10.1.10.13:34892        169.254.10.61:63444     SYN_SENT    1067/RoonAppliance
tcp6       0      1 10.1.10.13:44392        169.254.9.54:63444      SYN_SENT    1067/RoonAppliance
1 Like
#2

They are dynamically configured link-local addresses, see 169.254.0.0/16 addresses explained - PacketLife.net. I don’t believe these addresses route outside your network, and assume these messages appear because address information for IPV6 isn’t available/ configured on your network.

From my box, no output. My router supports IPV6.

martin@geoffroyi:~$ sudo netstat -anp | grep 169.254
martin@geoffroyi:~$
#3

Thanks. I understand that 169.254.0.0/16 is dynamically assigned link local addressing.

I still don’t get why my Roon core is attempting to initiate TCP connections to addresses in that range.

What is happening here is:

  • Roon is sending TCP SYNs to 169.254.x.x

  • These packets are routed to Roon’s default gateway

  • The router acting as the default gateway routes the packets to my firewall

  • My firewall default routes the packets to my ISP

  • Since 169.254.x.x is not routable on the public internet, packets are dropped.

  • Firewall closes the TCP connection after TCP SYN times out. Firewall logs confirm this.

So, yes…packets won’t make it far, but this doesn’t explain why Roon is sending them in the first place, and it means these packets are sent, and resources are spent sending them constantly for seemingly no reason.

Remember, it is Roon that is attempting to initiate TCP sessions to those IPs. What is it attempting to communicate with? Those IPs don’t exist locally on the box or anywhere on my network.

My best guess is it is some kind of fallback mechanism, In theory, if Roon core and other Roon components on the same LAN all failed to obtain DHCP leases, the core could try to communicate with them using predetermined link local addresses in the 169.254.0.0/16 space. This is just a guess though. If that is correct, that behavior should probably not happen once communication is properly up and running as to avoid unnecessarily sending packets to these addresses that will inevitably be blackholed upstream.

BTW, my core runs the latest build on Ubuntu Linux 20.04 LTS

#4

While I am willing to believe that the box in question might not have that network connected (you checked this already right?), it sounds unlikely to me that it isn’t in use anywhere else on a machine that runs Roon (as a remote or bridge).

The Roon software (Server, Bridge, Remote as well as the Desktop all-in-ones) always tries to bind itselve to all (except some blacklisted known useless) available network interfaces on the machine they run on. A convenience functionality for ease of use (some may think of it as bad behavior because it’s not configurable). As all instances of Roon software communicate with the server and can also work as endpoints, all the networks any instance has bound itself to end-up communicated to the server who then tries to communicate with instances (endpoints) on all of those networks. So if any Roon software instance runs on a box with an interface on 169.254.0.0/16 that information will end up on your core.
Looking at your example, the box doesn’t try to send packets blindly to that network but to specific hosts (*.9.54, *.10.61, *.10.146).
You should check the configured networks on all boxes that run Roon software. Do you, for example, use virtualized networks on any of those boxes (those may also come as a by-product of virtualization or containerization software like Docker, VM Ware, …)? Has any of the boxes possibly unused (but not disabled) additional Ethernet ports?
Depending on your findings, you may be able to do something against it, but most-likely not. So try to ignore it. Maybe you can setup a firewall rule that prevents the routing already on your side to prevent the waiting for timeout on the external side.

Your firewall should not route bogon packets to the internet for obvious reasons (you may have to add those rules yourself if your firewall doesn’t come already with an easy to use per-configured rule-set for it). But even if it doesn’t, if the rule is set to silently drop instead of actively deny bogon packets, then there is still the wait time until the connection attempt times out.

2 Likes
#5

Hey BlackJack,

Thanks very much for the detailed reply. This gave me some things to think about, and I’m happy to report, I’ve tracked this down! You were absolutely correct - I had a “ghost” in my network. Here is what I did to figure this out further:

First, I checked my roon core to make sure I didn’t have any unused network interfaces just to be sure. That all checked out. Then I did the same on my Macbook Pro, which is the only remote I have that is not an iOS device, and I didn’t see anything with a 169.254.x.x address. The only other Roon device I have is my bridge running on a Sonore UltraRendu. This device is pretty locked down, so you can’t really dig too deep. So, at this point I was pretty certain that no other Roon devices were generating traffic from the 169.254.0.0/16 address space.

Next, I did a packet capture on the roon core to see if any packets were coming IN to the network interface on the roon core sourced from 169.254.0.0/16. I made sure to include the ethernet header dump in the capture so I could use that in tracking what the device was.

sudo tcpdump -e src net 169.254.0.0/16

To my amusement, I saw quite a few, and they all matched up with the IP’s I referenced before in Netstat, plus a few others.

Specifically, it was all traffic sourced from 169.254.0.0/16 and destined to the multicast address 239.255.255.250 on UDP 1900 (UPNP). Since I snagged the Ethernet headers as well in the packet capture, I now had a list of about 5 IP/MAC address pairings that were doing this.

Next, I went to my main network switch and started mapping back what interface those MAC addresses came from. Guess what? All of them came from the same interface. So, what was it? My DirecTV DVR box (lol). The way my DirecTV setup works is that they essentially install a server somewhere in the house that plugs into your network/internet. This server becomes the central repository of all your recorded content. Amusingly, this DTV box has a normal valid IP on my network and is working just fine. For whatever reason, it also finds a need to use UPNP and multiple other 169.254.x.x addresses. Roon must listen for SSDP advertisements for discovery purposes, and then subsequently attempts to open connections to anything discovered.

So, mystery solved.

Additionally, I implemented a static route so that any traffic destined back to 169.254.0.0/16 gets dumped to the bit bucket.

Thanks for helping me think through this.

1 Like
#6

For sure it does. Multicast, mDNS (mDNS-SD), … it’s all part of either how Roon itself works or how supported streaming protocols (ChromeCast, AirPlay, …) work.

2 Likes
#7

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