Hello,

While configuring my firewall and QOS, I wanted to make use of the ipp2p module. On their website, some examples make use of these 2 modules.
Even if it's possible to build a firewall without them, i think this is interesting to put them in openwrt.

So here are 2 files :
Add this one in target/linux/linux-2.4/patches/generic
http://aorlinsk2.free.fr/openwrt/patche … SIFY.patch

Patch the lastest CVS repository with this file
http://aorlinsk2.free.fr/openwrt/patche … tory.patch

The new modules will be included in iptables-extra.

Anael

Has anyone build a .ipk yet that includes the CLASSIFY filter?  (I'm running WhiteRussion RC3.)

Thanks,
Bill

I didn't build an .ipk, because I spent over an hour getting a build environment setup, following these instructions to get the modules built:

http://forum.openwrt.org/viewtopic.php?id=1866

and getting everything working, but I've put up the two modules you need for WhiteRussion RC3. (in addition to the iptables-extra, and tc packages) here if anyone wants to use them:

http://blues.gotdns.org/ipt_classify.tar.bz

on your WRT:

Copy ipt_CLASSIFY.o to /lib/modules/2.4.30/
Copy libipt_CLASSIFY.so to /usr/lib/iptables/

make sure you've got all your modules insmod'd:

for module in sch_prio sch_htb sch_sfq sch_ingress cls_tcindex cls_fw cls_route cls_u32 ipt_CLASSIFY ipt_length
do
  insmod $module 2> /dev/null > /dev/null
done

and away you go. 

For anyone else (besides wtrenker reading this), if you're new to traffic shaping read this:

http://lartc.org/howto/lartc.cookbook.f … intro.html

Make sure you understand what's going on, then look at this example to see another way of doing it:

http://brewer123.home.comcast.net/openwrt/S46qos

and finally, look at this for what I think is the most elegant way, thus the reason I wanted the classify module (combined with some of the best bits from the other two):

http://www.knowplace.org/shaper/examples.html

For the weak at heart, don't attempt any of this. Just get the wondershaper package and start learning from there.  When you're feet are wet and you're comfortable, then have it.

Someone with more time could easily turn this into an .ipk if they want to, and personally, I'd really like to see the classify module included in the iptables-extra package, because it's much cleaner than using tc alone (not human readable), or having to go through multiple steps of marking packets with iptables (inefficient).

Greg

Hi bluesguy,

Thanks very much for such an informative reply.  Traffic shaping has become hugely important as the popularity of both VOIP (low latency) and downloading of all kinds (bandwidth hogs) continue to explode.

Cheers,
Bill

You're welcome, hope it helps.  I got interested in traffic shaping when I started playing with asterisk and VOIP, so I know exactly what you mean.  If you want to see what my setup looks like, I put it up as well:

http://blues.gotdns.org/traffic-shaping.tar.bz

These files are installed as follows:
75-ts -> /etc/modules.d/  (loads all the proper modules on bootup.  I like the way OpenWrt  does this; very clean!)
traffic-shaper.conf -> /etc  (configures your bandwidth settings, and your percentages for the different classes)
S61traffic-shaping -> /etc/init.d  (sets up the classes, categorizes with iptables classify, starts, stops, restart, status, etc.) 

I've commented these so it should be pretty easy to see what's going on... at least it is for me :-)

I shamlessly stole and modified the init.d script from http://www.knowplace.org/shaper/examples.html

What you need installed:
You'll need the classify modules I posted earlier.
You'll need bc (available via the tracker) to do some calculations.
In addition you need all the normal stuff for traffic shaping that can be found via the tracker (tc, iptables-extra, kmod-iptables-extra)

This is my first serious effort at traffic shaping, and I've done a lot of research, but there's certainly a chance I screwed something up.  Let me know if you see any glaring errors. 

FYI - I picked my own numbers (S61 and 75) for these files, and they don't have any official blessing, so it's possible that someone official (such as nbd) could make a change that conflicts with these.  Use at your own risk; YMMV; works for me. :-)

