[LARTC] filters not doing anything?

[LARTC] filters not doing anything?

[Frank v Waveren]

I have the following setup:

tc qdisc del dev eth1 root
tc qdisc add dev eth1 root handle 1: htb
tc class add dev eth1 parent 1: classid 1:1 htb rate 80kbit ceil 80kbit
tc qdisc add dev eth1 parent 1:1 handle 2: prio
tc qdisc add dev eth1 parent 2:1 handle 3: sfq perturb 10
tc filter add dev eth1 protocol ip parent 1: prio 2 u32 match u8 0 0x0 at 0 flowid 3:

(the filter line is not like the one suggested in the howto because my
version of tc (the most recent with htb patch) barfs on not having any
rules)

After a while, looking at the stats:
qdisc sfq 3: dev eth1 limit 128p quantum 1514b perturb 10sec 
 Sent 0 bytes 0 pkts (dropped 0, overlimits 0) 
qdisc prio 2: dev eth1 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
 Sent 0 bytes 0 pkts (dropped 0, overlimits 0) 
qdisc htb 1: dev eth1 r2q 10 default 0 direct_packets_stat 476
 Sent 112219 bytes 476 pkts (dropped 0, overlimits 0) 

All the traffic went through the top htb (which wasn't limited) and
went straight out again. Why didn't the filter rule put everything in
the 3: SFQ, forcing it to trickle through the limited HTB class 1:1? 

-- 
Frank v Waveren                                      Fingerprint: 21A7 C7F3
fvw@[var.cx|stack.nl|chello.nl] ICQ#10074100            1FF3 47FF 545C CB53
Public key: hkp://wwwkeys.pgp.net/fvw@var.cx            7BD9 09C0 3AC1 6DF2
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] filters not doing anything?

[Frank v Waveren]

On Sat, Apr 19, 2003 at 10:55:53PM +0200, Frank v Waveren wrote:
> tc filter add dev eth1 protocol ip parent 1: prio 2 u32 match u8 0 0x0 at 0 flowid 3:
Perhaps of interest:

Replacing the filter line with:
tc filter add dev $DEV protocol ip parent 1: prio 2 u32 match u8 0 0x0 at 0 flowid 1:1
tc filter add dev $DEV protocol ip parent 1:1 prio 2 u32 match u8 0 0x0 at 0 flowid 2:
will convince the packet to trickle down to 2:.
Adding
tc filter add dev $DEV protocol ip parent 2: prio 2 u32 match u8 0 0x0 at 0 flowid 3:
will not get it down to 3: however.
Also, adding just
tc filter add dev $DEV protocol ip parent 1: prio 2 u32 match u8 0 0x0 at 0 flowid 2:

will _not_ get it down to 2:.

I think this has gotten to the point where kernel versions are
interesting, I'm running 2.4.21-pre5-ac3.

-- 
Frank v Waveren                                      Fingerprint: 21A7 C7F3
fvw@[var.cx|stack.nl|chello.nl] ICQ#10074100            1FF3 47FF 545C CB53
Public key: hkp://wwwkeys.pgp.net/fvw@var.cx            7BD9 09C0 3AC1 6DF2
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] filters not doing anything?

[Stef Coene]

On Saturday 19 April 2003 22:55, Frank v Waveren wrote:
> I have the following setup:
>
> tc qdisc del dev eth1 root
> tc qdisc add dev eth1 root handle 1: htb
> tc class add dev eth1 parent 1: classid 1:1 htb rate 80kbit ceil 80kbit
> tc qdisc add dev eth1 parent 1:1 handle 2: prio
> tc qdisc add dev eth1 parent 2:1 handle 3: sfq perturb 10
> tc filter add dev eth1 protocol ip parent 1: prio 2 u32 match u8 0 0x0 at 0
> flowid 3:
>
> (the filter line is not like the one suggested in the howto because my
> version of tc (the most recent with htb patch) barfs on not having any
> rules)
>
> After a while, looking at the stats:
> qdisc sfq 3: dev eth1 limit 128p quantum 1514b perturb 10sec
>  Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
> qdisc prio 2: dev eth1 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
>  Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
> qdisc htb 1: dev eth1 r2q 10 default 0 direct_packets_stat 476
>  Sent 112219 bytes 476 pkts (dropped 0, overlimits 0)
>
> All the traffic went through the top htb (which wasn't limited) and
> went straight out again. Why didn't the filter rule put everything in
> the 3: SFQ, forcing it to trickle through the limited HTB class 1:1?
Qdisc 3: is added to class 2:1.  So all traffic flowing in class 2:1 is 
handled by qdisc 3:.  Also, traffic in class 1:1 is handled by qdisc 2:.  
So you have to put the traffic in the class and not the qdisc.  So your filter 
should be : 1: -> 1:1 and a second filter from 2: -> 2:1.  
Or 1: -> 2:1.
The end of a filter is a class, not a qdisc.

Stef

-- 

stef.coene@docum.org
 "Using Linux as bandwidth manager"
     http://www.docum.org/
     #lartc @ irc.oftc.net

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] filters not doing anything?

