Hi,

Thanks for the work on ktorrent. I've never used BitTorrent before, and ktorrent has been very easy to use.

I have a NetGear DG834G ADSL modem/router, which has UPnP enabled (I checked this). My computer is connected to the DG834G by Ethernet. Nothing else is connected to the network. My computer runs Fedora Core 4, and I turned off the firewall on it just to make sure that that wasn't a problem.

I loaded the UPnP plugin in ktorrent (1.2), and it doesn't show any peers. When I load the logging plugin and do a "Rescan", the log shows:

Trying to find UPnP devices on the local network
Invalid URL
Invalid URL

I ran Ethereal to see what was going on, and there were 3 packets that seemed to be relevant - SSDP protocol.
The first is sent from my machine to 239.255.255.250 (a broadcast address?) with "M-SEARCH * HTTP/1.1".
The next two are replies from the router (possibly corresponding to the two "Invalid URL"s above?). They seem to be telling ktorrent to go to "http://192.168.107.1:49153/gateway.xml".

I can fetch that URL manually, but ktorrent doesn't seem to fetch it. (Nothing in the packet capture). Presumably because it thinks it is an "invalid URL". Is it to do with the "\r\n" terminator? Does ktorrent insist on "\n" or something?

Anyway, I have saved both the packets from the capture, and the .xml file, here:

http://david.dw-perspective.org.uk/tmp/capture.pcap
http://david.dw-perspective.org.uk/tmp/gateway.xml

I hope that this helps. If I can do anything else, let me know. (I seem to be able to fetch the file I actually want without UPnP working anyway!).

By the way, your forum seems to have a bot called "!Anaka!" who posts adverts for Casinos.

David

This is allready fixed in trunk, you can try the latest SVN version. It should work in there.

If you don't want to do that, you can also create your own routers file ~/.kde/share/apps/ktorrent/routers

In your ethereal trace, the second packet contains two variables LOCATION and SERVER, if you put the values in the routers file like this : (first SERVER then LOCATION)

Linux/2.4.17_mvl21-malta-mips_fp_le, UPnP/1.0, Intel SDK for UPnP devices /1.
http://192.168.107.1:49153/gateway.xml

Then KT should be able to forward your ports.

Thanks for the tip. As it seems to download fine without UPnP, I'll just wait until the next release.

By the way, I found RPMs exist for ktorrent in the Dries repository, which isn't listed on your download page. Also, the download page doesn't give links to the spec files either which are the source for creation of the RPMs. Some people will want to rebuild the RPMs themselves using the spec files and obtaining the source directly (so that they can be more sure of the integrity of the binary).

Keep up the good work!

David

davidanderson wrote:Thanks for the tip. As it seems to download fine without UPnP, I'll just wait until the next release.

You will not get incoming connections, which can cost you some speed.

By the way, I found RPMs exist for ktorrent in the Dries repository, which isn't listed on your download page. Also, the download page doesn't give links to the spec files either which are the source for creation of the RPMs. Some people will want to rebuild the RPMs themselves using the spec files and obtaining the source directly (so that they can be more sure of the integrity of the binary).

I don't run an RPM based distro, I don't even know anything on spec files. People will have to make do with the source code or contributed binaries.

George wrote:You will not get incoming connections, which can cost you some speed.

You will.
Seeing the fact that two firewalled peer can't initiate a connection to each other and that when one of two peers have to be NAT enabled to get a connection build up, you end up with two things when you're firewalled:

1) all the peers in the swarm that are also firewalled will not be there for you. (and you can't be there for them, off course)
So, less connectable peers and therefore less sources/speed for you in the situation where both peers are firewalled.

2) In the situation where only one of two peers is firewalled, you'll connect slower to all peers that come latter into the swarm than.
This is because the announce response from the tracker that goes to a newly peer (one that goes fresh into the swarm) doesn't include you as a peer when you're firewalled and already in the swarm.

This is logic because a peer can only initiate a connection to a non-firewalled peer, not the other way around. (you're only not in the response to save bandwidth)
Seeing that bittorrent doesn't has a push command, a firewalled peer which already is in the swarm, is bound to wait until the next announce comes by for being able to make a connection to a non-firewalled peer.

So, when you're firewalled & already in the swarm and another non-firewalled peer comes into the swarm (a potential source, be it a seed or be it a leech), you have to wait until your client makes an announce so that you client get informed by a new peer and can initiate the connection. So in firewalled state you always have to wait max 30 minutes until you are informed there's a non-firewalled source in the swarm where it could have been instantly.

Offcouse with PEX (protocol exchange) this second point will be reduced somehow, but it will get you lower speeds than when not firewalled.