[ManiacoO]

Want more information on the Socket blocking ratio and what affects it. I noticed that when the active slot focus, many are left with BR high slot and slot focus does not work properly, I wonder why that? When I limit the speed of the slot, this problem rarely occurs.

In short: What affects Blocking Ratio? how to solve the problem?

ScreenShot:
http://img524.images.../blockrate.jpg/

http://img145.images...blockrate2.jpg/

Help! Thx

This post has been edited by ManiacoO: 11 January 2011 - 03:16 AM

[Stulle]

no crossposting! -.-

[aaa3i]

hy!, recent convert, love all those bars and stuff, but - not sure if stulle specific or base morph, if latter then sry - how can i turn off one specific one: the one in the transfer window's ,,completed'' column when expanding a particular file, basic emule only shows a growing number but here is a very cramped unreadable bar, no doubt with lots of delicious info for those who want it...

(p.s.: where is a decent specific guide about all the colours? this is about the icons http://www.angelfire...ansferinfo.pdf)

This post has been edited by aaa3i: 10 October 2011 - 08:40 AM

[pupet]

hello Stulle how to change the color of the speedgraph and minimule
pleas help me.
you thank in advance for your answer

I'm sorry for my English.

[Stulle]

No changing that.

[Yamakawa]

Hi, I use StulleMule v 7.0 on Windows 7 x64.
I noticed a strange peer on my list.

This peer appears on a certain file which I am downloading and also the peer is downloading. The peer sometimes seems to have complete source, and have partial source on other occasion. The strange thing is... the peer has changed its country and requesting file of mine so often, so it seems to me the peer changes its identity quite frequently, even during the same session. One more strange thing is... his software is said to be "eMule v5.0a" on popup from the transfer list, but also said to be "eMule v0.49b [Osnfbse 4.1]" on the client detail window (see the screenshot from Israel below). I think this client is quite fishy with Israel mod version.

However, looking at the details of the peer each time, I see no difference among each identity of the peer. That is, the client hash is always the same, and therefore the funny nick ("PS-2/3 [FN]").

Here are some shots of client detail. Look at the ID and amounts of transferred data. They are all the same.

Australia UK Israel Brazil N/A

Below is verbose log relating to PS/2-3 [FN] (IP is resolved by its country.):
2012/05/05 15:27:32: Clients: PS/2-3 [FN] (83.27.243.20 [POL]), Banreason: Userhash invalid
2012/05/05 15:27:32: Banned: Aggressive behaviour; 5998620@212.63.206.35 [SWE] (83.27.243.20) 'PS/2-3 [FN]' (eMule v0.48a [Xtreme 6.0],None/None/None)
2012/05/05 15:30:22: Client: PS/2-3 [FN] (203.214.3.144 [AUS]), Increased set m_fFailedFileIdReqs to 1
2012/05/05 15:36:27: Clients: PS/2-3 [FN] (87.222.99.0 [ESP]), Banreason: Userhash invalid
2012/05/05 15:36:27: Banned: Aggressive behaviour; 87.222.99.0 [ESP] 'PS/2-3 [FN]' (eMule v0.49a [MorphXT 11.0],None/None/None)
2012/05/05 15:39:12: Clients: PS/2-3 [FN] (95.247.221.113 [ITA]), Banreason: Userhash invalid
2012/05/05 15:39:12: Banned: Aggressive behaviour; 1@0.0.0.0 (95.247.221.113 [ITA]) 'PS/2-3 [FN]' (eMule v0.50a,None/None/None)
2012/05/05 15:43:36: Clients: PS/2-3 [FN] (189.35.144.208 [BRA]), Banreason: Userhash invalid
2012/05/05 15:43:36: Banned: Aggressive behaviour; 189.35.144.208 [BRA] 'PS/2-3 [FN]' (eMule v0.50a,None/None/None)
2012/05/05 15:44:22: Clients: PS/2-3 [FN] (85.65.13.15 [ISR]), Banreason: Userhash invalid
2012/05/05 15:44:22: Banned: Aggressive behaviour; 3876554@88.191.81.111 [FRA] (85.65.13.15 [ISR]) 'PS/2-3 [FN]' (eMule v0.49b [Osnfbse 4.1],None/None/None)
2012/05/05 15:52:41: Client: PS/2-3 [FN] (203.214.3.144 [AUS]), Increased set m_fFailedFileIdReqs to 2
2012/05/05 15:53:40: Clients: PS/2-3 [FN] (24.18.47.85 [USA]), Banreason: Userhash invalid
2012/05/05 15:53:40: Banned: Aggressive behaviour; 6958804@38.107.160.63 [CAN] (24.18.47.85 [USA]) 'PS/2-3 [FN]' (eMule v0.50a,None/None/None)
2012/05/05 17:03:04: Warning: Found matching client, to a currently connected client: Docker (203.214.3.144 [AUS]) and PS/2-3 [FN] (79.1.143.56 [ITA])
(log continued...)
2012/05/05 17:04:39: Client: PS/2-3 [FN] (200.127.255.98 [ARG]), Increased bad request to 1
2012/05/05 17:10:01: Client: PS/2-3 [FN] (91.75.174.221 [UAE]), Increased bad request to 2
2012/05/05 17:13:46: Client: PS/2-3 [FN] (203.214.3.144 [AUS]), Increased set m_fFailedFileIdReqs to 1
2012/05/05 17:14:49: Client: PS/2-3 [FN] (82.81.229.146 [ISR]), Increased set m_fFailedFileIdReqs to 1
2012/05/05 17:17:00: Client: PS/2-3 [FN] (82.81.229.146 [ISR]), Increased set m_fFailedFileIdReqs to 1
2012/05/05 17:19:17: Client: PS/2-3 [FN] (203.214.3.144 [AUS]), Increased set m_fFailedFileIdReqs to 1

Q: I think this peer is some kind of malpractice leecher or something. How can I avoid this peer, considering he changes his identity (maybe originating IP) so often? I don't care if the peer really transfer data to me or from me. I just don't like its behavior.

This post has been edited by Yamakawa: 05 May 2012 - 08:26 AM

[xilolee]

Yeah, very strange behaviour.
I'm afraid that you can not avoid it... The only way could be to delete the file and choose another one, if it exists.
Anyway your log shows that it is banned.
(it seems like he is using different proxies)

This post has been edited by xilolee: 05 May 2012 - 08:21 AM

[Riso64Bit]

From Changelog:

Quote

Updated: Anti-Leecher-Lists (DLP v43) [zz_fly]

Quote

//corrupt userhash check
static const TCHAR refuserhash3[] = _T("00000000000E00000000000000006F00");
static const TCHAR refuserhash4[] = _T("FE000000000E00000000000000006F00");
if(_tcsicmp(userhash,refuserhash3)==0 || _tcsicmp(userhash,refuserhash4)==0)
return _T("Corrupt Userhash");

it's an OLD corrupt userhash.Why StulleMule not ban this "bad userhash?

This post has been edited by Riso64Bit: 05 May 2012 - 08:27 AM

[Yamakawa]

I guess I was not banning this peer at the time of logging.
Before logging, I enabled some of Anti-leechers control including "Nick Changer", "Bad Mod String", "Bad Nick" and "Ghost Mod."
After logging, I disabled those checks and left only "Anti-Mod-Faker", "Anti-Nick-Thief", "Fake eMule", "File Faker" and "Vagaa" checked.
The reason I left these on and those off is because I really have little idea what is valid protect to ban particular type of threat such as this peer.
It seems to me, the peer was banned as "evil GPLdoer" before logging, and not banned after logging.
So, I am almost certain the peer was banned by either "Nick Changer", "Bad Mod String", "Bad Nick" or "Ghost Mod."
(Is there detailed description on how it works on every check? I looked into http://wiki.emule-we...leMule_features but had no clue.)

Also, I was thinking the peers might use proxy to connect to the servers. But then, they all have a complete source of the same file, which is quite rare as it has only a few (2-3) complete sources. So, the chances are not different clients use the same proxy and they appear every now and then, but only one user uses multiple identity to do some evil thing. Otherwise not all of them could have the complete source.

As for choosing another file, that could be it, but the file is quite unique in this case and I have no other way to choose the other. Anyway, thanks for your response.

Edit: Oh, I see the peer was banned at the time of logging when I see the line "Banned: Aggressive behaviour; ..." Strange thing is... the peer later connected as "Docker" and it is within 2 hours ban duration (I use the default value of 2hr for this).

This post has been edited by Yamakawa: 05 May 2012 - 09:33 AM

[Yamakawa]

Riso64Bit, on 05 May 2012 - 05:26 PM, said:

From Changelog:

Quote

Updated: Anti-Leecher-Lists (DLP v43) [zz_fly]

Quote

//corrupt userhash check
static const TCHAR refuserhash3[] = _T("00000000000E00000000000000006F00");
static const TCHAR refuserhash4[] = _T("FE000000000E00000000000000006F00");
if(_tcsicmp(userhash,refuserhash3)==0 || _tcsicmp(userhash,refuserhash4)==0)
return _T("Corrupt Userhash");

it's an OLD corrupt userhash.Why StulleMule not ban this "bad userhash?

The corresponding lines in Stulle's v7.0 implementation is in BaseClient.cpp pp. 1333-1344

Quote

//corrupt userhash check
static const TCHAR refuserhash4[] = _T("00000000000E00000000000000006F00");
static const TCHAR refuserhash5[] = _T("FE000000000E00000000000000006F00");
if(_tcsicmp(userhash,refuserhash4)==0 ||
_tcsicmp(userhash,refuserhash5)==0)
// ==> Reduce Score for leecher - Stulle
/*
return _T("Corrupt userhash");
*/
return BAN_COMMUNITY;
// <== Reduce Score for leecher - Stulle
} // ban systems optional - Stulle
//MORPH END - Added, Community/Corrupt userhash check [zz_fly/squallATF]

If this is into the binaries, then all it does is just reduce score, not ban, and we have no option to control how to punish the peer?
First of all, is the peer responsible for this corrupt userhash at all?

This post has been edited by Yamakawa: 05 May 2012 - 09:08 AM

[xilolee]

You can reproduce that user hash in this way:
1) close emule
2) open the preferences.dat with an hex editor
3) change the values with zeros
4) save the file

