CLASSIFY target

CLASSIFY target

[Chip Schweiss]

Is there a technical reason why the CLASSIFY target can only be called
from the POSTROUTING chain of the mangle table?  

It seems rather wasteful to repeat all the logic necessary to classify a
packet in the POSTROUTING chain that in most case will already be done
in the filter table.  Besides, in my testing the overhead of classifying
packets in the mangle table seems to be many magnitudes greater than in
the filter table.

Would it be possible to simply remove the checks if the rule is being
added in the POSTROUTING chain of mangle table from the kernel &
iptables sources and have the CLASSIFY target work from the filter
table?

Chip Schweiss

Re: CLASSIFY target

[Patrick McHardy]

Chip Schweiss wrote:
> Is there a technical reason why the CLASSIFY target can only be called
> from the POSTROUTING chain of the mangle table?  
> 
> It seems rather wasteful to repeat all the logic necessary to classify a
> packet in the POSTROUTING chain that in most case will already be done
> in the filter table.

It can also be called in the FORWARD and OUTPUT chains, but thats not
the point of course. Technically there is no reason for this, its more
of a convention to do packet mangling in the mangle table. The only
case where it is really necessary is marking packets for routing by
fwmark in the output chain, since these packets need to be rerouted.

I guess we could remove this restriction.

> Besides, in my testing the overhead of classifying
> packets in the mangle table seems to be many magnitudes greater than in
> the filter table.

How did you test this? Please post numbers if you have any.

> Would it be possible to simply remove the checks if the rule is being
> added in the POSTROUTING chain of mangle table from the kernel &
> iptables sources and have the CLASSIFY target work from the filter
> table?

Feel free so send a patch, but please also do this for all other
targets restricted to the mangle table and update the manpage.

RE: CLASSIFY target

[Eliot, Wireless and Server Administrator, Great Lakes Internet]

Thank you for your response. I did manage to finally find the code I was
looking for. I also just posted a new description to LARTC with a new
class/qdisc layout. Essentially, what I have now is:

dev wivl4 HFSC Qdisc root
  |
  |-> HFSC Class
  |
  |-> HFSC Class
  ...etc...

And I'm doing a classify directly to those classes. They have no sub
qdiscs or sub classes. Yet, it still will not work. Any additional
thoughts?

 
Eliot Gable
Certified Wireless Network Administrator (CWNA)
Certified Wireless Security Professional (CWSP)
Cisco Certified Network Associate (CCNA)
CompTIA Security+ Certified
CompTIA Network+ Certified
Network and System Engineer
Great Lakes Internet, Inc.
112 North Howard
Croswell, MI 48422
(810) 679-3395
(877) 558-8324
 
Now offering Broadband Wireless Internet access in Croswell, Lexington,
Brown City, Yale, Worth Township, and Sandusky. Call for details.

-----Original Message-----
From: Patrick McHardy [mailto:kaber@trash.net] 
Sent: Tuesday, May 30, 2006 3:22 PM
To: Eliot, Wireless and Server Administrator, Great Lakes Internet
Cc: netfilter-devel@lists.netfilter.org
Subject: Re: CLASSIFY target

Eliot, Wireless and Server Administrator, Great Lakes Internet wrote:
> I am attempting to classify packets in tc using the iptables classify
> target in the postrouting chain of the mangle table, but it does not
> work. I am looking through the code to try to find out what is going
on
> (whether I am doing something wrong, or whether the kernel module code
> is messed up). I have verified that the ipt_CLASSIFY.c file is
correctly
> building a handle and that it is storing the handle in the
skb->priority
> field. However, inside the packet scheduler code, I cannot find where
> the skb->priority field is being read so that the packets can be sent
to
> the correct class. Could someone please point me in the correct
> direction for viewing this section of the code? Thanks.


The *_classify functions of the individual schedulers use it. I see
you also posted a more detailed description of your problem to lartc:
you can't use classify to classify to multiple nested qdiscs. So
if you have something like:

         <1:0 (root) hfsc>
