Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Apple_TV discovery failing #85903

Closed
cmgrayb opened this issue Jan 14, 2023 · 10 comments
Closed

Apple_TV discovery failing #85903

cmgrayb opened this issue Jan 14, 2023 · 10 comments

Comments

@cmgrayb
Copy link

cmgrayb commented Jan 14, 2023

The problem

Expected Behavior:

Home Assistant connects to Apple TV

Actual Behavior:

Home Assistant immediately exits connection loop and declares "No devices found on the network"

Additional Testing:

Can see records which appear to contain the correct information for the desired Apple TV devices in zeroconfServiceBrowser under the following:
_companion-link._tcp.
_srpl-tls._tcp.
Apple Airplay (_airplay._tcp.)
Remote Audio Output Protocol (AirTunes) (_raop._tcp.)
Sleep Proxy Server (_sleep-proxy._udp.)
_meshcop._udp.

Network is flat, all devices and services on a single VLAN, subnet, and prefix

atvremote scan output:

Scan Results
========================================
       Name: Home Theater
   Model/SW: Apple TV 4K (gen2), tvOS 16.2
    Address: 192.168.1.154
        MAC: [redacted]
 Deep Sleep: False
Identifiers:
 - [same as MAC]
 - [same as MAC minus ':' separators]
Services:
 - Protocol: Companion, Port: 49153, Credentials: None, Requires Password: False, Password: None, Pairing: Mandatory
 - Protocol: AirPlay, Port: 7000, Credentials: None, Requires Password: False, Password: None, Pairing: Mandatory
 - Protocol: RAOP, Port: 7000, Credentials: None, Requires Password: False, Password: None, Pairing: Mandatory

       Name: Bedroom
   Model/SW: Apple TV 4K (gen2), tvOS 16.2
    Address: 192.168.1.155
        MAC: [redacted]
 Deep Sleep: False
Identifiers:
 - [same as MAC]
 - [same as MAC minus ':' separators]
Services:
 - Protocol: Companion, Port: 49159, Credentials: None, Requires Password: False, Password: None, Pairing: Mandatory
 - Protocol: AirPlay, Port: 7000, Credentials: None, Requires Password: False, Password: None, Pairing: Mandatory
 - Protocol: RAOP, Port: 7000, Credentials: None, Requires Password: False, Password: None, Pairing: Mandatory

atvremote is able to connect to, pair, and control the devices using the protocols found by the scan

All other Home Assistant integrations tried are working, including other mDNS services

What version of Home Assistant Core has the issue?

2023.1.4

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant Container

Integration causing the issue

Apple TV

Link to integration documentation on our website

https://www.home-assistant.io/integrations/apple_tv

Diagnostics information

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

Logger: frontend.js.latest.202301100
Source: components/system_log/__init__.py:256
First occurred: 2:31:55 PM (3 occurrences)
Last logged: 3:31:25 PM

:0:0 ResizeObserver loop completed with undelivered notifications.

Additional information

No response

@home-assistant
Copy link

Hey there @postlund, mind taking a look at this issue as it has been labeled with an integration (apple_tv) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of apple_tv can trigger bot actions by commenting:

  • @home-assistant close Closes the issue.
  • @home-assistant rename Awesome new title Change the title of the issue.
  • @home-assistant reopen Reopen the issue.
  • @home-assistant unassign apple_tv Removes the current integration label and assignees on the issue, add the integration domain after the command.

(message by CodeOwnersMention)


apple_tv documentation
apple_tv source
(message by IssueLinks)

@cmgrayb cmgrayb changed the title Apple_TV dicovery failing Apple_TV discovery failing Jan 15, 2023
@cmgrayb
Copy link
Author

cmgrayb commented Mar 3, 2023

Additional Testing Continued:

I was unable to use pyatv within the container to discover any Apple TV devices on the network by broadcast. The same broadcast-based script on the container host running the same version of pyatv was able to find all devices. I was able to use unicast to connect to a known IP using pyatv's manual_connect.py example from within the container, but received a failed authentication. My next task is to understand the HSGID and where it should be retrieved from.

