Thu 19 May 2005 04:15:26 PM UTC, comment #11:
1647477 May 19 18:05 file_sources.ini
grep 192.168 file_sources.ini|sort|uniq
(no output)
with 2.5.30.15, so the original bug is solved.
Does it make sense to distribute a guarding.p2p file with MLDonkey?
IPs change quickly so having an external source which is used by
web_infos sound better to me. Also I have a script to download
guarding.p2p files from openmedia.info in my cron.
Infos about those script are available there:
http://www.openmedia.info/p23.html
Can I close this bug?
|
Wed 18 May 2005 05:42:16 PM UTC, comment #10:
They are also included in the smaller guarding.p2p (search for example for INRIA).
|
Wed 18 May 2005 02:08:18 AM UTC, comment #9:
I thought only the guardin-full.p2p had the problem of universities being entered?
|
Sat 02 Apr 2005 08:13:27 AM UTC, comment #8:
asking for a special list from the guy resposible for the guarding.p2p site mentioned by spiralvoice should be the proper way to get something done as he already maintains a list
theres even a thread in the forum where he notifies about updates
btw some ip ranges should be always blocked by allow_local_network = false such as the private ips mentioned before
also should be blocked are "for research only" ips such as the experimental multicast ips http://www.iana.org/assignments/multicast-addresses
and the Internet Host Loopback 89.0.0.0-127.255.255.255
|
Fri 01 Apr 2005 11:46:18 PM UTC, comment #7:
the guardin.p2p list from that site includes ips that are not actively hurting p2p-networks/clients but include net-blocks that are owned by universities and so on... i thought of a much smaller hand-verified list.
|
Fri 01 Apr 2005 11:30:37 PM UTC, comment #6:
Maybe we can use a list from this site: http://www2.openmedia.info:8080/p23.html
|
Fri 01 Apr 2005 10:55:01 PM UTC, comment #5:
oh, yea private ips get filtered by Ip.reachable . but there are still some ips no one would want to connect to (for example known p2p-network atacker with static ip, otherwise reserved netblocks ...). for these it would be usefull to distribute a small guarding.p2p with mldonkey.
|
Fri 01 Apr 2005 09:32:26 PM UTC, comment #4:
Shouldn´t MLDonkey be able to filter them out correctly using IP.valid and IP.reachable?
|
Wed 16 Mar 2005 01:37:49 AM UTC, comment #3:
just put these ranges in the guarding.p2p . mldonkey may be used on the local network after all. but we should perhaps distribute a small guarding.p2p (with some ips that we are realy realy sure about we never would want to be connected to)
|
Sat 21 Aug 2004 11:59:05 AM UTC, comment #2:
Please check if this bug still is in current CVS version.
You should find a tarball of current CVS in files section of
this project: http://savannah.nongnu.org/download/mldonkey/
|
Sat 12 Jun 2004 09:03:33 AM UTC, comment #1:
I have seen sources from all "illegal" networks.
According to RFC 1918, you can use the following IP networks for private nets which will never be connected to the Internet:
10.0.0.0 - 10.255.255.255
172.16.0.0 - 172.31.255.255
192.168.0.0 - 192.168.255.255
Clients can be behind the NAT gateway and FT implementation does not take consider about this.
|
Fri 27 Feb 2004 11:06:34 AM UTC, original submission:
Why do I get a lot of these IPs as source? Can they not be filtered?
$ grep 192.168 file_sources.ini|sort|uniq
addr = ("192.168.0.152", 9952)
addr = ("192.168.0.83", 8130)
addr = ("192.168.1.100", 4662)
addr = ("192.168.1.100", 8662)
addr = ("192.168.1.101", 4682)
addr = ("192.168.1.12", 11854)
addr = ("192.168.1.12", 4662)
addr = ("192.168.1.15", 4662)
addr = ("192.168.1.2", 4661)
addr = ("192.168.1.2", 4662)
addr = ("192.168.1.218", 13240)
addr = ("192.168.1.5", 14954)
addr = ("192.168.100.101", 4772)
addr = ("192.168.222.2", 4662)
addr = ("192.168.3.9", 16923)
addr = ("192.168.69.1", 12064)
addr = ("192.168.69.1", 4662)
addr = ("192.168.99.101", 4662)
|