Patrick Spousta wrote:

<snip>

I don't think IMQ will help - but you can mark local src in postrouting


Do you mean manualy configured marking for many, many IP addresses? I think it isn't right way :-( I like ESFQ for it's source or destination hash because I don't need to setup any filters/markers for those IPs, ESFQ creats it's own queues for each IP.

Yes I agree - not nice for your setup, though personally the thing I don't like about using esfq on src/dst is you loose per tcp fairness - it was less than a year ago that I was on 56K and anyone with high latency downloading from you will get their already small bandwidth squeezed out by the low latency downloaders.


Maybe it's less noticable/of an issue for your big setup anyway.


In POSTROUTING chain it normaly look like this


... -> mangle -> nat -> imq -> (output interface)

I don't understand C language so I don't understand IMQ+NAT patch, but I'll try to use imq for egress shapping. Maybe the patch is working identically on PRE i POST chains.

I only just started getting into C myself - (used motorolla 68000 assembly years ago on an atari ST - these "high level" languages are much trickier :-) ).


I can see that the patch is trivial and needs an understanding of netfilter hooks more than C.

I just tested with u32 to double confirm what I knew really - the patch only affects prerouting hooks.

Then knowing nothing about netfilter decided to have a go at changing the egress hook - it appears to be working as expected.

One caveat - some people have reported stability problems using postrouting IMQ, probably to do with dropping locally generated traffic. I and others don't, but then I don't leave my gateway PC up that long. Grepping my logs :

Sent 3744702472 bytes 5539814 pkts (dropped 354902, overlimits 11722774)

is the most I can see (most of the drops are locally generated packets ie. bittorrent running on the shaping PC).

If you wan't to give my blind and possibly stupid hack a go you just need to change near the top of drivers/net/imq.c so it looks like -

static struct nf_hook_ops imq_egress_ipv4 = {
        { NULL, NULL},
        imq_nf_hook,
        PF_INET,
        NF_IP_POST_ROUTING,
        NF_IP_PRI_NAT_SRC - 1
};


Rather than -


static struct nf_hook_ops imq_egress_ipv4 = {
        { NULL, NULL},
        imq_nf_hook,
        PF_INET,
        NF_IP_POST_ROUTING,
        NF_IP_PRI_LAST
};

You could do the same for the egress ipv6 bits below it aswell.

If you still have your source tree intact and use modules cd to top dir in kernel tree do

make SUBDIRS=drivers/net modules

which should build a new imq.o in drivers/net

Backup /lib/modules/[your version]/kernel/drivers/net/imq.o

and replace with new one.

Take down shaping and modprobe -r imq (check it's gone with lsmod) and restart shaper.

It's a bit of a pain that imq is unstable for some anyway - you won't know whoose fault it is if/when it crashes :-)

Andy.

_______________________________________________
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Reply via email to