Password protection support

[Memphiz]

Hey - its me again :o)

I diddle a bit with your latest code. Is the password protection supposed to work atm? I tried it with my iphone4s running ios 6.1.2 and the music app and once the password protection is enabled it just bumps back to local playback without error. The log gives:

14:48:49 T:2956017664 INFO: AIRTUNES: Accepted IPv4 client on socket 66 14:48:49 T:2956017664 INFO: AIRTUNES: Local: 172.22.26.13 14:48:49 T:2956017664 INFO: AIRTUNES: Remote: 172.22.26.35 14:48:49 T:2956017664 DEBUG: AIRTUNES: Receiving on socket 66 14:48:49 T:2956017664 DEBUG: AIRTUNES: Handled request OPTIONS with URL * 14:48:49 T:2956017664 DEBUG: AIRTUNES: Receiving on socket 66 14:48:49 T:2956017664 INFO: AIRTUNES: Connection closed for socket 66

Thats it.

[juhovh]

Hmm, I added a debug log message for unsuccessful authorization, because that's what your log very much looks like. But I also have iphone4s with ios 6.1.3 and it seems to work more or less fine. There is a small glitch of the phone falling back to local playback for about less than a second before the password authentication alert pops up. Should see if something can be done for that, but otherwise seems to work for me.

Can you confirm that your mdns advertises the password properly? It should have pw=true if password is enabled.

[Memphiz]

Ha! That might be it - i don't even get the password prompt. Thx for the headsup - will try this asap.

[Memphiz]

Adding the pw=true to the zeroconf announcement gets me the password prompt now yay! ... but then it crashs with this stacktrace:

0xb6908025 in __memcpy_ssse3 () at ../sysdeps/i386/i686/multiarch/memcpy-ssse3.S:151 151 ../sysdeps/i386/i686/multiarch/memcpy-ssse3.S: Datei oder Verzeichnis nicht gefunden. in ../sysdeps/i386/i686/multiarch/memcpy-ssse3.S (gdb) bt

0 0xb6908025 in __memcpy_ssse3 () at ../sysdeps/i386/i686/multiarch/memcpy-ssse3.S:151

1 0xb76a7ade in MD5_Update () from /lib/i686/cmov/libcrypto.so.0.9.8

2 0xb3306a93 in digest_get_response (username=0xa381731 "iTunes", realm=0xa381741 "AppleTV", password=0xb0c05d38 "foo",

nonce=0xa381752 "b911fd2dad135425f445dcb808dd639c", method=0xb33183e6 "OPTIONS", uri=0xa38177a "_", response=0xb28ce90b "") at digest.c:54

3 0xb3306eaf in digest_is_valid (our_realm=0xb3318e7e "AppleTV", password=0xb0c05d38 "foo", our_nonce=0xa2ad750 "b911fd2dad135425f445dcb808dd639c",

method=0xb33183e6 "OPTIONS", our_uri=0xa380f70 "_", 
authorization=0x93654d8 "Digest username=\"iTunes\", realm=\"AppleTV\", nonce=\"b911fd2dad135425f445dcb808dd639c\", uri=\"*\", response=\"f87abffbea4b3a7fcc3a6ac8a0fe090f\"") at digest.c:152

4 0xb330d83c in conn_request (ptr=0xa2ad738, request=0xa380f10, response=0xb28ceef8) at raop.c:150

5 0xb330bd1b in httpd_thread (arg=0xb0c05dc0) at httpd.c:284

6 0xb761596e in start_thread (arg=0xb28cfb70) at pthread_create.c:300

7 0xb68c5a4e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130

last line in the log is:

AIRTUNES: Authorization: Digest username="iTunes", realm="AppleTV", nonce="666945251e9a549879feab62860f0007", uri="*", response="3d66e439b76bf7ef4da4f34476ddee73"

[juhovh]

Good to hear you got forward with the zeroconf stuff.

This sounds like a linking issue, libshairplay defines MD5_Update function in src/lib/crypto/, but in your case it gets overridden by OpenSSL's libcrypto MD5_Update instead and crashes because they are not compatible. This shouldn't be an issue if libshairplay is compiled using the provided autotools scripts, because they link statically to the local MD5 implementation. I can't help much more without knowing more about how you're linking your binary.

[Memphiz]

I did:

./autogen.sh ./configure --prefix=/usr make sudo make install

[juhovh]

That sounds weird, what does "ldd /usr/lib/libshairplay.so" or something similar say? This might be a problem in how autotools first compiles crypto as a static lib and then links to it, earlier they were all linked in one step. I'll try to reproduce here by linking to libcrypto.

[Memphiz]

Here is the output of some commands:

http://pastebin.com/jxdUddsg

libshairplay.so is not linked against libcrypto. But xbmc.bin is. Also we are dyloading libshairplay.so (so xbmc is not linked against libshairplay.so!).

Does this make any sense?

[juhovh]

Yes it makes sense, only thing weird there is the libmediaclient, but I guess it's preloaded. I can't seem to reproduce this on OS X but that's probably because it handles linking differently. I'll run some tests on linux and try to find a fix for it on autotools level, I wouldn't want to rename the functions just for this. I'll let you know as soon as I have something to test.

[Memphiz]

/opt/lib/libmediaclient.so is non-existent btw ... no clue how this got into the ldd output then.

[juhovh]

Please try if commit 139d5ef55564514c31f02dd82cef91236c9ff523 fixes this issue.

[Memphiz]

yep thats it :)