[Frank v Waveren]

Stef Coene wrote:
> The end of a filter is a class, not a qdisc.

Ok, changed it to:
tc qdisc del dev eth1 root
tc qdisc add dev eth1 root handle 1: htb
tc class add dev eth1 parent 1: classid 1:1 htb rate 80kbit ceil 80kbit
tc qdisc add dev eth1 parent 1:1 handle 2: prio
tc qdisc add dev eth1 parent 2:1 handle 3: sfq perturb 10
tc filter add dev eth1 protocol ip parent 1: prio 2 u32 match u8 0 0x0 at 0 flowid 2:1

>> After a while, looking at the stats:
Once again, after a while:

qdisc sfq 3: dev eth1 limit 128p quantum 1514b perturb 10sec 
 Sent 0 bytes 0 pkts (dropped 0, overlimits 0) 
qdisc prio 2: dev eth1 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
 Sent 0 bytes 0 pkts (dropped 0, overlimits 0) 
qdisc htb 1: dev eth1 r2q 10 default 0 direct_packets_stat 2600
 Sent 448816 bytes 2600 pkts (dropped 0, overlimits 0) 

Still no traffic going through the SFQ :-(

-- 
Frank v Waveren                                      Fingerprint: 21A7 C7F3
fvw@[var.cx|stack.nl|chello.nl] ICQ#10074100            1FF3 47FF 545C CB53
Public key: hkp://wwwkeys.pgp.net/fvw@var.cx            7BD9 09C0 3AC1 6DF2
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] filters not doing anything?

[Stef Coene]

On Sunday 20 April 2003 23:56, Frank v Waveren wrote:
> Stef Coene wrote:
> tc filter add dev eth1 protocol ip parent 1: prio 2 u32 match u8 0 0x0 at 0
> flowid 2:1
What do you want to match??????

Stef

-- 

stef.coene@docum.org
 "Using Linux as bandwidth manager"
     http://www.docum.org/
     #lartc @ irc.oftc.net

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] filters not doing anything?

[Frank v Waveren]

On Sun, Apr 20, 2003 at 11:59:44PM +0200, Stef Coene wrote:
> On Sunday 20 April 2003 23:56, Frank v Waveren wrote:
> > Stef Coene wrote:
> > tc filter add dev eth1 protocol ip parent 1: prio 2 u32 match u8 0 0x0 at 0
> > flowid 2:1
> What do you want to match??????

That should match anything, right? I tried not having any filter in
the commandline as the HOWTO suggested, but tc didn't like it and
complained:
Unknown filter "flowid", hence option "2:1" is unparsable.

-- 
Frank v Waveren                                      Fingerprint: 21A7 C7F3
fvw@[var.cx|stack.nl|chello.nl] ICQ#10074100            1FF3 47FF 545C CB53
Public key: hkp://wwwkeys.pgp.net/fvw@var.cx            7BD9 09C0 3AC1 6DF2
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] filters not doing anything?

[Stef Coene]

On Monday 21 April 2003 00:12, Frank v Waveren wrote:
> On Sun, Apr 20, 2003 at 11:59:44PM +0200, Stef Coene wrote:
> > On Sunday 20 April 2003 23:56, Frank v Waveren wrote:
> > > Stef Coene wrote:
> > > tc filter add dev eth1 protocol ip parent 1: prio 2 u32 match u8 0 0x0
> > > at 0 flowid 2:1
> >
> > What do you want to match??????
>
> That should match anything, right? I tried not having any filter in
> the commandline as the HOWTO suggested, but tc didn't like it and
> complained:
You can specify a default class if you add the htb qdisc.  So all packets not 
matched by a filter ends up in that default class.
And try this if you want to have a catch all rule :
tc filter add dev eth0 parent 1: protocol ip u32 match ip src 0/0 flowid 2:1 

Stef

-- 

stef.coene@docum.org
 "Using Linux as bandwidth manager"
     http://www.docum.org/
     #lartc @ irc.oftc.net

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] filters not doing anything?

[Frank v Waveren]

