Hello there! I am trying to get traffic shaping working on my Linux router (debian woody 3r02) and for some things I wanted to use the layer 7 packet classifier, but I can't get it to work. Here is what I did: -downloaded the patches from http://l7-filter.sourceforge.net -downloaded the kernel 2.6.7 source -downloaded the iptables 1.2.11 source -patched kernel (layer7 patch and some patch to get iptables 1.2.11 working with kernel 2.6.7) -patched iptables -compiled iptables -activated layer 7 support in kernel-config (and a lot of other packet classifing options) -compiled and installed kernel Now I tried to mark some packets with layer 7 so that I can shape them with tc afterwards. But nothing changed, outgoing connection still didn't changed. So I changed the line in the iptables-script to this: $IPTABLES -t filter -A OUTPUT -m layer7 --l7dir /etc/l7-protocols --l7proto ftp -j DROP before it was: $IPTABLES -t mangle -A POSTROUTING -m layer7 --l7proto ftp -j MARK --set-mark 322 but nothing of them worked (I could still connect over ftp). The /proc/net/layer7_numpackets is 08 (don't know which 8 packets got identified there, but the number is not going any higher). Any help is really appreciated! -FB
On Friday 09 July 2004 13:10, FB wrote: > Hello there! > > I am trying to get traffic shaping working on my Linux router (debian > woody 3r02) and for some things I wanted to use the layer 7 packet > classifier, but I can't get it to work. > Here is what I did: > > -downloaded the patches from http://l7-filter.sourceforge.net > -downloaded the kernel 2.6.7 source > -downloaded the iptables 1.2.11 source That's not necessary. You might be creating more work for yourself. I jus= t=20 recycled the Debian iptables package, which is still 1.2.9 I believe. You'= ll=20 need to patch it and create the appropriate dot file for the build to=20 succeed, but after that I just rebuild the package with 'debuild -uc -us' a= nd=20 copied it to my compiler-less router. I'm using 2.6.6, but I'm sure 2.6.7= =20 should work fine. > -patched kernel (layer7 patch and some patch to get iptables 1.2.11 > working with kernel 2.6.7) > -patched iptables > -compiled iptables > -activated layer 7 support in kernel-config (and a lot of other packet > classifing options) > -compiled and installed kernel > > Now I tried to mark some packets with layer 7 so that I can shape them > with tc afterwards. But nothing changed, outgoing connection still > didn't changed. So I changed the line in the iptables-script to this: > > $IPTABLES -t filter -A OUTPUT -m layer7 --l7dir /etc/l7-protocols > --l7proto ftp -j DROP I believe the documentation mentions that layer7 works best when it can see= =20 both 'sides' of the connection. If you're filtering through INPUT or OUTPU= T=20 you're missing half. Check the ftp protocol match. Does it rely on seeing= =20 both sides of the connection to match up? Try matching in FORWARD, PREROUTING, or POSTROUTING. I believe these see a= ll=20 sides of the connection. =46rom docs[1]: "Some patterns need to be able to observe both sides of a connection in ord= er=20 to match. This is pretty easy to achieve with Netfilter. By default, rules = in=20 the POSTROUTING chain of the mangle table will apply to both directions.=20 However, the OUTPUT chain (for example) only sees locally generated packets= ,=20 so it's not a good choice." [1] http://l7-filter.sourceforge.net/L7-HOWTO-Netfilter
Jason Boxman wrote: > That's not necessary. You might be creating more work for yourself. I just > recycled the Debian iptables package, which is still 1.2.9 I believe. You'll > need to patch it and create the appropriate dot file for the build to > succeed, but after that I just rebuild the package with 'debuild -uc -us' and > copied it to my compiler-less router. I'm using 2.6.6, but I'm sure 2.6.7 > should work fine. Ok, it may not be necessary, but shouldn't be the source of the problem, or? Should work with iptables 1.2.11 all the same or are there some issues there? > I believe the documentation mentions that layer7 works best when it can see > both 'sides' of the connection. If you're filtering through INPUT or OUTPUT > you're missing half. Check the ftp protocol match. Does it rely on seeing > both sides of the connection to match up? > > Try matching in FORWARD, PREROUTING, or POSTROUTING. I believe these see all > sides of the connection. Doesn't change anything :-( BTW, when I use the setting from the NETFILTER HOWTO page: iptables -t mangle -A POSTROUTING -m layer7 --l7proto http -j MARK --set-mark 1 and change it (as written in the howto under "blocking") to: iptables -t mangle -A POSTROUTING -m layer7 --l7proto http -j REJECT I get an "iptables: Invalid Argument" when executing the script, how that? (I must admit that I am not that iptable expert, so excuse some lack of knowledge of all the chains and structures ;) ) -FB
On Friday 09 July 2004 14:58, FB wrote: <snip> > Doesn't change anything :-( > BTW, when I use the setting from the NETFILTER HOWTO page: > > iptables -t mangle -A POSTROUTING -m layer7 --l7proto http -j MARK > --set-mark 1 > > and change it (as written in the howto under "blocking") to: > iptables -t mangle -A POSTROUTING -m layer7 --l7proto http -j REJECT > > I get an "iptables: Invalid Argument" when executing the script, how > that? (I must admit that I am not that iptable expert, so excuse some > lack of knowledge of all the chains and structures ;) ) More of a question for the netfilter list, but it sounds like you may not have compiled in support for the REJECT target. You should have ipt_REJECT in the output when you do an `lsmod` if you compiled it as a module.
Jason Boxman wrote: >On Friday 09 July 2004 14:58, FB wrote: ><snip> > > >>Doesn't change anything :-( >>BTW, when I use the setting from the NETFILTER HOWTO page: >> >>iptables -t mangle -A POSTROUTING -m layer7 --l7proto http -j MARK >>--set-mark 1 >> >>and change it (as written in the howto under "blocking") to: >>iptables -t mangle -A POSTROUTING -m layer7 --l7proto http -j REJECT >> >>I get an "iptables: Invalid Argument" when executing the script, how >>that? (I must admit that I am not that iptable expert, so excuse some >>lack of knowledge of all the chains and structures ;) ) >> >> > >More of a question for the netfilter list, but it sounds like you may not have >compiled in support for the REJECT target. You should have ipt_REJECT in the >output when you do an `lsmod` if you compiled it as a module. > > Can you REJECT in the mangle table?
On Friday 09 July 2004 16:51, Ed Wildgoose wrote: <snip> > Can you REJECT in the mangle table? > It seems not. rebecca:~# iptables -t mangle -A POSTROUTING -m layer7 --l7proto http -j REJECT iptables: Invalid argument rebecca:~# iptables -A INPUT -m layer7 --l7proto http -j REJECT rebecca:~# iptables -D INPUT -m layer7 --l7proto http -j REJECT `man iptables` "REJECT This is used to send back an error packet in response to the matched packet: otherwise it is equivalent to DROP so it is a terminating TARGET, ending rule traversal. This target is only valid in the INPUT, FORWARD and OUTPUT chains, and userdefined chains which are only called from those chains. The following option controls the nature of the error packet returned:"
> `man iptables` > "REJECT > This is used to send back an error packet in response to the matched packet: > otherwise it is equivalent to DROP so it is a terminating TARGET, ending rule > traversal. This target is only valid in the INPUT, FORWARD and OUTPUT > chains, and userdefined chains which are only called from those chains. The > following option controls the nature of the error packet returned:" I kinda expectet that, but I just did whats on the Netfilter HOWTO page...there ist says: "Blocking packets when they are identified is easy. Simply use "-j DROP" (or REJECT) at the ends of the lines in the above section." But this is still not my problem, the problem is that the Layer7 classifier don't recognize the packets! (Thanks anyway)
heya! first thanks to all for your help. shaping is working now (not 100% but working). This is why I didn't notice that it already worked: My settings where all correct, BUT when I establish for example a FTP connection from the router itself, it is somehow not shaped, however a connection over the router (from a computer inside the lan) the connection is shaped perfectly (with layer7). So my question: Why do the layer7 rules only work with connections over the router but not from the router itself? -FB
> So my question: Why do the layer7 rules only work with connections > over the router but not from the router itself? Look at your script and look at which interface you are shaping on. Most likely you are shaping on the interface which talks to the lan. So the stuff destined for the local machine never sees the shaper The only real solution is to add the IMQ device to the wan side and use this to effectively put something upstream of the machine that you can shape on