ipfilter.dat compability (Azureus, uTorrent, BitComet, etc)

[anonymous]

A IP blocking capability like that of many popular clients would be useful. Alot of people in scandinavia have DMZs, or "DeMilitarized? Zones" where network traffic can be exchanged free of charge, and the rest of the internet has limits. Universities, citities, or sometimes even whole countries (Iceland?) have DMZs where the users enjoy unlimited bandwidth, it would be very useful for these users if they could filter out unwanted IP address ranges that fall outside of their DMZ. Some private trackers also ban all clients wich does not support this feature, and thus *nix users are forced to use the bloated Azureus.

KTorrent has a IP blocking plugin as of 1.2, it's written i C++ (perhaps it even uses libtorrent?) and the code for the IP blocking plugin can be used as reference.  http://ktorrent.pwsp.net

[rakshasa]

There's a hook in libtorrent to allow filtering, but it is not being used atm.

Also, ktorrent has their own library called libtorrent.

[anonymous]

gi

[anonymous]

i meant to say hi

[anonymous]

Hi,

Is there a chance that this can be implemented easily somehow externally (other than using a firewall like software) in freebsd? I do not want to use ipfw or tcp wrappers?

[anonymous]

bump! IMHO filtering is essential, there are too many stats gathers bogons, and other organisations using intrusive torrent monitoring for it to be resonable to NOT including filter list support.

[anonymous]

I liked rtorrent at first sight, thank you very much for your work! Unfortunately i can't use it without IP filtering support, hope it will be implemented sometime. Until then can anyone recommend console based client for FreeBSD compatible with IPfilter.dat?

[anonymous]

Filtering is not a feature which belongs to the software, but to the underlying levels. If you want to filter certain IPs, go and use iptables!

BTW, someone who only wants connection to certain IPs didn\' really understand the concept of the Bittorrent protocol.

[anonymous]

IP filtering is very important, no one likes being monitored. So i've discontinued the use of rTorrent until the developers implement it. Hope it happens soon.

[anonymous]

Replying to anonymous:

Filtering is not a feature which belongs to the software, but to the underlying levels. If you want to filter certain IPs, go and use iptables! BTW, someone who only wants connection to certain IPs didn\' really understand the concept of the Bittorrent protocol.

I disagree. iptables/ipchains filters at the server level, not the application level. This is not what a lot of people want - for all sorts of legitimate reasons.

[anonymous]

would like to see this feature in the client as well. tried to solve this via iptables, but putting the blocked ip ranges from a normal filter file (~10mb of ip ranges) into iptables rules is a bad idea since it's only needed for p2p apps. there's no need to let iptables walk through all those ranges for every connection of every app.

[hansy]

i tried iptables but it didn't work. iptables = big slowdown! hell, with iptables like in bittorrent, i almost crashed linux. iptables is not designed for performance i guess.

to bad rtorrent does not have that feature, since it's a standard feature nowadays.

[anonymous]

iptables handles GBit/s with virtually no load, you must have set it wrong.

It's a "standard feature" on Windows, where setting up any kind of firewall is a PITA, but on Linux it wouldn't make sense to rewrite iptables in user space.

Keep working on a solution based on iptables, check out some Linux user group and get some help to set it up.

[anonymous]

May I post this piece of research here?

"P2P:Is Big Brother Watching You?"  http://www1.cs.ucr.edu/store/techreports/UCR-CS-2006-06201.pdf

The answer is that you ARE being watched and that blocking bogons is solves most of that. The bogon-list has over 6000 lines which I don't really want to load in an ipfw table.

[anonymous]

there're a lot of workaround to let rtorrent works on different devices (atv, nas etc.) which can't handle iptables\peerguardian\whatever. Since most of people can't leave without ipfiltering (I'm one of them) a native ipfilter.dat support (hopefully with autoupdating capability) would be so muche appreciated!

[anonymous]

there is no problem to restrict uploading by iptables. but i have no ideas how to restrict downloading.

[anonymous]

Another request for this capability.

Thanks

[anonymous]

Any ideas as to why this hasn't been touched for two years? rtorrent is the best torrent client I've used but I've been forced to abandon it until this is resolved.

[anonymous]

Use iptables, it seems a lot of you just have no idea how to do this properly.

[anonymous]

One simple but powerful way to quickly check many IP addresses in iptables is to use ipt_recent and populate the table by writing to /proc/net/ipt_recent/<name> directly. You'll probably have to tweak the ip_list_tot (to the number of IP addresses) and ip_pkt_list_tot settings (to 1 so as to conserve memory) kernel settings, if the list has >100 addresses. See man iptables. However ipt_recent uses a hash table to store the IP addresses so the lookup doesn't take longer with more addresses. I'd still recommend testing it only for new connections and not every single packet (-m state --state NEW).

[anonymous]

Iptables will work for all applications on the server. Yes, you can limit its filtering on specific port(s). For incoming connections it would work, but the idea is to limit or filter outgoing connections as well, but for rtorrent only. So it must be an application function, not system.

[anonymous]

iptables are not made for this, it should be on the application level, in this case rtorrent.

[comer]

Hi all,

I implemented ip filter for rtorrent. I'm not sure how to submit the sources, but if there's interest I can post them here. Implementation supports standard ip range files from bluetack. Supports multiple files. "Reload" command is implemented to use with "schedule". Lemme know.

comer

[berti]

Hi comer,

did you release your patch ?

[comer]

Nope. I dont know how.

[anonymous]

Ok, I will just attach diffs and new files. Hang on.

[comer]

changes to src/command_network.cc

[comer]

changes to src/core/Makefile.am

[comer]

changes to src/core/manager.cc

[comer]

changes to src/core/manager.h

[comer]

new files to be added to src/core/

[comer]

Here it is. First, Disclaimer: I assume no responsibility whatsoever explicit or implied if you use the attached and/or follow my instructions. Please review carefully and use at your own discretion.