Based on the pyatv examples and the connect routine in __init__.py, it appears to me that pyatv is broadcasting for a list of devices before trying to connect in most instances, which will occur on the container's network, which is not the host network, unless run on a Linux container host in "host" or "macvlan" networking mode to put the container on the same network as the devices to be managed. On Docker Desktop for Windows, which is where I am running it while I develop the configuration, networking is always performed through NAT unless two containers are on the same bridge network. Host and macvlan based networking only work on Linux.

This means that configuration routines must be entirely unicast to function in a Docker Desktop for Windows installation method.

One possible solution could be to have an optional unicast-only discovery flow with instructions on how to obtain authentication. If there is a way to trigger one that already exists and I am not seeing it, please feel free to say so, but at this time, it appears that the Apple TV component will not work on a container install on a Windows host due to protocol design and pairing method. If I manage to obtain a spare machine to load Linux on and containerize it appropriately there, I will give it another try at that time, but the VM method is even more fraught with problems.

@grolnn
Copy link

grolnn commented Mar 10, 2023

I'm not sure if I experience the exact same issue, but it sure is awfully similar. It's been happening for about a year now and finally had some tome to take a deep dive into this. I'm not as knowledgeable as @cmgrayb seems to be, but here are some of my findings.

Home Assistant Core in Docker, Ubuntu host. Spinned up a completely clean HA container on my Synology NAS, with the exact same behaviour as my live installation on the Ubuntu machine.

atvremote scan

This command finds 2 devices on the network; a MacBook and a Bluesound Powernode media player. It finds neither my Apple TV 3 gen or Apple TV 4k, which are on the same 192.168.1.0/24 subnet.

atvremote --scan-hosts 192.168.1.212,192.168.1.253 scan

When I manually specify the exact (static) IP-addresses of both ATV's, atvremote does find them.

Scan Results
========================================
       Name: Woonkamer
   Model/SW: Apple TV 4K, tvOS 16.3.2
    Address: 192.168.1.212
        MAC: [redacted]
 Deep Sleep: False
Identifiers:
 - [redacted]
 - [redacted]
Services:
 - Protocol: Companion, Port: 49153, Credentials: None, Requires Password: False, Password: None, Pairing: Mandatory
 - Protocol: AirPlay, Port: 7000, Credentials: None, Requires Password: False, Password: None, Pairing: Mandatory
 - Protocol: RAOP, Port: 7000, Credentials: None, Requires Password: False, Password: None, Pairing: Mandatory

       Name: Slaapkamer Apple TV
   Model/SW: Apple TV 3, ATV SW 8.4.4
    Address: 192.168.1.253
        MAC: [redacted]
 Deep Sleep: False
Identifiers:
 - [redacted]
 - [redacted]
 - [redacted]
Services:
 - Protocol: AirPlay, Port: 7000, Credentials: None, Requires Password: False, Password: None, Pairing: Mandatory
 - Protocol: DMAP, Port: 3689, Credentials: None, Requires Password: False, Password: None, Pairing: Mandatory
 - Protocol: RAOP, Port: 7000, Credentials: None, Requires Password: False, Password: None, Pairing: Mandatory

However, I'm unable to pair with any of the available options. I believe I've tried every possibility, including manual address, all different protocols, manual ports. All to no avail.

Edit: probably irrelevant and/or obvious, but I'm both able to ping and nmap the AppleTV inside the docker container shell.

