After upgrading to El Capitan, I've started noticing annoying connections from the AirPlayXPCHelper to subnet (my home network isn't in subnet, it's in subnet).

Questions are:

  1. Why AirPlayXPCHelper goes out to this network on port 5000 and 7000?
  2. Is there a way to limit it's desire to go there?

Thank you.

  • Anything on the 192.168 network it may be interested in connecting to? – agentroadkill Nov 26 '15 at 20:53
  • Not really. There is network from the cable modem, but nothing in the range. Not even VPN. – sashk Nov 27 '15 at 0:52
  • Since AirPlay is meant to work together with the AirPort Express base station, which default address range is at 192.168.1.x/24, it is possible that this is used by the helper to try to get responses from such base stations. – Phoenix Nov 27 '15 at 11:22
  • @Phoenix isn't is default for Airport? – sashk Nov 27 '15 at 14:10
  • There are 3 networks configurable: 10.0.x.x/24, 172.16.x.x/24 and 192.168.x.x/24. The third octet defaults to 1, but can be configured freely to anything from 0-255. If I'm not mistaken, it used to be 10.0.x.x/24 and got changed to 192.168.x.x/24 in later firmware versions. Since I have not defaulted my devices for a very long time, I'm not 100% sure though. – Phoenix Nov 27 '15 at 14:29

Time to answer my own question:

Why AirPlayXPCHelper goes out to this network on port 5000 and 7000?

This is related to the Peer-to-Peer AirPlay and Airplay device discovery. macOS discovers new device and attempts to connect using these ports to finish (?) discovery process.

Couple of my neighbours got new AppleTV and macOS attempts to connect to them. As all AppleTVs are connected to the different networks, it attempts to connect to each of them and it is what Little Snitch reports.

Is there a way to limit its desire to go there?

I'm not aware of any. I just blocked access for AirPlayXPCHelper to networks other than mine using Little Snitch.


I had this exact same issue where Little Snitch detected external AirPlayXPCHelper traffic on port 7000 but treated it as internal traffic. What I mean is that even though I had all external traffic marked as deny, Little Snitch continued to prompt me on each connection attempt until I set it to deny local traffic (just for testing purposes), obviously I do not want to deny local traffic on this port... I do not understand why Little Snitch is interpreting this as local traffic (when the address is not in the local DHCP scope), a bug with Little Snitch perhaps?

When I read a post about AirPlay it got me thinking about how AirPlay technology works, as it now uses bluetooth to establish connections between devices. I was unable to repeat the issue with local connections enabled and bluetooth disabled.

Long story short I am now convinced this is simply a bug in Little Snitch and not someone trying to hack into my network. Blocking local connection or disabling bluetooth are the only ways I can permanently stop attempts.

The bluetooth traffic is coming from an AirPlay enabled device somewhere near your computer. Maybe a next door neighbours AppleTV?

  • I don't see how this is an answer to the question and not another question entirely. Consider rewriting it so it answers the question or if you have another question, rewrite it and post it as a new question. – Allan Apr 27 '16 at 11:24

This question will help you disable the root cause of the problem.

If you're the curious type, I'd fire up WireShark somewhere and see if the Mac is actually sending out packets on those ports to those addresses. It may be that AirPlay has assigned itself an interface and is using it as a loop back or otherwise.

  • 3
    I don't want to disable AirPlay, but I want to get better understanding why it attempts to connect to subnets which are not in my network. I was looking at Wireshark dump, but did not see anything interesting. I should have mentioned this in my question. – sashk Nov 27 '15 at 6:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .