[Stulle]

Riso, might be a typo. where did you see it? You are currently just confusing me. Try to be a little more specific when posting what you tested. Which clients were involved at which side, what did you expect, what happened?

[xilolee]

The principal problem is that the releaser didn't send the complete hashset (masterhash), the hashes of each part.
It is a huge link (29202 bytes = 28,52 kB).
The masterhash wasn't in the forum ed2k link.
We established that the problem isn't on official 0.50a and isn't on extreme 8.1, because they sent the aich hashset.

This post has been edited by xilolee: 28 April 2012 - 03:18 PM

[Stulle]

So where is it? It sounds like you are suggesting it is caused by a specific mod. If that mod is in question please make a specific test which is entirely under your control and only uses creator-published, untainted binaries.

[xilolee]

Probably the problem doesn't exist...
Without masterhash, emule should receive the masterhash from 10 emules (reading docs) that are complete sources, but at that time there wasn't complete sources (neither the releaser because it used HideOs, I think).
In this case, it was a normal behaviour (the failed requests).

Anyway, later we'll also try the morph mod or the mod that the releaser should have (I am not sure it is the morph mod).

The abnormal behaviour is that of those amule 2.2.6 mods that sends few corrupted kiloBytes, but it seems it is an old story already known, reading changelogs.

Quote

-----------------------
- Feb, 09. 2007 -
-----------------------
Ornis: added Farsi translation [translated by Mory Abdi & Ali Mojarad]
.: The calculation of credits given for the first 9MB (less than one part) has been changed slightly to decrease the reward for clients who upload less than one part

This post has been edited by xilolee: 28 April 2012 - 05:19 PM

[tHeWiZaRdOfDoS]

No, that's a change to counter what leecher mods did for years: upload 1MB to as much clients as possible. That was to get the most out of your upload as you got the biggest boost (IIRC it was near 3x) from the first MB.
AFAIR 0.50 introduced some new mechanism for AICH hashes (i.e. they are sent along the file requests answers or something similar) so you don't actually have to ask for it but just evaluate the data you get anyways.

[Eulero]

xilolee, on 28 April 2012 - 05:59 PM, said:

Probably the problem doesn't exist...
Without masterhash, emule should receive the masterhash from 10 emules (reading docs) that are complete sources, but at that time there wasn't complete sources

i'm confused ....

According to the doc (http://www.emule-pro...9&rm=show_topic) :

If no Root Hash is provided in the link eMule has to trust the Root Hash, which the sources for the file send. It only trusts a Root Hash if at least 10 different sources send the same value and if at least 92% of all sources agree to this value.


In my case, Root Hash (h=...) was provided in the eD2K link, so i've root hash + all block hashes, in other words the entire tree called AICH Hashset.

Right?

This post has been edited by Eulero: 28 April 2012 - 04:46 PM

[tHeWiZaRdOfDoS]

Root Hash != Block Hashes
Once again: the block hashes create the root hash but there is NO WAY to retrieve the block hashes from the root hash.
You would have to use the "add full hashset" option for that but IIRC that'd only add the md4 part hashes...

[xilolee]

Eulero, on 28 April 2012 - 06:43 PM, said:

i'm confused ....

According to the doc (http://www.emule-pro...9&rm=show_topic) :

If no Root Hash is provided in the link eMule has to trust the Root Hash, which the sources for the file send. It only trusts a Root Hash if at least 10 different sources send the same value and if at least 92% of all sources agree to this value.


In my case, Root Hash (h=...) was provided in the eD2K link, so i've root hash + all block hashes, in other words the entire tree called AICH Hashset.

Right?

From what i've understood analyzing this problem (and if i've understood correctly ), the MasterHash, hashes of each part, should be this:

ed2k://|file|<file name>|<file size>|<file hash>|p=FirstPartHash:SecondPartHash:NthPartHash|h=<Root Hash>|/

For example like this (free file taken from emule-project content database):

ed2k://|file|Toehider.-.Children.Of.The.Sun.(EP).[contentdb.emule-project.net].zip|32590383|84D62818D1DE0B45A3989FAD90D8D82D|p=F1AEDC7DEFF634B9B96FDC823C022777:D35AE2DEEC654E2BEBF4C59F365B9490:872909B04A49B889FD624F70C59BE76E:B87D878375337DF01A5EE11682A1DD89|h=AF6HKMKSP7Y7CFHSUKI7FT4NDFI4QRDX|/

This post has been edited by xilolee: 28 April 2012 - 05:04 PM

[Eulero]

xilolee, on 28 April 2012 - 06:58 PM, said:

From what i've understood analyzing this problem (and if i've understood correctly ), the MasterHash, hashes of each part, should be this:

