Airplay mirroring error "Could not connect to Apple TV"

Question

Level 1

39 points

Airplay mirroring error "Could not connect to Apple TV"

Symptoms:

Airplay mirroring not working in OSX. Error “Could not connect to Apple TV”. This is regarding a 3rd gen. ATV. The problem exists when logged in using a network domain user account, local user account works fine.

My setup:

- Wired LAN, including ATV, on the same network, WLAN disabled in OSX.

- Network domain account, connects to a Synology Directory Server.

- Mac Mini (2014), OSX El Capitan 10.11.5 (software up to date)

- Router: ASUS RT-N56U (firmware up to date)

- ATV 3rd gen. (firmware up to date)

- ATV 4th gen. (firmware up to date)

What works:

- Local account in OSX, mirroring works correctly on both ATV 3rd gen. and 4th gen.

- Network account: Airplay mirroring to ATV 4th gen.

- Network account: iTunes Home Sharing to ATV 3rd gen. (video + audio)

- Network account: ATV 3rd gen. shows up in menu bar, even after name change

I have:

- Googled the issue for over a week

- Rebooted Mac

- Rebooted/turned off Mac, router and ATV

- Checked the IP config, made sure that DNS works correctly.

- Not installed Airparrot software (never has been installed).

- Checked Console.app, no error messages logged.

- Firewall: Off

- Enabled/disabled Security code (Passcode) on the ATV

- Deleted com.apple.airplay.plist

- Deleted /Library/Preferences/SystemConfiguration/ NetworkInterfaces.plist

- Reset PRAM/VRAM

- Booted into Safe Mode + restart

- Created another Network User account.

- Set network user as local computer admin

- Changed OSX computer name

- Changed ATV name

- Turned Display Preferences > “Show mirroring options…” off/on

- Deleted Display preferences plist file.

- Turned Bluetooth off.

- Executed command: sudo dscacheutil -flushcache

- Cleared DNS cache with command: sudo killall -HUP mDNSResponder

- Executed command: sudo killall coreaudiod

- Verified disk permissions with command: sudo /usr/libexec/repair_packages --verify --standard-pkgs /

- Repaired permissions with command: sudo /usr/libexec/repair_packages --repair --standard-pkgs --volume /

- Disabled Bonjour with command: sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist

- Enabled Bonjour with command: sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist

- Pinged the multicast group: ping 224.0.0.251, the ATV responds.

- Checked ATV availability with the software Bonjour Browser, the ATV shows up correctly.

Thoughts:

- No problems with the ATV or router/network, since everything works with local user account.

- Network user permission problem? Any way to “reset” or reinstall Airplay?

- Why is 4th gen. ATV working?

- How come iTunes Sharing works?

- Where to go next?

Ideas are welcome, thanks! //Marcus

Posted on Jun 10, 2016 10:30 AM

Reply

Answer 1

Jul 25, 2017 12:27 PM in response to BrianF-ICS

I am tech director at a school also and we're having the same problem with network users being unable to connect to our ATV3 devices. We do not have the money to purchase new ATV4s either. It's very frustrating.

Reply

Answer 2

Jun 10, 2016 11:56 AM in response to widen76

Wow. OK, let's start.

You don't have a Bonjour problem since the computer is able to "see" the ATV.

Home Sharing works because it's the ATV connecting to the computer, and you've taken steps to allow that.

ATV is rejecting the connection because of some security or protocol issue.

It shouldn't matter, but are the two ATVs on different Apple IDs?

Since this is only a problem with your network domain account, it's just possible that the older software in ATV 3 cannot handle it, but not likely.

Does your ATV 3 have the "Require Device Verification" AirPlay access control mode? That's a one-time code that makes the computer a friend for life. If so, you could try enabling it, and connecting using the good account. Then see if it opens the door for the other account.

Maybe someone else has some ideas.

There's no chance that using this network domain account changes your IP address, is there?

Reply

Answer 3

Jun 10, 2016 12:13 PM in response to widen76

You've described all the configuration items that might affect the AirPlay connection. Have you checked them in the network account? For instance, is the firewall off in that account? Cannot explain why it works for the a ATV 4, but they do have different software, and ATV 3 may need something different.

Reply

Answer 4

widen76 Author

Level 1

39 points

Jun 10, 2016 1:00 PM in response to Diana.McCall

Thank you for your reply Diana.

Does your ATV 3 have the "Require Device Verification" AirPlay access control mode? That's a one-time code that makes the computer a friend for life. If so, you could try enabling it, and connecting using the good account. Then see if it opens the door for the other account.
I enabled the device verification, when using the good account, the code shows up on the ATV and I enter the code in the dialog box in OSX, works without a problem. I then logged into the network user account and did the same thing (new code though), but when I enter the code it says "incorrect code". I've tried it a few times with the same result, so no-go on that one.
There's no chance that using this network domain account changes your IP address, is there?
No, the IPaddressis the same, since the lease time hasn't expired yet.

