OpenWrt Forum Archive

Topic: shairport on openwrt

The content of this topic has been archived between 2 Sep 2014 and 25 Apr 2018. Unfortunately there are posts – most likely complete pages – missing.


I need some help... just want to know how to program 2 image files; image1.bin at offset=0x00000000 and image2.bin at offset=0x00420000 to the flash chip using CFE...

i already install CFE... i need to program image2 without erasing image1...

jtonk wrote:

root@OpenWrt:/# opkg files libao
Package libao (1.1.0-1) is installed on root and has the following files:

I found out librt was not installed when I tried alsamixer. Message didn't come back since.

Audio quality is still bad, now I am sure that is the hardware, but I couldn't solve that in the past when I gave MPD a try

ao_alsa WARNING: sample rate 44100 not supported by the hardware, using 48000

I see this messages come by when I start the audio. the difference in sample rate could be the reason for the bad audio quality (cracks, noise, loud, no volume control).

my usb audio hardware is a TP6911:

root@OpenWrt:/# lsusb
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 002: ID 1130:f211 Tenx Technology, Inc. TP6911 Audio Headset

Any ideas, or should I switch to C-media usb audio?

EDIT: definitely is the hardware. music goes faster at a higher pitch

I think any usb audio is fine. Personally, I tried two different usb audio cards and the thing you look for it alsa configuration (/etc/asound.conf). Alsa by default uses 'plug' plugin that supports sample rate conversion. This needs to be configured correctly.

If you need some additional volume control, use alsa 'softvol' plugin.

Google, you will find it there. It is not straight forward though. Would advise to study alsa configuration first. Once you understand all the configuration plugins (dsnoop, plug, softvol, rate, asym) you will solve your problems.

I get following error when trying to run the server:

perl /usr/bin/
* IO::Socket::INET6 not present!     *
* Install this if iTunes won't play. *

Failed to create client object: Daemon not running
Avahi publishing failed! Do you have avahi-publish-service on your PATH? at /usr/bin/ line 97, <DATA> line 23.

is special configuration of the avahi-daemon required?

Found user 'nobody' (UID 65534) and group 'nogroup' (GID 65534).
Successfully dropped root privileges.
avahi-daemon 0.6.30 starting up.
WARNING: No NSS support for mDNS detected, consider installing nss-mdns!
dbus_bus_request_name(): Connection ":1.2" is not allowed to own the service "org.freedesktop.Avahi" due to security policies in the configuration file
WARNING: Failed to contact D-Bus daemon.
avahi-daemon 0.6.30 exiting.

Any ideas?

Got it to work by adding a policy for avahi in the dbus configuration.

(Last edited by stevo on 25 Apr 2011, 15:57)

If anyone is still interested in an all c version, I have one mostly working.  Music plays, but after that I'm not finished with the control messages. (volume, clean shutdown, etc.).
My c is rustier than I thought from when I started, so who knows, probably some memory leaks as well.

The only thing I don't like about it, is that I had to load the RSA public key out of a file.  If anyone has a code snippet of how to get an instance of RSA *, from a char *, please speak up.  It would be nice to compile the key in.

I plan to have it all put up on the github by the weekend.

(Last edited by andywebs on 28 Apr 2011, 11:22)

Sounds awesome, that would save half the memory consumed by shairport.
Looking forward to your release smile

That's VERY interesting news, looking forward to bake a compiled shairport into my build smile

Thanks andywebs.  An all c version will be much preferred.

c baby, way to go andywebs.

Okay, the code is posted up over here

It's missing raw pipes, password support (I couldn't get passwords to work in the perl version for testing), and full ipv6 support.  Ipv6 is almost there, just missing the address to binary conversion that is needed in the apple encrypted handshake.

Basic AirPlay iS working. I'll get back to the issues after my class final if nobody on the github fixes it first.

I wonder if anyone can publish working package for backfire / brcm47xx?

Firtly a massive thanks to the developers of this, it is quite simply brilliant!

I'm having some trouble with the C port and would be very grateful for any advice.  The daemon starts OK and advertises 'shairport' OK but connection fails.  Here is the verbose log output (the same is repeated over and over, about 90MB for one connection!):