On Mon, Apr 21, 2003 at 11:20:12AM +0200, Stef Coene wrote:
> You can specify a default class if you add the htb qdisc.  So all packets not 
> matched by a filter ends up in that default class.
Yeah, but the filters I pasted are just a test case, my actual setup
(pasted at the bottom of this email) really does require having
filters that properly delegate the traffic.

> And try this if you want to have a catch all rule :
> tc filter add dev eth0 parent 1: protocol ip u32 match ip src 0/0 flowid 2:1 
Tried that too, the packets still aren't going through the SFQ.

The setup:
BW€
DEV=eth1

HBW=$(($BW/2))

tc qdisc del dev $DEV root
tc qdisc add dev $DEV root handle 1: htb r2q 1
tc class add dev $DEV parent 1: classid 1:1 htb rate ${BW}kbit ceil ${BW}kbit
tc qdisc add dev $DEV parent 1:1 handle 2: prio bands 4
tc qdisc add dev $DEV parent 2:1 handle 10: sfq perturb 10 # Lowlatency
tc qdisc add dev $DEV parent 2:2 handle 20: sfq perturb 10 # Medium Latency
tc qdisc add dev $DEV parent 2:3 handle 30: sfq perturb 10 # Regular
tc qdisc add dev $DEV parent 2:4 handle 40: htb r2q 1      # Bulk

tc class add dev $DEV parent 40: classid 40:1 htb rate ${HBW}kbit ceil ${BW}kbit
tc class add dev $DEV parent 40: classid 40:2 htb rate ${HBW}kbit ceil ${BW}kbit
tc qdisc add dev $DEV parent 40:1 handle 41: sfq perturb 10
tc qdisc add dev $DEV parent 40:2 handle 42: sfq perturb 10

tc filter add dev $DEV parent 1: protocol ip prio 1 u32 match ip protocol 1 0xff flowid 2:1
tc filter add dev $DEV parent 1: protocol ip prio 1 u32 match ip tos 0x10 0xff flowid 2:1
tc filter add dev $DEV parent 1: protocol ip prio 1 u32 match ip protocol 6 0xff match u8 0x05 0x0f at 0 match u16 0x0000 0xffc0 at 2 match u8 0x10 0xff at 33 flowid 2:1 # Small ACKs

tc filter add dev $DEV parent 1: protocol ip prio 2 handle 1022 fw flowid 40:1  # Bulk1
tc filter add dev $DEV parent 1: protocol ip prio 2 handle 1027 fw flowid 40:2  # Bulk2

tc filter add dev $DEV parent 1: protocol ip prio 3 u32 match ip protocol 6 0xff match u8 0x10 0xff at nexthdr+13 flowid 2:1  # All ACKs

tc filter add dev $DEV protocol ip parent 1: prio 999 u32 match ip src 0/0 flowid 2:3  # Anything else goes into the Regular category


-- 
Frank v Waveren                                      Fingerprint: 21A7 C7F3
fvw@[var.cx|stack.nl|chello.nl] ICQ#10074100            1FF3 47FF 545C CB53
Public key: hkp://wwwkeys.pgp.net/fvw@var.cx            7BD9 09C0 3AC1 6DF2
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] filters not doing anything?

[Stef Coene]

On Monday 21 April 2003 16:04, Frank v Waveren wrote:
> On Mon, Apr 21, 2003 at 11:20:12AM +0200, Stef Coene wrote:
> > And try this if you want to have a catch all rule :
> > tc filter add dev eth0 parent 1: protocol ip u32 match ip src 0/0 flowid
> > 2:1
>
> Tried that too, the packets still aren't going through the SFQ.
>
> The setup:
> BW€
> DEV=eth1
>
> HBW=$(($BW/2))
>
> tc qdisc del dev $DEV root
> tc qdisc add dev $DEV root handle 1: htb r2q 1
> tc class add dev $DEV parent 1: classid 1:1 htb rate ${BW}kbit ceil
> ${BW}kbit tc qdisc add dev $DEV parent 1:1 handle 2: prio bands 4
> tc qdisc add dev $DEV parent 2:1 handle 10: sfq perturb 10 # Lowlatency
> tc qdisc add dev $DEV parent 2:2 handle 20: sfq perturb 10 # Medium Latency
> tc qdisc add dev $DEV parent 2:3 handle 30: sfq perturb 10 # Regular
> tc qdisc add dev $DEV parent 2:4 handle 40: htb r2q 1      # Bulk
>
> tc class add dev $DEV parent 40: classid 40:1 htb rate ${HBW}kbit ceil
> ${BW}kbit tc class add dev $DEV parent 40: classid 40:2 htb rate ${HBW}kbit
> ceil ${BW}kbit tc qdisc add dev $DEV parent 40:1 handle 41: sfq perturb 10
> tc qdisc add dev $DEV parent 40:2 handle 42: sfq perturb 10
>
> tc filter add dev $DEV parent 1: protocol ip prio 1 u32 match ip protocol 1
> 0xff flowid 2:1 tc filter add dev $DEV parent 1: protocol ip prio 1 u32
> match ip tos 0x10 0xff flowid 2:1 tc filter add dev $DEV parent 1: protocol
> ip prio 1 u32 match ip protocol 6 0xff match u8 0x05 0x0f at 0 match u16
> 0x0000 0xffc0 at 2 match u8 0x10 0xff at 33 flowid 2:1 # Small ACKs
>
> tc filter add dev $DEV parent 1: protocol ip prio 2 handle 1022 fw flowid
> 40:1  # Bulk1 tc filter add dev $DEV parent 1: protocol ip prio 2 handle
> 1027 fw flowid 40:2  # Bulk2
>
> tc filter add dev $DEV parent 1: protocol ip prio 3 u32 match ip protocol 6
> 0xff match u8 0x10 0xff at nexthdr+13 flowid 2:1  # All ACKs
>
> tc filter add dev $DEV protocol ip parent 1: prio 999 u32 match ip src 0/0
> flowid 2:3  # Anything else goes into the Regular category
But where is your catch all rule to put the packets in the 2:4 band?
And you never put packets in the 2:2 band.

