Description of problem: transmission-daemon only listens to IPv4 connection to its xmlrpc control interface on port 9091/tcp. It should also support IPv6. Version-Release number of selected component (if applicable): F12, transmission-1.76-1.fc12.i686 How reproducible: 100% Steps to Reproduce: 1. Attempt to connect to a transmission-daemon using IPv6 using transmission-remote or a web browser. 2. 3. Actual results: The connection fails. Expected results: The connection suceeds. Additional info: transmission-remote does support IPv6, oddly enough. If you use e.g. SSH tunneling to create a listening IPv6 socket on port [::1]:9091 that connects to a remote transmission-daemon (using IPv4), it will work perfectly. So the problem is not with the protocol, it's simply that the daemon process doesn't listen on a IPv6 socket. Another thing I noticed is that the daemon process only listens to IPv6 on the configured peer-port for TCP, and not UD. With IPv4, it does both. I'm seeing traffic from external peers arriving towards the UDP port as well (which then are rejected), so this is perhaps worthy of a separate bug report - let me know if I should open a new one for it. See netstat output from my server (peer-port is 62524): $ sudo netstat --listen -p -n | grep transmission tcp 0 0 0.0.0.0:9091 0.0.0.0:* LISTEN 25108/transmission- tcp 0 0 0.0.0.0:62524 0.0.0.0:* LISTEN 25108/transmission- tcp 0 0 :::62524 :::* LISTEN 25108/transmission- udp 0 0 0.0.0.0:62524 0.0.0.0:* 25108/transmission- Tore
Seems like this issue has already been reported upstream: http://trac.transmissionbt.com/ticket/2236 By the way it also seems like the second issue (no UDP IPv6 listening socket for data traffic) is fixed in 1.80b1. Tore
Tracking a RFE in two different places is not very useful. I will inherit a fix when it is made available upstream.