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.