An other question, why do you added that 4 bands prio?  You can do the same 
only with the htb qdisc.

Stef

-- 

stef.coene@docum.org
 "Using Linux as bandwidth manager"
     http://www.docum.org/
     #lartc @ irc.oftc.net

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] filters not doing anything?

[Frank v Waveren]

On Mon, Apr 21, 2003 at 09:33:52PM +0200, Stef Coene wrote:
> > The setup:
> > BW€
> > DEV=eth1
> > HBW=$(($BW/2))
> >
> > tc qdisc del dev $DEV root
> > tc qdisc add dev $DEV root handle 1: htb r2q 1
> > tc class add dev $DEV parent 1: classid 1:1 htb rate ${BW}kbit ceil
> > ${BW}kbit tc qdisc add dev $DEV parent 1:1 handle 2: prio bands 4
> > tc qdisc add dev $DEV parent 2:1 handle 10: sfq perturb 10 # Lowlatency
> > tc qdisc add dev $DEV parent 2:2 handle 20: sfq perturb 10 # Medium Latency
> > tc qdisc add dev $DEV parent 2:3 handle 30: sfq perturb 10 # Regular
> > tc qdisc add dev $DEV parent 2:4 handle 40: htb r2q 1      # Bulk
> >
> > tc class add dev $DEV parent 40: classid 40:1 htb rate ${HBW}kbit ceil
> > ${BW}kbit tc class add dev $DEV parent 40: classid 40:2 htb rate ${HBW}kbit
> > ceil ${BW}kbit tc qdisc add dev $DEV parent 40:1 handle 41: sfq perturb 10
> > tc qdisc add dev $DEV parent 40:2 handle 42: sfq perturb 10
> >
> > tc filter add dev $DEV parent 1: protocol ip prio 1 u32 match ip protocol 1
> > 0xff flowid 2:1 tc filter add dev $DEV parent 1: protocol ip prio 1 u32
> > match ip tos 0x10 0xff flowid 2:1 tc filter add dev $DEV parent 1: protocol
> > ip prio 1 u32 match ip protocol 6 0xff match u8 0x05 0x0f at 0 match u16
> > 0x0000 0xffc0 at 2 match u8 0x10 0xff at 33 flowid 2:1 # Small ACKs
> >
> > tc filter add dev $DEV parent 1: protocol ip prio 2 handle 1022 fw flowid
> > 40:1  # Bulk1 tc filter add dev $DEV parent 1: protocol ip prio 2 handle
> > 1027 fw flowid 40:2  # Bulk2
> >
> > tc filter add dev $DEV parent 1: protocol ip prio 3 u32 match ip protocol 6
> > 0xff match u8 0x10 0xff at nexthdr+13 flowid 2:1  # All ACKs
> >
> > tc filter add dev $DEV protocol ip parent 1: prio 999 u32 match ip src 0/0
> > flowid 2:3  # Anything else goes into the Regular category

> But where is your catch all rule to put the packets in the 2:4 band?
Catchall rule? I only want fwmarked traffic in 2:4, and it gets in
there through 40:1 and 40:2.

