i've set my ktorrent-2.0.1 under my FC5 to port 9003 or any port that i've set to be open for my machine for both my linux firewall and my router expect 9002 which is used by azureus

i got a fluctuation of speed from 0 to 20 kbps and values inbetween

so i've checked using iptraf and saw that packages are travelling through port 9002 in which azureus is used by azureus. But i've closed azureus, why ktorrent is still using 9002 as its port?

i get slow download compares to azureus...
ktorrent only meets 20% of azureus speed downloading the same torrent

is there a bug in ktorrent that cannot use the port that it is set?


iptraf log file http://fm.myseng.com/ip_traffic-1.log
as u can see in the picture, the traffic is going through port 9002 and not 9003 which is current set in ktorrent

There is a bug in 2.0.1 which can hurt download speeds, this will be fixed tomorrow with the 2.0.2 release.

The fact that you still see traffic on 9002 is just a side effect of the protocol. As long as there are people who think that somebody is still listening on 9002 they will try to connect to you.

thanx for the reply...

looking forward for the 2.0.2 release

i still have slow and fluctuation of download speed. not more than 20% of what azureus can do on same torrent

the following is the log of iptraf

i've notice that when i'm using azureus there is not ICMP dest unrch but when i use ktorrent i have alot of ICMp dest unrch message reported by iptraf as shown below.

and there is still many TCP connection to my ip 192.168.0.3 at port 5xxxx which is not the port that i set in ktorrent. That cant be seen in the screenshot of my 1st post on

Code: Select all

Fri Sep  1 05:26:47 2006; ICMP; eth0; 119 bytes; from 192.168.0.3 to 80.55.144.70; dest unrch (port)
Fri Sep  1 05:26:48 2006; UDP; eth0; 91 bytes; from 67.160.101.175:26538 to 192.168.0.3:9002
Fri Sep  1 05:26:48 2006; ICMP; eth0; 119 bytes; from 192.168.0.3 to 67.160.101.175; dest unrch (port)
Fri Sep  1 05:26:49 2006; UDP; eth0; 71 bytes; from 83.23.121.221:40000 to 192.168.0.3:9002
Fri Sep  1 05:26:49 2006; ICMP; eth0; 99 bytes; from 192.168.0.3 to 83.23.121.221; dest unrch (port)
Fri Sep  1 05:26:50 2006; UDP; eth0; 91 bytes; from 83.23.121.221:40000 to 192.168.0.3:9002
Fri Sep  1 05:26:50 2006; ICMP; eth0; 119 bytes; from 192.168.0.3 to 83.23.121.221; dest unrch (port)
Fri Sep  1 05:26:52 2006; TCP; eth0; 40 bytes; from 192.168.0.3:55290 to 208.39.44.164:80; FIN sent; 63 packets, 12306 bytes, avg flow rate 0.29 kbits/s
Fri Sep  1 05:26:52 2006; TCP; eth0; 40 bytes; from 192.168.0.3:55325 to 208.39.44.164:80; FIN sent; 21 packets, 5621 bytes, avg flow rate 0.14 kbits/s
Fri Sep  1 05:26:52 2006; TCP; eth0; 46 bytes; from 208.39.44.164:80 to 192.168.0.3:55290; FIN acknowleged
Fri Sep  1 05:26:52 2006; TCP; eth0; 46 bytes; from 208.39.44.164:80 to 192.168.0.3:55290; FIN sent; 62 packets, 67858 bytes, avg flow rate 1.60 kbits/s
Fri Sep  1 05:26:52 2006; TCP; eth0; 40 bytes; from 192.168.0.3:55290 to 208.39.44.164:80; FIN acknowleged
Fri Sep  1 05:26:52 2006; TCP; eth0; 46 bytes; from 208.39.44.164:80 to 192.168.0.3:55325; FIN acknowleged
Fri Sep  1 05:26:52 2006; TCP; eth0; 46 bytes; from 208.39.44.164:80 to 192.168.0.3:55325; FIN sent; 20 packets, 16205 bytes, avg flow rate 0.40 kbits/s
Fri Sep  1 05:26:52 2006; TCP; eth0; 40 bytes; from 192.168.0.3:55325 to 208.39.44.164:80; FIN acknowleged
Fri Sep  1 05:26:53 2006; UDP; eth0; 74 bytes; from 192.168.0.3:34952 to 202.188.0.133:53
Fri Sep  1 05:26:53 2006; UDP; eth0; 91 bytes; from 86.68.144.57:55471 to 192.168.0.3:9002
Fri Sep  1 05:26:53 2006; ICMP; eth0; 119 bytes; from 192.168.0.3 to 86.68.144.57; dest unrch (port)
Fri Sep  1 05:26:54 2006; UDP; eth0; 93 bytes; from 83.6.70.252:15832 to 192.168.0.3:9002
Fri Sep  1 05:26:54 2006; ICMP; eth0; 121 bytes; from 192.168.0.3 to 83.6.70.252; dest unrch (port)
Fri Sep  1 05:26:54 2006; UDP; eth0; 192 bytes; from 202.188.0.133:53 to 192.168.0.3:34952
Fri Sep  1 05:26:54 2006; UDP; eth0; 74 bytes; from 192.168.0.3:34952 to 202.188.0.133:53
Fri Sep  1 05:26:54 2006; UDP; eth0; 160 bytes; from 202.188.0.133:53 to 192.168.0.3:34952
Fri Sep  1 05:26:57 2006; UDP; eth0; 91 bytes; from 196.210.56.4:54263 to 192.168.0.3:9002
Fri Sep  1 05:26:57 2006; ICMP; eth0; 119 bytes; from 192.168.0.3 to 196.210.56.4; dest unrch (port)
Fri Sep  1 05:26:58 2006; TCP; eth0; 46 bytes; from 24.129.136.10:12714 to 192.168.0.3:54377; Connection reset; 1 packets, 46 bytes, avg flow rate 0.00 kbits/s; opposite direction 3 packets, 180 bytes; avg flow rate 0.00 kbits/s
Fri Sep  1 05:26:58 2006; UDP; eth0; 232 bytes; from 192.168.0.8:138 to 192.168.0.255:138

laiseng wrote:i still have slow and fluctuation of download speed. not more than 20% of what azureus can do on same torrent

the following is the log of iptraf

i've notice that when i'm using azureus there is not ICMP dest unrch but when i use ktorrent i have alot of ICMp dest unrch message reported by iptraf as shown below.

Maybe AZ caches known hosts, so when you restart AZ it tries to connect to these cached hosts first Which could explain at lot less ICMP destination unreachable packets. Which would also result in faster speeds initially.

and there is still many TCP connection to my ip 192.168.0.3 at port 5xxxx which is not the port that i set in ktorrent. That cant be seen in the screenshot of my 1st post on

This is how TCP works, you have one port where you listen for incoming connections, once a TCP connection has been established another port will be used for the connection.