I even went so far as to do a packet trace and looked at the communication between OSX and the ATV (see picture). The 3-way handshake is made and then does a PUSH and after that OSX ends the connection with a 4-way teardown. Reasonable enough. One thing that caught my eye was the "bad checksum" coming from OSX (192.168.132.18). However, this was also the case when capturing packets using the good account, so it shouldn't matter. //Marcus

Reply

Answer 5

widen76 Author

Level 1

39 points

Jun 10, 2016 1:11 PM in response to Diana.McCall

Thank you Diana,

Yes, the network configuration has been verified in the network user account, the firewall is set to "off", I believe this is a system-wide setting and applies to all user accounts, but it's good to double check. All network settings are equal to the good account, including default gateway, DNS settings and so on. I went through all of the other preferences as well, just to make sure that they are identical.

I'm currently out of ideas. There seems to be a difference in the software of the ATV4 and ATV3 how they handle network communications. Maybe it's OSX that gets confused. At this time I'm none the wiser...

One more thing I tried was to unplug the ATV3 for a couple of minutes, then checked the Airplay menu in OSX to make sure the entry was gone. Then I plugged the ATV3 back in, OSX picked it up and it was back in the Airplay menu. So the multicast/unicast Bonjour seems OK. However, the communication isn't.

Need more input 😕

//Marcus

Reply

Answer 6

Jun 10, 2016 3:31 PM in response to widen76

Too bad about the device verification. I was hoping it might be based on the MAC address, once and for all. Interesting that it rejects the code, but that's probably another way of rejecting the connection, misinterpreted by the computer.

There was another user who got the code prompt even when it was not enabled, and it was always rejected too. I'm not sure if they solved their problem.

Sorry I can't be more helpful. There's definitely something...

Reply

Answer 7

widen76 Author

Level 1

39 points

Jun 12, 2016 4:37 AM in response to Diana.McCall

Yes, I think you're right, the code rejection is a symptom of a failed communication negotiation between the two devices.

I looked into the "bad checksum" thing and found on Apple's site regarding TCPdump that it's normal behavior:

"The packet trace may show that the TCP checksum of packets sent by the Mac is "bad." This is because the packet trace is being captured at the link layer of the network stack, which is just before the physical network adapter where checksums are generated. This can be safely ignored."

I have a theory that the Directory Server might be involved in the problem, seeing that it answers to LDAP authentication querys and that it somehow interferes. I'm not sure about that though and I have to do more packet tracing on the good account and compare to the failed network account communication.

Any more ideas are always welcome

Thanks!

//Marcus

Diana.McCall wrote:

Too bad about the device verification. I was hoping it might be based on the MAC address, once and for all. Interesting that it rejects the code, but that's probably another way of rejecting the connection, misinterpreted by the computer.

There was another user who got the code prompt even when it was not enabled, and it was always rejected too. I'm not sure if they solved their problem.

Sorry I can't be more helpful. There's definitely something...

Reply

Answer 8

widen76 Author

Level 1

39 points

Jun 13, 2016 11:03 AM in response to widen76

Still no go. I've tried accessing the ATV through WiFi but still the same. As a last ditch effort I did a clean install of El Capitan and rejoined the domain. Same problem. It must be the ATV3 that has problems with OSX being joined to an Open Directory domain. So right now I'm thinking about purchasing another ATV4 to get around the issue...unless anyone has some more ideas?

Thanks!

//Marcus

Reply

Answer 9

widen76 Author

Level 1

39 points

Jun 20, 2016 9:51 AM in response to widen76

I have now bought another ATV4 and it works flawlessly, so problem solved I guess. Still, it would be nice to find out what caused the ATV3 problems...

Reply

Answer 10

Sep 28, 2016 3:26 PM in response to widen76

I'd like to bump this thread a bit...

We are having a similar issue, but as a school system, we can't just buy ATV4s - we have about 70 ATV3s in service, and all are displaying this issue with 10.11. Network accounts (AD or OD - we have schools running both) will not mirror using Airplay, local or mobile accounts will. Gone through all the steps as above - has anyone else seen this, or know of a fix? It would seem to be a permissions issue - something we have run into elsewhere with ElCap.

(Apple, you listening? El Capitan broke something that is very important...)

Reply

Answer 11

Sep 29, 2016 6:55 AM in response to BrianF-ICS

Hi. Obviously you have lots of info from the previous posts. Let me just add a couple of additional items.

Be sure you have enabled the necessary access in the OS X firewalls. See Use AirPlay to display video from your Mac on an HDTV - Apple Support

If you search the web for "active directory bonjour", there's quite a lot of information on how they can be made to work together. The following are a few that I have found:

https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/NetSe rvices/Introduction.html

https://www.csc.ncsu.edu/it/sites/default/files/apple-0004.pdf

https://kb.acronis.com/sites/default/files/content/2013/01/39490/wanbonjour_1.pd f

If you're unable to resolve or bind to domains that end in .local - Apple Support

By the way, Apple is not listening here. You need to send feedback here https://www.apple.com/feedback/. Also, since your problem relates to OS X, you might find more help in the OS X forums.

Reply

Answer 12

Jul 27, 2017 7:32 AM in response to widen76

Any luck figuring this out?

Reply