well it says ipv6 support is in the new release but i have no luck getting it to work using sixxs.net tracker, hmm is the kde ipv6 bug still present in kde4?

kevku wrote:well it says ipv6 support is in the new release but i have no luck getting it to work using sixxs.net tracker, hmm is the kde ipv6 bug still present in kde4?

Doesn't work here either, I'm on a box with native connectivity and it connects to the tracker using IPv4.

EDIT: Seems to be a KDE4 issue, even Konqueror does not connect to IPv6 webpages. I am using the Kubuntu Gutsy backport packages, maybe they have been compiled without IPv6 support.

Bernhard

Okay, found the problem. It is actually not the fault of KDE4, but of Qt4. Qt4 reorders addresses returned by getaddrinfo() and _always_ prefers IPv4 over IPv6. Since the SixXS tracker is reachable on both addresses but only works on IPv6 you don't get anything useful out of it.

The fix is a single line in Qt4, but recompiling this package takes some time and effort.

a related nice question for the programmers here, does ktorrent support IPv6 DHT already? I have been doing exclusive IPv6 Bittorrent on "the usual" [tm] content with Azureus by adding an IPv4 Filter from 0.0.0.0 to 255.255.255.255 and letting IPv6 DHT take care of finding the 1-10 IPv6 peers for each torrent, but according to my tests this doesn't work with ktorrent.

Tracker based works fine after the Qt4 patch and compiling ktorrent from svn though (3.0beta1 crashed pretty soon).

Bernhard

berni wrote:a related nice question for the programmers here, does ktorrent support IPv6 DHT already? I have been doing exclusive IPv6 Bittorrent on "the usual" [tm] content with Azureus by adding an IPv4 Filter from 0.0.0.0 to 255.255.255.255 and letting IPv6 DHT take care of finding the 1-10 IPv6 peers for each torrent, but according to my tests this doesn't work with ktorrent.

Tracker based works fine after the Qt4 patch and compiling ktorrent from svn though (3.0beta1 crashed pretty soon).

Bernhard

I haven't tested DHT yet with IPv6, but looking at the code, there are some bits which still assume IPv4, so it looks like I will need to do some changes there.

EDIT: there are also some shortcomings in the protocol which assume IPv4, and the latest mainline client, doesn't appeared to have solved these.