ipp2p vs. l7 filter
l7 uses regular expressions, so they are slower (some rules are EXTREME
slow like fasttrack) and not so strong like the ipp2p rules (which can
have for example packet length checks). ipp2p is specialized for p2p
detection, so a many p2p packets are not detected by l7 (for example not
all BitTorrent connections start with a 013h "BitTorrent"). The worst
part is that l7 filter has some p2p rules which detect false positives:
http://l7-filter.sourceforge.net/layer7-protocols/protocols/edonkey.pat
"... This will match about 1% of streams with random data in them! ..."
If you drop p2p connection, one of hundred downloads / web pages will
fail (and fail every time) ?
I would recommend l7-filter for everything but not for p2p. It is a VERY
nice filter, but if they would have something else than regexp, i would
use it maybe too.
Klaus, Maintainer of ipp2p
Edgar wrote:
Hi, thanks for your help and interest, someone told me about that already, so
I did it, and this is the script I'm running to do it:
#!/bin/sh
### ERASING RULES AND USER CREATED CHAINS ###
iptables -t mangle -F
iptables -t mangle -X
iptables -t mangle -N lay7PRE
iptables -t mangle -N lay7POST
### PREROUTING RULES ###
iptables -t mangle -A lay7PRE -j CONNMARK --restore-mark
iptables -t mangle -A lay7PRE -m mark ! --mark 0 -j ACCEPT
iptables -t mangle -A lay7PRE -m layer7 --l7proto bittorrent -j MARK
--set-mark 1
iptables -t mangle -A lay7PRE -m layer7 --l7proto smtp -j MARK --set-mark 2
iptables -t mangle -A lay7PRE -m layer7 --l7proto http -j MARK --set-mark 3
iptables -t mangle -A lay7PRE -j CONNMARK --save-mark
### POSTROUTING RULES ###
iptables -t mangle -A lay7POST -o eth1 -m mark --mark 1 -j CLASSIFY
--set-class 2:2
iptables -t mangle -A lay7POST -o eth1 -m mark --mark 2 -j CLASSIFY
--set-class 2:3
iptables -t mangle -A lay7POST -o eth1 -m mark --mark 3 -j CLASSIFY
--set-class 2:4
### ------------------------------------------------------------------- ###
iptables -t mangle -A PREROUTING -j lay7PRE
iptables -t mangle -A POSTROUTING -j lay7POST
I'm trying this right now, and I believe its kind of working, but web surfing
is very slow, I might say unusable, so this is not what I want, also I had to
mark http traffic to make this work, give it a higher prio in htb, so I
believe I'm missing something else? someone suggested to add a new class for
ACK packets, I've done that already, but I've only noticed little
difference... really don't know whats happening, if you don't have tcng I can
show you my tc rules (showed by tc -s class show dev eth1). Thank you again
EDGAR MERINO
On Wednesday 06 July 2005 23:30, Jody Shumaker wrote:
You need to use connection marking as well. --l7proto bittorrent will
only recognize the first packet in a bittorrent stream, you need to save
a mark on the whole tcp connection, and restore the mark for all future
packets if you want the entire connection to be classified.
iptables -t mangle -A lay7 -p tcp -j CONNMARK --restore-mark
iptables -t mangle -A lay7 -m layer7 --l7proto bittorrent -j MARK
--set-mark 1 iptables -t mangle -A lay7 -o eth1 -m mark --mark 1 -j
CLASSIFY --set-class 2:2 iptables -t mangle -A lay7 -m layer7 --l7proto
smtp -j MARK --set-mark 2 iptables -t mangle -A lay7 -o eth1 -m mark --mark
2 -j CLASSIFY --set-class 2:3 iptables -t mangle -A lay7 -p tcp -m mark !
--mark 0 -j CONNMARK --save-mark
If you're marking ever gets more complex, it might take a little more work
( -j accepts for matching already classified connections after the
--restore-mark) but the above should help get the full bittorrent
connection classified, not just the first packet.
- Jody
Edgar wrote:
Hello,
I've been trying to shape the bittorrent traffic (on my external
interface, upload), but without luck, for this I'm using layer7 filter
right now, but I've also tried ipp2p, with the same results, I might say
that this is not a problem with this packet classifiers, the problem is
with HTB, here's why. When I open azureus (the bittorrent client I use) I
see upload traffic getting shapped, but also I see that my download
traffic won't go up if I'm shaping on the upload interface, if I stop
shaping on that interface then upload ( as expected) will increase, and
so the download rate, this happens to me using the default bittorrent
client (classic), so its not a client problem. Ok, the problem here is
that when using bittorrent, although I see the traffic is shaped I can't
surf web pages, nor chat in msn messenger, nor do anything at all, and
merely that's all I want to do, shape p2p traffic to be able to use my
bandwidth fairly, maybe its a bittorrent problem, because with the
edonkey protocol I have no problem at all, traffic get shaped and I can
use the rest of my bandwidth, I'll post my iptables rules for marking the
bittorrent packets and the htb rules I use (using tcng):
### IPTABLES RULES ###
iptables -t mangle -F
iptables -t mangle -X
iptables -t mangle -N lay7
iptables -t mangle -A POSTROUTING -j lay7
iptables -t mangle -A lay7 -m layer7 --l7proto bittorrent -j MARK
--set-mark 1 iptables -t mangle -A lay7 -o eth1 -m mark --mark 1 -j
CLASSIFY --set-class 2:2
iptables -t mangle -A lay7 -m layer7 --l7proto smtp -j MARK --set-mark 2
iptables -t mangle -A lay7 -o eth1 -m mark --mark 2 -j CLASSIFY
--set-class 2:3
### HTB RULES ###
#define UPLOAD eth1
#define UPRATE 25kBps
#define P2P 10kBps
dev UPLOAD {
egress {
class ( <$emule> ) ;
class ( <$smtp> ) ;
class ( <$ssh> ) if tcp_dport == 8080 ; /*Changed port from 22 to 8080
*/ class ( <$otro> ) if 1 ;
htb () {
class ( rate UPRATE, ceil UPRATE ) {
$emule = class ( prio 8, rate 6kBps, ceil P2P ) { sfq; } ;
$smtp = class ( prio 1, rate 6kBps, ceil 12kBps ) { sfq; } ;
$ssh = class ( prio 0, rate 3kBps, ceil 5kBps) { sfq; } ;
$otro = class ( prio 1, rate 8kBps, ceil UPRATE ) { sfq; } ;
}
}
}
}
Also, given the priorities it's expected to let me surf the web or chat in
msn messenger rather than take my whole bandwidth.
I hope someone can help me out with this, maybe it not ok to use tcng with
iptables? thank you in advance
EDGAR MERINO
_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
