[Mldonkey-users] Bug in Overnet source handling causes being banned

[mldonkey]

Hi list!

Most people probably know the problem of being banned by some clients 
for "connecting too fast". I think that at least some of them are due to 
a bug in the Overnet source handling of mldonkey. Here is what I found 
today:

(all IP adresses, client names and client hashes changed)


From the Messages tab:

===== snip =====
Time          IP address    Num   Client name  Message
20:22:12 Thu  123.45.67.89  8525  xwotpc       [AUTOMATED WARNING] Your 
client is connecting too fast, it will get banned
21:55:48 Thu  123.45.67.89  9091  xwotpc       [AUTOMATED WARN...
23:46:36 Thu  123.45.67.89  14978 xwotpc       [AUTOMATED WARN...
00:11:30 Fri  123.45.67.89  9091  xwotpc       [AUTOMATED WARN...
===== snap =====

Ok, so here we have the same client with 3 different client numbers (Row 
"Num"). That means mldonkey thinks it has 3 different clients, but it 
really is the same one. And that seems to be the reason my client 
connects too fast, because it sends all messages for 3 different clients 
to the same IP and gets banned. :-(

I found the file that "xwotpc" was downloading and had a closer look:

From the File Details page at 11:32:00 Fri
(unnecessary rows left out)

===== snip =====
Num   CS   Name   CB  O C IP address   UL   DL MD4
16655      xwotpc OVR T D 123.45.67.89 0    0  899F7E8...
37088 Qued xwotpc tML F D 123.45.67.89 2.0M 0  899F7E8...
...
23743      ababab OVR T D 234.56.78.90 0    0  0F8E08E...
36646 Qued ababab eMU F D 234.56.78.90 2.6M 0  0F8E08E...
...
35378      andi79 OVR T D 34.56.78.90  0    0  A3CB60D...
38207 Qued andi79 eMU F D 34.56.78.90  0    0  A3CB60D...
===== snap =====

In the "Num" row you can see that "xwotpc" had TWO nums assigned. The CB 
(Client Brand) row and the Overnet (O) row state that one of those nums 
is from Overnet, while the other one is from edonkey. That is why the 
client exists twice.

If the "CB" row is right, "xwotpc" is a trusted MLdonkey.

There are two more clients with two nums assigned to one client: 
"ababab" and "andi79". Same thing here (one from edonkey, one from overnet).


I believe that a solution would be to check if a client with the same 
IP/Port and the same client hash already exists in either edonkey OR 
overnet sources before adding a new source. (Just checking the IP is not 
enough, because it is possible that more than one client run on the same 
machine with a different port & client hash.)

What do you think, am I right? Should I file a bug report?


Regards,

phoenix




PS: The Client Brand (CB row) of "ababab" and "andi79" is obviously NOT 
eMule, because eMule has no overnet support. It must be either an 
edonkey hybrid or another mldonkey.

PPS: My reask-options are fairly reasonable, so that should not be the 
problem:
  min_reask_delay = 620   (default: 600)
  max_reask_delay = 1500  (default: 3600)

PPPS: No, I cannot explain why "xwotpc" has 3 instead of 2 client nums 
in the messages tab. I suppose mldonkey forgets "xwotpc" from time to 
time and then learns about him again. There are several hours between 
the single messages and between the messages and the file details page.