Plex spamming NetworkServiceBrowser: Error ... 169.254. in logs

Server Version#: 1.16.1.1291
Player Version#:

NetworkServiceBrowser: Error sending out discover packet from 169.254.30.11 to 169.254.255.255: Can’t assign requested address

The 169.254/16 range is a DHCP fallback when a device is unable to get a DHCP IP. The apple airport routers and some macs set these up automatically. There are older threads that have complained about this issue.

These routes are set up automatically at boot and they are almost never routable by normal traffic.

Tweaking plex to ignore this range, or at least ignoring it after broadcasting X errors in the logs would help to make plex a nice network denizen. Thanks!

I’d suggest that this isn’t a Plex issue, but one with your network. If a device is auto-configuring itself with a 169.254.x.x address you have DHCP issues that need sorting.

These addresses are never assigned by another device like a router; a network connected device that asks for a DHCP lease but, for whatever reason, doesn’t manage to get one configures itself with a 169.254.x.x address.

This is a basic function of the internet. The error message is roughly equivalent to plex trying to find devices on the loopback address (127.0.0.1).

See RFC 5735 section 3 and in RFC 3827.

169.254.0.0/16 - This is the “link local” block. As described in [RFC3927], it is allocated for communication between hosts on a single link. Hosts obtain these addresses by auto-configuration, such as when a DHCP server cannot be found.

Edit: since the purpose of this block is documented and is not a suitable range for plex to explore for devices, it simply shouldn’t be using this block, OR at the very least, stop attempting to do so after getting a few messages.

My point is that your server running PMS shouldn’t have an interface with 169.254.30.11 assigned to it. PMS will try to discover resources on the 169.254.255.255 network only if the server has an interface with an address on that network. Have a look in System Preferences -> Network on the Mac PMS is running on and see if there are any unexpected interfaces there (besides the Ethernet or Wi-Fi you’d expect to see and use) that are configured with the link local address you mention. If you do, down the interface, as it’s probably not being used.

You’re confusing the use of the loopback device and link local, though.

I used the loopback address as an example since it’s also a known block with behavior described by a RFC. The 169.254/16 block is a RFC, the mac is doing the absolute right thing in setting up the route, the airport utility is doing the absolute right thing in setting it up. The equipment between here and there doesn’t always conform to the RFC though since its an edge case.

Further, even though I can actually ping my airport router from my mac on the 169.254/16 address, plex gets into trouble because it macOS doesn’t let it use that address because it’s just a placeholder for admins to go in and fix stuff. The actual error message is:

Edit: NetworkServiceBrowser: Error sending out discover packet from 169.254.30.11 to 169.254.255.255: Can’t assign requested address.

And again this route is set up by the OS and the routers and any other device that adheres to RFC standards. So this route isn’t actually in the settings network pane anymore than 127.0.0.1 is. It simply is, because that’s how the internet is suppose to work.

tl;dr 169.254.x.x addresses should only appear on a misconfigured network as a fallback mechanism to retain IP connectivity. This isn’t Plex’s fault, it’s just trying to use a valid interface on the host machine. My advice is to fix your network.

With that in mind…

An IPv6 stack will always bring up link local address, regardless of whether you’ve DHCPv6, SLAAC or a staticly configured address on the interface, it’s always there for communications you don’t want/need to pass outside your local network segment.

IPv4 only configures itself with a link local address if the interface is configured for DHCP and doesn’t successfully get a lease assigned. A router will not tell a network station to use a 169.254/16 address. Link local addresses are always configured by the DHCP client (be it on a client device or an interface on the router configured for DHCP) as a fallback in the event of DHCP lease assignment failure.

It sounds to me like you’ve got an interface (or sub interface) on your Mac that’s not disabled, believes it is connected to media (be it a copper or radio PHY), is configured to obtain an IPv4 address using DHCP, but for some reason isn’t. The most likely reason is that there’s no DHCP server servicing requests on that network segment.

You say the interface with the 169.254/16 address isn’t shown in the network pane. Try the following from the terminal and see if there’s an interface with the offending address on it:

ifconfig | grep -C 5 169.254

The interface must exist for you to be able to ping the Airport 169.254/16 interface.

You say:

The 169.254/16 block is a RFC, the mac is doing the absolute right thing in setting up the route, the airport utility is doing the absolute right thing in setting it up. The equipment between here and there doesn’t always conform to the RFC though since its an edge case.

Further, even though I can actually ping my airport router from my mac on the 169.254/16 address, plex gets into trouble because it macOS doesn’t let it use that address because it’s just a placeholder for admins to go in and fix stuff.

Are you using this link local network between your Mac and Airport by design?

It’s interesting that you say your Airport also has a 169.254/16 address. As a router, it’s best practice to staticly configure the IP addresses on its interface(s). Is there a DHCP server on this network segment? Most people with an Airport use it as the DHCP for their network.

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