Ho. I recognized an attackfield inside of the emule network. I heard from people who get paid for uploading damaged parts of files to let the bandwidth stuck!
For Example: You are downloading a file and u only need 5MB to finish the file. Now you see in your queque many people which have finished the file and many more who have only the last few MBs. The Problem is that the some people upload fake parts to people. Their waiting list is set to a small level (such as 100) so you wont wait to get their defect parts! In a few hours you will see many people which has the faked parts.

In your Emule it looks like:
Downloaded Part 13 is damaged (Name of File)
Downloaded Part 45 is damaged (Name of File)
Downloaded Part 75 is damaged (Name of File)
Downloaded Part 23 is damaged (Name of File)
Downloaded Part 54 is damaged (Name of File)
Downloaded Part 22 is damaged (Name of File)


This side discribes the problem in german GoldEselBoard. They point to a system to block these user from getting asked for your files. This System is intergrated in Emule since v26b.
It is a file called ipfilter.dat you have to copy into your /emuledir. You can get this file here.


My Idea is to add a funtion to emule where you can decide between:
1. downloading only from people who have finished this file 100% and
2. from anyone else!

The main feature is to walkaround the problem described at the beginning.
I hope this funktion will be added soon! I need this funtion to complete some files! from the last 2 month!

Sorry about the bad english

ipfilter is already included in both installer and binary package.

I think overpeer problem is blown out of proportions. If you experience successive part corruptions like you note above, than the problem is sertainly NOT overpeer or another malicious party. It's mostly a problem with your ***.part.met or ***.part files. Try fixing them with donkeydocter (or any other .part.met fixer). If everything failed, delete both the ***.part.met and ***.part file and download the file from the beginning. GL with fixing ur problem

I would like to report another version of problems with damaged parts...
It seems that if the server changes then the part file is completed, the file is accepted although faulty... then you can download this part file at least three times... the quality control refuses it... it is damaged, its hash is other than the original... but it will be discovered only at the final quality control then the file is complete at the other peer...

Another problem happens if iTunes uses MP3 files from the eMule directory...
If you change the comentary or the volume output, the file gets backed up and so it has a new hash... If it is downloaded without eMule reload, it has the same name but the actual hash changed, and the quality control scraps it...

I think for clients that are never shut down, the part files and the completed files should be checked, for new back up, certainly if the download was two times faulty... the new hash possibility should be programed...

Enviroment:
Windows XP Professional
Emule Plus v1.2a
Norton Antivirus with firewall
14809 port is not reachable

Sorry but I'm under the impression that you have not read the FAQ or anything related to the use of eMule.

I'll explain you shortly:

Hash of a file is calculated in base of the binary data inside it, if you change a commentary, the audio is not going to get changed, but the binary data who produces the file it is.

Ie:

Think this is the original Mp3 song:
10101010110101010110101010101
Where Blue is the audio data and Red the commentary. When emule hash it, it will produce an "X" hash.


Now, the same audio but you erased the commentary:
10101010110101010000000000000
When emule hash it, it will alert that binary data hash changed (it does not matter if audio remain equal), then it will produce an "Y" hash, which has to be different from hash "X".

Why?, the Hash is calculated with mathematical operations based in the binary data of the file, if you swap an byte, let say, from "1" for "0", the hash will differ cause every byte is used to identify a file.

Now, you're wrong with the way you are using the files, you have to make a copy of them for your personal use, every time you change an audio Mp3, you add a "new" version of it in the eD2K network, and you are not source for the original Mp3 file anymore . This is the reason for why there's so many almost-identical Mp3 files with only 1 source out there.


And, btw, you have Low ID, please search for it in forums.

[quote=Vladimir (SV),Dec 23 2006, 13:55]

Ok, I did not read the FAQ, sry Vladimir;
ok, I have a low ID, I tried to change it,
to open the requested port, it did not work yet...
but this does not change the three facts:

first:
my eMule downloaded six times a part file from the same peer (of course a rare file) and always scraped it...

second:
my eMule downloaded three times a complete file from the same peer (of course a rare one too) and always scrapped it...

the explanation is obvious, the actual hash must be different from the saved one...

third:
my eMule completed a part file as it was changing server, quality control accepted it, and as the file was completed it scrapped this same part file as damaged...

I just thought this information might help you all...

Merry Christmas & Happy 2007

it's not that obvious, it mostly dued to a fake client, so keep updated your ipfilter as some bad guys send corrupt data at porpouse

If there's the possibility of find a similar file (ie, another releaser) for that file, please change to it, keep an eye in the number of sources, higher is obviously better to avoid corrupt data.

Merry Christmas you too ^^

[quote=Vladimir (SV),Dec 23 2006, 23:02]

News from the Combat Front



Thx very much

First Case: This one peer completed the file (archive RAR format).
I got my part file after seven trials and 1.56 MB were rescued... HURRA!!!

Send Case: The 4.17 MB MP3 format file is still downloading from the same peer...

Life would be so much easier,
if my eMule could request the peer's eMule
to check that bloody hash number again...

The problem is that a fake client (by general, used by bad people), could send the correct hash, as the remote client can tell us whatever he likes, so eMule Plus got a valid hash to start downlading, but later the remote client send us different data than he had tell us before (data not matching the hash he say), therefore the corruption is found until the data is downloaded and compared with the hash

Anyway, you should be able to identify which is the fake client and then banning it with the IPFilter (sorry, there's not GUI option, I wish an option to ban manually too )