So probably that source is using a mod with userhash = 0 for all of its clients (dreamule?)

This post has been edited by xilolee: 05 May 2012 - 09:57 AM

[Yamakawa]

xilolee, on 05 May 2012 - 06:33 PM, said:

You can reproduce that user hash in this way:
1) close emule
2) open the preferences.dat with an hex editor
3) change the values with zeros
4) save the file

So probably that source is using a mod with userhash = 0 for all of its clients (dreamule?)

I mistakenly regenerated the above method on my own and got this:

Quote

2012/05/05 21:44:13: Obfuscated packet expected but magicvalue mismatch on UDP packet from clientIP: x.x.x.x, Possible RecvKey: 3291105716
2012/05/05 21:44:13: Client UDP socket: prot=0x48 opcode=0x45 sizeaftercrypt=43 realsize=43 Unknown protocol 0x48: x.x.x.x:4814
2012/05/05 21:44:13: Obfuscated packet expected but magicvalue mismatch on UDP packet from clientIP: x.x.x.x, Possible RecvKey: 2947762865
2012/05/05 21:44:13: Client UDP socket: prot=0xdc opcode=0x7c sizeaftercrypt=51 realsize=51 Unknown protocol 0xdc: x.x.x.x:24190
2012/05/05 21:44:13: Obfuscated packet expected but magicvalue mismatch on UDP packet from clientIP: x.x.x.x, Possible RecvKey: 4011316647
2012/05/05 21:44:13: Client UDP socket: prot=0xf8 opcode=0x46 sizeaftercrypt=51 realsize=51 Unknown protocol 0xf8: x.x.x.x:5142
2012/05/05 21:44:13: Obfuscated packet expected but magicvalue mismatch on UDP packet from clientIP: x.x.x.x, Possible RecvKey: 2584683428
2012/05/05 21:44:13: Client UDP socket: prot=0x44 opcode=0x12 sizeaftercrypt=51 realsize=51 Unknown protocol 0x44: x.x.x.x:18991
2012/05/05 21:44:14: Obfuscated packet expected but magicvalue mismatch on UDP packet from clientIP: x.x.x.x, Possible RecvKey: 3628847846
2012/05/05 21:44:14: Client UDP socket: prot=0x58 opcode=0x1e sizeaftercrypt=51 realsize=51 Unknown protocol 0x58: x.x.x.x:57621
2012/05/05 21:44:14: Obfuscated packet expected but magicvalue mismatch on UDP packet from clientIP: x.x.x.x, Possible RecvKey: 2784448775
2012/05/05 21:44:14: Client UDP socket: prot=0x68 opcode=0x60 sizeaftercrypt=51 realsize=51 Unknown protocol 0x68: x.x.x.x:4672
2012/05/05 21:44:15: Obfuscated packet expected but magicvalue mismatch on UDP packet from clientIP: x.x.x.x, Possible RecvKey: 3107291372
2012/05/05 21:44:15: Client UDP socket: prot=0x8c opcode=0xfb sizeaftercrypt=51 realsize=51 Unknown protocol 0x8c: x.x.x.x:18464
2012/05/05 21:44:15: Obfuscated packet expected but magicvalue mismatch on UDP packet from clientIP: x.x.x.x, Possible RecvKey: 1313766359
2012/05/05 21:44:15: Client UDP socket: prot=0x50 opcode=0x0b sizeaftercrypt=51 realsize=51 Unknown protocol 0x50: x.x.x.x:64672
2012/05/05 21:44:15: Obfuscated packet expected but magicvalue mismatch on UDP packet from clientIP: x.x.x.x, Possible RecvKey: 1924387588
2012/05/05 21:44:15: Client UDP socket: prot=0x6c opcode=0xd6 sizeaftercrypt=51 realsize=51 Unknown protocol 0x6c: x.x.x.x:25162
2012/05/05 21:44:15: Obfuscated packet expected but magicvalue mismatch on UDP packet from clientIP: x.x.x.x, Possible RecvKey: 3489142454
2012/05/05 21:44:15: Client UDP socket: prot=0x04 opcode=0x9b sizeaftercrypt=51 realsize=51 Unknown protocol 0x04: x.x.x.x:40478
2012/05/05 21:44:15: CEncryptedStreamSocket: Received wrong magic value from clientIP x.x.x.x on a supposly encrytped stream / Wrong Header
2012/05/05 21:44:15: Client TCP socket: Error: Encryption layer error; IP=x.x.x.x
2012/05/05 21:44:15: Obfuscated packet expected but magicvalue mismatch on UDP packet from clientIP: x.x.x.x, Possible RecvKey: 3355666530
2012/05/05 21:44:15: Client UDP socket: prot=0xc8 opcode=0x52 sizeaftercrypt=51 realsize=51 Unknown protocol 0xc8: x.x.x.x:11239
2012/05/05 21:44:15: Obfuscated packet expected but magicvalue mismatch on UDP packet from clientIP: x.x.x.x, Possible RecvKey: 223554476
2012/05/05 21:44:15: Client UDP socket: prot=0x18 opcode=0x46 sizeaftercrypt=44 realsize=44 Unknown protocol 0x18: x.x.x.x:59710
2012/05/05 21:44:16: Obfuscated packet expected but magicvalue mismatch on UDP packet from clientIP: x.x.x.x, Possible RecvKey: 2180517440
2012/05/05 21:44:16: Client UDP socket: prot=0x58 opcode=0x7d sizeaftercrypt=51 realsize=51 Unknown protocol 0x58: x.x.x.x:26134