<1:1 hfsc class> <1:2 hfsc class>
         |
   <2:0 PRIO>
         |
<2:1 - 2:3 PRIO classes>


and say CLASSIFY --set-class 2:1, the upper HFSC qdisc had no idea
how to reach qdisc 2:0. You can either use CLASSIFY --class 2:0
and then attach more classifiers to the PRIO qdisc or manually
direct traffic from 1:0 -> 2:0 and use CLASSIFY --set-class 2:1.
CLASSIFY is really only useful if you have only a single level
of classful qdiscs.

Re: CLASSIFY target

[Patrick McHardy]

Eliot, Wireless and Server Administrator, Great Lakes Internet wrote:
> Thank you for your response. I did manage to finally find the code I was
> looking for. I also just posted a new description to LARTC with a new
> class/qdisc layout. Essentially, what I have now is:
> 
> dev wivl4 HFSC Qdisc root
>   |
>   |-> HFSC Class
>   |
>   |-> HFSC Class
>   ...etc...
> 
> And I'm doing a classify directly to those classes. They have no sub
> qdiscs or sub classes. Yet, it still will not work. Any additional
> thoughts?

No, please show the classids and commands uses.

CLASSIFY target

[Eliot, Wireless and Server Administrator, Great Lakes Internet]

I am attempting to classify packets in tc using the iptables classify
target in the postrouting chain of the mangle table, but it does not
work. I am looking through the code to try to find out what is going on
(whether I am doing something wrong, or whether the kernel module code
is messed up). I have verified that the ipt_CLASSIFY.c file is correctly
building a handle and that it is storing the handle in the skb->priority
field. However, inside the packet scheduler code, I cannot find where
the skb->priority field is being read so that the packets can be sent to
the correct class. Could someone please point me in the correct
direction for viewing this section of the code? Thanks.

 
Eliot Gable
Certified Wireless Network Administrator (CWNA)
Certified Wireless Security Professional (CWSP)
Cisco Certified Network Associate (CCNA)
CompTIA Security+ Certified
CompTIA Network+ Certified
Network and System Engineer
Great Lakes Internet, Inc.
112 North Howard
Croswell, MI 48422
(810) 679-3395
(877) 558-8324
 
Now offering Broadband Wireless Internet access in Croswell, Lexington,
Brown City, Yale, Worth Township, and Sandusky. Call for details.

Re: CLASSIFY target

[Patrick McHardy]

Eliot, Wireless and Server Administrator, Great Lakes Internet wrote:
> I am attempting to classify packets in tc using the iptables classify
> target in the postrouting chain of the mangle table, but it does not
> work. I am looking through the code to try to find out what is going on
> (whether I am doing something wrong, or whether the kernel module code
> is messed up). I have verified that the ipt_CLASSIFY.c file is correctly
> building a handle and that it is storing the handle in the skb->priority
> field. However, inside the packet scheduler code, I cannot find where
> the skb->priority field is being read so that the packets can be sent to
> the correct class. Could someone please point me in the correct
> direction for viewing this section of the code? Thanks.


The *_classify functions of the individual schedulers use it. I see
you also posted a more detailed description of your problem to lartc:
you can't use classify to classify to multiple nested qdiscs. So
if you have something like:

         <1:0 (root) hfsc>
<1:1 hfsc class> <1:2 hfsc class>
         |
   <2:0 PRIO>
         |
<2:1 - 2:3 PRIO classes>


and say CLASSIFY --set-class 2:1, the upper HFSC qdisc had no idea
how to reach qdisc 2:0. You can either use CLASSIFY --class 2:0
and then attach more classifiers to the PRIO qdisc or manually
direct traffic from 1:0 -> 2:0 and use CLASSIFY --set-class 2:1.
CLASSIFY is really only useful if you have only a single level
of classful qdiscs.