Which Interfaces support Bonjour Sleep Proxy?

Somewhere along this 10.6 to 10.8 time frame I got an Apple TV and learned that this device can perform the role of a Bonjour Sleep Proxy Server.  So I began to see if I could get that working but haven't had much success.

First step was to learn which Apple products can support Sleep Proxy on client side.  I found that the feature is controlled by mDNSResponder daemon.  You can run this command to have it dump out some needed info to /var/log/system.log:

Look for section at very end that lists Network Interfaces:

The interesting part are the symbols.  If you see a sun, as above, it says that this Network Interface supports Wake on Demand and that its detected a Sleep Proxy on your network.  If its a sun but with clear center then it means this Network Interface supports Wake on Demand but no Sleep Proxy was seen on network.  If there is no sun symbol then it means mDNSResponder thinks your interface does not support Wake on Demand.

I've found that all Wifi interfaces claim Wake on Demand is not supported inside mDNSResponder; regardless of what your System Information window says or the fact that Apple swears it works on Wifi.  I've checked on an iMac and a Macbook Air.

I also found enabling addition logging from mDNSResponder is helpful in pinpointing where things are going wrong:

sudo killall -USR1 mDNSResponder
sudo syslog -c mDNSResponder en

Perform a forced sleep and then after waking up, search for the phrase WOMP (Wake on Magic Packet).

If it thinks its not supported then it will say "no WOMP".

If your motivated enough, it is the NetWakeInterface() function that (mis)detects if the interface supports WOMP (Wake on Magic Packet).  You could hack it to see if this is "en0" or "en1" and force to supports regardless of kernel flags.  The following is piece of code that needs modification:

Take care to not say ever device supports it.

That change alone is probably not enough since; as stated above; waking from Wifi usually takes several packet sends but it looks like Sleep Proxy Servers only send 2 packets.   It would be difficult to fix your Apple TV or Airport.  If you  have an Apple computer you always leave running, you can tell it to support being a Sleep  Proxy Server and hack up SendWakeup() to send multiple times.

For now, I'm sticking with my Ethernet port and disabling my Wifi ports.

Sleep Proxy Clients in NIC

Some newer Mac's support a mini-Sleep Proxy in the NIC so the computer doesn't need to wake up to refresh th advertised services.   If you enable above -USR1 logging option and sleep, you can grep for this support:

Detecting Sleep Proxy Server Registration

Sleep Proxy Server Interactions

To debug problems with a Sleep Proxy Server, its helpful to understand how they work.  A Sleep Proxy Server must advertise a _sleep-proxy._udp service.  You can detect this with the dns-sd command and Sleep Proxy Clients perform the same query right before going to sleep:

Local Sleep Proxy Server

If you have a spare Mac; besides the one your trying to be a Sleep Proxy Client and wake from sleep; you can tell its mDNSResponder daemon to be a Sleep Proxy Server. This gives you the ability to enable logging and better debug your issues. This is enabled by editing /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist and -OfferSleepProxyService 10 to the start options.  Find the sections that looks similar to this and add the missing lines:

I've used this and the killall -USR1 to log timestamps of when server starts responding to ARP requests and when it stops responding to them.  Seems it stops responding to them at roughly 75 minutes after the last Dynamic DNS Update message was sent from Client.

Back To My Mac

Apple has an iCloud service called Back To My Mac which lets you connect to your computer from a remote location.  I believe its somewhat meant to work with sleeping Macs as well.  As best I understand, the sleeping computer's mDNSResponder must perodically wake to refresh its registered services with both any local Sleep Proxy Server and to the iCloud Back To My Mac Servers but that a local Sleep Proxy Server is always required to send the magic packets to wake the sleeping Mac.

To ssh from a command line from a remote location, you'll need to find the ID given to your iCloud account by running dns-sd command:

The above tells you the iCloud address for this account is 1245678.members.btmm.icloud.com.  If you wanted to look for computer names registered with ssh service for that account you can run dns-sd -B _ssh 12345678.members.btmm.icloud.com.  If you know the name of your computer (convert spaces to dashes and drop any other special character) you can ssh to it with ssh username@my-imac.12345678.members.btmm.icloud.com.

If I look at my router's port forwarding table, I see that ports related to Back To My Mac are being registered multiple times and on NAT boxes you can only forward 1 port 1 time.  If your router only supports UPNP registration then I think only 1 computer can register to BTMM at a time.  If it uses NAT-PMP then that supports a way for clients to request a port # but a different one be returned.  When you look at output on your router from NAT-PMP registration you should see unrelated IP addresses and ports 4500 and 5353 mapped to unrelated ports on:

If your having issues with BTMM, look at your port forwards and verify that you computer in question is registered and has a non-conflicting port value on the WAN side.

Lose of Services During Sleep

Using both an Apple TV 2 and an Macbook Air as a Sleep Proxy Server, I notice that over time the sleeping Mac's services slowly stop showing up in Bonjour Browser for the local network.  When using the Apple TV 2, the services also disappear from Back To My Mac/iCloud network most the time.  Using Macbook Air, the BTMM network seems to keep advertising the services longer.  I can't quite nail down exact timing of when the services are lost.

I've seen reports that BTMM works more reliably for people in waking their Mac's up which kinda aligns with above.  But on the other hand, my experience tells me that its the sleep proxy that wakes up the Mac in all cases and once it loses knowledge of a service for sleeping Mac, it also stops sending Magic Packets to wake the Mac.

If your sleeping Mac doesn't wake up in a timely fashion, the services will expire and be removed.  You can use the following command to get a feel for what time intervals mDNSResponder is waking up your Mac:

From above log, you can tell its sometimes setting to wake up in about 1 hour and 45 minutes and other times in about 1 hour and you can tell the timestamps correspond roughly to those time periods.  mDNSResponder likes to wake up 10% early compared to Time To Live values its tracking.  Those values above roughly correspond with TTL of 75 minutes and 120 minutes.

So it seems my Mac is attempting to do the right thing and wake up occasional to refresh its advertised services.  Its a little suspicious to me that its using the 6466 values.  I've done some initial investigation into what a Sleep Proxy Client does (mostly by browsing this python script) when it goes to sleep to see how long the Sleep Proxy Server will wait before timing out the client's services.

The server not responding to ARP's after 75 minutes; which is same time period as Time To Live in Dynamic DNS Update for the services.   Here is a small snippet of decoding packet from wireshark:

Changing to Short TTL

Search for _SendSPSRegistration: to find begining of this function and then search for 7200. It is the one that looks like this:

000000010003f380        movq    -1504(%rbp), %rax
000000010003f387        movw    $2, 4(%rax)
000000010003f38d        movq    -1504(%rbp), %rax
000000010003f394        movw    $4, 6(%rax)
000000010003f39a        movq    -1504(%rbp), %rax
000000010003f3a1        movl    $7200, 8(%rax)

So take note of the 0x3f3a1 value (ignore the 1 set up higher) and use your favorite binary editor to change the value. Here is one way:

Large Number of Services