This is just an example of 3 seconds. This continues every second, that is ALWAYS.
And now I have no peer on my requesting list, not only the file in question but also other files.
Strangely enough, I am uploading to 2 peers who are only requesting to me.
I also have other 18 peers requesting their files on me.
So, I am just uploading, whereas I have no peer to download from.
I tried to use back-upped preferences.dat file to fail. I also tried deleting preferences*.dat files as well.
Both methods let me have no peers to download.
I disabled both Sivka-ban and Anti-leecher controls for sure.
If this happens because of my using zero filled preferences.dat, then why the peer in question "PS/2-3 [FN]" could download from me?
Most of all, how can I repair this situation? I am in stuck.

Edit: I suppressed the message by making verbose log level down to 2 (default was 5 and until level 3 the nagging message continues). I also all cleared the config files and started all over again. Sorry for those who uploaded to me a lot.

This post has been edited by Yamakawa: 05 May 2012 - 02:03 PM

[xilolee]

Those messages are not related to the changed preferences.dat.
If you want to do experiments with emule config files, first thing to do is a backup of your config files!

Trying with that userhash, i'm having this in verbose log:

05/05/2012 17.42.41: 'Nick' has failed the secure identification, V2 State: 0

Only 12 clients over 833 say "identification: successful", the most are MlDonkey 3.0/3.1