> And you never put packets in the 2:2 band.
Yeah, that's yet to be filled, I was going to select traffic for that
once I had it up and running. But I don't yes, because I can't even
get the simple test case working properly, let alone this :-(

> An other question, why do you added that 4 bands prio?  You can do the same 
> only with the htb qdisc.
How? I want the first band to have priority, always. I could make its
rate equal to its ceil, but that'd mean the other classes in the HTB
would have to have rate 0, and that'd mean the bandwidth that gets
left after the first band was depleted would get distributed evenly,
and I don't want that.

-- 
Frank v Waveren                                      Fingerprint: 21A7 C7F3
fvw@[var.cx|stack.nl|chello.nl] ICQ#10074100            1FF3 47FF 545C CB53
Public key: hkp://wwwkeys.pgp.net/fvw@var.cx            7BD9 09C0 3AC1 6DF2
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] filters not doing anything?

[Stef Coene]

> > But where is your catch all rule to put the packets in the 2:4 band?
>
> Catchall rule? I only want fwmarked traffic in 2:4, and it gets in
> there through 40:1 and 40:2.
Ok.

> > And you never put packets in the 2:2 band.
> Yeah, that's yet to be filled, I was going to select traffic for that
> once I had it up and running. But I don't yes, because I can't even
> get the simple test case working properly, let alone this :-(
Ok.

> > An other question, why do you added that 4 bands prio?  You can do the
> > same only with the htb qdisc.
>
> How? I want the first band to have priority, always. I could make its
> rate equal to its ceil, but that'd mean the other classes in the HTB
> would have to have rate 0, and that'd mean the bandwidth that gets
> left after the first band was depleted would get distributed evenly,
> and I don't want that.
It depends on what you want to achieve.  You create a very complicated setup 
with 3 qdiscs.  If you only want speed up ACK, and other traffic, you can do 
this with 1 htb qdisc only.  More qdiscs, means more queues so higher 
latency, higher CPU usage.
It also depends on how mach traffic you put in the bands.  If you only want to 
speed up ACK, you can also use a htb class with a higher priority.

So it just depends on what you want to do.  Maybe there is a cleaner solution.

Stef

-- 

stef.coene@docum.org
 "Using Linux as bandwidth manager"
     http://www.docum.org/
     #lartc @ irc.oftc.net

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] filters not doing anything?

[Frank v Waveren]

On Tue, Apr 22, 2003 at 04:41:31PM +0200, Stef Coene wrote:
> It depends on what you want to achieve.  You create a very complicated setup 
> with 3 qdiscs.  If you only want speed up ACK, and other traffic, you can do 
> this with 1 htb qdisc only.  More qdiscs, means more queues so higher 
> latency, higher CPU usage.
> It also depends on how mach traffic you put in the bands.  If you only want to 
> speed up ACK, you can also use a htb class with a higher priority.
So a class with a higher priority that isn't empty will always be
scheduled in front of one with a lower prio? That'd do the trick yes,
good.

> So it just depends on what you want to do.  Maybe there is a cleaner solution.
Perhaps, but at the moment I'd be happy with just having filters work
properly. I'll try a clean, unpatched, straight-from-linus (or
marcelo) kernel later this week and see if it works on that.

-- 
Frank v Waveren                                      Fingerprint: 21A7 C7F3
fvw@[var.cx|stack.nl|chello.nl] ICQ#10074100            1FF3 47FF 545C CB53
Public key: hkp://wwwkeys.pgp.net/fvw@var.cx            7BD9 09C0 3AC1 6DF2
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] filters not doing anything?

[Stef Coene]

On Tuesday 22 April 2003 19:25, Frank v Waveren wrote:
> On Tue, Apr 22, 2003 at 04:41:31PM +0200, Stef Coene wrote:
> > It depends on what you want to achieve.  You create a very complicated
> > setup with 3 qdiscs.  If you only want speed up ACK, and other traffic,
> > you can do this with 1 htb qdisc only.  More qdiscs, means more queues so
> > higher latency, higher CPU usage.
> > It also depends on how mach traffic you put in the bands.  If you only
> > want to speed up ACK, you can also use a htb class with a higher
> > priority.
>
> So a class with a higher priority that isn't empty will always be
> scheduled in front of one with a lower prio? That'd do the trick yes,
> good.
Yes.  But if you send too much data in the higher priority class (so you 
overlimit it), latency goes up.

> > So it just depends on what you want to do.  Maybe there is a cleaner
> > solution.
>
> Perhaps, but at the moment I'd be happy with just having filters work
> properly. I'll try a clean, unpatched, straight-from-linus (or
> marcelo) kernel later this week and see if it works on that.

-- 

stef.coene@docum.org
 "Using Linux as bandwidth manager"
     http://www.docum.org/
     #lartc @ irc.oftc.net

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/