gtk-gnutella 0.93 released. Please upgrade :)
 

Hello,

version 0.93 was released.
As usual, you should upgrade :)

More information on http://gtk-gnutella.sf.net

Thanks for the upgrade, but,
"As soon as a download is started, can be used as an alternate source for others even though the download is not completed yet."
What if I don't want to share that file back out, just my own hand picked list?
"When a mismatch happens during downloading the file can now be automatically removed and restarted again"
What if I have 600MB of a file and it decides there is a "mis match" and starts over, can't you simply save this with some sort of tag like (1) (2) like I have seen around
"Sends out alternate locations which should not be tried"
What? Why not just list all the bad addresses on the net and really go crazy.
"Won't send full headers when short on bandwith"
Are your headers getting that big? Try a shorter "Server: Gtk-Gnutella (date, make, model, serial number, kitchen sink)"

Then disable partial file sharing in you configuration.
The remove on mismatch feature is only a temporarly solution. Currently tigertree implementation is on its way, which should make this feature unncessary because it will be able to detect where it did go wrong and only redownload that part.
These locations there are listed are send because they might first have been send in an working alternate locations list. There is nothing wrong with these servents, just that they might not be sharing that file anymore or are offline.
:) It isn't the Server: header which is that big. gnutella clients send out alternate locations also via HTTP headers, queue information has also an HTTP header. When you are short on bandwith the number of alternate locations send is less.
So when you are short on bandwith, only the necessary parts for each header (if that header is required at all) is sent out.

Could there be a bug in 0.93? (80/tcp inviting problem)
 

I've noticed lately, that although I have never run any gnutella servant on port 80/tcp, other gnutella servants, especially LimeWire ones, has started to knock on 80/tcp port where Apache is listening for my other uses.

gtk-gnutella has always been listening and using the default port 6346/tcp on my machines and noone else has had this IP-address for over two years now.

This didn't happen before, so either gtk-gnutella, LimeWire or gnet-protocol has changed during last month.

I also asked this on LimeWire forum.

Somehow it would seem to be a problem in gtk-gnutella though, as there is also rather old versions of LimeWire doing this, and it didn't happen before couple of months ago when I used to run older version of gtk-gnutella regularly.

When gtk-gnutella is quit, the knocks to 80/tcp becomes soon more seldom and eventually stops. When gtk-gnutella is started again, the knocks start soon again on 80/tcp.

There is several thousands of these kind of lines already in the httpd-logs: (now lately I've turned the logging off from /uri-red/N2R, but they are still there if I enable it.)

[07/Jan/2004:15:40:28 +0200] (148.61.253.127 148.61.253.127) - - -> "GET /uri-res/N2R?urn:sha1:4R4VM2DXDTEMWEW3BIU6TEH42XXXXXXX HTTP/1.1" - <- 404 1045B 0s "LimeWire/3.6.10" "-" 1014

[07/Jan/2004:15:47:39 +0200] (213.54.113.112 213.54.113.112) - - -> "GET /uri-res/N2R?urn:sha1:4R4VM2DXDTEMWEW3BIU6TEH42XXXXXXX HTTP/1.1" - <- 404 1045B 0s "LimeWire/3.6.8 (Pro)" "-" 1016

[07/Jan/2004:15:58:09 +0200] (68.4.59.73 68.4.59.73) - - -> "GET /uri-res/N2R?urn:sha1:4R4VM2DXDTEMWEW3BIU6TEH42XXXXXXX HTTP/1.1" - <- 404 1045B 0s "LimeWire(Acquisition)/100.2" "-" 1018

[07/Jan/2004:15:58:18 +0200] (24.132.241.16 24.132.241.16) - - -> "GET /uri-res/N2R?urn:sha1:4R4VM2DXDTEMWEW3BIU6TEH42XXXXXXX HTTP/1.1" - <- 404 1045B 0s "LimeWire/3.6.14" "-" 1011

07/Jan/2004:16:12:32 +0200] (211.91.191.30 211.91.191.30) - - -> "GET /uri-res/N2R?urn:sha1:4R4VM2DXDTEMWEW3BIU6TEH42XXXXXXX HTTP/1.1" - <- 404 1045B 0s "LimeWire/3.6.15 (Pro)" "-" 1017

[07/Jan/2004:16:19:11 +0200] (148.233.159.24 148.233.159.24) 201.128.98.64 - ->
"GET /uri-res/N2R?urn:sha1:4R4VM2DXDTEMWEW3BIU6TEH42XXXXXXX HTTP/1.1" - <- 404 1045B 0s "LimeWire/3.6.15" "-" 1012

[07/Jan/2004:16:22:18 +0200] (68.4.59.73 68.4.59.73) - - -> "GET /uri-res/N2R?urn:sha1:4R4VM2DXDTEMWEW3BIU6TEH42XXXXXXX HTTP/1.1" - <- 404 1045B 0s "LimeWire(Acquisition)/100.2" "-" 1018

Short story: There is a client which is forwarding wrong alternate locations. It seems to add port 80 instead of 6346 as the default port to the alternate locations.
Not gtk-gnutella's fault. And not that much that can be done about it. Except for fixing the faulty client.

I'm glad someone else was experencing that. I figured that it was probably a poorly written client out there--but I couldn't find anyone else with the same problem

This may not be the right place to ask, but how this "forwarding alternate locations" thing works?

Is it so essential feature, that if gtk-gnutella and other clients would refuse to believe forwarded alternate locations to ports 0-1024 are valid, but must be bogus, it would make gnet worse?

Because I see a security risk here, if crackers start to use this to cause DDOS to http, ftp, *- servers; they will get more reasons to ban gnutella-clients on hosts of ISPs' customers. There is also other instances which would like to harm gnet.

And for Apache-users, putting these two lines to /etc/httpd/conf/httpd.conf helps (but won't solve the problem):
SetEnvIf Request_URI /uri-res/N2R gnet-request
CustomLog logs/access_log combined env=!gnet-request

See http://httpd.apache.org/docs/mod/mod_log_config.html

There are 2 headers at work here. One header contains a list of all possible alternate locations. Another header contains a list of alternet locations which should not be used because they are bogus.

It is perfectly valid to run a gnutella client on any port you want. It should also be possible to run gnutella from behind a proxy. The last thing is AFAIK not yet correctly supported by gtk-gnutella. However, with banning ports in the lower range it is likely to also ban valid alternate locations.

I think it is essential that clients implement both X-Alt and X-Nalt, (X-Nalt are the locations which are known to be bogus).
Gtk-gnutella emits both, but currently doesn't use the X-Nalt part itself yet.

So, If one wants to flood someone's HTTP server logs with "GET /uri-res/N2R/" requests, one is able just make bogus X-Alt (Alternate locations) replies with hits of most common requested files and there is nothing anyone can do about it except find the IP-addresses of those hosts and ban them from gnet?

Yet if the servents get X-Nalt information from some other servants telling victim.host.com:80 is bogus, they still have to decide which one to believe. If they blindly trust X-Nalt fields, then one can use that to cause DoS to valid gnet-servants also.

I think there is a risk someone starts to use gnet for DDOS with this feature.

DOS attacks (like when windows became a front for DOS, it's a joke) are probably going to be against one IP so you could probably DOS at about the same rate as if you just DOS'ed directly.