This post has been edited by xilolee: 06 May 2012 - 06:38 PM

[Stulle]

Make sure to enable banning (not reduce) and detection for Community clients. I am not as selective with banning/ reducing as the DLP sometimes is, I basically just assigned some groups and ban accordingly. See this list:

enum EBanReason{
	GOOD_BOY,
	// reduce
	BAN_FAKE_MOD,
	BAN_MORPH_LEECHER,
	BAN_FAKE_NICK,
	BAN_LEECHER_NICK,
	BAN_COMMUNITY,
	BAN_WRONG_HASHSIZE,
	BAN_HEX_CHECK,
	BAN_BAD_MOD,
	BAN_BAD_NICK,
	BAN_REDUCE_COUNT, // all above are reduced
	// ban - no reason relayed
	BAN_SIVKA,
	BAN_SPAMMER,
	BAN_FILEFAKER,
	BAN_FRIEND_SHARING,
	BAN_GHOST,
	BAN_FAKE_VER,
	BAN_EMPTY_NICK,
	BAN_NICK_CHANGER,
	BAN_APPLE_JUICE,
	BAN_VAGAA,
	BAN_NORELAY_COUNT, // all above do not relay a particular ban reason
	// ban - reason relayed
	BAN_BAD_INFO,
	BAN_BAD_HELLO,
	BAN_SNAFU,
	BAN_EXTRABYTE,
	BAN_CREDIT_HACK,
	BAN_COUNT // last item
};