LogLevel: 7
AirName: ShairPort
HWID_Hex(12): 00514E3A4070
Avahi/DNS-SD started on PID: 791
Starting connection server: specified server port: 5000
Waiting for clients to connect
...Accepted Client Connection..
In Handle Client
Constructing ipv6 address
Peer IP address: ::ffff:
Peer port      : 5000
Read more data after end of http request. -1 instead of 0
Finished Reading Data:

Finished Reading some data from client
GettingFromBuffer: Content-Length
Not Found
No content, header only
********** RECV  **********
GettingFromBuffer: Apple-Challenge
Not Found

Un-Handled recv:
GettingFromBuffer: CSeq
Not Found
Writing: 66 chars to socket

----Beg Send Response Header----
RTSP/1.0 200 OK
Audio-Jack-Status: connected; type=analog

----Send Response Header----
Read more data after end of http request. -1 instead of 0
Finished Reading Data:

Finished Reading some data from client

Tried this with Debian 5 and Ubuntu 11 with the same result unfortunately.

Many thanks indeed!

I've got a bit further now, looking at this:

int readDataFromClient(int pSock, struct shairbuffer *pClientBuffer)
  char tReadBuf[MAX_SIZE];

  int tRetval = TRUE;
  int tEnd = -1;
  while(tRetval > 0 && tEnd < 0)

Then it seems that TRUE needs to be positive (via the constant defs at the top).  With that changed -vv log output shows it stuck at "Waiting to Read".  From tcpdump iTunes is sending a short reply to the response before it:

----Beg Send Response Header----
RTSP/1.0 200 OK
Apple-Response: UkQ3Ro01+Kk5+5+OMU4G1jjKeaRCVM1e3vBeEwqIrGeWIcH7KT31nwVjCwzv8iCjy5DiID1EH85VUnuZJcZ2yD4Ku7QDw1NrAVMzAeqbwDeyixOseA7r3fGlsNBy5kNlPLeuIpV6PN+uCZ4Ms6T8YxVsb3ov7Rih54FE9l1JwPqTvt2BC1QJhRyAtHjobten9Dumv09997Ay1ByvnQVJmvIwU/4Ac549v4XdabgZ1UyuYe+x2wNdMr5wzBaogV5wYUZCc26VSnhhNAX7Y0pAK2wMNQ5XmMOSRxurMrcBa/z6HvJ3TZ0Atsb3KCYGX99lOU9FBwBbYq0D8KkjITtrYQ
Audio-Jack-Status: connected; type=analog
CSeq: 1

----Send Response Header----
Waiting To Read...

Maybe this is related, a little way above:

GettingFromBuffer: Apple-Challenge
Found 2hDLmZwNBvGuipQ22rhU+g  length: 22
HeaderChallenge: [2hDLmZwNBvGuipQ22rhU+g
] len: 23  sizeFound: 22
Challenge Decode size: 15  expected 16

I tried changing pAddNL to FALSE so that HeaderChallenge is then on one line in the log, but "size:15 expected 16" remains (and it makes no difference).

I updated my branch with some changes.  the maintainer of the original branch added in some ifdef's that redfined TRUE -> -1 (should have been doing that in the first place), and that caused some ruckus in my code.  Everywhere that I was using TRUE for anything other than a == TRUE, I changed it to 1.  I also changed some of the decode_base64 functions to properly handle un-terminated encoded_base64 strings.

All this worked with my iphone4, and ipad2 (on fedora 13, and 14).  I'm not sure what is causing the difference, but the update should fix the size 15 expected 16 issue, which will definitely cause the encrypted handshake to fail.

(Last edited by andywebs on 4 May 2011, 21:20)

Thanks very much indeed!

It's not playing ball for some reason, this is from iTunes 10.x to Linux x86.  Looking at packet captures I noticed a real A.E. is seperating lines 0x0D 0x0A ("\r\n").  Changing the addToShareBuff calls accordingly does make it go further... but then lots of buffer underrun messages and no audio.  Although, iTunes does think it's playing and continues sending the data.

