GNOME Bugzilla – Bug 402477
DAAP IPv6 support
Last modified: 2018-05-22 12:09:40 UTC
Not that I think this is a great idea all in all, but... From: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=198408 Patch available at: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=198408#c1 My comments were: " The DAAP source only works on local networks, and advertised through mDNS, so I don't think it makes sense to have IPv6 support there. " Feel free to close this as WONTFIX if you don't believe it to be a problem.
This patch doesn't work, the main problem is that the libsoup requests are constructed without [] around the ipv6; but even if they were, libsoup doesn't understand them, it seems.
Created attachment 107332 [details] [review] patch to listen on ipv6 This patch makes the server part listen on the ipv6 :::3689 instead of 0.0.0.0:3689 if possible. The client part still uses ipv4 due to aforementioned problems.
Hmhm, I don't think the fact that DAAP is local and advertised by mDNS means it can't work with IPv6. I got the same problem here on a Debian box. If I disable ipv4 in my avahi configuration (on the serving rhythmbox), other rhythmbox can't see DAAP shares anymore.
Reassigning to libdmapsharing.
I think IPv6 should be supported. I did some experimentation with avahi's IPv6 support, but was unable to get "avahi-browse -a" to display IPv6 services. As far as I can tell, all I should need to do is set "use-ipv6=yes" in avahi-daemon.conf, but this does not seem to work (note, I am not referring to getting DAAP to work yet, only rudimentary avahi services). Once I get avahi and IPv6 sorted out in general, I think the solution is: 1) extend the libdmapsharing API to allow developers to specify whether their server-side application should provide its services on IPv4 or IPv6 (or both). I don't think I like the idea of just trying IPv6 and falling back to IPv4 if IPv6 fails, but I would be interested to see what precendent other applications set. It may make sense to take the time to allow users to limit which interfaces are used as well. 2) Ensure the client-side API interacts with both IPv4 and IPv6 services.
I was able to get Avahi to work with IPv6 and am now looking into what needs to be done with libdmapsharing. Please see also http://mail.gnome.org/archives/rhythmbox-devel/2011-January/msg00001.html
I just pushed some IPv6-related changes to the Git branch LIBDMAPSHARING_2_2. LIBDMAPSHARING_2_2 is the Git branch that works with the current Rhythmbox version. Libdmapsharing now tries to open both IPv4 and IPv6 sockets.
Reopening as I don't see open question.
I'm seeing this with libdmapsharing 2.9.36 and rhythmbox 3.4.1. Rhythmbox outputs the following: (rhythmbox:20993): libdmapsharing-WARNING **: Failed to resolve service 'User Name's Music' of type '_daap._tcp' in domain 'local': Timeout reached while on the same system: $ avahi-browse -c _daap._tcp -r + robots IPv6 User Name's Music iTunes Audio Access local = robots IPv6 User Name's Music iTunes Audio Access local hostname = [foo.local] address = [fdce:7fbe:f572:9c6e:f021:21ff:fe23:583d] port = [3689] txt = ["Password=false"]
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/libdmapsharing/issues/2.