GNOME Bugzilla – Bug 380972
Cannot connect to iTunes 7 DAAP share
Last modified: 2020-03-17 09:32:07 UTC
+++ This bug was initially created as a clone of Bug #334095 +++ Please describe the problem: ITunes share shows up on the left side. But when I click to access it I get: Cannot login to DAAP share. Failed to Login. I know the share works fine among ITunes Steps to reproduce: 1. Start Banshee 2. Click on an ITunes share 3. Actual results: Failure to login into DAAP message box Expected results: Access to my DAAP share Does this happen every time? Yes
Is the share exported by iTunes 7? If so, there's really no hope of getting it to work. Apple added some nasty new "features" that keeps its shares from being accessed by non-iTunes 7 clients.
Yes it's from iTunes 7 :-( Can you please give me some reference to get information on this problem?
As noted in comment #1, this is a problem for all third-party clients for an iTunes 7 server as well as iTunes < 7 acting as a client. For example this is also a problem with rhythmbox: bug #356627. See: http://www.snorp.net/log/2006/09/12/itunes-7/#comments for more details.
(In reply to comment #1) > Is the share exported by iTunes 7? If so, there's really no hope of getting it > to work. Apple added some nasty new "features" that keeps its shares from being > accessed by non-iTunes 7 clients. By the way, is there really no hope of reverse engineering the newly revised protocol? The comment in http://www.snorp.net/log/2006/09/12/itunes-7/#comments suggests that it would be possible.
Offcourse it's possible, someone just has to do it. I'll gladly do it if someone sponsors me two macs ;-).
The wording in the blog comment was: "This is being worked on, and hopefully a new open specification will be out soon." so I figured that since there haven't been any updates, that it was "worked on", and perhaps abandoned because Apple made it tough to crack.
I'm going to drop this to an enhancement. As far as I'm concerned this is not a defect in our software - it's a defect in Apple's. Someone will crack it eventually, but it's certainly not a priority of this project.
http://www.saveourtunes.com/ are working this
Created attachment 85626 [details] tcpdump: rhythmbox - itunes handshake failing 192.168.10.67 rhythmbox 0.9.8 192.168.10.1 mt-daap server 192.168.10.18 windows itunes 7
Marking low priority as per Aaron's remark in comment #7.
Not much use without the private key but I'm fairly certain that this is what the server uses for encrypting the data: Certificate: Data: Version: 3 (0x2) Serial Number: 33:33:af:06:08:23:af:00:01:af:00:00:09 Signature Algorithm: sha1WithRSAEncryption Issuer: C=US, O=Apple Computer, Inc., OU=Apple Computer Certificate Authority, CN=Apple FairPlay Certificate Authority Validity Not Before: Aug 23 18:22:34 2006 GMT Not After : Aug 22 18:22:34 2011 GMT Subject: C=US, O=Apple Computer, Inc., OU=Apple Computer FairPlay, CN=FP.3333AF060823AF0001AF000009 Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:e5:92:25:bb:c6:83:08:b6:74:5c:78:3b:c8:b6: a6:69:25:dd:85:48:26:81:04:75:e1:a2:64:7c:5b: 6c:05:f3:ed:e8:68:7d:12:65:e0:a0:66:b7:59:52: 79:ef:4b:e4:69:ad:e8:d0:46:c1:a0:07:bf:ea:aa: 35:a4:a7:7b:25:c6:9f:70:f9:95:9a:67:44:1a:38: 54:be:2c:0e:ac:6c:72:2d:db:9e:29:1c:7f:23:a6: bd:3b:23:33:e4:91:9e:ae:d1:68:0c:9e:c2:49:d5: 7f:b2:30:22:c6:99:24:c6:6d:cb:73:68:a7:34:4b: b9:a1:91:5e:0d:39:23:00:a9 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Key Usage: critical Digital Signature, Key Encipherment, Data Encipherment, Key Agreement X509v3 Basic Constraints: critical CA:FALSE X509v3 Subject Key Identifier: 70:59:25:54:24:25:79:62:4E:AE:A6:E1:6F:98:1B:2E:A7:6D:33:78 X509v3 Authority Key Identifier: keyid:D6:9B:6F:87:B8:02:01:D2:A6:60:D9:00:72:4D:28:98:4C:CE:14:20 Signature Algorithm: sha1WithRSAEncryption 24:f5:61:0a:5d:d9:1a:24:7b:34:92:11:1d:1c:d0:20:a7:20: 05:74:e5:de:66:ee:57:cd:5a:6b:c7:1c:02:75:37:48:b1:d2: e2:a7:cb:26:6b:d5:84:f6:17:6c:7e:6d:1e:0b:12:0f:85:04: 50:54:e3:44:e9:6a:d3:a2:14:48:d2:70:91:0b:0d:21:7b:b7: eb:6b:ae:65:0a:e7:09:36:44:10:08:29:7d:43:de:e7:3b:86: 7f:f1:07:35:57:e0:35:34:e6:33:6c:42:b4:db:03:f7:e4:64: 5b:20:f5:05:01:7b:a0:7b:2d:a1:88:19:62:e4:d2:55:03:79: 35:69 -----BEGIN CERTIFICATE----- MIIC4zCCAkygAwIBAgINMzOvBggjrwABrwAACTANBgkqhkiG9w0BAQUFADCBijEL MAkGA1UEBhMCVVMxHTAbBgNVBAoTFEFwcGxlIENvbXB1dGVyLCBJbmMuMS0wKwYD VQQLEyRBcHBsZSBDb21wdXRlciBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxLTArBgNV BAMTJEFwcGxlIEZhaXJQbGF5IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wNjA4 MjMxODIyMzRaFw0xMTA4MjIxODIyMzRaMHYxCzAJBgNVBAYTAlVTMR0wGwYDVQQK ExRBcHBsZSBDb21wdXRlciwgSW5jLjEgMB4GA1UECxMXQXBwbGUgQ29tcHV0ZXIg RmFpclBsYXkxJjAkBgNVBAMTHUZQLjMzMzNBRjA2MDgyM0FGMDAwMUFGMDAwMDA5 MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDlkiW7xoMItnRceDvItqZpJd2F SCaBBHXhomR8W2wF8+3oaH0SZeCgZrdZUnnvS+RprejQRsGgB7/qqjWkp3slxp9w +ZWaZ0QaOFS+LA6sbHIt254pHH8jpr07IzPkkZ6u0WgMnsJJ1X+yMCLGmSTGbctz aKc0S7mhkV4NOSMAqQIDAQABo2AwXjAOBgNVHQ8BAf8EBAMCA7gwDAYDVR0TAQH/ BAIwADAdBgNVHQ4EFgQUcFklVCQleWJOrqbhb5gbLqdtM3gwHwYDVR0jBBgwFoAU 1ptvh7gCAdKmYNkAck0omEzOFCAwDQYJKoZIhvcNAQEFBQADgYEAJPVhCl3ZGiR7 NJIRHRzQIKcgBXTl3mbuV81aa8ccAnU3SLHS4qfLJmvVhPYXbH5tHgsSD4UEUFTj ROlq06IUSNJwkQsNIXu362uuZQrnCTZEEAgpfUPe5zuGf/EHNVfgNTTmM2xCtNsD 9+RkWyD1BQF7oHstoYgZYuTSVQN5NWk= -----END CERTIFICATE-----
Banshee is not under active development anymore and had its last code changes more than three years ago. Its codebase has been archived. Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (or rather transfer the project to GNOME Gitlab, as GNOME Bugzilla is being shut down) if anyone takes the responsibility for active development again. See https://gitlab.gnome.org/Infrastructure/Infrastructure/issues/264 for more info.