Closed xzerogx closed 11 years ago
Thanks for testing my sleepproxyclient. It seems the AirportExpress announced multiple IPs but should not be a problem in general...
This sounds very strange. I need some more information to investigate the issue.
Please run this command on your Ubuntu server and post the output:
avahi-browse --resolve --no-db-lookup --terminate _sleep-proxy._udp
Please post the script-output too.
+ p4p1 IPv4 70-35-60-63 Apple__TV _sleep-proxy._udp local
= p4p1 IPv4 70-35-60-63 Apple__TV _sleep-proxy._udp local
hostname = [AppleTV.local]
address = [192.168.178.47]
port = [52442]
txt = []
+ p4p1 IPv6 70-35-60-63 Apple__TV _sleep-proxy._udp local
= p4p1 IPv6 70-35-60-63 Apple__TV _sleep-proxy._udp local
hostname = [AppleTV.local]
address = [192.168.178.47]
port = [52442]
txt = []
+ p4p1 IPv4 50-35-10-70 AirPort K__che _sleep-proxy._udp local
= p4p1 IPv4 50-35-10-70 AirPort K__che _sleep-proxy._udp local
hostname = [AirPort-K-che.local]
address = [fe80::2a37:37ff:fe46:7210]
port = [63051]
txt = []
+ p4p1 IPv6 50-35-10-70 AirPort K__che _sleep-proxy._udp local
= p4p1 IPv6 50-35-10-70 AirPort K__che _sleep-proxy._udp local
hostname = [AirPort-K-che.local]
address = [169.254.173.103]
port = [63051]
txt = []
It seems the AirPort Express announces the service via 169.254.173.103
only. There is just not other usable IP address...
Please run python /usr/share/sleepproxyclient/scripts/sleepproxyclient.py --debug
and post the output.
It might be also a good idea to check your AirPort Extreme configuration...
Interfaces: lo, p4p1
-sendUpdateForInterface: p4p1
-sendUpdateForInterface: IPs: 192.168.178.84, fe80::922b:34ff:fe55:a593
-sendUpdateForInterface: HW-Addr: 90:2b:34:55:a5:93
-discoverSleepProxyForInterface: Interface: p4p1
-discoverSleepProxyForInterface: selected proxy: {'ip': '169.254.173.103', 'name': 'AirPort-K-che.local', 'port': '63051'} with properties: 50-35-10-70\032AirPort\032K\195\188che
-sendUpdateForInterface: Host: plexmediaserver.local
-discoverServices: IPs: 192.168.178.84, fe80::922b:34ff:fe55:a593
-discoverServices: discovered Services: [['_plexmediasvr._tcp', '32400', 'SPC_STATE=sleeping', 'SPC_STATE=sleeping', 'SPC_STATE=sleeping', 'playersModified=1355595477.0', 'machineIdentifier=ec2f018214d80b768100dd7fab748f0480348ae2', 'version=0.9.7.7.339-5ec3b53', 'SPC_STATE=sleeping', 'SPC_STATE=sleeping'], ['_workstation._tcp', '9', 'SPC_STATE=sleeping', 'SPC_STATE=sleeping', 'SPC_STATE=sleeping', 'SPC_STATE=sleeping'], ['_workstation._tcp', '9', ''], ['_smb._tcp', '139', 'SPC_STATE=sleeping', 'SPC_STATE=sleeping', 'SPC_STATE=sleeping', 'SPC_STATE=sleeping']]
-sendUpdateForInterface: request: id 36509
opcode UPDATE
rcode NOERROR
flags
edns 0
eflags
payload 1280
;ZONE
. IN SOA
;PREREQ
;UPDATE
84.178.168.192.in-addr.arpa. 120 IN PTR plexmediaserver.local
plexmediaserver.local 120 IN A 192.168.178.84
3.9.5.a.5.5.e.f.f.f.4.3.b.2.2.9.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. 120 IN PTR plexmediaserver.local
plexmediaserver.local 120 IN AAAA fe80::922b:34ff:fe55:a593
plexmediaserver._plexmediasvr._tcp.local 4500 IN TXT "SPC_STATE=sleeping" "SPC_STATE=sleeping" "SPC_STATE=sleeping" "playersModified=1355595477.0" "machineIdentifier=ec2f018214d80b768100dd7fab748f0480348ae2" "version=0.9.7.7.339-5ec3b53" "SPC_STATE=sleeping" "SPC_STATE=sleeping" "SPC_STATE=sleeping"
_services._dns-sd._udp.local 4500 IN PTR _plexmediasvr._tcp.local
_plexmediasvr._tcp.local 4500 IN PTR plexmediaserver._plexmediasvr._tcp.local
plexmediaserver._plexmediasvr._tcp.local 120 IN SRV 0 0 32400 plexmediaserver.local
plexmediaserver._workstation._tcp.local 4500 IN TXT "SPC_STATE=sleeping" "SPC_STATE=sleeping" "SPC_STATE=sleeping" "SPC_STATE=sleeping" "SPC_STATE=sleeping"
_services._dns-sd._udp.local 4500 IN PTR _workstation._tcp.local
_workstation._tcp.local 4500 IN PTR plexmediaserver._workstation._tcp.local
plexmediaserver._workstation._tcp.local 120 IN SRV 0 0 9 plexmediaserver.local
plexmediaserver._workstation._tcp.local 4500 IN TXT "\000" "SPC_STATE=sleeping"
_services._dns-sd._udp.local 4500 IN PTR _workstation._tcp.local
_workstation._tcp.local 4500 IN PTR plexmediaserver._workstation._tcp.local
plexmediaserver._workstation._tcp.local 120 IN SRV 0 0 9 plexmediaserver.local
plexmediaserver._smb._tcp.local 4500 IN TXT "SPC_STATE=sleeping" "SPC_STATE=sleeping" "SPC_STATE=sleeping" "SPC_STATE=sleeping" "SPC_STATE=sleeping"
_services._dns-sd._udp.local 4500 IN PTR _smb._tcp.local
_smb._tcp.local 4500 IN PTR plexmediaserver._smb._tcp.local
plexmediaserver._smb._tcp.local 120 IN SRV 0 0 139 plexmediaserver.local
;ADDITIONAL
-sendUpdateForInterface: sending update to 169.254.173.103
Unable to register with SleepProxy AirPort-K-che.local (169.254.173.103:63051)
<class 'dns.query.UnexpectedSource'> got a response from ('192.168.178.74', 63051) instead of ('169.254.173.103', 63051)
it works if i check for atv2 port: 52442 instead of 63051.
This looks almost perfect: The sleepproxyclient is working (indicated by "SPC_STATE=sleeping"
txt-records).
The dns.query.UnexpectedSource
exception should be no problem.
Thus it should work - but it seems there is still a problem... strange...
Are you sure the sleepproxyclient is not working? (Sorry - I'm just unable to locate the problem...) Please try the following steps:
sudo service avahi-daemon restart
SPC_STATE=sleeping
txt-records are present: avahi-browse -a --resolve
python /usr/share/sleepproxyclient/scripts/sleepproxyclient.py --debug
SPC_STATE=sleeping
- the registration was successful(Please note: the server-ports are not fixed. The port will/may change when rebooting the device)
Sorry - I accidently closed the issue... Back to the topic: The problem is caused by using the 169.254. address. This problem seems to be mostly APE-specific but should definitely get a fix. I would be glad to get a dump of the SPC-related network traffic (a pcap-file would be great). Does the Airports announce a device-info service? Does it contain the 192... IP (that could be a possible workaround)
A quick update: I am currently working on a fix by using IPv6 instead of IPv4 if possible. It seems avahi is somehow broken because it resolves even IPv6-results to IPv4 addresses...
Hi Andreas,
i am in the office and within the next days i'll have some christmas celebrations with friends, employer and so on...i'll get back to this on saturday/sunday.
I have to test the actual setup with my workaround using the atv2s' IP... Thanks for your help so far!
Nils
ok - could not wait...
i changed line 261 to:
cmd = "avahi-browse --resolve --parsable --no-db-lookup --terminate _sleep-proxy._udp 2>/dev/null | grep '^=;" + interface.rsplit(":")[0] + "'" + " | grep 192.168.178.47"
That is the work around for the above error.
Now im running into another problem! The client goes to sleep and immediately wakes up again. I thought about a problem with USB EHCI XHCI or else but it seems to be the ATV2!
When ATV2 is not powered the client sleeps as expected. When its powered on: it wakes up... Any ideas?
Greets Nils
This seems to be somehow unrelated to this issue but it would be great to get a network dump to be able to investigate this new issue. Without more details I would suggest the AppleTV tried to access one of the services offered by your server.
@xzerogx thanks for reporting this issue. It should be fixed now. It would be great to get some feedback to validate a0e2eed actually resolved your problem. (To resolve your second problem just post here, create a new issue or contact me via mail)
Hi,
im running ubuntu server 12.10 64 bit and installed sleepproxyclient. Calling the the sleepproxyclient.sh returns an error:
my airportexpress has got following IP: 192.168.178.XX The sleepproxyserver publishes a different IP: 169.XXX.....
sleepproxyclient.sh sends data to my AirPortExpress (169.XXX....) and it answers from 192.168.178.XX. This turns into an error and the script breaks.
I used a workaround and use my Apple TV2 as sleepproxyserver. I hardcoded a port-check for the sleepproxy. The ATV2 port differs from the airportexpress port... ATV2 publishes its own correct IP in the usual style: 192.168.178.XX.
So its an issue due to apples airportexpress behaviour publishing the sleepproxy IP...
any thoughts how to handle the situation?
greets
nils