The diffs are for existing files, taken from ver 0.8.2 package. The tar is a set of new files with directories (src/core basically). NOTE: Requires Boost ( http://www.boost.org/users/download/) for regular expression parsing and some string manipulation. No fear, it's only a set of headers, no compiled libraries :) By default it installs in /usr/local/boost_1_35_0/boost. If that happens, just "mv /usr/local/boost_1_35_0/boost /usr/local" and "rmdir /usr/local/boost_1_35_0".

Usage:

The filter files are the ones from bluetack.co.uk. Multiple files can be used. Overlapping ranges are merged automatically. Both incoming and outgoing connections are checked against the filter. Exclusions are not supported, so connection to/from IPs in all the loaded ranges will be disallowed and dropped.

Include "ip_filter=<file,...>" directive in .rtorrent.rc. For example mine looks like:

---

ip_filter=ipfilter/level1,ipfilter/level2,ipfilter/bogon,ipfilter/dshield,ipfilter/Microsoft,ipfilter/templist

---

It is probably a good idea to reload files once in a while, so you can also include "reload_ip_filter" directive on schedule to refresh the filter. The same files named in "ip_filter" will be reloaded.

---

schedule = filter,18:30:00,24:00:00,reload_ip_filter=

---

To support the feature you may want to setup cron job to reload and unzip files from bluetack. I personally use the following script:

---

#! /bin/bash
for f in $(find ~/ipfilter/ -regex '.*/[^\./]+' -printf '%f\n'); do
        echo -n Processing $f...
        wget -q -t 3 -P ipfilter http://www.bluetack.co.uk/config/$f.gz
        if [ $? != 0 ] ; then
                echo can not be retrieved
        else
                gzip -dfq ipfilter/$f.gz 2>/dev/null
                if [ $? != 0 ] ; then
                        echo unzip error
                else
                        echo done
                fi
        fi
done
exit 0

---

So you can see, I once "preload" files manually I want in "~/ipfilter" dir and then let the script reload those same files on cron schedule.

For developers: I tested the filter (alone) with Valgrind. No leaks, no corruption. If you want to test on your own I included "ip_filter_test.cc" with same test cases. Of course, this file is not needed for rtorrent, it's only for your experiments/tests.

Have a good one.
comer
=====

[comer]

changes to src/command_network.cc

[comer]

changes to src/command_network.cc

[comer]

Sorry guys, the command_network diff would remove one extra line, which I played with during testing, so please use the last one srccommand_network.cc.2.diff

comer
=====

PS: I can't replace the attachment once it's there - administrative privileges required.

[anonymous]

Just a hint, next time simply do "svn diff > foo.diff" and you'll get it all in one file. You'll need to "svn add" the new files first (you can do that on your local checkout even if you don't have commit access). That'll also make it easier to make a diff for future revisions of rtorrent, just svn update and svn diff again (after fixing any conflicts) and it makes it MUCH easier to use the patch, with only one file to download and one patch command to call.

If you want to submit the patch for inclusion in rtorrent, you'll have to learn rakshasa's coding style. Try to do get rid of the boost dependency (use the rak/* headers for regexes etc.). Learn about the coding style from existing code, especially regarding placement of parenthesis and braces in "if" and "for" statements and the like. Also inline functions in .h files are either one line in the class definition or multi-line below it. The order in a class definition is types first, then public member fns and private member fns, finally fields. Don't use tabs, indentation is two spaces. Don't put things like "range_map" in the core namespace, they should go in the IpFilter class. range_map should probably store the IpRange directly instead of a pointer to it, to avoid unnecessary indirections and it also eliminates the need for static void clear(range_map* map). What is the need for the Printable base class?

That is all presuming rakshasa is actually interested in it, you might want to first email or IRC to find out before revising the patch.

[comer]

I didn't want to install svn just for the sake of diff. If I had access to real repository I would use svn client.

I emailed rakshasa a while ago, he didn't respond. Besides, I posted it not for rakshasa (though he may be interested), but for people such as myself who find ip filter is a must in torrent client.

Pointer is generally faster and safer, because with straight value it is easy to miss implicit call to copy constructor. I have no problem with managing pointers.

I agree with type declarations - they belong to IpFilter?.

Printable - is to define one operator << for ostream and any class that implements it (logging, debugging...).

Coding style... yes, it would be nice of me to use the existing one exactly, but I concentrated on functionality first and decided it was hard enough for me to use underscored names and I didn't want to spend more time to refactor placement of parenthesis and braces.

Feel free to get rid of Boost. What would you use instead?

[anonymous]

Replying to comer:

I didn't want to install svn just for the sake of diff. If I had access to real repository I would use svn client.

Well, the repository has anonymous read access. See Download.

Feel free to get rid of Boost. What would you use instead?

I'm not sure what else you use from it, but for regex there's rak/regex.h and for string ops you have rak/string_manip.h.

Not that it really matters if rakshasa isn't interested though.

[anonymous]

Replying to anonymous:

Replying to comer:

I didn't want to install svn just for the sake of diff. If I had access to real repository I would use svn client.

Well, the repository has anonymous read access. See Download.

Point taken, I did not look hard enough :)

Feel free to get rid of Boost. What would you use instead?

I'm not sure what else you use from it, but for regex there's rak/regex.h and for string ops you have rak/string_manip.h.

It's not even close :) It can not break string into matching groups and as far as I can tell it only supports '*' out of whole bananza of regex. Correct me if I'm wrong. Trim can be replaced, yes, but since I already dependent on Boost why not use it's facilities.

Not that it really matters if rakshasa isn't interested though.

True, true. I think those anxious enough to have ip filter can live with Boost :))

[rakshasa]

I never even bothered looking at the stuff you sent cause it wasn't diffed, and it was tared.

[berti]

Comer,

thank you very much. I had severe trouble compiling it with g++ 3.4.6. The solution was using version 4.1.2.

Tahank you Berti

[anonymous]

Hi all, I have rtorrent running, and it works like a charm. I have added the info from above to my .rtorrent.rc But I am somewhat of a newbie and do not understand what to do with the "rtorrent-ip_filter.tar.gz". I cannot find src/core? I am running suse 10.3 and am wondering if someone could point me to the right direction.

Thanks in advance

[anonymous]

You need to download the sources for rtorrent, and compile it yourself after merging in the patch posted here.

[anonymous]

Replying to anonymous:

Hi all, I have rtorrent running, and it works like a charm. I have added the info from above to my .rtorrent.rc But I am somewhat of a newbie and do not understand what to do with the "rtorrent-ip_filter.tar.gz". I cannot find src/core? I am running suse 10.3 and am wondering if someone could point me to the right direction. Thanks in advance

1. Download both libtorrent-0.12.2.tar.gz and rtorrent-0.8.2.tar.gz.
2. Run

tar -xzvf libtorrent-0.12.2.tar.gz
tar -xzvf rtorrent-0.8.2.tar.gz

This will create two subdirs "libtorrent-0.12.2" and "rtorrent-0.8.2"

3. Do

chdir libtorrent-0.12.2
./configure
make
sudo make install

assuming there's no errors in the process.

4. From the previous directory do

chdir rtorrent-0.8.2.

5. Put ".diff" and ".tar.gz" files of the patch in this dir if they are not already there.
6. Run

patch -b src/command_network.cc src__command_network.cc.2.diff
patch -b src/core/manager.cc src__core__manager.cc.diff
patch -b src/core/manager.h src__core__manager.h.diff
patch -b src/core/Makefile.am src__core__Makefile.am.diff
tar -xzvf rtorrent-ip_filter.tar.gz

7. Do

./configure
make

8. You should have executable rtorrent in the current dir now. Either do make install (the you just start as rtorrent) or copy wherever suitable (then start from that directory ./rtorrent).
9. Don't forget to enjoy! :))

comer
=====

[comer]

Replying to anonymous:

Hi all, I have rtorrent running, and it works like a charm. I have added the info from above to my .rtorrent.rc But I am somewhat of a newbie and do not understand what to do with the "rtorrent-ip_filter.tar.gz". I cannot find src/core? I am running suse 10.3 and am wondering if someone could point me to the right direction. Thanks in advance

Just in case you forgot about Boost before making rtorrent (steps 5 to 9 above):
1. Download  boost.
2. Untar/zip it depending on what package you downloaded. If .tar.gz then as before run

tar -xzvf boost_1_35_0.tar.gz

3. Do

chdir boost_1_35_0
./configure
make
sudo make install

4. In my case it installed headers in /usr/local/include/boost_1_35_0/boost, whereas it itself expect it to be just /usr/local/include/boost. Check ls /usr/local/include. If boost_1_35_0 is there, no big deal, do

sudo mv /usr/local/include/boost_1_35_0/boost /usr/local/include/
sudo rmdir /usr/local/include/boost_1_35_0

comer
=====

[anonymous]

I have followed the instructions above, and everything seems to do OK, except for the final make of rtorrent when I get this:

make make all-recursive make[1]: Entering directory `/downloads/rtorrent files/rtorrent-0.8.2' Making all in doc make[2]: Entering directory `/downloads/rtorrent files/rtorrent-0.8.2/doc' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/downloads/rtorrent files/rtorrent-0.8.2/doc' Making all in src make[2]: Entering directory `/downloads/rtorrent files/rtorrent-0.8.2/src' Making all in core make[3]: Entering directory `/downloads/rtorrent files/rtorrent-0.8.2/src/core'

cd ../.. && automake-1.10 --gnu src/core/Makefile

/bin/sh: line 10: automake-1.10: command not found make[3]: *** [Makefile.in] Error 127 make[3]: Leaving directory `/downloads/rtorrent files/rtorrent-0.8.2/src/core' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/downloads/rtorrent files/rtorrent-0.8.2/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/downloads/rtorrent files/rtorrent-0.8.2' make: *** [all] Error 2

Not sure what is causing this. I am installing on the following system. Intel pentium D 805 2 gigs of Ram 74 gig WD raptor Suse 10.3 64bit with KDE Kernel 2.6.22.17-0.1-default smp I have all the required compile packages installed.

Any help would be great.

Thanks

[anonymous]

Sorry thats not what it looked like when I entered it.

[anonymous]

Try running autogen.sh

[anonymous]

I get aclocal not found. yet there is an aclocal.m4 listed

[anonymous]

Install autoconf and automake then. You need them when the Makefile must be remade, like in this case.

[anonymous]

Almost there... I got the following errors after make:

make all-recursive

make[1]: Entering directory `/downloads/rtorrent files/rtorrent-0.8.2'

Making all in doc

make[2]: Entering directory `/downloads/rtorrent files/rtorrent-0.8.2/doc'

make[2]: Nothing to be done for `all'.

make[2]: Leaving directory `/downloads/rtorrent files/rtorrent-0.8.2/doc'

Making all in src

make[2]: Entering directory `/downloads/rtorrent

files/rtorrent-0.8.2/src'

Making all in core

make[3]: Entering directory `/downloads/rtorrent

files/rtorrent-0.8.2/src/core'

g++ -DHAVE_CONFIG_H -I. -I../.. -I. -I./.. -I../.. -g -O2 -g -DDEBUG
-I/usr/include/sigc++-2.0 -I/usr/lib64/sigc++-2.0/include -I/usr/include/libtorrent -MT dht_manager.o -MD -MP -MF .deps/dht_manager.Tpo -c -o dht_manager.o dht_manager.cc

make[3]: Leaving directory `/downloads/rtorrent files/rtorrent-0.8.2/src/core'

make[2]: Leaving directory `/downloads/rtorrent files/rtorrent-0.8.2/src'

make[1]: Leaving directory `/downloads/rtorrent files/rtorrent-0.8.2'

[comer]

Umm... where's the error?

[anonymous]

Sorry, I'm not a programmer and when I saw this output, I assumed there was something else wrong. Glad to know its ok then.. Thanks for your help

[comer]

No problem :) hope it works for ya

[anonymous]

Hi comer, you've been a big help, and I thought I wouldn't have anymore issues but I am. I am going to attach a txt file for you to read called "make errors.txt" It was just looking like crap when I previewed it here.

./configure gave me no problems what so ever, but 'make' gave me errors, and I could go no further.

Thanks again.

[anonymous]

It seems you have not built and/or installed the libtorrent (step 3 in my post #36). Btw, I don't think attaching error log is a good idea. Next time you can just use the "code block" (see the square lined icon in the reply editor) :)

[anonymous]

Hi again, I did install libtorrent and it seemed to have gone smoothly, but when I check the version number its not 12.2 but 11.9. I'm not sure what is going on with this. Being a linux noob can be awfully frustrating.

[comer]

No fear, it's not a rocket science, you can do it :)) Make sure you downloaded libtorrent 12.2, after untar you have 12.2 directory and you ./configure, make and make install from it. Did "make install" give you any problems? You run it under "sudo" did you?

[anonymous]

I ran everything under root. And I did not see any errors or problems when I installed libtorrent.

[comer]

oh-oh, working under root is not such a good idea. anyway, do you see "/usr/local/include/torrent/dht_manager.h" and "/usr/local/include/torrent/peer/connection_list.h"? If not, there's something wrong with libtorrent installation. Did you unpack the tar file included here? If not, unpack and check "./src/core/ip_filter.h" does exist. Start from scratch - create a new dir in your home (you'd better create a regular user for work), say "src", download rtorrent package and build without ip_filter. Is it successfull?

[anonymous]

Is it possible to use the patch with libtorrent 0.11.9 / rtorrent 0.7.9? If not, could you please provide something to make it work this version? Thanks in advance

[anonymous]

I think it's hardly worth the effort. Why would you go back in version?

[anonymous]

Cause it's a stable version and 0.8.2 is not allowed on my favorite tracker. I'd really love to use rtorrent, but without that function i'm going to wait.

[quew]

Great! I re-installed rtorrent with the above patches and it works like a charm! Will this be included in upcoming official releases?

[anonymous]

I am happy to see that 8.2 is out for my version of linux from the repository. What I am having problems with now is when I start rtorrent I get "rtorrent: Error in option file: ~/.rtorrent.rc:96: Command "ip_filter" does not exist." Is there something that I need to change? I pasted the options above for ip_filter in the .rtorrent.rc file. If I # them out, rtorrent works, but without filtering. Any help would be great. Thanks

[anonymous]

You need to get the rtorrent source, apply the above patches and recompile. It's not in standard rtorrent.

[anonymous]

I second quew request: any chance will be included in next official release?

[glen]

Request thirded, I can't use a client without this feature.

[anonymous]

From the looks of it, it may get included when the author (or whoever else) makes it conform to rtorrent's coding style. A start would be to make it into one patch, and make it against svn (ideally both at once using "svn diff"). Getting rid of the boost dependency would probably help too, or otherwise it would need to be added properly to the configure checks.

[anonymous]

When I compile rtorrent 0.8.2 with ipfilter patch (also with gcc4.3 patch, my OS is Debian Lenny, gcc 4.3) I got following errors:

se -lxmlrpc_xmltok 
mkdir .libs
g++ -g -O2 -g -DDEBUG -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -I/usr/include -o rtorrent command_download.o comman
d_events.o command_file.o command_helpers.o command_local.o command_network.o command_peer.o command_tracker.o command_scheduler.o
 command_ui.o control.o globals.o main.o option_parser.o signal_handler.o  ../src/ui/libsub_ui.a ../src/core/libsub_core.a ../src/
display/libsub_display.a ../src/input/libsub_input.a ../src/rpc/libsub_rpc.a ../src/utils/libsub_utils.a -lncurses /usr/lib/libcur
l-gnutls.so /usr/lib/libtorrent.so -lcrypto /usr/lib/libsigc-2.0.so -L/usr/lib /usr/lib/libxmlrpc_server.so -L.libs -L/build/build
d/xmlrpc-c-1.06.27/src/../lib/libutil/.libs /usr/lib/libxmlrpc.so /usr/lib/libxmlrpc_util.so /usr/lib/libxmlrpc_xmlparse.so /usr/l
ib/libxmlrpc_xmltok.so  
command_network.o: In function `IpFilter':
/home/b3nd3r/my/src/rtorrent-0.8.2/src/core/ip_filter.h:41: undefined reference to `vtable for core::IpFilter'
command_network.o: In function `apply_ip_filter(torrent::Object const&)':
/home/b3nd3r/my/src/rtorrent-0.8.2/src/command_network.cc:134: undefined reference to `core::IpFilter::add_from_file(std::basic_st
ring<char, std::char_traits<char>, std::allocator<char> > const&)'
command_network.o: In function `~IpFilter':
/home/b3nd3r/my/src/rtorrent-0.8.2/src/core/ip_filter.h:42: undefined reference to `vtable for core::IpFilter'
command_network.o: In function `core::IpFilter::clear()':
/home/b3nd3r/my/src/rtorrent-0.8.2/src/core/ip_filter.h:68: undefined reference to `core::IpFilter::clear(std::map<core::IpAddress
 const, core::IpRange*, std::less<core::IpAddress const>, std::allocator<std::pair<core::IpAddress const, core::IpRange*> > >*)'
/home/b3nd3r/my/src/rtorrent-0.8.2/src/core/ip_filter.h:68: undefined reference to `core::IpFilter::clear(std::list<std::basic_str
ing<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allo
cator<char> > > >*)'
../src/core/libsub_core.a(manager.o): In function `~IpFilter':
/home/b3nd3r/my/src/rtorrent-0.8.2/src/core/ip_filter.h:42: undefined reference to `vtable for core::IpFilter'
../src/core/libsub_core.a(manager.o): In function `core::IpFilter::clear()':
/home/b3nd3r/my/src/rtorrent-0.8.2/src/core/ip_filter.h:68: undefined reference to `core::IpFilter::clear(std::map<core::IpAddress
 const, core::IpRange*, std::less<core::IpAddress const>, std::allocator<std::pair<core::IpAddress const, core::IpRange*> > >*)'
/home/b3nd3r/my/src/rtorrent-0.8.2/src/core/ip_filter.h:68: undefined reference to `core::IpFilter::clear(std::list<std::basic_str
ing<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allo
cator<char> > > >*)'
../src/core/libsub_core.a(manager.o): In function `core::Manager::reload_ip_filter()':
/home/b3nd3r/my/src/rtorrent-0.8.2/src/core/manager.cc:574: undefined reference to `core::IpFilter::reload()'
../src/core/libsub_core.a(manager.o): In function `~IpFilter':
/home/b3nd3r/my/src/rtorrent-0.8.2/src/core/ip_filter.h:42: undefined reference to `vtable for core::IpFilter'
../src/core/libsub_core.a(manager.o): In function `core::IpFilter::clear()':
/home/b3nd3r/my/src/rtorrent-0.8.2/src/core/ip_filter.h:68: undefined reference to `core::IpFilter::clear(std::map<core::IpAddress
 const, core::IpRange*, std::less<core::IpAddress const>, std::allocator<std::pair<core::IpAddress const, core::IpRange*> > >*)'
/home/b3nd3r/my/src/rtorrent-0.8.2/src/core/ip_filter.h:68: undefined reference to `core::IpFilter::clear(std::list<std::basic_str
ing<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allo
cator<char> > > >*)'
../src/core/libsub_core.a(manager.o): In function `core::Manager::filter_ip(sockaddr const*)':
/home/b3nd3r/my/src/rtorrent-0.8.2/src/core/manager.cc:160: undefined reference to `core::IpFilter::find_range(int) const'
collect2: ld returned 1 exit status
make[3]: *** [rtorrent] Ошибка 1
make[3]: Leaving directory `/home/b3nd3r/my/src/rtorrent-0.8.2/src'
make[2]: *** [all-recursive] Ошибка 1
make[2]: Leaving directory `/home/b3nd3r/my/src/rtorrent-0.8.2/src'
make[1]: *** [all-recursive] Ошибка 1
make[1]: Leaving directory `/home/b3nd3r/my/src/rtorrent-0.8.2'
make: *** [all] Ошибка 2

[anonymous]

Ошибка = Error

[anonymous]

I also have got errors:

make[3]: Entering directory `/home/grant/src/rtorrent/rtorrent-0.8.2/src/display'
g++ -DHAVE_CONFIG_H -I. -I../.. -I. -I./.. -I../..    -g -O2 -g -DDEBUG -I/opt/libtorrent/include -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include   -MT window_download_statusbar.o -MD -MP -MF .deps/window_download_statusbar.Tpo -c -o window_download_statusbar.o window_download_statusbar.cc
In file included from window_download_statusbar.cc:42:
/opt/libtorrent/include/torrent/tracker_list.h:135: error: expected unqualified-id before ‘&’ token
/opt/libtorrent/include/torrent/tracker_list.h:135: error: expected ‘,’ or ‘...’ before ‘&’ token
make[3]: *** [window_download_statusbar.o] Ошибка 1
make[3]: Leaving directory `/home/grant/src/rtorrent/rtorrent-0.8.2/src/display'
make[2]: *** [all-recursive] Ошибка 1
make[2]: Leaving directory `/home/grant/src/rtorrent/rtorrent-0.8.2/src'
make[1]: *** [all-recursive] Ошибка 1
make[1]: Leaving directory `/home/grant/src/rtorrent/rtorrent-0.8.2'
make: *** [all] Ошибка 2

and, I think it didn't connected with ipfilter

p.s. OS=Debian Lenny

[anonymous]

rTorrent can't import more than 64 ranges from ipfilter file. my ipfilter with 210 ranges. If i use ipfilter with 7 ranges (simple version, more agressive), then rtorrent cant't block all ip, some ip are not blocked. In uTorrent and Azureus ipfilter with 7 ranges work and all ip blocked, but uTorrent is only for windows and Azureus is too slow on my PC.

[anonymous]

Thank you, comer, for the patch.

[anonymous]

Hi. Is there a way to see whether ipfilter is working (while rTorrent is running), that is, whether it is blocking any IPs? Is there any logging capability (to a log file, for example) like PeerGuardian? has, or something similar? Or maybe it exists already but I didn't find it. Regards.

[anonymous]

Replying to anonymous:

I also have got errors: {{{ make[3]: Entering directory `/home/grant/src/rtorrent/rtorrent-0.8.2/src/display' g++ -DHAVE_CONFIG_H -I. -I../.. -I. -I./.. -I../.. -g -O2 -g -DDEBUG -I/opt/libtorrent/include -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -MT window_download_statusbar.o -MD -MP -MF .deps/window_download_statusbar.Tpo -c -o window_download_statusbar.o window_download_statusbar.cc In file included from window_download_statusbar.cc:42: /opt/libtorrent/include/torrent/tracker_list.h:135: error: expected unqualified-id before ‘&’ token /opt/libtorrent/include/torrent/tracker_list.h:135: error: expected ‘,’ or ‘...’ before ‘&’ token make[3]: *** [window_download_statusbar.o] Ошибка 1 make[3]: Leaving directory `/home/grant/src/rtorrent/rtorrent-0.8.2/src/display' make[2]: *** [all-recursive] Ошибка 1 make[2]: Leaving directory `/home/grant/src/rtorrent/rtorrent-0.8.2/src' make[1]: *** [all-recursive] Ошибка 1 make[1]: Leaving directory `/home/grant/src/rtorrent/rtorrent-0.8.2' make: *** [all] Ошибка 2 }}} and, I think it didn't connected with ipfilter p.s. OS=Debian Lenny

you need to add #include <string> to the tracker_list.h file

[anonymous]

Replying to anonymous:

When I compile rtorrent 0.8.2 with ipfilter patch (also with gcc4.3 patch, my OS is Debian Lenny, gcc 4.3) I got following errors: {{{ se -lxmlrpc_xmltok mkdir .libs g++ -g -O2 -g -DDEBUG -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -I/usr/include -o rtorrent command_download.o comman d_events.o command_file.o command_helpers.o command_local.o command_network.o command_peer.o command_tracker.o command_scheduler.o command_ui.o control.o globals.o main.o option_parser.o signal_handler.o ../src/ui/libsub_ui.a ../src/core/libsub_core.a ../src/ display/libsub_display.a ../src/input/libsub_input.a ../src/rpc/libsub_rpc.a ../src/utils/libsub_utils.a -lncurses /usr/lib/libcur l-gnutls.so /usr/lib/libtorrent.so -lcrypto /usr/lib/libsigc-2.0.so -L/usr/lib /usr/lib/libxmlrpc_server.so -L.libs -L/build/build d/xmlrpc-c-1.06.27/src/../lib/libutil/.libs /usr/lib/libxmlrpc.so /usr/lib/libxmlrpc_util.so /usr/lib/libxmlrpc_xmlparse.so /usr/l ib/libxmlrpc_xmltok.so command_network.o: In function `IpFilter?': /home/b3nd3r/my/src/rtorrent-0.8.2/src/core/ip_filter.h:41: undefined reference to `vtable for core::IpFilter?' command_network.o: In function `apply_ip_filter(torrent::Object const&)': /home/b3nd3r/my/src/rtorrent-0.8.2/src/command_network.cc:134: undefined reference to `core::IpFilter::add_from_file(std::basic_st ring<char, std::char_traits<char>, std::allocator<char> > const&)' command_network.o: In function `~IpFilter?': /home/b3nd3r/my/src/rtorrent-0.8.2/src/core/ip_filter.h:42: undefined reference to `vtable for core::IpFilter?' command_network.o: In function `core::IpFilter::clear()': /home/b3nd3r/my/src/rtorrent-0.8.2/src/core/ip_filter.h:68: undefined reference to `core::IpFilter::clear(std::map<core::IpAddress? const, core::IpRange?*, std::less<core::IpAddress? const>, std::allocator<std::pair<core::IpAddress? const, core::IpRange?*> > >*)' /home/b3nd3r/my/src/rtorrent-0.8.2/src/core/ip_filter.h:68: undefined reference to `core::IpFilter::clear(std::list<std::basic_str ing<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allo cator<char> > > >*)' ../src/core/libsub_core.a(manager.o): In function `~IpFilter?': /home/b3nd3r/my/src/rtorrent-0.8.2/src/core/ip_filter.h:42: undefined reference to `vtable for core::IpFilter?' ../src/core/libsub_core.a(manager.o): In function `core::IpFilter::clear()': /home/b3nd3r/my/src/rtorrent-0.8.2/src/core/ip_filter.h:68: undefined reference to `core::IpFilter::clear(std::map<core::IpAddress? const, core::IpRange?*, std::less<core::IpAddress? const>, std::allocator<std::pair<core::IpAddress? const, core::IpRange?*> > >*)' /home/b3nd3r/my/src/rtorrent-0.8.2/src/core/ip_filter.h:68: undefined reference to `core::IpFilter::clear(std::list<std::basic_str ing<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allo cator<char> > > >*)' ../src/core/libsub_core.a(manager.o): In function `core::Manager::reload_ip_filter()': /home/b3nd3r/my/src/rtorrent-0.8.2/src/core/manager.cc:574: undefined reference to `core::IpFilter::reload()' ../src/core/libsub_core.a(manager.o): In function `~IpFilter?': /home/b3nd3r/my/src/rtorrent-0.8.2/src/core/ip_filter.h:42: undefined reference to `vtable for core::IpFilter?' ../src/core/libsub_core.a(manager.o): In function `core::IpFilter::clear()': /home/b3nd3r/my/src/rtorrent-0.8.2/src/core/ip_filter.h:68: undefined reference to `core::IpFilter::clear(std::map<core::IpAddress? const, core::IpRange?*, std::less<core::IpAddress? const>, std::allocator<std::pair<core::IpAddress? const, core::IpRange?*> > >*)' /home/b3nd3r/my/src/rtorrent-0.8.2/src/core/ip_filter.h:68: undefined reference to `core::IpFilter::clear(std::list<std::basic_str ing<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allo cator<char> > > >*)' ../src/core/libsub_core.a(manager.o): In function `core::Manager::filter_ip(sockaddr const*)': /home/b3nd3r/my/src/rtorrent-0.8.2/src/core/manager.cc:160: undefined reference to `core::IpFilter::find_range(int) const' collect2: ld returned 1 exit status make[3]: *** [rtorrent] Ошибка 1 make[3]: Leaving directory `/home/b3nd3r/my/src/rtorrent-0.8.2/src' make[2]: *** [all-recursive] Ошибка 1 make[2]: Leaving directory `/home/b3nd3r/my/src/rtorrent-0.8.2/src' make[1]: *** [all-recursive] Ошибка 1 make[1]: Leaving directory `/home/b3nd3r/my/src/rtorrent-0.8.2' make: *** [all] Ошибка 2 }}}

what fixed this for me was running autogen.sh then configure then make

[Panasonic1]

Hello!

Can you show some examples of ipfilter configs?

[comer]

Hi,

Mine looks like:

ip_filter=ipfilter/level1,ipfilter/level2,ipfilter/bogon,ipfilter/dshield,ipfilter/Microsoft,ipfilter/templist

just a list of files with ranges. See my post #26.

To post #66: I assume you mean 64 files, not ranges. Each file contain a lot of them. For example:

Loading IP filters from 'ipfilter/level1'...done. Loaded 218130 ranges. 4511 ranges were merged.
Loading IP filters from 'ipfilter/level2'...done. Loaded 59561 ranges. 19769 ranges were merged.
Loading IP filters from 'ipfilter/bogon'...done. Loaded 5913 ranges. 851 ranges were merged.
Loading IP filters from 'ipfilter/dshield'...done. Loaded 115 ranges. 5 ranges were merged.
Loading IP filters from 'ipfilter/Microsoft'...done. Loaded 718 ranges. 244 ranges were merged.
Loading IP filters from 'ipfilter/templist'...done. Loaded 1397 ranges. 48 ranges were merged.

I don't know if there's alimit on a number of arguments for configuration command, but 64 range files is more than enough. Bluetack does not even have that many :)

To post #68: (guys, you really should start using nick names :)) yes, the ip filter outputs blocked IPs in log. Press "L" in main screen to view the log (however small it is currently).

comer =====

[Panasonic1]

Hello!

I had installed this ipfilter, but now i have some bugs...

Mine filter is:

NonKT:0.0.0.0-9.255.255.255 NonKT:11.0.0.0-82.200.127.255 NonKT:82.201.0.0-88.204.127.255 NonKT:88.205.0.0-89.217.255.255 NonKT:89.219.0.0-92.45.255.255 NonKT:92.48.0.0-95.55.255.255 NonKT:95.60.0.0-255.255.255.255

But sometimes i have peers from subnets, such as 195.*.*.* or 213.*.*.*

[comer]

Replying to Panasonic1: Do you see messages on console and screens that your filter file has been loaded? Should be similar to what I quoted above, like "Loading...done with so and so ranges". Do you see any messages on the log screen similar to "IP rejected by filter"? How do you know you have connections with the IPs that should be filtered?

comer
=====

[Panasonic1]

Hello agian!

Replying to comer:

Do you see messages on console and screens that your filter file has been loaded?

At start I see messages, that all of ranges were loaded...

(12:39:55) IpFilter is initialized with files: /root/ipfilter.dat
(12:39:55) 7 ranges total. 0 ranges were merged.

Do you see any messages on the log screen similar to "IP rejected by filter"?

Yes, I see... For example

(12:42:25) Address '62.84.63.10' is rejected by IP filter range 'NonKT: [11.0.0.0 - 82.200.127.255]
(12:42:25) Address '91.76.226.129' is rejected by IP filter range 'NonKT: [89.219.0.0 - 92.45.255.255]
(12:42:25) Address '92.112.245.174' is rejected by IP filter range 'NonKT: [92.48.0.0 - 95.55.255.255]
(12:42:25) Address '92.113.78.207' is rejected by IP filter range 'NonKT: [92.48.0.0 - 95.55.255.255]
(12:42:25) Address '90.151.19.41' is rejected by IP filter range 'NonKT: [89.219.0.0 - 92.45.255.255]
(12:42:25) Address '90.188.64.123' is rejected by IP filter range 'NonKT: [89.219.0.0 - 92.45.255.255]
(12:42:25) Address '93.81.136.195' is rejected by IP filter range 'NonKT: [92.48.0.0 - 95.55.255.255]
(12:42:25) Address '92.125.29.136' is rejected by IP filter range 'NonKT: [92.48.0.0 - 95.55.255.255]
(12:42:55) Address '89.12.71.150' is rejected by IP filter range 'NonKT: [88.205.0.0 - 89.217.255.255]
(12:42:55) Address '84.108.80.129' is rejected by IP filter range 'NonKT: [82.201.0.0 - 88.204.127.255]
(12:42:55) Address '91.76.226.129' is rejected by IP filter range 'NonKT: [89.219.0.0 - 92.45.255.255]
(12:42:55) Address '77.126.179.190' is rejected by IP filter range 'NonKT: [11.0.0.0 - 82.200.127.255]

But i don't see rejections of this rule

NonKT:95.60.0.0-255.255.255.255

Other rules works with no problem...

How do you know you have connections with the IPs that should be filtered?

By latest rule in my filner i should't have IPs from range 95.60.0.0-255.255.255.255 But in peer list i see, that IPs from this range is downloading\uploading some data from mine machine...

netstat says the same...

I think it is a bug in a filter, so i decided to report it...

With best regards, Panasonic1

[comer]

Replying to Panasonic1:

By latest rule in my filner i should't have IPs from range 95.60.0.0-255.255.255.255 But in peer list i see, that IPs from this range is downloading\uploading some data from mine machine... netstat says the same... I think it is a bug in a filter, so i decided to report it...

Thanks, Panasonic1! I will looks into it...

comer
=====

[spil]

Having problems implementing this set of patches on FreeBSD-7.0-p3.
The vanilla libtorrent-devel-0.12.2 and rtorrent-devel-0.8.2 ports install and run fine.

Process to implement IpFilter?
Installed  http://www.freshports.org/devel/boost/ from ports
libtorrent-0.12.2 is installed from ports
Downloaded the patches, result:

-rw-r--r--  1 root  wheel  4820 May 28 14:59 rtorrent-ip_filter.tar.gz
-rw-r--r--  1 root  wheel  3160 May 28 15:19 src__command_network.cc.2.diff
-rw-r--r--  1 root  wheel   475 May 28 14:57 src__core__Makefile.am.diff
-rw-r--r--  1 root  wheel  1871 May 28 14:58 src__core__manager.cc.diff
-rw-r--r--  1 root  wheel  1087 May 28 14:58 src__core__manager.h.diff

Untarred the distributed rtorrent-0.8.2.tar.gz and applied patches/added files from rtorrent-ip_filter.tar.gz

# tar zxf /usr/ports/distfiles/rtorrent-0.8.2.tar.gz
# mv rtorrent-0.8.2 rtorrent-ip_filter
# tar zxf rtorrent-ip_filter.tar.gz
# cd rtorrent-ip_filter
# patch src/command_network.cc ../src__command_network.cc.2.diff
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- rtorrent-0.8.2-org/src/command_network.cc  2008-05-07 08:19:11.000000000 -0400
|+++ rtorrent-ip_filter/src/command_network.cc  2008-05-17 19:46:36.964555772 -0400
--------------------------
Patching file src/command_network.cc using Plan A...
Hunk #1 succeeded at 36.
Hunk #2 succeeded at 66.
Hunk #3 succeeded at 103.
Hunk #4 succeeded at 426.
done
# patch src/core/manager.cc ../src__core__manager.cc.diff
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- rtorrent-0.8.2-org/src/core/manager.cc     2008-05-07 08:19:11.000000000 -0400
|+++ rtorrent-ip_filter/src/core/manager.cc     2008-05-17 19:46:36.964555772 -0400
--------------------------
Patching file src/core/manager.cc using Plan A...
Hunk #1 succeeded at 150.
Hunk #2 succeeded at 191.
Hunk #3 succeeded at 236.
Hunk #4 succeeded at 568.
done
# patch src/core/manager.h ../src__core__manager.h.diff
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- rtorrent-0.8.2-org/src/core/manager.h      2008-05-07 08:19:11.000000000 -0400
|+++ rtorrent-ip_filter/src/core/manager.h      2008-05-17 19:46:54.965581592 -0400
--------------------------
Patching file src/core/manager.h using Plan A...
Hunk #1 succeeded at 44.
Hunk #2 succeeded at 109.
Hunk #3 succeeded at 148.
done
# patch src/core/Makefile.am ../src__core__Makefile.am.diff
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- rtorrent-0.8.2-org/src/core/Makefile.am    2008-05-07 08:19:11.000000000 -0400
|+++ rtorrent-ip_filter/src/core/Makefile.am    2008-05-17 16:59:20.849853381 -0400
--------------------------
Patching file src/core/Makefile.am using Plan A...
Hunk #1 succeeded at 35.
done

Next I ./configure and then make resulting in the following error:

g++ -g -O2 -g -DDEBUG -I/usr/local/include/sigc++-2.0 -I/usr/local/lib/sigc++-2.0/include -I/usr/local/include -o rtorrent command_download.o command_events.o command_file.o command_helpers.o command_local.o command_network.o command_peer.o command_tracker.o command_scheduler.o command_ui.o control.o globals.o main.o option_parser.o signal_handler.o -rpath=/usr/lib:/usr/local/lib  ../src/ui/libsub_ui.a ../src/core/libsub_core.a ../src/display/libsub_display.a ../src/input/libsub_input.a ../src/rpc/libsub_rpc.a ../src/utils/libsub_utils.a -lncursesw -L/usr/local/lib /usr/local/lib/libcurl.so -lssl -lz /usr/local/lib/libtorrent.so -lcrypto /usr/local/lib/libsigc-2.0.so   -Wl,--rpath -Wl,/usr/local/lib -Wl,--rpath -Wl,/usr/local/lib
command_network.o(.text+0xc31): In function `apply_ip_filter(torrent::Object const&)':
core/ip_filter.h:41: undefined reference to `vtable for core::IpFilter'
command_network.o(.text+0xe02): In function `apply_ip_filter(torrent::Object const&)':
/usr/local/src/rtorrent-ip_filter/src/command_network.cc:134: undefined reference to `core::IpFilter::add_from_file(std::string const&)'
command_network.o(.text+0x1107): In function `apply_ip_filter(torrent::Object const&)':
core/ip_filter.h:42: undefined reference to `vtable for core::IpFilter'
command_network.o(.text+0x110f):core/ip_filter.h:68: undefined reference to `core::IpFilter::clear(std::map<core::IpAddress const, core::IpRange*, std::less<core::IpAddress const>, std::allocator<std::pair<core::IpAddress const, core::IpRange*> > >*)'
command_network.o(.text+0x111a):core/ip_filter.h:68: undefined reference to `core::IpFilter::clear(std::list<std::string, std::allocator<std::string> >*)'
../src/core/libsub_core.a(manager.o)(.text+0x16aa): In function `core::Manager::reload_ip_filter()':
/usr/local/src/rtorrent-ip_filter/src/core/manager.cc:574: undefined reference to `core::IpFilter::reload()'
../src/core/libsub_core.a(manager.o)(.text+0x218f): In function `core::Manager::~Manager()':
/usr/local/src/rtorrent-ip_filter/src/core/ip_filter.h:42: undefined reference to `vtable for core::IpFilter'
../src/core/libsub_core.a(manager.o)(.text+0x2197):/usr/local/src/rtorrent-ip_filter/src/core/ip_filter.h:68: undefined reference to `core::IpFilter::clear(std::map<core::IpAddress const, core::IpRange*, std::less<core::IpAddress const>, std::allocator<std::pair<core::IpAddress const, core::IpRange*> > >*)'
../src/core/libsub_core.a(manager.o)(.text+0x21a2):/usr/local/src/rtorrent-ip_filter/src/core/ip_filter.h:68: undefined reference to `core::IpFilter::clear(std::list<std::string, std::allocator<std::string> >*)'
../src/core/libsub_core.a(manager.o)(.text+0x290f): In function `core::Manager::~Manager()':
/usr/local/src/rtorrent-ip_filter/src/core/ip_filter.h:42: undefined reference to `vtable for core::IpFilter'
../src/core/libsub_core.a(manager.o)(.text+0x2917):/usr/local/src/rtorrent-ip_filter/src/core/ip_filter.h:68: undefined reference to `core::IpFilter::clear(std::map<core::IpAddress const, core::IpRange*, std::less<core::IpAddress const>, std::allocator<std::pair<core::IpAddress const, core::IpRange*> > >*)'
../src/core/libsub_core.a(manager.o)(.text+0x2922):/usr/local/src/rtorrent-ip_filter/src/core/ip_filter.h:68: undefined reference to `core::IpFilter::clear(std::list<std::string, std::allocator<std::string> >*)'
../src/core/libsub_core.a(manager.o)(.text+0x598a): In function `core::Manager::filter_ip(sockaddr const*)':
/usr/local/src/rtorrent-ip_filter/src/core/manager.cc:160: undefined reference to `core::IpFilter::find_range(int) const'
*** Error code 1

Stop in /usr/local/src/rtorrent-ip_filter/src.
*** Error code 1

Stop in /usr/local/src/rtorrent-ip_filter/src.
*** Error code 1

Stop in /usr/local/src/rtorrent-ip_filter.
*** Error code 1

Stop in /usr/local/src/rtorrent-ip_filter.

So I redo from start (rm -rf rtorrent-ip_filter, unpack, patch)
Now I run ./autogen.sh as suggested before running ./configure and make
The resulting error is:

if g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I. -I./.. -I../..     -g -O2 -g -DDEBUG -I/usr/local/include/sigc++-2.0 -I/usr/local/lib/sigc++-2.0/include -I/usr/local/include -MT ip_address.o -MD -MP -MF ".deps/ip_address.Tpo" -c -o ip_address.o ip_address.cc;  then mv -f ".deps/ip_address.Tpo" ".deps/ip_address.Po"; else rm -f ".deps/ip_address.Tpo"; exit 1; fi
ip_address.cc: In static member function 'static std::pair<bool, unsigned int> core::IpAddress::to_int(const std::string&)':
ip_address.cc:12: error: 'AF_INET' was not declared in this scope
ip_address.cc: In member function 'virtual std::string core::IpAddress::to_string() const':
ip_address.cc:21: error: 'AF_INET' was not declared in this scope
*** Error code 1

Stop in /usr/local/src/rtorrent-ip_filter/src/core.
*** Error code 1

Stop in /usr/local/src/rtorrent-ip_filter/src.
*** Error code 1

Stop in /usr/local/src/rtorrent-ip_filter.
*** Error code 1

Stop in /usr/local/src/rtorrent-ip_filter.

Anyone have a clue?
The patches apply cleanly against 0.12.3/0.8.3 as well, running make results in the same errors.

Help would be well appreciated!

[spil]

Solved my problem. Now even running succesfully on 0.8.3/0.12.3 (latest at date of writing) [code] (22:16:10) Using 'select' based polling. (22:16:10) IpFilter? is initialized with files: /var/db/blacklist/level1, /var/db/blacklist/level2 (22:16:10) 277720 ranges total. 24286 ranges were merged.

(22:25:45) Address '64.125.152.178' is rejected by IP filter range 'Abovenet Communications, Inc........ /code Finally, including sys/socket.h in src/core/ip_address.cc solved the problem...

Steps to get this working on FreeBSD: - Unpacking an patching as listed in previous post - Edit src/core/ip_addres.cc, add line 4 #include <sys/socket.h> - Run autogen.sh - Run configure - Run gmake

I took the effort of adding this as a complete diff to the FreeBSD port, just add devel-ip-filter-0.8.3-FreeBSD to /usr/ports/net-p2p/rtorrent-devel/files/ and build the port. (submitted the patch to the maintainer as well, it may end up in the official port)

[spil]

Patch file for inclusion in FreeBSD net-p2p/rtorrent-devel port

[solsTiCe]

hi. comer, could you resubmit your work as a proper patch (i mean a single diff file). please

that's really a pain in the ** to try to use your work right now. between the diff file and the head file missing from the tar...

please use diff -u between your 2 trees and that 's all thnx

[anonymous]

Replying to anonymous:

IP filtering is very important, no one likes being monitored. So i've discontinued the use of rTorrent until the developers implement it. Hope it happens soon.

Using iptables for filtering userland blacklists/whitelists/greylists is a very stupid idea that will bog down the performance of iptables. It's recommended that applications have their own filtering for their services in complement to general iptables rules. Another suggestion is to create a ipfilterdaemon that has black-/white-/greylists that applications can interact with to check credentials,combined with PAM this would be pretty flexible.

[anonymous]

Replying to anonymous:

Using iptables for filtering userland blacklists/whitelists/greylists is a very stupid idea that will bog down the performance of iptables.

You people keep claiming this, but it's wrong. If it bogs down iptables, you're not doing it right. It's quite possible to efficiently implement filtering rules in iptables, for many individual addresses using ipt_recent's IP hash tables, and for IP ranges using a few chained custom tables. That way you also have more control about HOW the connection is rejected, i.e. you could reset it or ignore it or even tarpit it to slow down further attacks. In the app, you can only reset the connection, which means the peer will know that he can just try to reopen it immediately, so you'll have to filter it over and over and over again. With iptables, you can setup ipt_recent to add any matching peer to a blacklist and ignore all future packets automatically and efficiently without even any need to check the filter lists afterwards.

Besides, with iptables, you ONLY need special rules for the initial connection setup (i.e. the SYN packet), all following packets will be handled by the kernel's connection tracking. Sure if you add these filtering rules indiscriminately for any packet using a truckload of rules in the INPUT table, it'll be inefficient. But then you're doing it wrong anyway, so that's no surprise.

And the advantage is that using iptables, the filtering works for ALL applications, instead of every application needing its own set of filters and rules. Sure, it may not be as easy to setup as clicking a button in your torrent client (however a easy-to-use tool could be written to do this), but don't say that it's inefficient.

[anonymous]

But wouldn't implementing ipfiltering with iptables interfere with the bt-client, unless it get's signaled that the peer is blocked? If, f.e. a tracker tells the bt-client to connect to peer A, the bt-client tries to connect to said peers. Now if iptables either blocks the outbound connection request or the inbound response from peer A, the bt-client would probably keep a half-open connection slot until it timed out. If on the other hand the filtering is done by the bt-client itself, it wouldn't even bother to try to connect to peer A, but subsequently try to connect to another peer reported by the tracker. Besides, I bet many people don't offer any services to alien clients on their machine besides the bt-client, so there wouldn't be any synergies in using iptables for filtering. Just my opinion.

[anonymous]

Replying to anonymous:

You people keep claiming this, but it's wrong. If it bogs down iptables, you're not doing it right. It's quite possible to efficiently implement filtering rules in iptables, for many individual addresses using ipt_recent's IP hash tables, and for IP ranges using a few chained custom tables.

Sorry, I seem to be misinterpreting something. That sounded like you said you use ipt_recent for loading the Bluetack blacklists. I agree, ipt_recent is extremely useful. I use it for several things. But, so far as I'm aware, ipt_recent only tracks individual IPs; loading a list of 2.2 billion (and climbing) addresses might cause some slight memory issues. The ipt_set match is more promising, it at least can store CIDR blocks. But not all the list entries convert into ranges neatly. Only real way I can see it is to use some 200,000 -m iprange rules, one for each blocklist entry. I suppose a "few" custom rules could help - say, 256 rules, one for each /8 in the IPv4 range - and divide the entries up amongst them. It would do the job, certainly. Might take a while for iptables-restore to parse that, and it'd eat a fair bit of kernel memory. I'm still unconvinced it's better than the userspace implementation most commonly used.

[spil]

FreeBSD ports patch for inclusion in net-p2p/rtorrent-devel/files (for version 0.8.4)

[anonymous]

Hi can this be used with the current version of rtorrent or is it outdated? will it be included in a upcoming release? this is a rather high prio for me :)

[anonymous]

The FreeBSD patch says it's for 0.8.4. I guess it may get included if it's updated to adhere to rtorrent's coding style. There doesn't seem to be any effort regarding that though.

[anonymous]

Hm why aint this pasted to one of the milestones, is it because of the coding style? cant someone with skill in these matters port it to a correct syntax :) and no dont look at me ;P

[anonymous]

I'd love to see this integrated into the next release also... This is a must have feature.

[comer]

ip_filter for rtorrent 0.8.4.diff

[comer]

Attached ip_filter .diff for rtorrent-0.8.4
Besides being a "proper" diff it also fixes bug reported by Panasonic1.

comer
=====

[anonymous]

Seems the patch is missing printable.h and possibly some other files too (those that don't exist on the server). Did you do "cvsdo add src/core/printable.h" before doing "svn diff"?

[comer]

hmm... sure i did... let me check again

[comer]

ip_filter for rtorrent 0.8.4.diff FIXED

[comer]

fixed

[anonymous]

Compiles and runs fine now. Many thanks!

[anonymous]

Compiles and runs. However, I got some strange behavior when the unchanged list is reloaded according to schedule:

                                                                                                                                                                     !! to < from
(16:54:53) Reloading IP filter
(16:54:53) 77560 ranges total. 8 ranges were merged.

Is this the intended output in that case (unchanged file)?

Thanks for the patch!

[comer]

Replying to anonymous:

Compiles and runs. However, I got some strange behavior when the unchanged list is reloaded according to schedule: Is this the intended output in that case (unchanged file)?

What would be the expected behaviour? The number of ranges or number of merges were different the first time it was loaded?

comer
=====

[anonymous]

Hi Comer,

I thought that the " !! to < from" part looked a bit strange. On a side note: Is it possible to get information about the ranges that were merged? Does it merge adjacent IP-ranges automatically? 'Cause I'm just using one static list, so I was a little bit surprised about the merging.

[comer]

Replying to anonymous:

Hi Comer, I thought that the " !! to < from" part looked a bit strange. On a side note: Is it possible to get information about the ranges that were merged? Does it merge adjacent IP-ranges automatically? 'Cause I'm just using one static list, so I was a little bit surprised about the merging.

I missed that part as it was on the far right :)) It means that the range is invalid. The rage format is:
<description>:<IP from>-<IP to>
where '"IP from'" should be less or equal to "IP to". In this case it is not. The range should be reversed, perhaps? I did not add output of every merged rage since it may be very big, potentially. For example I currently have "285982 ranges total. 31448 ranges were merged." You can imagine what output it would create.
I think I will attach my stand-alone test runner for IP filter, so you can test ranges/inclusions/exclusions yourself. Soon :)

comer
=====

[anonymous]

Replying to anonymous:

Hi Comer, I thought that the " !! to < from" part looked a bit strange. On a side note: Is it possible to get information about the ranges that were merged? Does it merge adjacent IP-ranges automatically? 'Cause I'm just using one static list, so I was a little bit surprised about the merging.

And no, it does not merge adjacent ranges, only overlapping.

[anonymous]

Replying to comer:

I missed that part as it was on the far right :)) It means that the range is invalid. The rage format is:
<description>:<IP from>-<IP to>
where '"IP from'" should be less or equal to "IP to". In this case it is not. The range should be reversed, perhaps?

Not intentionally ;-). The list has some approx. 70000 ranges, so I think one range is sort of messed up.

I think I will attach my stand-alone test runner for IP filter, so you can test ranges/inclusions/exclusions yourself. Soon :)

That would be highly appreciated! Thanks again for the patch and your help using it!

[rakshasa.no@simonrycroft.com]

Building this on Fedora 10 (using all standard Fedora libraries) requires the use of the  -fpermissive flag.

Also, many thanks for the work on this comer, it's very much appreciated.

[comer]

No problem :) I am glad people find it usefull :)

I got rid of dependency on Boost. Hopefully it will facilitate inclusion of the filter in the official release. I am attaching the diff.
Note: if you already use "boosted" version - no need to recompile to this one. There's no change in functionality.

Drawback: there's a noticeable slow down in filter load. However, main functionality is not impacted in any way, so there's no change in performance during normal operation.

comer
=====

[comer]

ip_filter WITHOUT BOOST for rtorrent 0.8.4 (diff)

[Panasonic1]

Wow! Thank you, comer! This patch works well! I hope this patch will be included in official release or maybe at your own branch ;)

[Io)]

Works like a charm in gentoo using  http://bugs.gentoo.org/265024

But don't try to use bluetack's lists as the ipfiletring patch does not accept the leading 0s in the addresses, need to rework it a bit

[anonymous]

What format of ipfilter lists are preferred for this patch?

[chronos <do.it@i.ua>]

comer, thank you for your work!

I'm joining the choir of those asking if this feature is going to be added to the official release.

Local free traffic exchangers are really common; e.g. in Ukraine we have the UA-IX traffic exchange, which allows free (well, almost) up to gigabit-speed traffic exchanges.

Running a world-visible server I cannot use iptables to cut off all but UA-IX users - I would prefer that filtering be performed at the rtorrent level. Inclusion of this feature (as implemented by comer) into an official release will make lifes much easier for the users of OSes with binary packages (like Debian and derivatives), and will bring new followers to the speed and quality of rtorrent, and may - in the long run - help support the cause for the legal content exchange in p2p networks, as fighted for by the TPB.

[anonymous]

If you’re a dedicated follower of  tiffany co like me. Don't miss the  tiffany uk & co. on sale including pendants, necklace, earrings, bracelets on line.  tiffanys is the one thing that outlasts the cake, champagne and music.

[theultramage@gmail.com]

On my P733 Freebsd 7.2 system, the no-boost patch requires adding one more line to src/core/ip_address.cc: #include <sys/socket.h> // AF_INET. There's also a performance issue. A 300kB/6400 line file takes several seconds to load, and a 15MB/300000 line file won't load even after 5 minutes of waiting at 100% cpu usage. Some part of that code is not running efficiently.

[yb]

Replying to comer:

Drawback: there's a noticeable slow down in filter load. =====

Thank you for your patch. I didn't try the "boosted" version but the no-boost is really slow. Obviously using regexp, ifstream and strings objects for loading and parsing the IP-filter files gives serous performance penalty. On a P4-2.4GHz Linux machine it takes 38 seconds to load.

I made some changes to the code to avoid ifstream, string and regexp usage. Instead fopen and char[]'s are used. The modified version loads the same set of IPfilters in 1.6 seconds. Attaching a patch (ip_filter_no_boost-ip_filter_no_boost-fast.patch) that should be aplyed after ip_filter_0.8.4_no_boost.diff.gz. It is rested with rtorrent 0.8.5 release.

A patch that incorporates ip_filter_0.8.4_no_boost.diff.gz and ip_filter_no_boost-ip_filter_no_boost-fast.patch is available  there.

[yb]

to make ip_filter_no_boost faster 20 times faster

[anonymous]

I liked rtorrent at first sight, thank you very much for your work! Unfortunately i can't use it without IP filtering support, hope it will be implemented sometime.  1000 games

[anonymous]

Yes, IP filtering at the application level is an obligatory feature IMHO. I want to try rtorrent but can/will not until such a feature appears. So please consider this Yet Another Request :-)

Meanwhile I want to mention alternatives to the 'azureus' bittorrent client. I first started with azureus, but eventually migrated to ktorrent. At some point ktorrent stopped handling my blocklist properly, so I searched for a new open source bittorrent client and eventually found 'deluge'. It is cross platform, simple but effective, and handles blocklists very nicely. Obviously you need a GUI; it does not run on the command-line.

Worth a look if you can't do without a blocklist-enabled bittorrent client...

[PuhL]

Replying to yb:

A patch that incorporates ip_filter_0.8.4_no_boost.diff.gz and ip_filter_no_boost-ip_filter_no_boost-fast.patch is available  there.

After applying such patch get an make errors on 0.8.5 rT Here is the log:

ip_filter.cc: In member function ‘int core::IpFilter::add_from_file(const std::string&, core::range_map*, core::str_list*)’:
ip_filter.cc:66: error: ‘malloc’ was not declared in this scope
ip_filter.cc:80: error: ‘free’ was not declared in this scope
make[3]: *** [ip_filter.o] Error 1
make[3]: Leaving directory `/root/install/rtorrent_svn/rtorrent/src/core'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/root/install/rtorrent_svn/rtorrent/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/root/install/rtorrent_svn/rtorrent'
make: *** [all] Error 2

But when I use only slow patch (without boost) compilation goes fine. Any ideas?

[richardmonk@gmail.com]

ip_filter "fast" patch with libraries included to prevent malloc/free warnings on compilation

[richardmonk@gmail.com]

Replying to PuhL:

After applying such patch get an make errors on 0.8.5 rT Here is the log:

-SNIP-

But when I use only slow patch (without boost) compilation goes fine. Any ideas?

I have attached above a modified patch that should fix the malloc/free errors. Honestly, it's been a long time since I did C/C++ so I just included stdio.h AND stdlib.h, I don't remember which has malloc and free.

[anonymous]

"rtorrent-0.8.5-ip_filter_no_boost-fast.patch"

ip_filter works fine but no block log events :(

[Cooking games <bobsapoc@ymail.com>]

Thanks for good post. <a href=" http://cookinggamesdressup.com/">Bratz games</a>

[denis@fateyev.com]

ip_filter feature for rtorrent 0.8.6 (diff)

[denis@fateyev.com]

BTW, here you can download libtorrent and rtorrent RHEL/CentOS RPMs with ip_filter support:  http://www.fateyev.com/RPMS/RHEL5/

[anonymous]

Maybe I'm doing something wrong, but the build fails with following error message:

g++ -DHAVE_CONFIG_H -I. -I../.. -I. -I./.. -I../..    -g -O2 -g -DDEBUG -I/opt/local/include/sigc++-2.0 -I/opt/local/lib/sigc++-2.0/include   -I/opt/local/include   -I/opt/local/include   -MT ip_filter.o -MD -MP -MF .deps/ip_filter.Tpo -c -o ip_filter.o ip_filter.cc
ip_filter.cc: In member function ‘int core::IpFilter::add_from_file(const std::string&, core::range_map*, core::str_list*)’:
ip_filter.cc:72: error: ‘getline’ was not declared in this scope
make[3]: *** [ip_filter.o] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

I'm on OSX 10.5.8 PPC. I have an libtorrent/rtorrent vanilla install using Macports. Now I tried to build a patched 0.8.6 version, utilizing the installed libtorrent version (0.12.6). So I downloaded the 0.8.6 source, but it in a separate directory, run the patch with

patch -p1 < rtorrent-0.8.6-ip_filter_no_boost-fast.patch

without any error messages. Then I ran

./configure --bindir=/Users/Me/Desktop/rtorrent.0.8.6.ip/rtorrent-0.8.6 --program-suffix=-ipfilter

again, no errors. But the consecutive "make" fails. Any ideas?

[debian user]

Is this ip filter / blocklist patch going to be sometime a default feature for rtorrent? This will surely boost rtorrent because I think it's a big minus to not have at least a basic ip filtering.

[mhtsaras]

I tried rtorrent for my debian arm headless pc (sheevaplug -->  http://www.plugcomputer.org/plugwiki .../plugforum) and it was perfect for my needs with small cpu and memory usage (better than transmission which sucks ), but without ipfilter/blocklist until I found this patch and decided to try it. I will describe the steps I took to successfully install the latest rtorrent with ipfilter support, following things I know or red from other posters here, for other noobs like me, that may need a little help... Make a new dir and downloaded latest rtorrent and libtorrent

mkdir rtorrent-ipfilter-patch
cd rtorrent-ipfilter-patch
wget http://libtorrent.rakshasa.no/downloads/rtorrent-0.8.6.tar.gz
wget http://libtorrent.rakshasa.no/downloads/libtorrent-0.12.6.tar.gz
tar -xzvf libtorrent-0.12.6.tar.gz
tar -xzvf rtorrent-0.8.6.tar.gz

instal libtorrent

cd ../libtorrent
./configure
make
sudo make install

inside rtorrent directory download and apply ip-filter patch

cd ../rtorrent-0.8.6
wget http://libtorrent.rakshasa.no/raw-attachment/ticket/239/rtorrent-0.8.6-ip_filter_no_boost-fast.patch
patch -p1 < rtorrent-0.8.6-ip_filter_no_boost-fast.patch
.....
Hunk #3 succeeded at 277 (offset 6 lines).
patching file src/utils/pattern.cc
patching file src/utils/pattern.h
user@debian:~/rtorrent-ipfilter-patch/rtorrent-0.8.6$

then cont. with installation

./configure
......
checking for library containing add_wch... no
checking for library containing wbkgdset... no
*** The ncurses library is required!

oops ...after a little search I found that I was looking for libncursesw5 but for developers, so I installed this lib and cont. with the rtorrent installation

sudo apt-get update
sudo apt-get install libncursesw5-dev
...
...
./configure
...
make 
sudo make install

The to check for the ip filter if it's working downloaded two block lists from  http://blocklistpro.com/download-center/ the blocklists must have this pattern description:"from ip"-"to ip" and put them in a folder ..../rtorrent/ipfilter after that I added to the end of .rtorrent.rc: ip_filter=/mnt/usbext4/rtorrent/ipfilter/ads-trackers-and-bad-pr0n.txt,/mnt/usbext4/rtorrent/ipfilter/psplist.txt

---

after that how to see if the filter is running? I run rtorrent inside rtorrent:

IpFilter? is initialized with files: /mnt/usbext4/rtorrent/ipfilter/ads-trackers-and-bad-pr0n.txt, /mnt/usbext4/rtorrent/ipfilter/psplist.txt

( 0:07:40) 196543 ranges total. 2669 ranges were merged. ( 0:07:43) Address '91.121.144.145' is rejected by IP filter range 'OVH System / adserver.ma-regie-publicitaire.com / adserve

r.ma-regie-publicitaire.com / adserver.ma-regie-publicitaire.com / adserver.ma-regie-publicitaire.com / adserver.m a-regie-publicitaire.com: [91.121.0.0 - 91.121.255.255]

( 0:07:43) Address '98.173.44.19' is rejected by IP filter range 'Cox Busine: [98.172.0.0 - 98.175.226.255] ...

---

outside rtorrent: user@debian:~$ rtorrent Loading IP filters from '/mnt/usbext4/rtorrent/ipfilter/psplist.txt'...done. Loaded 193893 ranges. 2645 ranges were merged. 196543 ranges total. 2669 ranges were merged. IP_Filters loaded in 2.96 seconds

---

the blocklist has about 196500 ip ranges and it already started blocking... I also added some entries manually to the ip filter lists and saw that next time when i rebooted it was started blocking them in the log window

The idea to update the lists with a script is super but despite the fact that I am reloading the ip filter with : Ctrl-x reload_ip_filter and rtorrent seems to read the new lists, but it can not close a connection that is allready made with a new ip filter.in my case at least. Or maybe I didn't waited too long But the coders must have a look for this issue... After all the rtorrent is working pretty fine until now and the memory and cpu usage is lower than expected. Keep on the good work guys! you and the posters are the best!

[anonymous]

Well, after some researching it appears that this patch won't build on OSX, because quote: "there is no getline() on BSD's libC, only in GNU's". Someone else ran into the same  problem (search for "getline"), and as a workaround it was suggested to switch to fgetln() instead. This would require some recoding, though. I found another possible workaround, but this was, as I understand (did no C or C++ coding before), only for C. Someone else had a similar problem while porting the 7DS proxy server to OSX, and needed to use the missing getline() command. Hence they made a custom  getline.c file. Now I'd like to ask someone familiar with OSX development and rtorrent to check if the patch could be ported to OSX, using either workaround. Would be really appreciated! Thanks!

[denis@fateyev.com]

A time ago I've modified last rtorrent-0.8.6-ip_filter patch to add compatibility with BSD-system. Reported as working under OSX and I believe there will be no problems with other BSD systems.

It's working both with Linux and BSD, but running autoreconf at first is required for proper build on target system, due to some changes in configure.ac file.

Note: that isn't a new version of the patch, but only an adapted version. So, if you already have ip_filter feature working in your rtorrent, you haven't need this one.

[denis@fateyev.com]

ip_filter feature for rtorrent 0.8.6 (Linux/BSD) (diff)

[Arkox]

Hi ! Thanks for the patches for OSX, I was looking for one (I had c++ issues with normal patches) when building rtorrent (after patching) i got this error : download_list.cc: In member function ‘void core::DownloadList::open_throw(core::Download*)’: download_list.cc:224: error: ‘open_enable_fallocate’ is not a member of ‘torrent::Download’

Any clue ?

[anonymous]

Strange, on my system everything (10.5.8 PPC, every dependency installed via Macports) build just fine, including the #2064 GeoIP patch on top of the IPFilter-BSD patch. Did you run ./autogen.sh in advance? Any other configure options enabled? Does a vanilla rtorrent 0.8.6 build successfully?

[Arkox]

Well, I'm on a 10.5.8 PPC too... Same error with a vanilla rtorrent (./autogen.sh, ./configure and make) I may miss some depencies though, I'll check...

[newreality]

+1 for inclusion into next release of rtorrent!

Rtorrent really needs this as a built-in feature. I just finished getting this all set up on linux mint. It took me waaaay too long to figure out how to get everything running correctly. What a time-suck! Suck!

Also, although the status of this ticket is technically correct, this feature is way more than an enhancement... it's a necessity! A necessary enhancement!

[denis@fateyev.com]

Replying to newreality:

Rtorrent really needs this as a built-in feature. I just finished getting this all set up on linux mint. It took me waaaay too long to figure out how to get everything running correctly. What a time-suck! Suck!

It's easy to install; will be enough to follow the instructions, that mentioned in comments above. See comment 117 for example.

[newreality]

Replying to denis@…:

It's easy to install; will be enough to follow the instructions, that mentioned in comments above. See comment 117 for example.

Denis, I didn't mean to sound thankless for the code provided. It's great! Thanks to everyone involved!

I wrote a script I'd like to post. I tried posting it inline with the triple-bracket syntax, but it wouldn't accept it. It said the spam rule was triggered because I had too many external links in the post. There are two commented-out links in the bash script I'm trying to post. Should I do the "attach file" option at the top, then link to it in a new comment? Or am I missing something. trac faqs have me stumped.

[Martin van Nostrand]

Post it to any kind of pastebin then link it here.

[newreality]

Denis, I didn't mean to sound thankless for the code provided. It's great! Thanks to everyone involved! I just meant to highlight my experience as a casual linux user who needs to understand what I'm doing or I usually screw it, or something else, up. The time investment, in reading the whole ticket thread, and then implementing it the way I needed, WAS worth it to me. However, I wanted to add my voice to those who have rightly said how this working code needs to be incorporated into rtorrent proper. As the best and most powerful torrent client geared towards running on headless servers and embedded linux devices, the security provided by this awesome patch is essential for the general public. For most newbish people, just getting .rtorrent.rc set up the way they need is a headache. I have been looking for solutions to this problem for about five months, and I'm glad I found this hidden track ticket! (hidden to most people like me, who until recently were newb-scared of trac sites)

I wasn't satisfied with moblock for the same reasons others here have mentioned; I didn't want my whole server blocking the ipfilter list, just rtorrent. For me, the reason for not wanting to use a system-wide solution like moblock is that I use webmin to manage my system firewall rules, and webmin overwrites/reformats? the iptables script that moblock adds; so moblock is out. I want to use webmin and rtorrent, AND use a blocklist. The solution provided here by comer & denis solved my problems. Yay open source! Now let's just get it INTO the source!?! But alas, this isn't a democracy, exactly. All due respect and thanks to rakshasa, who made the luxury of this frustration possible.

Just to let everyone know, my personal solution was to first incorporate some source changes from  Calomel.org. Don't worry, I'm not into the spoofing stuff, and neither should anybody else!! Then, once I made those changes, I followed the above instructions to patch rtorrent for ipfilter utilization. Once compiled, installed, and rtorrent.rc was updated, I struggled with the cron update script. I went with another script I found elsewhere, then modified it a ton, ok, almost completely. Here's the modified script, geared more for those like me who want a little more hand-holding and memory-prompting if I forget everything about this in six months.

 Bluetack blocklist downloader

Edit the path and blocklist lines accordingly, then make it executable. Create a cron job to run the whatever.sh script daily, along with editing your .rtorrent.rc, of course!

Let me know if I made any errors. And thanks again to comer, denis, rakshasa, et al!

[rufflove]

I've had success with the patch and 0.8.6 stable. It didn't want to play with Joseph Drexler's bad peer handling patch though :/

Grabbing level1, level2 and microsoft (bogon, dshield etc. handled globally by iptables) results in a 16mb file and a doubling in rtorrent memory usage to about 22mb for me. Ouch, but hey, as long as CPU usage remains low, I'll live :))

Thanks for the patch and supporting info from others!

[anonymous]

Is it possible to revert that patch and achieve the opposite effect? I'd rather have a whitelist than a blacklist so I can just allow ip ranges I trust. Anyone tried something like that yet?

[anonymous]

Replying to anonymous:

Is it possible to revert that patch and achieve the opposite effect? I'd rather have a whitelist than a blacklist so I can just allow ip ranges I trust. Anyone tried something like that yet?

You could always create a blocklist that blocks everything besides the ranges in your whitelist ...

[denis@fateyev.com]

Replying to anonymous:

I'd rather have a whitelist than a blacklist so I can just allow ip ranges I trust.

When we use the blacklist feature, we automatically implement whitelist (allow connections from non-blacklisted addresses only).

[anonymous]

A week ago I did some rework of latest "rtorrent-0.8.6-ip_filter_no_boost-fast-bsd.patch". Technically, it's still the same (from user's point of view), but more compliant with "properly" C-coding style and, as I dare to believe, with those cosmetic changes it looks more decent with other pieces of code. I think, now it's a bit closer to conception how this should to be presented.

Despite it's title (which includes a "bsd-" suffix), it must be compiled flawlessly on all machines, where original rTorrent can be compiled (even without running "autogen.sh/autoconf" anymore; but, certainly, those tools don't break anything and will work too.)

[denis@fateyev.com]

ip_filter feature for rtorrent 0.8.6 (Linux/BSD) (diff)

[denis@fateyev.com]

The previous post (anonymous) is mine, I just forgot to fill out the "username" field.

[Cadriel]

Denis - any chance you can prep a patch file for the current trunk?

Or - any idea when this may (or if) be implemented directly into trunk?

[denis@fateyev.com]

Replying to Cadriel:

Denis - any chance you can prep a patch file for the current trunk? Or - any idea when this may (or if) be implemented directly into trunk?

Unfortunately, now I haven't enough time to do it. Probably a time later. I don't think, that it will be implemented into trunk due the rtorrent author's politics. I only will be glad if things will change.

[anonymous]

wow - this is really disappointing. rtorrent is a great app from what ive heard, but i wouldnt know. I ABSOLUTELY NEED the blocklist feature. im not sure if there are performance or memory usage implications by adding this ipfilter patch to the default codebase, or if the author would rather not have to code around it in future releases to keep it working, but im in the group that lists this as a mandatory feature...

it would be nice to have a plug-in infrastructure similar to ktorrent, so we can implement things like web interface without having to roll out apache or lighthttpd. honestly the way rtorrent does things makes a huge mess on any box its deployed on requiring its own dedicated server - which ive been looking at implementing in a vm.

honestly this is disgusting and it would be nice if it were rectified. rtorrent is a fast piece of code, but in this dangerous world we live in, it just not up to the task of safe bittorrenting on its own. Instead the end user has to implement hacks which often have a far reaching affect on the host OS - not cool.

My question to the author is this - if so many people apparently are interested in this feature, why are you dragging your feet about adding it when the coding has practically been DONE FOR YOU!!

[anonymous]

Honestly, it is disgusting that you use rtorrent for illegal purpose, period. It is good for rtorrent not having ipfilter so that anyone who demand it would go away in tears.

(I think those demands are just indication of not knowing how safer they can be by those bloated filter in wild, but oh well.)

Note that I'm not saying this feature is useless. On the contrary, it would be useful to kick known-to-be-bad networks, i.e. too narrow bandwidth, hijacked in the middle by ISPs, and so on. Similar to kick known-to-be-evil peers (which is also lacking ATM). But well, we know how to patch, and is it.

Though maintaining patches out of trunk is somewhat dumb indeed, the real problem here is that libtorrent's internal structures are not very fixed and subject to change so often. Cost of syncing patches to trunk will be negligible once after the interface get stable.