Future plans:
1)  I don't do any ingress throttling, primarily because TCP should do that for me based on my egress rates, which I'm controlling.  I may add it later though just to play around a bit...
2)  I may add some lines to set ToS on certain traffic.  I don't do that now for two reasons.  First, asterisk already sets ToS on it's own traffic via its config, and second, it's extremely unlikely that all the hops along the way really obey ToS anyway.  However I may do some ToS over VPN tunnels where I have more control (ToS encapsulated in the payload) so the endpoints could get it and repect the setting.

Let me know what you think or if you've got something better!

Greg

I've just submitted Connbytes-patch to the devs. Hopefully this'll be included in the openwrt-source. The connbytes-patch can be used like this, http://sill.rtfm.se/~ph/sully/qos-regler.txt

Note the connbytes matcher used in conjuction with connmark/CONNMARK.

Patrik, did you look at the documentation links I referenced, or the files I posted, because what you're doing seems much more complicated than it needs to be.

I prefer iptables with the classify module because IMHO it's much cleaner, and by that I mean more efficient and human readable.  The link you posted is very difficult to clearly see what's going on.

Second, my script and modules fit very nicely into the stock OpenWrt setup, and could easily be an add-on ipkg.  Thanks to the elegant way that OpenWrt is structured, my files fit in very nicely and require no modifications to anything.  I purposely separated them from the firewall.user file so that I could turn traffic shaping on and off with affecting the rest of my NAT and firewall stuff.  Your link, on the other hand, looks like a massive depature from the stock setup. 

If you combine my bits with the already available p2p package, it seems like you'll have the same thing as what you posted, with much less of a headache when you're done.

Anyway I really hope no traffic shaping stuff gets included in the mainline image, but rather stays as an optional package.  The real beauty (and the secret to the success) of OpenWrt is the very nicely organized, minimal image that easy to customize the way you want it!  So your device can be an access point, or a radius server, or a web server, or a router, all with same base image, and a minimal amount of effort.

Thanks developers!

G

Hi,

I wanted to keep my scripts clean from using the famous "ipp2p"-software. I'd much rather be able to tell the kernel "ok, check new connections, but only do it if they haven't previously been checked AND the connection is in it's statup-phase". This saves alot of cpu cycles.

Also your script does things a bit different that mine does, and it needs to be that complicated since i don't want to shape traffic which goes from one internal interface to another internal interface (wireless to local wired), hence my interface matching in FORWARD.

This can be discussed alot, I didn't ask the core team to include my script into the mainstream image. I will make it public by an ipkg. What i did ask for was them to include connbytes, which i provided in the patch i submitted, nothing more, nothing less. No wrong in having one more match available in the kernel aslong as its' code is clean, imho.

The choice of shaper-script should be up to the user, not to us authors.
Freedom of choice

My Script can be found here, http://sill.rtfm.se/~ph/sully/shaper/
It uses a config file which is to be placed in /etc

Make sure you start the script after any existing scripts, such as Shorewall or the regular S45firewall.

The script is started something like this.

shaper.sh start eth1 17291 1000 72 eth0 932 1000 3

Where:
eth1 is the network card connected to your LAN
17291 is your (actual) download speed in Kbit/s
1000 is the amount of traffic (in mille (1/1000)) available to the p2p-class (2:1030)
72 is the correct R2Q (RateToQueue), Make sure your quantum doesn't drop below your MTU.

eth0 is the network card connected to the WAN (Internet)
932 is your (actual) upload speed in Kbit/s
1000 is the amount of traffic (in mille (1/1000)) available to the p2p-class (1:1030)
3 is the correct R2Q (RateToQueue), Make sure your quantum doesn't drop below your MTU.

Note that this script requires {connbytes, CONNMARK, connmark, string, mark, MARK, [ipp2p]} for full functionality

It also utilizes the TC-version which enables you to set MPU and OVERHEAD variables for better calculations when used with links such as ADSL & friends. Binary for the WRT54G/S (and perhaps other platforms aswell using MIPS32) here, http://sill.rtfm.se/~ph/sully/tc

Enjoy!

Sincerely,
Patrik

(Last edited by patrik on 29 Oct 2005, 21:06)

