#dns-sd

[jaredsartin]

MDNS, AirPlay, and You

Did a brief presentation today on MDNS, DNS-SD, and AirPlay... Nothing too technical, but showing the start of the inner workings of how AirPlay isn’t too hard to tap into.

MDNS

MDNS is Multicast DNS - a local-network, decentralized, DNS. What this allows for is things like routing http://AppleTV.local calls to the Apple TV on the local network. How? All the devices that want to allow access via this URL broadcast to a known location, saying they will be known as DeviceName.local - When a call needs to be made to DeviceName.local, there is a local resolution of the IP address: “Hey, raise your hand if you are DeviceName!”

DNS-SD

This is similar to the MDNS setup, but instead devices announce capabilities. Devices or applications will again broadcast to a known location on the network and say what they support: HTTP Server, Printer, AirPlay, AirPlayAudio, etc. When something like a printer discovery service or an iPhone needs to find a certain type of service, they ask: “Who here can print things?”

AirPlay

AirPlay servers announce two things, their name on the network and their capabilities. Your phone then jumps through the hoops to find the devices that can accept airplay and their location on the network (IP and Port of the service). Once the resolution has been made, the fin begins. Simple things like playing a video are just a HTTP POST - http://AppleTv.local/play with a payload specifying the URL of the video.

Light Reading

ZeroConf/DNS-SD

Multicast DNS

Unofficial Airplay Protocols

[clanger9]

World’s stupidest AirPlay speaker

Sometimes the designers of electronic equipment make truly baffling design choices. Here is a low cost, neat-looking AirPlay speaker I bought very cheaply online.

The speaker itself works well enough, but is ruined by some bizarre software choices:

It puts itself to sleep after only 5 minutes of idle time - and disappears from your network

You then have to physically press the power button on the back to wake it up again

After you wake it up, it reconnects to wifi and emits a loud, shrill, high-frequency “BEEP”.

Even a quiet “ding” would be superfluous (as there’s a blue light that also indicates wifi connection) and quite why it needs to sleep after only 5 minutes is beyond me, as this renders the convenience of Airplay redundant. I can’t believe it is supposed to work this way. Perhaps it’s running some sort of testing firmware?

Anyway, I think I have eventually found a way to stop the stupid thing dozing off. Pinging it doesn’t work, connecting to the internal web server doesn’t work. The only thing that seems to stop it falling asleep is to stream music at it. So I created a 1 second, silent mp3 file and tried streaming that every minute. Amazingly, this seems to work! An added bonus is that this doesn’t seem to get in the way of normal use i.e. it’ll just ignore the mp3 “pings” if it’s already playing something.

The challenge is to automate this in a script. On the face of it, this should be simple enough. For example, you can use curl to AirPlay an .mp3 file over RTSP  like this:

curl -s -X PUT --data-binary silent.mp3 -H 'Connection: keep-alive' -H 'User-Agent: MediaControl/1.0' -H 'X-Apple-Transition: None' -H 'Content-Type:' -H 'Accept:' -H 'Host:' -H 'Expect:' rtsp://<hostname>.local:<port>

Just replace <hostname> and <port> with those of the speaker. Easy enough? Well, it would be, only the $@*! thing changes the listening port every half hour or so for no apparent reason whatsoever! 

Grr.

So, for my next trick: how on earth to find out what port it is listening on? You can use Bonjour to query it, but unfortunately the command line tool dns-sd is hopeless for scripting purposes.

Eventually I found a way to do it in Python using the pybonjour module. I cobbled together a grotty Python script to return the current port and then piped this into the command line above. It works! Yay! Unfortunately the script is too horrific/embarrassing to post here, but if I ever get around to cleaning it up then I guess I might put it up.

Total waste of time, shoulda bought a proper speaker in the first place. :-P

[thzinc]

As an interesting follow-up to my post about configuring Dynamic Global Hostnames on the Time Capsule, I noticed that the OS X Airport Utility now shows the option to configure the hostname. It seems that once configured on the Time Capsule, the OS X utility allows for further management of the hostname.

[thzinc]

I've been a long-time Dyn user (good ol' free DynDNS at first, but now I'm on Dyn Standard DNS), and for a long time, my router was a dependable Linksys WRT-54G that supported automatic DynDNS updates. But recently, I upgraded to a Time Capsule, and while I really do think the Time Capsule excels in a number of ways, I didn't have a way to use it to make DynDNS updates. Dyn acknowledges that they had a solution using wide-area Bonjour, but that Apple yanked the necessary configuration item, Dynamic Global Hostname, from the Airport Utility. Major bummer.

Set up Dynamic Global Hostname using iOS Airport Utility

Open the Airport Utility app on your iOS device and tap on your device

Tap the Edit button

Tap Advanced

Tap Dynamic Global Hostname

Slide the Global Hostname switch to "ON" and fill in the hostname, username, and password according to the Dyn article:

Tap the Done button on each of the screens until the app asks if you want to update the device with its new settings.

Using the iOS Airport Utility, I've been able to successfully configure my Time Capsule to perform automatic dynamic DNS updates with DynDNS using wide-area Bonjour. I hope other Time Capsule/Airport owners find this useful.