Closed sling100 closed 3 years ago
Here's a bit more context. The ATV appears in the scan, but I cannot then get it to bind?
(pyatv_venv) C:\Pyatv\pyatv_venv\Scripts>atvremote scan
Scan Results
========================================
Name: Apple TV 2
Model/SW: 4 tvOS 14.3
Address: 192.168.11.70
MAC: D0:03:4B:1D:AA:AA
Deep Sleep: False
Identifiers:
- 935C22E5-7497-447D-A614-7E1E9DB2DC8E
- D0:03:4B:1D:AA:AA
Services:
- Protocol: MRP, Port: 49152, Credentials: None
- Protocol: AirPlay, Port: 7000, Credentials: None
(pyatv_venv) C:\Pyatv\pyatv_venv\Scripts>atvproxy mrp a369a5c6d90866297cb3678c80537c6480bb5a7fe16f1e01c1f9861f7544d65b:28494243679192c53ff67e1ddb95a4dc93f594f0fbe4a1ff6ad09f7a1bd5af91:36363132393332322d383831332d346632342d616463652d626530373062336132623638:34336663663863372d323837342d346239662d393766392d3763353061623631aaaaaaaa 192.168.11.70
Traceback (most recent call last):
File "C:\Program Files\Python37\lib\runpy.py", line 193, in _run_module_as_main
"__main__", mod_spec)
File "C:\Program Files\Python37\lib\runpy.py", line 85, in _run_code
exec(code, run_globals)
File "C:\Pyatv\pyatv_venv\Scripts\atvproxy.exe\__main__.py", line 7, in <module>
File "c:\pyatv\pyatv_venv\lib\site-packages\pyatv\scripts\atvproxy.py", line 315, in main
return loop.run_until_complete(appstart(loop))
File "C:\Program Files\Python37\lib\asyncio\base_events.py", line 587, in run_until_complete
return future.result()
File "c:\pyatv\pyatv_venv\lib\site-packages\pyatv\scripts\atvproxy.py", line 302, in appstart
zconf = Zeroconf()
File "c:\pyatv\pyatv_venv\lib\site-packages\zeroconf\__init__.py", line 2509, in __init__
interfaces, unicast, ip_version, apple_p2p=apple_p2p
File "c:\pyatv\pyatv_venv\lib\site-packages\zeroconf\__init__.py", line 2343, in create_sockets
respond_socket = new_respond_socket(i, apple_p2p=apple_p2p)
File "c:\pyatv\pyatv_venv\lib\site-packages\zeroconf\__init__.py", line 2305, in new_respond_socket
bind_addr=cast(Tuple[Tuple[str, int, int], int], interface)[0] if is_v6 else (cast(str, interface),),
File "c:\pyatv\pyatv_venv\lib\site-packages\zeroconf\__init__.py", line 2250, in new_socket
s.bind((bind_addr[0], port, *bind_addr[1:]))
OSError: [WinError 10049] The requested address is not valid in its context
OK, by removing all the network interfaces except one it now starts
2021-04-15 16:19:21 DEBUG: Binding to local address 192.168.11.80 2021-04-15 16:19:21 INFO: Started MRP server at port 50668 2021-04-15 16:19:21 DEBUG: Publishing zeroconf service: ServiceInfo(type='_mediaremotetv._tcp.local.', name='Apple TV 2 Proxy._mediaremotetv._tcp.local.', addresses=[b'\xc0\xa8\x0bP'], port=50668, weight=0, priority=0, server='Apple TV 2 Proxy._mediaremotetv._tcp.local.', properties={'ModelName': 'Apple TV', 'AllowPairing': 'YES', 'macAddress': '40:cb:c0:12:34:56', 'BluetoothAddress': 'False', 'Name': 'Apple TV 2 Proxy', 'UniqueIdentifier': '5D797FD3-3538-427E-A47B-A32FC6CF3A69', 'SystemBuildVersion': '17K499', 'LocalAirPlayReceiverPairingIdentity': '4D797FD3-3538-427E-A47B-A32FC6CF3A6A'}) Press ENTER to quit
However the proxy device never appears in any mdns query and it seems to make no difference what credentials are inserted as the script never seems to pair with the specified Apple TV.
Am I missing something fundamental here?
Thanks
I have never tested the proxy on Windows, so I'm not sure if or how well it works I'm afraid (Windows is not prioritized platform to me). It might be that some interfaces can't be bound to due to some other Zeroconf instance (probably Windows itself) already using the port. Would be great to add some error handling and just ignore those addresses and at least bind to what works. Anyways...
Is 192.168.11.80 on the same network as your Apple TV?
Hey Pierre
I'm running pytv on WSL, so in theory it's not actually running on Windows, although quite how the network traffic is shared I don't know.
ATV is on 11.70 and appears fine in the atvremote scan from the same machine.
If I open a UDP port on 5353 on another machine and send the correct announce packet the ATV responds every time, but the proxy never does. It's almost like it isn't running. It sends one broadcast as you run the script and then that's it. It never replies to any other device.
Thanks for your help
Simon
On Fri, 16 Apr 2021, 07:57 Pierre Ståhl, @.***> wrote:
I have never tested the proxy on Windows, so I'm not sure if or how well it works I'm afraid (Windows is not prioritized platform to me). It might be that some interfaces can't be bound to due to some other Zeroconf instance (probably Windows itself) already using the port. Would be great to add some error handling and just ignore those addresses and at least bind to what works. Anyways...
Is 192.168.11.80 on the same network as your Apple TV?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/postlund/pyatv/issues/1005#issuecomment-820958894, or unsubscribe https://github.com/notifications/unsubscribe-auth/ATE76HZFWV5P3W3SFMG7SHTTI7NULANCNFSM42O7OQOA .
Scanning and publishing services works a bit differently in this case, since I rely on python-zerconf for publishing (used by the proxy to expose the zeroconf service) and scanning is based on my own implementation of zeroconf. When starting the proxy, you should see broadcast messages from it on the network however, e.g. with wireshark. If you don't, then there's obviously a problem. Maybe there's a firewall blocking the packets?
I can see packets being sent directly to the multicast group. What doesn't seem to happen is the proxy responding directly to the remote. The ATV does, but the proxy doesn't. As a result the proxy never appears as a pairable device.
I tried to run the same code on a Raspberry Pi, but I couldn't get the cryptography wheel to build in the virtual environment.
On Fri, 16 Apr 2021, 08:33 Pierre Ståhl, @.***> wrote:
Scanning and publishing services works a bit differently in this case, since I rely on python-zerconf for publishing (used by the proxy to expose the zeroconf service) and scanning is based on my own implementation of zeroconf. When starting the proxy, you should see broadcast messages from it on the network however, e.g. with wireshark. If you don't, then there's obviously a problem. Maybe there's a firewall blocking the packets?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/postlund/pyatv/issues/1005#issuecomment-820980186, or unsubscribe https://github.com/notifications/unsubscribe-auth/ATE76H6P365GMZ7TGLOTNKDTI7R6JANCNFSM42O7OQOA .
Hmm, I'm not sure what you mean by What doesn't seem to happen is the proxy responding directly to the remote.? Your device (iOS device) should pick up the packets sent to the multicast address and parse everything from them, there's no additional communication between your device and proxy for MDNS purposes.
Sorry – I should have made myself clearer. As far as I can tell the remote sends an announce packet to the multicast address and all of the ATV units respond directly to this with a MDNS packet with IP/port etc to allow a direct connection to occur. The proxy does not seem to do this?
From: Pierre Ståhl @.> Sent: 16 April 2021 10:33 To: postlund/pyatv @.> Cc: sling100 @.>; Author < @.> Subject: Re: [postlund/pyatv] ATVProxy IP error (#1005)
Hmm, I'm not sure what you mean by What doesn't seem to happen is the proxy responding directly to the remote.? Your device (iOS device) should pick up the packets sent to the multicast address and parse everything from them, there's no additional communication between your device and proxy for MDNS purposes.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/postlund/pyatv/issues/1005#issuecomment-821050196, or unsubscribe https://github.com/notifications/unsubscribe-auth/ATE76HYC6JTHYMBTIYT6RP3TI7743ANCNFSM42O7OQOA .
Right, it that happens when someone subscribes to a new service. Have you verified that this packet is received in your WSL instance? Not sure what you can do there exactly, but would be good if you could verify if it is received at all with tcpdump or wireshark. I suspect it's an environmental problem with the packet not reaching the proxy at all.
Ah ok that’s interesting. So maybe the problem isn’t that the proxy is not responding – its more that it isn’t actually getting the announce packet in the first place. I’ll give tcpdump a run and see what I get.
Thanks
From: Pierre Ståhl @.> Sent: 16 April 2021 10:49 To: postlund/pyatv @.> Cc: sling100 @.>; Author < @.> Subject: Re: [postlund/pyatv] ATVProxy IP error (#1005)
Right, it that happens when someone subscribes to a new service. Have you verified that this packet is received in your WSL instance? Not sure what you can do there exactly, but would be good if you could verify if it is received at all with tcpdump or wireshark. I suspect it's an environmental problem with the packet not reaching the proxy at all.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/postlund/pyatv/issues/1005#issuecomment-821059082, or unsubscribe https://github.com/notifications/unsubscribe-auth/ATE76H7E24QAT4ZJFBU4OKLTJABYZANCNFSM42O7OQOA .
ATV is 11.70
Pyatv is 11.80
This is what I see when I run ‘atvremote scan’.
394696 2651.469210 192.168.11.70 192.168.11.80 MDNS 505 Standard query response 0x35ff PTR _mediaremotetv._tcp.local, "QU" question PTR Apple TV 2._mediaremotetv._tcp.local SRV 0 0 49152 Apple-TV-2.local TXT TXT AAAA fe80::b1:d1e9:5a67:ba5b A 192.168.11.70
This is the proxy response
394753 2652.071535 192.168.11.80 224.0.0.251 MDNS 421 Standard query response 0x0000 PTR Apple TV 2 Proxy._mediaremotetv._tcp.local SRV, cache flush 0 0 50668 Apple TV 2 Proxy._mediaremotetv._tcp.local TXT, cache flush A, cache flush 192.168.11.80
So the ATV responds directly to the scan, but the proxy only ever seems to respond back to the multicast group? I’m guessing because the proxy isn’t receiving the direct announce request from the remote?
From: Pierre Ståhl @.> Sent: 16 April 2021 10:49 To: postlund/pyatv @.> Cc: sling100 @.>; Author < @.> Subject: Re: [postlund/pyatv] ATVProxy IP error (#1005)
Right, it that happens when someone subscribes to a new service. Have you verified that this packet is received in your WSL instance? Not sure what you can do there exactly, but would be good if you could verify if it is received at all with tcpdump or wireshark. I suspect it's an environmental problem with the packet not reaching the proxy at all.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/postlund/pyatv/issues/1005#issuecomment-821059082, or unsubscribe https://github.com/notifications/unsubscribe-auth/ATE76H7E24QAT4ZJFBU4OKLTJABYZANCNFSM42O7OQOA .
I would expect so, yes. The proxy will announce the new service when started to the multicast group, but should respond to an individual host whenever said host subscribes to a service (which is basically a callout to the multicast address, but all hosts having that service should respond directly to the client). So it sounds much like the proxy doesn't receive the request.
Yes – that’s the bit that isn’t happening. I can see the announcement in wireshark, but that is running in windows, not WSL. Tcpdump doesn’t work in WSL either, so I’m a bit stuck. That must be the issue though.
From: Pierre Ståhl @.> Sent: 16 April 2021 11:35 To: postlund/pyatv @.> Cc: sling100 @.>; Author < @.> Subject: Re: [postlund/pyatv] ATVProxy IP error (#1005)
I would expect so, yes. The proxy will announce the new service when started to the multicast group, but should respond to an individual host whenever said host subscribes to a service (which is basically a callout to the multicast address, but all hosts having that service should respond directly to the client). So it sounds much like the proxy doesn't receive the request.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/postlund/pyatv/issues/1005#issuecomment-821083810, or unsubscribe https://github.com/notifications/unsubscribe-auth/ATE76HY2QY4MTDTH5EE6K7LTJAHGDANCNFSM42O7OQOA .
I tried it again but using a VM rather than WSL and the issue is still the same. Atvremote works fine (scan, pair etc) but atvproxy only sends announce packets to the group and never to the individual host. It’s very strange.
From: Pierre Ståhl @.> Sent: 16 April 2021 11:35 To: postlund/pyatv @.> Cc: sling100 @.>; Author < @.> Subject: Re: [postlund/pyatv] ATVProxy IP error (#1005)
I would expect so, yes. The proxy will announce the new service when started to the multicast group, but should respond to an individual host whenever said host subscribes to a service (which is basically a callout to the multicast address, but all hosts having that service should respond directly to the client). So it sounds much like the proxy doesn't receive the request.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/postlund/pyatv/issues/1005#issuecomment-821083810, or unsubscribe https://github.com/notifications/unsubscribe-auth/ATE76HY2QY4MTDTH5EE6K7LTJAHGDANCNFSM42O7OQOA .
Then I would suspect firewall.
I ran up tcpdump on the VM (doesn’t work on WSL) and I found the announce question from the remote – so it is def not a firewall issue.
Here’s the line:
15:40:03.928905 IP 192.168.11.201.1024 > 224.0.0.251.mdns: 0 PTR (QM)? _mediaremotetv._tcp.local. (43)
The ATV then responds to this directly, but the proxy doesn’t.
Is there anything in the proxy log that would showing incoming traffic?
From: Pierre Ståhl @.> Sent: 16 April 2021 11:35 To: postlund/pyatv @.> Cc: sling100 @.>; Author < @.> Subject: Re: [postlund/pyatv] ATVProxy IP error (#1005)
I would expect so, yes. The proxy will announce the new service when started to the multicast group, but should respond to an individual host whenever said host subscribes to a service (which is basically a callout to the multicast address, but all hosts having that service should respond directly to the client). So it sounds much like the proxy doesn't receive the request.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/postlund/pyatv/issues/1005#issuecomment-821083810, or unsubscribe https://github.com/notifications/unsubscribe-auth/ATE76HY2QY4MTDTH5EE6K7LTJAHGDANCNFSM42O7OQOA .
There's no way to enable logging in the python-zeroconf module right now, but you could probably add logging.getLogger("zeroconf").setLevel(logging.DEBUG)
or so in atvproxy
and enable it.
Did you make any progress on this? Would be interesting to know what the problem is. Also, I will prepare a patch to just log a warning and ignore interfaces that doesn't bind properly. That should "solve" the issue of not being able to start the proxy.
Right, just realized that it's a bug in python-zeroconf and reported here: https://github.com/jstasiak/python-zeroconf/issues/337
No I didn’t – I simply couldn’t get the proxy to respond directly to the ATV rather than to the multicast group. I was going to try on a native Linux install rather than a Windows VM, but I haven’t had time. But maybe the issue is a python one as your other comment suggested?
Thanks
From: Pierre Ståhl @.> Sent: 28 April 2021 11:46 To: postlund/pyatv @.> Cc: sling100 @.>; Author < @.> Subject: Re: [postlund/pyatv] ATVProxy IP error (#1005)
Did you make any progress on this? Would be interesting to know what the problem is. Also, I will prepare a patch to just log a warning and ignore interfaces that doesn't bind properly. That should "solve" the issue of not being able to start the proxy.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/postlund/pyatv/issues/1005#issuecomment-828354787, or unsubscribe https://github.com/notifications/unsubscribe-auth/ATE76H27I36S6TRQ5KKQTFLTK7RODANCNFSM42O7OQOA .
They fixed the zeroconf bug and now it works 😊 Thanks for your time!
From: Simon Ling @.> Sent: 28 April 2021 15:25 To: 'postlund/pyatv' < @.>; 'postlund/pyatv' @.> Cc: 'Author' @.> Subject: RE: [postlund/pyatv] ATVProxy IP error (#1005)
No I didn’t – I simply couldn’t get the proxy to respond directly to the ATV rather than to the multicast group. I was going to try on a native Linux install rather than a Windows VM, but I haven’t had time. But maybe the issue is a python one as your other comment suggested?
Thanks
From: Pierre Ståhl @.> Sent: 28 April 2021 11:46 To: postlund/pyatv @.> Cc: sling100 @.>; Author < @.> Subject: Re: [postlund/pyatv] ATVProxy IP error (#1005)
Did you make any progress on this? Would be interesting to know what the problem is. Also, I will prepare a patch to just log a warning and ignore interfaces that doesn't bind properly. That should "solve" the issue of not being able to start the proxy.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/postlund/pyatv/issues/1005#issuecomment-828354787, or unsubscribe https://github.com/notifications/unsubscribe-auth/ATE76H27I36S6TRQ5KKQTFLTK7RODANCNFSM42O7OQOA .
Awesome! Thanks for reporting back 👍
Hello Pierre
Can you confirm if the atvproxy works with v9 (ios 15)? I’m trying to work through the mrp over airplay layer!
Thanks
Simon
From: Pierre Ståhl @.> Sent: 28 April 2021 11:46 To: postlund/pyatv @.> Cc: sling100 @.>; Author < @.> Subject: Re: [postlund/pyatv] ATVProxy IP error (#1005)
Did you make any progress on this? Would be interesting to know what the problem is. Also, I will prepare a patch to just log a warning and ignore interfaces that doesn't bind properly. That should "solve" the issue of not being able to start the proxy.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/postlund/pyatv/issues/1005#issuecomment-828354787, or unsubscribe https://github.com/notifications/unsubscribe-auth/ATE76H27I36S6TRQ5KKQTFLTK7RODANCNFSM42O7OQOA .
Nope, won't work as MRP doesn't exist anymore. Will need AirPlay support in the proxy, which I haven't pushed yet (still code clean ups to do). But I should try to fix that at some point to make sure thr code doesn't rot...
I'm trying to set up atvproxy so i can keep an eye on the HID commands my iOS remote is using. I cannot get it to start though - I get a '10049' error, which would suggest the IP I am passing (of the ATV) is being used locally rather than remotely? I've added --remote_port and --local-ip but they make no difference.
python atvproxy.py mrp 'creds.txt' 192.168.11.70 --remote_port 49152 --local-ip 192.168.11.66
File "C:\Python\Python37\site-packages\zeroconf__init__.py", line 2250, in new_socket s.bind((bind_addr[0], port, *bind_addr[1:])) OSError: [WinError 10049] The requested address is not valid in its context