bash-5.1# nmap -Pn 192.168.1.212
Starting Nmap 7.92 ( https://nmap.org ) at 2023-03-10 19:37 CET
Nmap scan report for 192.168.1.212
Host is up (0.0010s latency).
Not shown: 994 closed tcp ports (reset)
PORT      STATE SERVICE
5000/tcp  open  upnp
7000/tcp  open  afs3-fileserver
7100/tcp  open  font-service
49152/tcp open  unknown
49153/tcp open  unknown
62078/tcp open  iphone-sync

Nmap done: 1 IP address (1 host up) scanned in 72.23 seconds

@postlund
Copy link
Contributor

One potential issue here is that Home Assistant wait for all services that it paired with when adding the device. Looks to me like MRP is no longer amongst the announced services but it most likely did when you added the device. So simplest test: remove and re-add the device and see if that helps?

@grolnn Check AirPlay access settings in your Apple TV and make sure it is set to everyone on the same network.

@grolnn
Copy link

grolnn commented Mar 10, 2023

@postlund I completely removed the integration a while ago. And I thought it would be smart to check this with a completely new Home Assistant installation, so there's nothing to remove and re-add in my case. It's a completely clean intstall with zero integrations just to test this.

AirPlay Access on the ATV is set to Same Network. I've also tried it with the Everyone setting, and tried toggling the Home Hub-setting (not sure what that does though), without success. Still the same behviour. Just to be sure, I've temporarily disabled the firewall on the host machine.

atvremote --id [redacted] --protocol mrp pair
2023-03-10 20:03:07 ERROR [pyatv.scripts.atvremote]: Could not find any Apple TV on current network

I've tried all protocols with the exact same result. It's like atvremote is unable to find the ATV's by ID. It can find them by IP-address, but is unable to pair when specifying the address. Really odd.

@fredriklj
Copy link

I experience something similar to what @cmgrayb is seeing. However, in my installation hass runs in a docker image on a linux host (with network_mode: host). It appears, for some reason, that multicast traffic isn't making it through the docker networking. To resolve this, I run a mdns-repeater between the vlan where the Apple TV is located, and the docker0 interface.

After this, "atvremote scan" detects the Apple TV, listing its IP address. And under "services", the following is reported:

"Protocol: RAOP, Port: 7000, Credentials: None, Requires Password: False, Password: None, Pairing: Mandatory"

From time to time, the field "MAC" is empty ("MAC: None"), but at times the correct mac address shows up (and then airplay is also reported under "services"). I can also pair with the Apple TV from the command line, no issues. I get a token.

But regardless how I try with the Apple TV integration, I always end up with "No devices found on the network" trying to configure the integration. I also tried the beta version of the integration, but same result. It does seem to me that something is broken here?

@fredriklj
Copy link

Responding to my own post with an update. My issue was related to PEBKAC. Home assistants network component automatic selection of interface for multicast had picked the wrong interface. It was resolved by simply going to Settings-->System-->Network and selecting the right one.

@grolnn
Copy link

grolnn commented Mar 20, 2023 via email

@fredriklj
Copy link

You are likely running your docker container with the bridge network driver (which means docker has set up a L2 network between the host and the container). What I found out was that hass needs to be able to send multicast to your zeroconf-devices (not only receive). So, run your docker with host networking. And if you have several interfaces (like I do), make sure hass is configured to use the right one (facing your zero-conf devices).

@cmgrayb
Copy link
Author

cmgrayb commented Mar 23, 2023

@postlund I'm going to close this issue, as it is not a code problem. Perhaps others will run across the issue in the future, so I will leave some final thoughts.

In my case, the problem was an unsupported configuration of Home Assistant itself. Container on Windows just will not work with mDNS-based or true broadcast-based services due to the Docker network capabilities on Windows. I was able to free up a machine, and as soon as I loaded the machine with Debian Bullseye and a Supervised install, the Apple TV integration not only worked, but discovered all of my devices on its own after restoring the original machine's configuration onto the new machine. I would have gone with Home Assistant OS, but the machine is somehow too old for UEFI, yet all of the requirements run fine. For other containerized configurations, please have a look at the comments left by @fredriklj. I believe he is on the right track.

Thank you for your time @postlund, and my apologies for wasting it.

@cmgrayb cmgrayb closed this as completed Mar 23, 2023
@github-actions github-actions bot locked and limited conversation to collaborators Apr 22, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants