[Nissenice]

The quote of the day:

fox88, on 18 October 2009 - 07:05 PM, said:

It might be advisable to use clear and consitent terms,

[jestheonlyone]

James R. Bath, on 17 October 2009 - 04:48 AM, said:

jestheonlyone, on 16 October 2009 - 02:58 AM, said:

James R. Bath, on 15 October 2009 - 07:00 PM, said:

Limiting it to just the following cases would also stop most of corrupt transfers:

Download session ended: The remote client decided to stop/complete the transfer (got OP_OutOfPartReqs).

Yes, obviously.
But this would also stop most transfers...

Even if "Req blocks not yet completed" is also taken into account, BTW.

No, they don't. Look at the statistics I posted. These also apply to the "client decided to stop/complete the transfer" or "OP_OutOfPartReqs". OP_OutOfPartReqs is even rarer than "Req blocks". To compare, you need to have a log file where you download nothing but valid files. For that matter, most fakes don't have this kind of problem, which is repeatedly uploading incomplete blocks.

Here are the log entries for each and every end of download sessions (all complete and uncorrupted) from a single client during a single day:

02:18:56: Download session ended: The remote client decided to stop/complete the transfer (got OP_OutOfPartReqs). User: 77.207.98.xxx 'bla' (eMule v0.49b,Downloading/OnUploadQueue/None) in SetDownloadState(). New State: 1, Length: 17:48 mins, Payload: 9.32 MB, Transferred: 9.32 MB, Req blocks not yet completed: 3.
03:20:05: Download session ended: The remote client decided to stop/complete the transfer (got OP_OutOfPartReqs). User: 77.207.98.xxx 'bla' (eMule v0.49b,Downloading/Uploading/None) in SetDownloadState(). New State: 1, Length: 18:00 mins, Payload: 9.31 MB, Transferred: 9.31 MB, Req blocks not yet completed: 3.
14:41:17: Download session ended: The remote client decided to stop/complete the transfer (got OP_OutOfPartReqs). User: 77.207.98.xxx 'bla' (eMule v0.49b,Downloading/None/None) in SetDownloadState(). New State: 1, Length: 19:36 mins, Payload: 9.32 MB, Transferred: 9.32 MB, Req blocks not yet completed: 3.
15:17:59: Download session ended: The remote client decided to stop/complete the transfer (got OP_OutOfPartReqs). User: 77.207.98.xxx 'bla' (eMule v0.49b,Downloading/None/None) in SetDownloadState(). New State: 1, Length: 17:30 mins, Payload: 9.32 MB, Transferred: 9.32 MB, Req blocks not yet completed: 3.
16:01:30: Download session ended: The remote client decided to stop/complete the transfer (got OP_OutOfPartReqs). User: 77.207.98.xxx 'bla' (eMule v0.49b,Downloading/None/None) in SetDownloadState(). New State: 1, Length: 19:12 mins, Payload: 9.32 MB, Transferred: 9.32 MB, Req blocks not yet completed: 3.
16:46:38: Download session ended: The remote client decided to stop/complete the transfer (got OP_OutOfPartReqs). User: 77.207.98.xxx 'bla' (eMule v0.49b,Downloading/None/None) in SetDownloadState(). New State: 1, Length: 19:26 mins, Payload: 9.32 MB, Transferred: 9.32 MB, Req blocks not yet completed: 3.
17:37:30: Download session ended: The remote client decided to stop/complete the transfer (got OP_OutOfPartReqs). User: 77.207.98.xxx 'bla' (eMule v0.49b,Downloading/None/None) in SetDownloadState(). New State: 1, Length: 17:15 mins, Payload: 9.32 MB, Transferred: 9.32 MB, Req blocks not yet completed: 3.
18:28:56: Download session ended: The remote client decided to stop/complete the transfer (got OP_OutOfPartReqs). User: 77.207.98.xxx 'bla' (eMule v0.49b,Downloading/None/None) in SetDownloadState(). New State: 1, Length: 16:55 mins, Payload: 9.32 MB, Transferred: 9.32 MB, Req blocks not yet completed: 3.
19:53:59: Download session ended: The remote client decided to stop/complete the transfer (got OP_OutOfPartReqs). User: 77.207.98.xxx 'bla' (eMule v0.49b,Downloading/None/None) in SetDownloadState(). New State: 1, Length: 18:50 mins, Payload: 9.32 MB, Transferred: 9.32 MB, Req blocks not yet completed: 3.
21:06:50: Download session ended: The remote client decided to stop/complete the transfer (got OP_OutOfPartReqs). User: 77.207.98.xxx 'bla' (eMule v0.49b,Downloading/None/None) in SetDownloadState(). New State: 1, Length: 19:20 mins, Payload: 9.32 MB, Transferred: 9.32 MB, Req blocks not yet completed: 3.
22:24:35: Download session ended: The remote client decided to stop/complete the transfer (got OP_OutOfPartReqs). User: 77.207.98.xxx 'bla' (eMule v0.49b,Downloading/None/None) in SetDownloadState(). New State: 1, Length: 19:18 mins, Payload: 9.32 MB, Transferred: 9.32 MB, Req blocks not yet completed: 3.

[WentloogWhix]

Enig123, on 14 October 2009 - 03:40 AM, said:

In that case, an ipfilter list may help a lot more than Limits/bans.

It's easy enough to add the following to your IPFilter (ipfilter.dat)

84.128.0.0      - 84.135.255.255  ,   0 , Poison, Deutsche Telekom AG
85.176.0.0      - 85.182.127.255  ,   0 , Poison, HanseNet Telekommunikation GmbH
92.228.0.0      - 92.231.255.255  ,   0 , Poison, HanseNet Telekommunikation GmbH
78.48.0.0       - 78.50.159.255   ,   0 , Poison, HanseNet Telekommunikation GmbH

But have a look at those ranges: they're all ADSL pools for regular broadband subscribers. Would you like it if your pool range was one of those and you were suddenly being ostracised by hundreds of eMule users for no fault of your own?

What will happen when the rogue software is set up in ADSL pools in every major city in the EU? Do we just ban them all? The IPFilter option is like hitting a nail with a battering ram: there is too much collateral damage.

Also, there is no simple, unified way of getting millions of eMule clients to update their filters. The current eMule 0.49c install doesn't include a filter, or the address for one, and the data from emulepawcio appears to be years out of date, which hardly inspires confidence:

http://emulepawcio.sourceforge.net/nieuwe_site/index.html said:

19-10-2004: Emule 0.44b Pawcio 5.15 is released

Today's data file is dated 1-Oct-2009, which is better, but not ideal.

Depending on where you are in the world, an ADSL IP address can change anytime between 6 hours and 6 months. You can be sure that the bad guys will be changing their IP address as often as possible.

Also, there is no documented way of being able to report dodgy IP addresses, and Peerguardian.net has closed. So if anything, IPFilter is broken too. I am using PeerBlock and Blocklist manager, and neither of these has stopped the poisoning.

This post has been edited by WentloogWhix: 18 October 2009 - 08:41 PM

[omeringen]

WentloogWhix, on 18 October 2009 - 11:36 PM, said:

. . .
and the data from emulepawcio appears to be years out of date:
. . .

Wrong; Ipfilter & Fakes

[torpon]

Ipfilter in emulepawcio is usually updated every month. All we would like it to be updated more often, but it takes it time.

Cheers

[fox88]

WentloogWhix, on 18 October 2009 - 10:23 PM, said:

It might be advisable to contribute to the discussion

Discussion of exactly what? Can you explain the exact algorithm suggested? If not, what is your point?

PS. Nothing personal here, but you said you know how IP filters are made. As far as I know making a decent IP filter never meant banning whole providers.

[Nissenice]

fox88, on 19 October 2009 - 12:42 AM, said:

WentloogWhix, on 18 October 2009 - 10:23 PM, said:

It might be advisable to contribute to the discussion

Discussion of exactly what? Can you explain the exact algorithm suggested? If not, what is your point?

PS. Nothing personal here, but you said you know how IP filters are made. As far as I know making a decent IP filter never meant banning whole providers.

Well, fox. Don't you think you have had your chances already to say anything useful about what IPs needs to be blocked regarding this matter. But you chose to ignore them. So why bring it up again? It's not very decent if you ask me.

WentloogWhix, on 09 October 2009 - 10:07 AM, said:

@fox88: Please confirm whether your current ipfilter excludes 84.135.69.193, 85.181.38.247, 92.228.200.119, or not.

