I have posted in Forum about Gnucleus the info.
THIS IS A MAJOR THREAT FOR GNUTELLA!!!
If you are using Morpheus aka gnucleus 1.6.0.0 and are satisfied with it DO NOT UPGRADE to morpheus/gnucleus or any clone.
Versions 1.7.x are bringing bad supernodes and usefull complex re-research feature.
Versions 1.8.x (morpheus called 1.9.x but is 1.8.2), last being 1.8.4.9 brings cool ultrapeer mode and great hashing feature(read later how great).

posted in forum about Gnucleus

Faulty HASH !!!!
You may have noticed that Gnucleus haven't been updated for two month.

You may have noticed that Morpheus uses a pure copy of Gucleus engine.

There are new clients like AtomWire using Gnucleus renamed code (even functions) compiled as .NET (Gnucleus is done for that either).

You also know that when newer Gnutella (like Gnucleus, Morpheus, Bearshare, Limewire or even GTK-Gnutella...) clients get hashed files they use the hashes to validate the downloading file.

You may also have noticed that Morpheus+Gnucleus=50% of gnutella network.

Now what if from the beginning there was a bug in the hashing system of Gnucleus when getting the hash for shared files ready to upload ?

Well, this is the case, and it is worse than anyone can imagine : the bug consists in having something around getting half of the shared files (one every two) with wrong hash result. Somehow if you share only one file, this may not happen. Even worse, when this happens, the wrong hashes may be a replication of well hashed shared files. This is, however not a rule, so when looking at gnuhashes.ini you may not get what is wrong if you do not have a hashing tool. The fact that you may have msleading hashes with misleading tables may result in wrong requests, blocked downloads and this may happen for one half of half of the gnutella network. Imagine the problem the Gnutella network is facing. If you want to use Gnucleus, or Morpheus (stay away from new clones) and especially if you want to share files you may have to get Morpheus 1.6.0.0 or last Gnucleus 1.6.X version. If you are compiling the 1.6.X source, do not forget to apply the re-research patch. You may also have to delete from partials the .nfo files and rename the files without hash1 search info. No more ultrapeers but you may see how fast your downloads and uploads are working again.

For those who compile the source, put the re-research feature in GnudownloadShell.cpp of 1.6.X version of Gnucleus:

if(!StillHope)
{
// Added re-research by mort4
m_Active = false;
m_Retry = true;
if (!m_Cooling)
m_Cooling = 300;
else
m_Cooling--;
m_Searching = 0;
m_Dead = false;
if (!m_Cooling)
Start();

// end Added re-research by mort4 and remove next 2
// m_ReasonDead = "Unable to connect";
// m_pComm->TransferMessage(DOWNLOAD_UPDATE, (WPARAM) this);
}
}
}

This is the only fix until Gnucleus developper gets on it again.

Some people say they can connect to Morphus/Gnucleus better with Shareaza than with any other.

1st problem : Gnucleus 1.8.2 used in Morheus 1.9.x does have a handshake bug corrected in 1.8.3/1.8.4. Gnucleus 1.8.4 may handle this bug well.
2nd problem : Gnucleus 1.8.x and so Morpheus 1.9.x are computing bad hash results for half of the files.

The 1st as the 2nd problem can be handled by any client aware of the bugs.
Especially the 2nd one may be handled by not considering hash results (even searches) from gnucleus (wait for the first version that may solve it) and morpheus and getting files the old way. Those bugs do not affect uploading hashed files to Gnucleus or Morpheus which do handle them well.

This may only disable downloading or may get error messages on requests. I am just looking at what's wrong in gnucleus and it seems there is some buffer problem on hashing data which is well computed (even if you may have noticed how slow). Both problems may be quite easily solved.

... and I added some other features (more intelligent blocking IP) and multiple choice for downloading and also working on a DoS massive conter-strike (getting info on DoS). It seems other are working on the latter on Gnucleus.

1st reason. I nearly forgot about the bug in Morphus 1.6.0.0 which was translated from the short living Gnucleus 1.6.0 (upgraded to 1.6.1) which had a bug when assembling partial files (I don't remember if it was wrong uploading info or bad partial file handling from multi-source downloading).

2nd reason. Overpeer et al. This is real. If you get version 1.8.4 of Gnucleus, don't forget to use the blocking feature against their fixed IP. I also added every fake request IP (those like my_request.asf) and fake file IP (quite empty media files mainly with good headers). However, one may be carefull as spoofing is also used to get you out of IP sharing real files. Some random pinging may reveal the truth (this has to be implemented).