A real A.E. also seems to have the Public: ANNOUNCE... (etc) before the Apple-Response:, although that probably doesn't make any difference.  Although it also advertises more methods (POST and GET) and a Server version (Server: AirTunes/102.2) before the CSeq:.

I'll keep chipping away at it!

First of all, Is the perl version working for you?

I did packet capture comparisons between the perl version and mine to make sure everything looked good.  There is a -k option (int the C version), which makes the HWID constant.  That way I could test both C and Perl with the same HWID.  You would need to add that to the Perl script.  The Apple-Challenge that IOS/iTunes sends always changes, but at least the others stay constant.

I never got an ANNOUNCE from a playing device before I sent the response back.  I only got OPTIONS requests.

Hi Andy, thanks every so much for taking the time to reply to me.

The \r\n was the key - the underuns were due to iffy wireless NIC in my netbook lack of audio was alsa config issue.

Also I added a very simple substr() function to handle the long-hand parameters (--apname= wasn't working).

Not sure on the protocol for these things, but my slightly modified working debian/ubuntu C code (shairport.h and .c) can be downloaded via

I'm getting the odd stutter (every 10 minutes maybe) but that is a job for another day.  This running in Debian 5 x86 uses about 36MB RAM and 15-25% CPU on a 466MHz PIII.


(Last edited by J1mbo on 5 May 2011, 01:00)

Looks like one of my changes was lost somewhere, strcmp being used instead of strncmp(), I'm checking that in to the github instead of the substr version.  I did incorporate your \n -> \r\n fixes.  They were in the perl version, but I removed them during encryption debugging, when it didn't seem to make a difference if the \r was in or not.  I guess iTunes wants them in.

I snagged my wife's apple, and tried the itunes connection, and it did work.  There were a lot of errors.  When I get time to really work on this, I'll packet capture all the traffic, and figure out what's going wrong.

It's awesome that it works at all - but of course, if you can improve it further it would be even better!

Nice work Andy.  I now have your latest version running on my WZR-HP-G300NH with OpenWrt.  I had to strip some INET6 stuff to get it to work on my IPv4 only OpenWrt build.  Here are my usage notes:

AP name is always empty regardless if one is set from the command line or not. I get about one drop out per song which corresponds with "missing frame." flooding the console.  I didn't have this issue with, but I haven't tested it head to head so it could just be a hairtunes issue (I was so excited about shairport.c that I left perl out of my build).  The client in my case was an iPad.  I also had some stutters that seemed to go away when I disconnected all other wireless clients from the AP, but the dropouts still occur.  CPU usage during playback is about 40%.

Overall this seems to be a great start.  Thanks again.

Any idea if a Linksys WRT54G3G would have enough oomph to run the C compiled version of this?

J1mbo wrote:

Any idea if a Linksys WRT54G3G would have enough oomph to run the C compiled version of this?

It should run fine.  You should try it and let us know.

I've seen the name not showing up in a few people's debug dumps.  Sometime next week I'll be setting up a build environment for my openwrt stuff.  Hopefully I can track down the issues then.  I didn't make any changes to hairtunes, other than moving the main function around.  So your droupouts may be due to the work people have been doing in that area of the code.

I would love it if more people jumped in and helped.  Currently on my todo list:
- debug iTunes client oddities.
- don't leave child process orphans. (keep track of child pid's and catch signals)
- Add more command line options / address feature gap between and shairport.c

I came across an old Celeron based appliance (sbc8a806 board basically) so I'm giving this a whirl on that, instead of using a WRT54G.

I have try to build from
and get this error

cc -O2 -Wall hairtunes.c alac.c -o hairtunes  -lssl -lcrypto -lao -lpthread -ldl   -lm -lpthread
make: *** No rule to make target `shairport.c', needed by `shairport'.  Stop.

What could be wrong?

Here is an updated Makefile:


The updated Makefile has a new package, shairport-perl, that has all the perl dependencies and installs  The shairport package now only includes the C-coded shairport.

You can get this as a feed by adding this line to feeds.conf:

src-git jlars git://;master

If you do not yet have a feeds.conf then you can copy feeds.conf.default to feeds.conf.

edit: added branch name to feeds.conf example

(Last edited by jlars on 12 Jul 2011, 02:29)