I see.  Yeah, that's a nice touch, but it does make it a little more complicated.

I don't think I shape anything except traffic that's leaving outbound on vlan1, which is the external interface on my WRT54GS.  That's why I do everything in the POSTROUTING chain of the mangle table.  So I'm not sure what you mean here....

Right.  I wasn't saying that you did, perhaps I came across wrong?  I was just saying I like the way the mainstream image is very clean, and that's the reason it's so popular.  The stripped down image makes for easy customization.

I couldn't agree more.   And I was basically saying the same thing.  I hope the ipt_CLASSFY modules get included in the iptables-extra package because they're very useful, and a only tiny increase in the size of the package.  For those people who are going to install iptables-extra, it just makes sense to have them there.

So are you mostly just throttling p2p more efficiently, or is there something else you're getting out of doing it this way?  As you can see from my script, I'm really not that concerned about p2p, because it just gets lumped into the default class (lowest bandwidth).  If I'm not doing anything else, it does get the whole pipe though, so it works well for me....

Greg

(Last edited by bluesguy on 29 Oct 2005, 21:49)

For anyone who's interested, I updated my traffic shaping script to fix some problems I noticed.   The biggest problem was that I didn't notice that sshd generates all of its outbound traffic as ToS type 16 (minimize-delay) and my script was honoring ToS before doing anything else, so all the ssh traffic was getting a much higher priority that it was supposed to, and my later rules for ssh were being ignored.  Ooops.  That'll teach me to write a script and not sniff the wire to see what was happening...

Since there doesn't seem to be any configuration option to change the way sshd marks its packets, I've resorted to modifying the ToS bits on the ssh packets before classifying them.  Kind of a shame to have to mangle the same packet twice, but my WRT can handle it.  You'll notice I'm doing it inbound on the br0 interface which means that even internal ssh traffic is getting mangled.  This certainly isn't neccesary as I could just do it on the POSTROUTING chain on vlan1 prior to my other rules, but I prefer to keep it that way for no particular reason.  Probably lack of coffee. :-)

So my primary changes are:
* [bug] - Fixed how I handled ssh traffic to properly give interactive traffic higher priority than bulk traffic
* [feature] - Switched udp to highest priority for SIP and games
* [bug] - Included an /etc/services file so the script will actually work

The last bit is optional, and is only for convenience.  If you have the space on your device, you can add the services file so you can use text descriptions of ports in the script like I do, but the file is rather large.  Those short on space should not use the file, and instead change the text to actual port numbers.  I have a GS so I've got room. :-)

To recap my last few notes...

I've put the new version here:

http://blues.gotdns.org/traffic-shaping-1.3.tar.bz

and the classify modules for WR-RC3 are still here:

http://blues.gotdns.org/ipt_classify.tar.bz

The files are as follows:

services -> /etc (standard services file taken from Fedora Core 3, allows text descriptions of ports in script)
75-ts -> /etc/modules.d/  (loads all the proper modules on bootup.  I like the way OpenWrt  does this; very clean!)
traffic-shaper.conf -> /etc  (configures your bandwidth settings, and your percentages for the different classes)
S61traffic-shaping -> /etc/init.d  (sets up the classes, categorizes with iptables classify, starts, stops, restart, status, etc.)
ipt_CLASSIFY.o -> /lib/modules/2.4.30/ (kernel module for classifying packets)
libipt_CLASSIFY.so -> /usr/lib/iptables/ (iptables interface to kernel module)

What you need installed:
You'll need the classify modules.
You'll need bc (available via the tracker) to do some calculations.
You need all the normal stuff for traffic shaping that can be found via the tracker (tc, iptables-extra, kmod-iptables-extra)

-----------

So the result is that I've written and customized this to shape my traffic that I see on my network, but it should be a really useful starting point for anyone looking to do the same on the their network.  I just think it's cleaner and more understandable than the various versions of wondershaper that are out there.  It's at least a very good learning tool, if nothing else.

Maybe someone would like to help me make an ipkg of this?  Anyone have any feedback or suggestions?

Greg

This has nothing to do with this discussion.  Please start a new thread, preferably in the General Discussion area.