[Yamakawa]

Isn't this odd with the user hash?

I checked ban options as below:
Anti-leechers control -> Enable, Enable Aniti-Nick-Thief, Enable Community Check, Enable File Faker Check... all chcked
+ Leecher punishment -> Ban checked



Yet, the user is shown as "Good guy" and as Banned "No."
(Actually, it says 4 users are banned, but there is no user listed as Banned "Yes" on the queue list.)
He has much more score as 100720 even sorted by score.
Though his queue is ranked quite below when sorted by score despite of his very higher score, I am afraid if he gets served.
Am I okay with this guy? I mean, am I really banning this guy?



What about changing his status as "Bad guy" or something and shown as Banned "Yes" in future release?
Hope things clear up soon.

This post has been edited by Yamakawa: 08 May 2012 - 12:56 AM

[Stulle]

1. Make sure you did not add any client as friend that has this hash. This will prevent those clients from being banned.

2. Banned clients are usually removed from the QueueList immediately. You will only occasionally see a client remain there for a wee bit longer.

[tHeWiZaRdOfDoS]

xilolee, on 05 May 2012 - 10:33 AM, said:

You can reproduce that user hash in this way:
1) close emule
2) open the preferences.dat with an hex editor
3) change the values with zeros
4) save the file

So probably that source is using a mod with userhash = 0 for all of its clients (dreamule?)

If one does that then he/she will fail the SUI and will be banned. Usually the same hash for multiple clients originates in a faulty installer (or binary) that includes the installer creators' hash and thus all clients using that installer get the same hash...

[xilolee]

@wizard: not by everyone... when i've tried, my client has downloaded some MB.
And this should also happen when disabling SUI (secure user identification)...
SUI should be hardcoded (and enabled), if disabling it causes a massive/global ban.

This post has been edited by xilolee: 08 May 2012 - 06:08 PM

[Yamakawa]

Stulle, on 08 May 2012 - 01:26 PM, said:

1. Make sure you did not add any client as friend that has this hash.

Thanks for quick reply.
This explains everything. Removing one of friends which happens to have the userhash and no user with that hash ever appears again. Community Ban is surely working now, I think.
It happened I put one of the users with the hash and a complete source as a friend at one time. This must be the cause of all trouble here.

xilolee, on 09 May 2012 - 03:07 AM, said:

SUI should be hardcoded (and enabled), if disabling it causes a massive/global ban.

Using SUI is always checked on Stulle V7.0.
[Security] -> [Miscellaneous] -> [Use secure identification] is checked as default and a user cannot change it.

[Stulle]

yep, that's intended and default in MorphXT for a long while now.