Official eMule-Board: Normal Kad Contact Could Be Banned By Remote Peers - Official eMule-Board

Jump to content


Page 1 of 1

Normal Kad Contact Could Be Banned By Remote Peers normal eMule clients kademlia requests baseline need to be established

#1 User is offline   Enig123 

  • Golden eMule
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 553
  • Joined: 22-November 04

Posted 15 December 2018 - 11:17 PM

As we all know, eMule introduced a flood protection mechanism since 0.49a BETA to mitigate some sort of attacks targeting kademlia. Namely, eMule will not respond to a kademlia request if it's within an allowed time distance, and the remote ip will be banned if the time distance is less than 1/5 of that is allowed.

I've been tracking a normal kad contact's (myself) requests, by keeping the request queue in which responded requests are just marked, and output the latest same opcode request to the same ip, when the flood criteria (time interval) could be activated in remote peer's side.

It turned out that some of requests, 0x21 mostly, also 0x43 and 0x44 sometimes, is so close to the last one, that would even make us banned by the remote peer.

For the following logs of mine:
12/15/2018 7:30:18 AM: Ignore Sending Kademlia packet opcode=0x21 to 89.73.xx.xx to avoid flood control of remote client, previous request is 0 ms before
12/15/2018 7:30:19 AM: Ignore Sending Kademlia packet opcode=0x21 to 77.73.xx.xxx to avoid flood control of remote client, previous request is 1093 ms before


As you can see, if the request packet sent to remote contact, our ip will be banned by them since the time delay from former same opcode request is less than 1/5 of 0x21 allowed, i.e., 6/5 == 1200 ms.

My suggestion is, when trying to send a kad request, and the remote side will surely filter it or even ban our ip, don't actually send it. Since even we send out the request, the remote side will not respond to it, if flood protection is activated at remote side.

I would like to have your opinions on that.

Edit1: Just checked my log files, there're 1,632 hits in 73 files, which means the requests that are not supposed to get responses is quite common.

This post has been edited by Enig123: 15 December 2018 - 11:41 PM

0

#2 User is offline   fox88 

  • Golden eMule
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 4974
  • Joined: 13-May 07

Posted 16 December 2018 - 11:57 AM

This condition is checked before banning.
	if (rCurTrackedRequest.m_nCount > iAllowedPacketsPerMinute * 5){

Why would a node get blocked because of only one packet?
0

#3 User is offline   Enig123 

  • Golden eMule
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 553
  • Joined: 22-November 04

Posted 16 December 2018 - 08:04 PM

It would be nice eMule will not been banned by remote node due to one packet. I must have focused too much on my own codes, in which a straightforward way is used to store timestamp of each requests, and uses request speed to judge if it be banned.

And wouldn't it better to totally avoid initiate a request that will not be responded in the first place?
0

#4 User is offline   Enig123 

  • Golden eMule
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 553
  • Joined: 22-November 04

Posted 23 December 2018 - 08:48 PM

The experiments did yield fruit, the following are some facts for a normal eMule kad node's baseline:

1. The short interval (less than 1min/allowed packets) between 0x21 requests are quite normal, while maintained only 2 consequent requests a round;
2. Requests of 0x34, 0x44, sometimes 0x33, are also possible to have short distance, yet not commonly seen;
3. Other opcodes are rarely seen in the logs, they seem to always have the time distance larger than limit.

Perhaps the above facts can help building a more reasonable criteria to judge if a kad node is behaving well, and whether it should be banned or not.

This post has been edited by Enig123: 23 December 2018 - 08:52 PM

0

#5 User is offline   fox88 

  • Golden eMule
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 4974
  • Joined: 13-May 07

Posted 25 December 2018 - 07:39 AM

Official code uses average rates here; and it does not ban indiscriminately.
Measuring intervals between messages would be more restrictive and less precise method.
0

  • Member Options

Page 1 of 1

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users