WentloogWhix, on 13 October 2009 - 08:03 AM, said:

@fox88: I am still waiting for your definitive ipfilter.dat URL, and you still haven't explained why I would want to block the ADSL pool range for 3 ISPs, or whether the IP addresses I supplied are included in your IP Filter.

WentloogWhix, on 16 October 2009 - 12:25 AM, said:

@fox88: you still haven't answered the question about your IPfilter.dat file or the server.met file, so should I abandon my fresh installation of eMule 0.49c?

This post has been edited by Nissenice: 18 October 2009 - 11:34 PM

[Andu]

I don't get this or any of the other threads. SomeSupport already said that AICH will become part of the file identification sooner or later. At that point we will be hashing 180kb blocks anyway and the entire problem is resolved.

I wonder if the devs would consider sharing blocks instead of chunks too.

[James R. Bath]

Andu, on 19 October 2009 - 12:47 AM, said:

I don't get this or any of the other threads. SomeSupport already said that AICH will become part of the file identification sooner or later. At that point we will be hashing 180kb blocks anyway and the entire problem is resolved.

If that's the case and it's sooner rather than at some indefinite point in the future, then that will take care of my request.

For people who still don't comprehend the problem and why a feature to discourage/eliminate it is necessary, turn on your verbose logs and reply back next week with the transferred vs. completed amounts on this file:
ed2k://|file|InfiniteIncompleteReqBlocks.rar|248670941|E0D99FBAC76358D14FC7F1249C2F3273|/

[fox88]

Nissenice, on 19 October 2009 - 03:33 AM, said:

Don't you think you have had your chances already to say anything useful about what IPs needs to be blocked regarding this matter. But you chose to ignore them. So why bring it up again? It's not very decent if you ask me.

My way thinking here is of no importance. I can do very little if someone choses not to read or just ignores already posted things:

fox88, on 10 October 2009 - 12:50 PM, said:

Properly updated IP filter should do the trick for this time. Not your tiny one; try to go to bluetack.com and report there your trouble with corrupted contents senders.

By the way, James R. Bath made a report. Hopefully the filter would be updated in the near future.

Nissenice, on 19 October 2009 - 03:33 AM, said:

It's not very decent if you ask me.

Maybe I underestimate the importance of endless repetition of the same lines over and over again: 'everything is broken', 'we are doomed', etc.

This post has been edited by fox88: 21 October 2009 - 08:09 PM

[jestheonlyone]

James R. Bath, on 19 October 2009 - 07:56 AM, said:

ed2k://|file|InfiniteIncompleteReqBlocks.rar|24867xxxx|E0D99FBAC76358D14FC7F1249C2Fxxxx|/

There are some rules on this forum...
What's your relationship with WentloogWhix?

[WentloogWhix]

jestheonlyone, on 20 October 2009 - 12:45 AM, said:

What's your relationship with WentloogWhix?

It seems that the problem is common enough that two posters independently of one another have run into the same problem. It must be a conspiracy.

Since there is no PUBLISHED information on the upcoming release, or how it works, or whether the trust issue has been addressed, I'm not holding my breath.

[James R. Bath]

jestheonlyone, on 18 October 2009 - 09:09 PM, said:

Here are the log entries for each and every end of download sessions (all complete and uncorrupted) from a single client during a single day:

