Wed 21 Sep 2005 12:51:58 AM UTC, comment #14:
patch #4424 has more improvements for this bug
|
Fri 19 Aug 2005 11:07:42 AM UTC, comment #13:
Yesterday I had no single packet to a private/invalid address, today one (1). It's an UDP packet from the Overnet port. I guess that's OK.
I try to see, if I can setup something that's not to heavy for the machine (it's rather low powered), but can capture this packet. But I have no ready clue for doing so right now.
So, I would say that the patch is fixing the bug.
|
Wed 17 Aug 2005 06:43:11 PM UTC, comment #12:
OK: There is some strange behaviour, that I will investigate tomottow. I switch on 16th Aug to MLNet 2.6.2 (I wasn't at home before);
on the 16th I had 84 packets of pruvate addresses from the Overnet port (none other); today (most of the day had passed by already :) I had just ONE single one - from Overnet again.
I did not changed the guarding.p2p and I verfied that mlnet says that it loaded XYZ blacklisted IP addresses. Maybe it has to do with the web_info "guarding.p2p ; 96 ; http://www.bluetack.co.uk/config/antip2p.txt", however, this entry is enabled since a long time and I didn't found no single trace of an attempt to access that URL in the logs of the proxy.
I will report tomorrow again.
|
Wed 17 Aug 2005 12:28:59 AM UTC, comment #11:
any news?
|
Thu 04 Aug 2005 09:41:48 PM UTC, comment #10:
Patch #4270 was applied to CVS, please test
|
Wed 03 Aug 2005 08:08:51 PM UTC, comment #9:
Please test the attached patch for current CVS.
|
Wed 03 Aug 2005 08:03:40 PM UTC, comment #8:
It seems some Overnet clients sent us a wrong IP:
2005/08/03 21:44:58 [Overnet] UDP FROM 84.134.xx.xx:20760:
OvernetConnect
{ md4 = xxxxxxxxxxxxxxxxxxxxxxxxxxx ip = 192.168.123.123 port = 20760 kind = 0}
Normally MLDonkey would send OvernetConnectReply to 192.168.123.123
I made a patch which transforms this wrong IP into the one
from which the UDP packet came from:
2005/08/03 21:44:58 [Overnet] Connect: local IP 192.168.123.123:20760, fix it to 84.134.xx.xx:20760
So the OvernetConnectReply will be sent to the correct IP:
2005/08/03 21:44:58 Sending UDP to 84.134.52.97:20760 (0x0B)
2005/08/03 21:44:58 OvernetConnectReply
|
Sat 23 Jul 2005 08:42:05 PM UTC, comment #7:
Yesterday I conducted some tests myself, you are right, there is
a problem.
2005/07/23 01:11:14 [Overnet]: UDP FROM yy.yyy.yy.yy:8304:
OvernetSearchReply
target = ABABABABABBBBBBBBBBBABBBBBBBBBBB npeers = 2
{ md4 = CBCBBCCBBBBBBBBBBBBBBBBCCCCCCBCB ip = 192.168.1.111 port = 17565 kind = 1}
{ md4 = DDDDDDEDDEDEDDEDEDEDDDDDDDDDDEEE ip = xx.xxx.xxx.xx port = 7726 kind = 3}
This is what we receive from another client. Then i filtered the UDP connections from MLdonkey:
2005/07/23 01:11:27 Sending UDP to 192.168.1.111:17565 (0x0E)
2005/07/23 01:11:43 Sending UDP to 192.168.76.1:18724 (0x0B)
2005/07/23 01:11:57 Sending UDP to 192.168.1.10:15479 (0x0E)
2005/07/23 01:12:48 Sending UDP to 192.168.0.99:10066 (0x0E)
There are more... I will investigate further...
I believe the search replies are not properly processed for
local IPs.
|
Sat 23 Jul 2005 06:41:35 PM UTC, comment #6:
Hmm, well, here some of the logs are:
The IP of the host is an official (not a private) one.
Also, with these few lines you see that the destination addresses are spread through many networks and that many destination ports are used.
Jul 23 19:12:30 me kernel: IPT_OTHER: IN= OUT=ppp0 SRC=me DST=192.168.1.3 LEN=47 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=overnet DPT=20567 LEN=27
Jul 23 19:13:19 me kernel: IPT_OTHER: IN= OUT=ppp0 SRC=me DST=192.168.1.102 LEN=47 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=overnet DPT=10000 LEN=27
Jul 23 19:39:21 me kernel: IPT_OTHER: IN= OUT=ppp0 SRC=me DST=192.168.7.101 LEN=47 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=overnet DPT=6726 LEN=27
Jul 23 19:41:23 me kernel: IPT_OTHER: IN= OUT=ppp0 SRC=me DST=10.0.1.248 LEN=47 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=overnet DPT=14632 LEN=27
Jul 23 19:41:36 me kernel: IPT_OTHER: IN= OUT=ppp0 SRC=me DST=10.0.1.248 LEN=47 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=overnet DPT=14632 LEN=27
Jul 23 19:42:22 me kernel: IPT_OTHER: IN= OUT=ppp0 SRC=me DST=10.0.1.248 LEN=47 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=overnet DPT=14632 LEN=27
Jul 23 19:46:59 me kernel: IPT_OTHER: IN= OUT=ppp0 SRC=me DST=192.168.0.6 LEN=492 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=overnet DPT=14523 LEN=472
Jul 23 19:53:15 me kernel: IPT_OTHER: IN= OUT=ppp0 SRC=me DST=192.168.0.254 LEN=30 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=overnet DPT=2334 LEN=10
Jul 23 19:55:29 me kernel: IPT_OTHER: IN= OUT=ppp0 SRC=me DST=192.168.1.76 LEN=47 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=overnet DPT=5507 LEN=27
Jul 23 19:57:30 me kernel: IPT_OTHER: IN= OUT=ppp0 SRC=me DST=10.0.1.248 LEN=47 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=overnet DPT=14632 LEN=27
Jul 23 19:57:30 me kernel: IPT_OTHER: IN= OUT=ppp0 SRC=me DST=192.168.0.2 LEN=47 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=overnet DPT=20922 LEN=27
Jul 23 19:57:30 me kernel: IPT_OTHER: IN= OUT=ppp0 SRC=me DST=192.168.1.200 LEN=47 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=overnet DPT=15333 LEN=27
Jul 23 19:58:03 me kernel: IPT_OTHER: IN= OUT=ppp0 SRC=me DST=10.0.1.248 LEN=47 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=overnet DPT=14632 LEN=27
Jul 23 19:58:44 me kernel: IPT_OTHER: IN= OUT=ppp0 SRC=me DST=192.168.1.2 LEN=47 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=overnet DPT=17837 LEN=27
Jul 23 20:09:08 me kernel: IPT_OTHER: IN= OUT=ppp0 SRC=me DST=192.168.10.3 LEN=93 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=overnet DPT=5332 LEN=73
Jul 23 20:09:23 me kernel: IPT_OTHER: IN= OUT=ppp0 SRC=me DST=192.168.1.5 LEN=47 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=overnet DPT=16546 LEN=27
Jul 23 20:12:33 me kernel: IPT_OTHER: IN= OUT=ppp0 SRC=me DST=192.168.0.1 LEN=47 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=overnet DPT=12635 LEN=27
Jul 23 20:18:33 me kernel: IPT_OTHER: IN= OUT=ppp0 SRC=me DST=192.168.123.35 LEN=30 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=overnet DPT=14364 LEN=10
Jul 23 20:24:53 me kernel: IPT_OTHER: IN= OUT=ppp0 SRC=me DST=192.168.0.2 LEN=47 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=overnet DPT=6747 LEN=27
Jul 23 20:25:12 me kernel: IPT_OTHER: IN= OUT=ppp0 SRC=me DST=192.168.0.2 LEN=47 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=overnet DPT=6747 LEN=27
|
Fri 22 Jul 2005 10:50:41 PM UTC, comment #5:
Are you able to post some examples of IP addresses MLDonkey tries to reach?
|
Fri 22 Jul 2005 08:26:09 PM UTC, comment #4:
OK, in my last comment about the Bittorrent:
That protocol was enabled in addition to the other ones.
I made the following stats after downloading and enabling guarding.p2p (the small one):
That's the UDP statistics packet per hour:
00= overnet=30
01= overnet=27
02= overnet=24
03= overnet=35
04= overnet=26
05= overnet=30
06= overnet=27
07= kademlia=1,overnet=12
08= overnet=6
09= overnet=37
10= kademlia=1,overnet=39
11= overnet=29
12= overnet=31
13= overnet=61
14= overnet=50
15= overnet=52
16= overnet=33
17= overnet=13
18= overnet=8
19= overnet=12
20= overnet=9
21= overnet=7
However, they are lots less compared to the 160 packets before.
|
Thu 21 Jul 2005 07:05:20 PM UTC, comment #3:
I had enabled Bittorrent at the time I wrote the bugreport.
Now I run: donkey, overnet, Kademlia, server
and re-checked the logs again.
The packets are all UDP and the (two) source ports are the ones of Overnet and Kademlia.
About guarding: It would be nice to have some Warning that guarding is not found or something like that. I'll try it.
|
Tue 12 Jul 2005 10:51:18 AM UTC, comment #2:
What networks are you using?
There should be no problems if only eD2k is used.
Can you verify this?
|
Sun 10 Jul 2005 03:45:01 PM UTC, comment #1:
using ip_blocking a guarding.p2p or ipfilter.dat list with those ranges listed will block them
go to http://www.guarding.info and get a list
|
Sun 10 Jul 2005 01:38:17 PM UTC, original submission:
Hello,
I found bug #9929 and bug #7200, maybe there are others. However, they seem to deal with serves.
I configured my firewall to log and drop incoming and outgoing packets, which source or destination address matches a private or otherwise not legal address, see http://www.chip.de/c1_forum/thread.html?bwthreadid=847118 and rfc3330.
When I run mldonkey, I see about 5 through 160 dropped outgoing packets per hour, which destination address is a private or illegal one.
Although it's the duty of the router interfacing the internet to drop these packets, it would be nice if mldonkey wouldn't at first place try to connect to these hosts. -- option allow_local_network is off -- I guess, that mldonkey is spending resources, time, memory, whatever, when it deals with these hosts, one knows beforehand that they won't respond.
It would be nice to have a configuration option, that defaults to the well-known illegal address ranges, so you can enable some local clients on demand or add further locally well-known bad addresses.
|