It did not take more than a couple of days for around thirty of my neighbors to start using the open "Welcome" network. Most of them turned to being modest doing mostly mail and some surfing, but two or three bittorrent fans turned out to be a problem. If you decide to provide some Internet for your neighbors you certainly should do something about this problem.
You have at least two options: l7-filter from http://l7-filter.clearfoundation.com/ and ipp2p from http://www.ipp2p.org/. During one time or another I used both of them and the results are relatively similar. I still prefer ipp2p as I believe it is less CPU consuming. The project web page claims that the project is discontinued. This is not exactly true, it is only discontinued as a separate project for the external module. It was moved to patch-o-matic which is today defunct. Nowadays after netfilter.org discontinued patch-o-matic, it was moved to xtables-addons and netfilter.org is still support it. First, do not forget to install libmnl from http://www.netfilter.org/projects/xtables-addons/index.html and then the xtables-addons. Then you will need something like this:
$IPTABLES -N Bittorrent $IPTABLES -t mangle -N Bittorrent $IPTABLES -t mangle -A PREROUTING -s 172.17.0.0/16 -m ipp2p --bit -j Bittorrent $IPTABLES -A INPUT -s 172.17.0.0/16 -m ipp2p --bit -j Bittorrent $IPTABLES -A OUTPUT -s 172.17.0.0/16 -m ipp2p --bit -j Bittorrent $IPTABLES -A FORWARD -s 172.17.0.0/16 -m ipp2p --bit -j Bittorrent $IPTABLES -A Bittorrent -j LOG --log-level info --log-prefix "Bittorrent " $IPTABLES -t mangle -A Bittorrent -j LOG --log-level info --log-prefix "Bittorrent m " $IPTABLES -A Bittorrent -j DROP $IPTABLES -t mangle -A Bittorrent -j DROP
Most of these commands are unnecessary, just doing:
iptables -t mangle -A PREROUTING -s 172.17.0.0/16 -m ipp2p --bit -j DROP
iptables -A XXXXX -m state --state ESTABLISHED,RELATED -j ACCEPT
Anyway, do not expect too much from it, or from l7-filter for that matter. They will slow down bittorrent clients significantly, but both have problems recognizing encrypted connections. At least the bittorrent clients for sure will not be able to kill anymore all other connections. If you are not satisfied with the results of the solution just described you should combine it with traffic shaping (next paragraph).
The decision to spend time to setting up and fine tuning traffic shaping depends on: the type of Internet connection used, the number of clients you have, their behavior and most important, will you provide some Internet for your neighbors.
If you have a relatively fast and symmetric connection you have nothing to worry about, but if you are on something like ADSL and your provider has an illicit behavior than moving the queue to your machine makes a real difference. You can read about the reasons for getting control over your queue here "The Ultimate Traffic Conditioner".
It is important to mention that since "Linux Advanced Routing & Traffic Control HOWTO" was written, lots of things have changed, though probably the most important new thing in the field of traffic shaping is the "Intermediate Functional Block device". A lot of work has been done in the field and you have to be really careful when you are doing your own research since many of the online documentations and examples are outdated. Most examples will still work fine, but often better solutions have been developed.
My traffic shaping script had the following goals:
Move the queue to my machine.
Provide fairness between both my family clients and guests in the "Welcome" network.
Give a warranted advantage to my own clients, leaving the clients in "Welcome" with what is left, while at the same time warranting some bandwidth for Welcome even in moments of heavy load. My Internet connection is actually 99% unused anyway, but I did not want to listen to complaints from my family.
Have a method to separate clients that misbehave from the crowd.
Here is the resulting script rc.traffic_shaping. It does what I wanted it to, but is certainly not perfect and will require additional fine-tuning. Anyway you will have to readjust it to your conditions.
One important thing that needs to be mentioned is that limiting the outgoing traffic from a specific source, does not lead to proportional limitation to the incoming traffic. Most streaming protocols require small amounts of outgoing requests in order to get real floods of incoming video. As a result even class 1:13 (this is where baddies go), can seem too restrictive with its "rate 10kbit burst 15kbit", but it actually gives them around 600kbits of download speed. This demonstrates that in order to have precise control you need to shape incoming connections as well.
Next is the chart of outgoing traffic shaping.
The traffic goes as follow:
|From Acer_A1 ->1:11|
|From Welcome -> 1:12|
|Bad clients -> 1:13|
|Between may cable clients and Acer_A1 -> 1:2|
For example the traffic is classified by iptables with rules like this:
iptables -t mangle -A POSTROUTING -s 192.168.1.0/24 -d 192.168.1.0/24 -j CLASSIFY --set-class 1:2
You can see how I set the classes in "Policy: Traffic_Control" in acer_br.pdf or check the detailed syntax inside the acerap_br.fw script.
The next picture represents the chart of incoming traffic shaping.
The traffic goes as follow:
|To Acer_A1 ->1:31|
|From Welcome -> 1:32|
|Bad clients -> 1:33 - nobody is there yet, but it is ready:-).|
|Between may cable clients and Acer_A1 -> 1:4|
The first step in shaping the outgoing traffic is to get the ifb0 Intermediate Functional Block device" working. It turned out that the module does not load automatically, but I rather loaded it in the rc.traffic_shaping script by:
/sbin/modprobe ifb ifconfig ifb0 up
The next problem is really interesting look at the part of the rc.traffic_shaping script pasted below:
############################## # It is necessary to mirror both eth0 and br0 to ifb0 in order to have both traffics # with destinations 172.17.0.0/16 and 192.168.1.0/24, # because each of them sees only one destination as outgoing. # You may check it by remarking one of the mirrors and the running WireShark on ifb0. tc filter add dev $DEV parent ffff: protocol ip prio 10 u32 \ match ip dst 0.0.0.0/0 flowid 1: \ action mirred egress redirect dev ifb0 tc filter add dev br0 parent ffff: protocol ip prio 10 u32 \ match ip dst 0.0.0.0/0 flowid 1: \ action mirred egress redirect dev ifb0 ##############################
The $DEV=eth0 is set at the beginning of the script. There is probably a better way of directing traffic to ifb0, but this is the only way that works for me. You will need the following commands, to investigate and adjust the script to your own needs:
tc class ls dev eth0 tc class ls dev ifb0 tc -s -d qdisc show dev eth0 tc -s -d qdisc show dev ifb0 tc -s class show dev eth0
Having a cache DNS server was a great advantage in the time when everyone thought that a 28'800 modem is lighting fast. With today's speed the percentage of economized bandwidth is close to zero, but it is so easy to install, and besides old habits die hard. Just make /etc/rc.d/rc.bind executable. Slackware has a /etc/named.conf pre-ready. It is a good idea to setup regular updates of named.root by simply creating the script /etc/cron.monthly/named.root and putting the following two commands in it:
#!/bin/sh # /usr/bin/wget --user=ftp --password=ftp \ http://www.internic.net/zones/named.root \ -O /var/named/caching-example/named.root /etc/rc.d/rc.bind restart
The dhcpd log can be moved to separate files by three simple steps:
Putting the next line at the end of the dhcpd.conf
Append at the end of /etc/syslog.conf the line
Create an empty dhcpd.log by:
Of course dhcpd and syslogd need to be restarted.
iptables log. It is a tempting idea to move the iptables log in a separate file if you use Firewall Builder or just enjoy having extensive logs from your firewall. The complication here comes from the limited choice of "
--log-level X" available. As a result, the kernel (and not the iptables) is in reality doing all the filtering thus all logs go in log facility "kern.*". The choice for * is limited between those levels "0 emerg, 1 alert, 2 crit, 3 err, 4 warning, 5 notice, 6 info, 7 debug". Besides "crit" is the default level for klogd to send messages to the console so whatever goes on this level inevitably goes on the console as well. You may experiment with other levels or try changing "klogd -c 3" to something else.
Everything else is simple after these difficult choices are made.
First either change the log level setting in Firewall Builder, or if you wrote your own script set it to something like "
-j LOG --log-level warn --log-prefix "my log text"".
After this is done, append at the end of /etc/syslog.conf the line:
and exclude it from
*.warn;kern.!=warn;\ authpriv.none;cron.none;mail.none;news.none -/var/log/syslog
If you decide to experiment with other levels, for example "notice", change the line like this:
But in the case of "notice" you will also have to exclude "kern.notice" from /var/log/messages by editing the related line in syslog.conf in a similar way yielding the line:
*.info;*.!warn;kern.!=notice;\ authpriv.none;cron.none;mail.none;news.none -/var/log/messages
There is no perfect choice and some of your boot messages will always go to fwbuilder.log instead of going in to the messages or syslog files. The biggest problem are the eventual error messages generated during the normal course of work, which will be buried in the fwbuilder.log.
If you want see what else goes on in the /var/log/fwbuilder.log and iptables logs, the next command will help you:
cat /var/log/fwbuilder.log |grep RULE -v