02:18:56: Download session ended: The remote client decided to stop/complete the transfer (got OP_OutOfPartReqs). User: 77.207.98.xxx 'bla' (eMule v0.49b,Downloading/OnUploadQueue/None) in SetDownloadState(). New State: 1, Length: 17:48 mins, Payload: 9.32 MB, Transferred: 9.32 MB, Req blocks not yet completed: 3.
03:20:05: Download session ended: The remote client decided to stop/complete the transfer (got OP_OutOfPartReqs). User: 77.207.98.xxx 'bla' (eMule v0.49b,Downloading/Uploading/None) in SetDownloadState(). New State: 1, Length: 18:00 mins, Payload: 9.31 MB, Transferred: 9.31 MB, Req blocks not yet completed: 3.
14:41:17: Download session ended: The remote client decided to stop/complete the transfer (got OP_OutOfPartReqs). User: 77.207.98.xxx 'bla' (eMule v0.49b,Downloading/None/None) in SetDownloadState(). New State: 1, Length: 19:36 mins, Payload: 9.32 MB, Transferred: 9.32 MB, Req blocks not yet completed: 3.
15:17:59: Download session ended: The remote client decided to stop/complete the transfer (got OP_OutOfPartReqs). User: 77.207.98.xxx 'bla' (eMule v0.49b,Downloading/None/None) in SetDownloadState(). New State: 1, Length: 17:30 mins, Payload: 9.32 MB, Transferred: 9.32 MB, Req blocks not yet completed: 3.
16:01:30: Download session ended: The remote client decided to stop/complete the transfer (got OP_OutOfPartReqs). User: 77.207.98.xxx 'bla' (eMule v0.49b,Downloading/None/None) in SetDownloadState(). New State: 1, Length: 19:12 mins, Payload: 9.32 MB, Transferred: 9.32 MB, Req blocks not yet completed: 3.
16:46:38: Download session ended: The remote client decided to stop/complete the transfer (got OP_OutOfPartReqs). User: 77.207.98.xxx 'bla' (eMule v0.49b,Downloading/None/None) in SetDownloadState(). New State: 1, Length: 19:26 mins, Payload: 9.32 MB, Transferred: 9.32 MB, Req blocks not yet completed: 3.
17:37:30: Download session ended: The remote client decided to stop/complete the transfer (got OP_OutOfPartReqs). User: 77.207.98.xxx 'bla' (eMule v0.49b,Downloading/None/None) in SetDownloadState(). New State: 1, Length: 17:15 mins, Payload: 9.32 MB, Transferred: 9.32 MB, Req blocks not yet completed: 3.
18:28:56: Download session ended: The remote client decided to stop/complete the transfer (got OP_OutOfPartReqs). User: 77.207.98.xxx 'bla' (eMule v0.49b,Downloading/None/None) in SetDownloadState(). New State: 1, Length: 16:55 mins, Payload: 9.32 MB, Transferred: 9.32 MB, Req blocks not yet completed: 3.
19:53:59: Download session ended: The remote client decided to stop/complete the transfer (got OP_OutOfPartReqs). User: 77.207.98.xxx 'bla' (eMule v0.49b,Downloading/None/None) in SetDownloadState(). New State: 1, Length: 18:50 mins, Payload: 9.32 MB, Transferred: 9.32 MB, Req blocks not yet completed: 3.
21:06:50: Download session ended: The remote client decided to stop/complete the transfer (got OP_OutOfPartReqs). User: 77.207.98.xxx 'bla' (eMule v0.49b,Downloading/None/None) in SetDownloadState(). New State: 1, Length: 19:20 mins, Payload: 9.32 MB, Transferred: 9.32 MB, Req blocks not yet completed: 3.
22:24:35: Download session ended: The remote client decided to stop/complete the transfer (got OP_OutOfPartReqs). User: 77.207.98.xxx 'bla' (eMule v0.49b,Downloading/None/None) in SetDownloadState(). New State: 1, Length: 19:18 mins, Payload: 9.32 MB, Transferred: 9.32 MB, Req blocks not yet completed: 3.

Either your client has corrupt logging or you're posting corrupt/fake logs. I have no cases "Req blocks not yet completed: 3" It's either 2, 1, or 0. And my verbose log samples go back to 2005.

Regardless of your questionable logs, since there are actual cases of incomplete blocks after uploading MB, simply adding the previously suggested rule to only include cases of transfers less than 3x180 KB (that's 540 unless someone would like to change the multiplication algorithm) would not ban the client listed above (cf., "Transferred").

[James R. Bath]

James R. Bath, on 19 October 2009 - 05:56 AM, said:

For people who still don't comprehend the problem and why a feature to discourage/eliminate it is necessary, turn on your verbose logs and reply back next week with the transferred vs. completed amounts on this file:
ed2k://|file|InfiniteIncompleteReqBlocks.rar|248670941|E0D99FBAC76358D14FC7F1249C2F3273|/

Still waiting. Another file where all the complete sources are capable of producing and sharing AICH but none do and eMule doesn't see the discrepancy:
ed2k://|file|Infinitely%20Incomplete%20ReqBlocks%202.rar|250000000|6F4C2D975ED615E0F34B49A26F92D263|/