ed2k://|file|<file name>|<file size>|<file hash>|p=FirstPartHash:SecondPartHash:NthPartHash|h=<Root Hash>|/

OK, then the MasterHash and the Root Hash are different, right?

xilolee, on 28 April 2012 - 05:59 PM, said:

Without masterhash Root Hash, emule should receive the masterhash Root Hash from 10 emules (reading docs) that are complete sources, but at that time there wasn't complete sources (neither the releaser because it used HideOs, I think).

I just have the root hash provided with eD2K link, so this is not my case.

This post has been edited by Eulero: 28 April 2012 - 05:19 PM

[xilolee]

If you tick/check/select the option "add complete hashset" for that file, you'll see what that ***I think*** is the MasterHash (for that file)...
If this is exact, maybe docs should be corrected...
But up to this moment, I'm confused too!

This post has been edited by xilolee: 28 April 2012 - 05:26 PM

[Riso64Bit]

xilolee, on 28 April 2012 - 07:24 PM, said:

If you tick/check/select the option "add complete hashset" for that file, you'll see what that ***I think*** is the MasterHash (for that file)...
If this is exact, maybe docs should be corrected...
But up to this moment, I'm confused too!

but if I have the FULL link whit MasterHash & "complete Hashset" and i receive a bad part WHY emule try to ask other clients? shouldn't be to delete the bad chunk received or try to recover via AICH?

[xilolee]

Because: requested Hash differs from Masterhash for SomeFile

1) Our clients request a (corrupted) part to the fake amule 2.2.6 client
2) It sends us the corrupted (and very incomplete, about 20-30 kB) part
3) Other clients CAN NOT provide us the FAKE Masterhash (and the fake part hash), although they HAVE GOT the CORRECT Masterhash
4) Our clients start asking to EVERY client for the FAKE masterhash, but nobody has got the fake Masterhash (neither the fake amule client)
5) And the flood in verbose log starts...

Conclusion: there aren't buggy clients, this behavior has been specifically designed
In other words, emule, and its mods, works as always in the right manner.
So, yes, it is a normal behaviour for emule.
It is not a normal behavior that of the fake amule client (or, it is normal for who designed it in that manner, but only for him)

(this time maybe it is the correct answer )

This post has been edited by xilolee: 29 April 2012 - 12:35 AM

[xilolee]

Re-downloading the file, this time with hundreds of complete sources:

Quote

04/05/2012 3.23.27: Download session started. User: 62.211.218.157 'http://emule-project.net' (aMule v2.2.6,OnQueue/Uploading/None) in SetDownloadState(). New State: 0

04/05/2012 3.34.13: Removing client from upload list: Completed transfer Client: 62.211.218.157 'http://emule-project.net' (aMule v2.2.6,Downloading/Uploading/None) Transferred: 15:17 min SessionUp: 3.32 MB QueueSessionPayload: 3.31 MB In buffer: 210.00 KB Req blocks: 1 File: SomeFile

04/05/2012 3.35.41: Requesting AICH Hash (HighId) from client FirstClient

04/05/2012 3.35.41: Requesting AICH Hash (HighId) from client SecondClient

04/05/2012 3.35.41: AICH Request failed, Trying to ask another client (file SomeFile, Part: 822, FirstClient)

04/05/2012 3.35.43: AICH Packet Answer: Succeeded to read and validate received recoverydata

04/05/2012 3.35.43: Found and marked 184320 recorded bytes of 184320 as corrupted in the CorruptionBlackBox records
(18 times)

04/05/2012 3.35.43: Found and marked 143360 recorded bytes of 143360 as corrupted in the CorruptionBlackBox records

04/05/2012 3.35.43: CorruptionBlackBox: Banning: Found client which send 3.34 MB of 4.04 MB corrupted data, 62.211.218.157 'http://emule-project.net' (aMule v2.2.6,Downloading/OnUploadQueue/None)

[Riso64Bit]

I think that these bad clients use a "new trick" to collect credit spamming bad data to other clients.

question: when client A send a request to client B from any other chunk, B send to A the "partial hash" of the complete chunk before start to send data?

[xilolee]

From the verbose log before your post, it seems that our eMule asks the AICH Hash of the part after it has been downloaded.

[Riso64Bit]

bad news
is not the first time.... Every the same username but now client version is 2.3.1

after some days:

This post has been edited by Riso64Bit: 23 September 2012 - 08:02 PM