thr3ads.net - LARTC - iptables CLASSIFY and MARK not working? [May 2006]

If this information is useful, please help other people find it:
Share via:

Eliot, Wireless and Server Administrator, Great Lakes Internet

2006-May-19 14:31 UTC

iptables CLASSIFY and MARK not working?

I have to match my packets based on MAC address, which I cannot do in
the POSTROUTING chain, so I do it in PREROUTING using MARK. Then, I
match on the MARK in the POSTROUTING chain to do a CLASSIFY. But this
does not seem to work:

wireless-r1 bwlimit # iptables -L -v -n -t mangle
Chain PREROUTING (policy ACCEPT 3353K packets, 941M bytes)
 pkts bytes target     prot opt in     out     source
destination
12527   11M CONNMARK   all  --  *      *       0.0.0.0/0
0.0.0.0/0           CONNMARK restore
 3227  130K MARK       all  --  *      *       0.0.0.0/0
0.0.0.0/0           MAC 00:05:9E:81:3D:07 MARK set 0x30
 3231  132K CONNMARK   all  --  *      *       0.0.0.0/0
0.0.0.0/0           MARK match 0x30 CONNMARK save
    0     0 MARK       udp  --  *      *       0.0.0.0/0
0.0.0.0/0           MAC 00:05:9E:81:3D:07 multiport ports
53,4569,5060,10000:20000 MARK set 0x2f
    0     0 MARK       tcp  --  *      *       0.0.0.0/0
0.0.0.0/0           MAC 00:05:9E:81:3D:07 multiport ports 22,23,53 MARK
set 0x2f
    3   180 MARK       icmp --  *      *       0.0.0.0/0
0.0.0.0/0           MAC 00:05:9E:81:3D:07 MARK set 0x2f
 3222  129K MARK       tcp  --  *      *       0.0.0.0/0
0.0.0.0/0           tcp flags:0x18/0x10 MAC 00:05:9E:81:3D:07 MARK set
0x2f
    0     0 MARK       udp  --  *      *       0.0.0.0/0
0.0.0.0/0           udp dpt:53 MAC 00:05:9E:81:3D:07 MARK set 0x2f
    0     0 MARK       udp  --  *      *       0.0.0.0/0
0.0.0.0/0           udp spt:53 MAC 00:05:9E:81:3D:07 MARK set 0x2f
10272   10M CONNMARK   all  --  *      *       0.0.0.0/0
0.0.0.0/0           MARK match 0x2f CONNMARK save
    0     0 MARK       all  --  *      *       0.0.0.0/0
0.0.0.0/0           MAC 00:05:9E:81:3D:07 ipp2p v0.8.0 --ipp2p MARK set
0x31
    0     0 CONNMARK   all  --  *      *       0.0.0.0/0
0.0.0.0/0           MARK match 0x31 CONNMARK save

Chain INPUT (policy ACCEPT 1177K packets, 165M bytes)
 pkts bytes target     prot opt in     out     source
destination

Chain FORWARD (policy ACCEPT 1157K packets, 703M bytes)
 pkts bytes target     prot opt in     out     source
destination

Chain OUTPUT (policy ACCEPT 535K packets, 95M bytes)
 pkts bytes target     prot opt in     out     source
destination

Chain POSTROUTING (policy ACCEPT 1613K packets, 790M bytes)
 pkts bytes target     prot opt in     out     source
destination
 3225  129K CLASSIFY   all  --  *      br1     0.0.0.0/0
0.0.0.0/0           MARK match 0x2f CLASSIFY set 47:1
    2   506 CLASSIFY   all  --  *      br1     0.0.0.0/0
0.0.0.0/0           MARK match 0x30 CLASSIFY set 48:1
    0     0 CLASSIFY   all  --  *      br1     0.0.0.0/0
0.0.0.0/0           MARK match 0x31 CLASSIFY set 49:1
 6352 9321K CLASSIFY   all  --  *      wivl4   0.0.0.0/0
0.0.0.0/0           MARK match 0x2f CLASSIFY set 47:1
    4  1932 CLASSIFY   all  --  *      wivl4   0.0.0.0/0
0.0.0.0/0           MARK match 0x30 CLASSIFY set 48:1
    0     0 CLASSIFY   all  --  *      wivl4   0.0.0.0/0
0.0.0.0/0           MARK match 0x31 CLASSIFY set 49:1

wireless-r1 bwlimit # tc -s qdisc show dev wivl4
qdisc prio 5: bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
 Sent 11887911 bytes 8179 pkt (dropped 878, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
qdisc htb 26: parent 5:1 r2q 10 default 1 direct_packets_stat 0
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
qdisc htb 27: parent 5:2 r2q 10 default 1 direct_packets_stat 0
 Sent 10657 bytes 162 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
qdisc htb 28: parent 5:3 r2q 10 default 1 direct_packets_stat 0
 Sent 11877254 bytes 8017 pkt (dropped 878, overlimits 1120 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
qdisc htb 47: parent 26:1 r2q 10 default 1 direct_packets_stat 0
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
qdisc htb 48: parent 27:1 r2q 10 default 1 direct_packets_stat 0
 Sent 10657 bytes 162 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
qdisc htb 49: parent 28:1 r2q 10 default 1 direct_packets_stat 0
 Sent 11877254 bytes 8017 pkt (dropped 878, overlimits 1120 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0

wireless-r1 bwlimit # tc -s class show dev wivl4
class prio 5:1 parent 5: leaf 26:

class prio 5:2 parent 5: leaf 27:

class prio 5:3 parent 5: leaf 28:

class htb 26:1 root leaf 47: prio 0 rate 30000Kbit ceil 30000Kbit burst
16593b cburst 16593b
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 lended: 0 borrowed: 0 giants: 0
 tokens: 4532 ctokens: 4532

class htb 27:1 root leaf 48: prio 0 rate 60000Kbit ceil 60000Kbit burst
31590b cburst 31590b
 Sent 54187 bytes 790 pkt (dropped 0, overlimits 0 requeues 0)
 rate 624bit 1pps backlog 0b 0p requeues 0
 lended: 790 borrowed: 0 giants: 0
 tokens: 4306 ctokens: 4306

class htb 28:1 root leaf 49: prio 0 rate 10000Kbit ceil 10000Kbit burst
6598b cburst 6598b
 Sent 16539369 bytes 11178 pkt (dropped 1160, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 lended: 11178 borrowed: 0 giants: 0
 tokens: 5368 ctokens: 5368

class htb 47:1 root prio 1 rate 80000bit ceil 128000bit burst 125Kb
cburst 8000b
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 lended: 0 borrowed: 0 giants: 0
 tokens: 13107200 ctokens: 512000

class htb 48:1 root prio 2 rate 2048Kbit ceil 3072Kbit burst 3000Kb
cburst 192000b
 Sent 54187 bytes 790 pkt (dropped 0, overlimits 0 requeues 0)
 rate 624bit 1pps backlog 0b 0p requeues 0
 lended: 790 borrowed: 0 giants: 0
 tokens: 12287744 ctokens: 511831

class htb 49:1 root prio 3 rate 960000bit ceil 960000bit burst 960000b
cburst 60000b
 Sent 16539369 bytes 11178 pkt (dropped 1160, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 lended: 11178 borrowed: 0 giants: 0
 tokens: 8191591 ctokens: 511591


In the iptables rules, you''ll see that the bulk of the traffic
I''m
sending through is getting marked with 0x2f (47 decimal). In the
POSTROUTING chain, it is being classified as 47:1. In fact, nothing at
all is getting classified as 49:1. But, in the TC class and qdisc
displays, everything is coming up under the 49:1 instead of the 47:1.
What happened? Either I have some weird typo I''m not seeing, or this is
just not working the way I''m expecting it to. Anyone have any thoughts
on this?

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 Systems Administrator
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, and Sandusky. Call for details.

Andreas Unterkircher

2006-May-19 17:31 UTC

head link

Re: iptables CLASSIFY and MARK not working?

Have you checked that the ip_conntrack module is loaded or compiled into 
the kernel?
If not the mark is lost...

Cheers,
Andreas

Eliot, Wireless and Server Administrator, Great Lakes Internet
schrieb:> I have to match my packets based on MAC address, which I cannot do in
> the POSTROUTING chain, so I do it in PREROUTING using MARK. Then, I
> match on the MARK in the POSTROUTING chain to do a CLASSIFY. But this
> does not seem to work:
>
> wireless-r1 bwlimit # iptables -L -v -n -t mangle
> Chain PREROUTING (policy ACCEPT 3353K packets, 941M bytes)
>  pkts bytes target     prot opt in     out     source
> destination
> 12527   11M CONNMARK   all  --  *      *       0.0.0.0/0
> 0.0.0.0/0           CONNMARK restore
>  3227  130K MARK       all  --  *      *       0.0.0.0/0
> 0.0.0.0/0           MAC 00:05:9E:81:3D:07 MARK set 0x30
>  3231  132K CONNMARK   all  --  *      *       0.0.0.0/0
> 0.0.0.0/0           MARK match 0x30 CONNMARK save
>     0     0 MARK       udp  --  *      *       0.0.0.0/0
> 0.0.0.0/0           MAC 00:05:9E:81:3D:07 multiport ports
> 53,4569,5060,10000:20000 MARK set 0x2f
>     0     0 MARK       tcp  --  *      *       0.0.0.0/0
> 0.0.0.0/0           MAC 00:05:9E:81:3D:07 multiport ports 22,23,53 MARK
> set 0x2f
>     3   180 MARK       icmp --  *      *       0.0.0.0/0
> 0.0.0.0/0           MAC 00:05:9E:81:3D:07 MARK set 0x2f
>  3222  129K MARK       tcp  --  *      *       0.0.0.0/0
> 0.0.0.0/0           tcp flags:0x18/0x10 MAC 00:05:9E:81:3D:07 MARK set
> 0x2f
>     0     0 MARK       udp  --  *      *       0.0.0.0/0
> 0.0.0.0/0           udp dpt:53 MAC 00:05:9E:81:3D:07 MARK set 0x2f
>     0     0 MARK       udp  --  *      *       0.0.0.0/0
> 0.0.0.0/0           udp spt:53 MAC 00:05:9E:81:3D:07 MARK set 0x2f
> 10272   10M CONNMARK   all  --  *      *       0.0.0.0/0
> 0.0.0.0/0           MARK match 0x2f CONNMARK save
>     0     0 MARK       all  --  *      *       0.0.0.0/0
> 0.0.0.0/0           MAC 00:05:9E:81:3D:07 ipp2p v0.8.0 --ipp2p MARK set
> 0x31
>     0     0 CONNMARK   all  --  *      *       0.0.0.0/0
> 0.0.0.0/0           MARK match 0x31 CONNMARK save
>
> Chain INPUT (policy ACCEPT 1177K packets, 165M bytes)
>  pkts bytes target     prot opt in     out     source
> destination
>
> Chain FORWARD (policy ACCEPT 1157K packets, 703M bytes)
>  pkts bytes target     prot opt in     out     source
> destination
>
> Chain OUTPUT (policy ACCEPT 535K packets, 95M bytes)
>  pkts bytes target     prot opt in     out     source
> destination
>
> Chain POSTROUTING (policy ACCEPT 1613K packets, 790M bytes)
>  pkts bytes target     prot opt in     out     source
> destination
>  3225  129K CLASSIFY   all  --  *      br1     0.0.0.0/0
> 0.0.0.0/0           MARK match 0x2f CLASSIFY set 47:1
>     2   506 CLASSIFY   all  --  *      br1     0.0.0.0/0
> 0.0.0.0/0           MARK match 0x30 CLASSIFY set 48:1
>     0     0 CLASSIFY   all  --  *      br1     0.0.0.0/0
> 0.0.0.0/0           MARK match 0x31 CLASSIFY set 49:1
>  6352 9321K CLASSIFY   all  --  *      wivl4   0.0.0.0/0
> 0.0.0.0/0           MARK match 0x2f CLASSIFY set 47:1
>     4  1932 CLASSIFY   all  --  *      wivl4   0.0.0.0/0
> 0.0.0.0/0           MARK match 0x30 CLASSIFY set 48:1
>     0     0 CLASSIFY   all  --  *      wivl4   0.0.0.0/0
> 0.0.0.0/0           MARK match 0x31 CLASSIFY set 49:1
>
> wireless-r1 bwlimit # tc -s qdisc show dev wivl4
> qdisc prio 5: bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
>  Sent 11887911 bytes 8179 pkt (dropped 878, overlimits 0 requeues 0)
>  rate 0bit 0pps backlog 0b 0p requeues 0
> qdisc htb 26: parent 5:1 r2q 10 default 1 direct_packets_stat 0
>  Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>  rate 0bit 0pps backlog 0b 0p requeues 0
> qdisc htb 27: parent 5:2 r2q 10 default 1 direct_packets_stat 0
>  Sent 10657 bytes 162 pkt (dropped 0, overlimits 0 requeues 0)
>  rate 0bit 0pps backlog 0b 0p requeues 0
> qdisc htb 28: parent 5:3 r2q 10 default 1 direct_packets_stat 0
>  Sent 11877254 bytes 8017 pkt (dropped 878, overlimits 1120 requeues 0)
>  rate 0bit 0pps backlog 0b 0p requeues 0
> qdisc htb 47: parent 26:1 r2q 10 default 1 direct_packets_stat 0
>  Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>  rate 0bit 0pps backlog 0b 0p requeues 0
> qdisc htb 48: parent 27:1 r2q 10 default 1 direct_packets_stat 0
>  Sent 10657 bytes 162 pkt (dropped 0, overlimits 0 requeues 0)
>  rate 0bit 0pps backlog 0b 0p requeues 0
> qdisc htb 49: parent 28:1 r2q 10 default 1 direct_packets_stat 0
>  Sent 11877254 bytes 8017 pkt (dropped 878, overlimits 1120 requeues 0)
>  rate 0bit 0pps backlog 0b 0p requeues 0
>
> wireless-r1 bwlimit # tc -s class show dev wivl4
> class prio 5:1 parent 5: leaf 26:
>
> class prio 5:2 parent 5: leaf 27:
>
> class prio 5:3 parent 5: leaf 28:
>
> class htb 26:1 root leaf 47: prio 0 rate 30000Kbit ceil 30000Kbit burst
> 16593b cburst 16593b
>  Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>  rate 0bit 0pps backlog 0b 0p requeues 0
>  lended: 0 borrowed: 0 giants: 0
>  tokens: 4532 ctokens: 4532
>
> class htb 27:1 root leaf 48: prio 0 rate 60000Kbit ceil 60000Kbit burst
> 31590b cburst 31590b
>  Sent 54187 bytes 790 pkt (dropped 0, overlimits 0 requeues 0)
>  rate 624bit 1pps backlog 0b 0p requeues 0
>  lended: 790 borrowed: 0 giants: 0
>  tokens: 4306 ctokens: 4306
>
> class htb 28:1 root leaf 49: prio 0 rate 10000Kbit ceil 10000Kbit burst
> 6598b cburst 6598b
>  Sent 16539369 bytes 11178 pkt (dropped 1160, overlimits 0 requeues 0)
>  rate 0bit 0pps backlog 0b 0p requeues 0
>  lended: 11178 borrowed: 0 giants: 0
>  tokens: 5368 ctokens: 5368
>
> class htb 47:1 root prio 1 rate 80000bit ceil 128000bit burst 125Kb
> cburst 8000b
>  Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>  rate 0bit 0pps backlog 0b 0p requeues 0
>  lended: 0 borrowed: 0 giants: 0
>  tokens: 13107200 ctokens: 512000
>
> class htb 48:1 root prio 2 rate 2048Kbit ceil 3072Kbit burst 3000Kb
> cburst 192000b
>  Sent 54187 bytes 790 pkt (dropped 0, overlimits 0 requeues 0)
>  rate 624bit 1pps backlog 0b 0p requeues 0
>  lended: 790 borrowed: 0 giants: 0
>  tokens: 12287744 ctokens: 511831
>
> class htb 49:1 root prio 3 rate 960000bit ceil 960000bit burst 960000b
> cburst 60000b
>  Sent 16539369 bytes 11178 pkt (dropped 1160, overlimits 0 requeues 0)
>  rate 0bit 0pps backlog 0b 0p requeues 0
>  lended: 11178 borrowed: 0 giants: 0
>  tokens: 8191591 ctokens: 511591
>
>
> In the iptables rules, you''ll see that the bulk of the traffic
I''m
> sending through is getting marked with 0x2f (47 decimal). In the
> POSTROUTING chain, it is being classified as 47:1. In fact, nothing at
> all is getting classified as 49:1. But, in the TC class and qdisc
> displays, everything is coming up under the 49:1 instead of the 47:1.
> What happened? Either I have some weird typo I''m not seeing, or
this is
> just not working the way I''m expecting it to. Anyone have any
thoughts
> on this?
>
> 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 Systems Administrator
> 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, and Sandusky. Call for details.
>
> _______________________________________________
> LARTC mailing list
> LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
>
>

Jody Shumaker

2006-May-19 19:26 UTC

head link

Re: iptables CLASSIFY and MARK not working?

On 5/19/06, Andreas Unterkircher <unki@netshadow.at>
wrote:> Have you checked that the ip_conntrack module is loaded or compiled into
> the kernel?
> If not the mark is lost...
>
> Cheers,
> Andreas
>
I doubt that''s the issue.  I do however recall there being issues with
using iptables classify to targets that were more than 1 level deep in
the tc qdisc hierarchy.  In such situations it works much better if
you instead use a tc filter on the mark instead of an iptables
classify. Is there any particular reason you''re using classify on a
mark instead of a tc filter on the mark?

- Jody

Eliot, Wireless and Server Administrator, Great Lakes Internet

2006-May-22 21:56 UTC

head link

RE: iptables CLASSIFY and MARK not working?

You were exactly right here. Moving to the filters instead of the
iptables classify solved the issue. As for performance, I have not yet
benchmarked it to determine if the filters are fast enough for the
number of users I need this to support. 

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: lartc-bounces@mailman.ds9a.nl
[mailto:lartc-bounces@mailman.ds9a.nl] On Behalf Of Jody Shumaker
Sent: Friday, May 19, 2006 3:27 PM
To: Andreas Unterkircher
Cc: lartc@mailman.ds9a.nl
Subject: Re: [LARTC] iptables CLASSIFY and MARK not working?

On 5/19/06, Andreas Unterkircher <unki@netshadow.at>
wrote:> Have you checked that the ip_conntrack module is loaded or compiled
into> the kernel?
> If not the mark is lost...
>
> Cheers,
> Andreas
>
I doubt that''s the issue.  I do however recall there being issues with
using iptables classify to targets that were more than 1 level deep in
the tc qdisc hierarchy.  In such situations it works much better if
you instead use a tc filter on the mark instead of an iptables
classify. Is there any particular reason you''re using classify on a
mark instead of a tc filter on the mark?

- Jody
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Jody Shumaker

2006-May-23 04:32 UTC

head link

Re: iptables CLASSIFY and MARK not working?

On 5/22/06, Eliot, Wireless and Server Administrator, Great Lakes
Internet <support8@greatlakes.net> wrote:> You were exactly right here. Moving to the filters instead of the
> iptables classify solved the issue. As for performance, I have not yet
> benchmarked it to determine if the filters are fast enough for the
> number of users I need this to support.
>
>
And makes me wonder if its a bug or a design choice that iptables
classify doesn''t handle this. If the performance isn''t
acceptable, you
might want to look into that. Or look into tc filters and hashing
which can improve performance depending on the filters.

- Jody

Eliot, Wireless and Server Administrator, Great Lakes Internet

2006-May-30 19:25 UTC

head link

RE: iptables CLASSIFY and MARK not working?

Ok, I ran into a different issue with using the tc filters which
basically puts me right back to using the iptables classify target --
which means that I am running right back into the same problem I was on
before. 

As a refresher, the problem is that the classify target, while matching
in the postrouting chain of the mangle table, is not actually directing
the traffic through the correct TC class. 

Now, I took a look through the iptables classify target code in iptables
and in the Linux kernel. From what I have deciphered thus far, it does
not appear likely that there is a bug in the code in iptables. In fact,
it is a very small amount of code. Essentially, the iptables code runs
through its normal hooks and simply does a sscanf on the --set-class
option to convert the string into numbers. Then it uses the TC_H_MAKE
macro in the packet scheduler code to create a scheduler handle (by
shifting the major node number left 16 bits and ORing in the minor node
number). This 32-bit handle is then stored in the socket buffer priority
field (skb->priority) for use in the scheduler. That''s the end of
the
iptables code.

At this point, it is up to the scheduler algorithms to handle the
placement of the packets into the correct class. 

// From hfsc_classify()

if (TC_H_MAJ(skb->priority ^ sch->handle) == 0 &&
  (cl = hfsc_find_class(skb->priority, sch)) != NULL)
 if (cl->level == 0)
   return cl;

// filter code cut out

// From htb_classify()

/* allow to select class by setting skb->priority to valid classid;
   note that nfmark can be used too by attaching filter fw with no
   rules in it */
if (skb->priority == sch->handle)
        return HTB_DIRECT;  /* X:0 (direct flow) selected */
if ((cl = htb_find(skb->priority,sch)) != NULL && cl->level == 0)
        return cl;

// filter code cut out

// From cbq_classify()

/*
 *  Step 1. If skb->priority points to one of our classes, use it.
 */
if (TC_H_MAJ(prio^sch->handle) == 0 &&
    (cl = cbq_class_lookup(q, prio)) != NULL)
  return cl;

// filter code cut out

So, it would appear that we are doing essentially this logic:

If the priority field is set such that it contains a major node number
(a handle) that is equal to the handle for the current qdisc, then we
try to find a class that matches the priority field. If the find
function does not find a class, we fall back on the filter code to pick
a class. If the find function does find a class, we check to make sure
the class is a leaf node (HTB and HFSC). If it is a leaf node, we return
a pointer to the class. On CBQ, we just return a pointer to the class
without a leaf node check. 

This logic seems pretty straight forward. So, if this is failing, there
can only be a couple of reasons:

1) The skb->priority field is blank when this function starts 
2) The skb->priority field contains an invalid class id. 
3) The skb->priority field does not reference the handle we are inside
of
4) The handle and class specified in the skb->priority field is not a
leaf node
5) The code elsewhere in tc is messed up.

Now, I have double checked my rules to verify that the class IDs match
up:

Chain POSTROUTING (policy ACCEPT 15224 packets, 1809K bytes)
 pkts bytes target     prot opt in     out     source
destination
   27  1792 CLASSIFY   all  --  *      br1     0.0.0.0/0
0.0.0.0/0           MARK match 0x1f8 CLASSIFY set 1:504
   11  4569 CLASSIFY   all  --  *      br1     0.0.0.0/0
0.0.0.0/0           MARK match 0x1f9 CLASSIFY set 1:505
    0     0 CLASSIFY   all  --  *      br1     0.0.0.0/0
0.0.0.0/0           MARK match 0x1fa CLASSIFY set 1:506
   19  2172 CLASSIFY   all  --  *      wivl4   0.0.0.0/0
0.0.0.0/0           MARK match 0x1f8 CLASSIFY set 5:504
   10   640 CLASSIFY   all  --  *      wivl4   0.0.0.0/0
0.0.0.0/0           MARK match 0x1f9 CLASSIFY set 5:505
    0     0 CLASSIFY   all  --  *      wivl4   0.0.0.0/0
0.0.0.0/0           MARK match 0x1fa CLASSIFY set 5:506
 3960  252K CLASSIFY   all  --  *      br1     0.0.0.0/0
0.0.0.0/0           MARK match 0x1fe CLASSIFY set 1:510
    8  4485 CLASSIFY   all  --  *      br1     0.0.0.0/0
0.0.0.0/0           MARK match 0x1ff CLASSIFY set 1:511
    0     0 CLASSIFY   all  --  *      br1     0.0.0.0/0
0.0.0.0/0           MARK match 0x200 CLASSIFY set 1:512
 3899  235K CLASSIFY   all  --  *      wivl4   0.0.0.0/0
0.0.0.0/0           MARK match 0x1fe CLASSIFY set 5:510
   20  1064 CLASSIFY   all  --  *      wivl4   0.0.0.0/0
0.0.0.0/0           MARK match 0x1ff CLASSIFY set 5:511
    0     0 CLASSIFY   all  --  *      wivl4   0.0.0.0/0
0.0.0.0/0           MARK match 0x200 CLASSIFY set 5:512

wireless-r1 ~ # tc -s class show dev wivl4
class hfsc 5: root
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 period 0 level 1

class hfsc 5:505 parent 5: sc m1 160000bit d 2.0s m2 0bit ul m1
160000bit d 2.0s m2 0bit
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 period 0 level 0

class hfsc 5:1 parent 5: sc m1 0bit d 2.6ms m2 30000Kbit
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 period 0 level 0

class hfsc 5:504 parent 5: sc m1 400000bit d 30.0ms m2 128000bit
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 period 0 level 0

class hfsc 5:2 parent 5: ls m1 60000Kbit d 2.0s m2 60000Kbit ul m1
60000Kbit d 2.0s m2 60000Kbit
 Sent 566530 bytes 8797 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 period 8797 work 566530 bytes level 0

class hfsc 5:3 parent 5: ls m1 10000Kbit d 2.0s m2 10000Kbit
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 period 0 level 0

class hfsc 5:510 parent 5: sc m1 400000bit d 30.0ms m2 128000bit
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 period 0 level 0

class hfsc 5:511 parent 5: sc m1 2560Kbit d 2.0s m2 480000bit ul m1
2560Kbit d 2.0s m2 1920Kbit
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 period 0 level 0

class hfsc 5:512 parent 5: ls m1 960000bit d 2.0s m2 960000bit
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 period 0 level 0

You''ll notice that the iptables rules show matches for class 5:510,
5:511, and others; yet, the only class taking traffic here is 5:2. 

Now, this proves that options 2 & 3 above are not the case. That leaves:

1) The skb->priority field is blank when this function starts
4) The handle and class specified in the skb->priority field is not a
leaf node
5) The code elsewhere in tc is messed up.

As for option #4, we can show that there are no children for the class
by also taking a look at the qdiscs for the interface:

qdisc hfsc 5: default 2
 Sent 593904 bytes 9198 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0

Well, there is only 1 qdisc. Since there are no other classes listed
that say they are a child of 5:510 or 5:511, then obviously 5:510 must
be a leaf node. Thus, option #4 is negated. 

Does anyone have any clues on this?

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.

-----Original Message-----
From: Jody Shumaker [mailto:jody.shumaker@gmail.com] 
Sent: Tuesday, May 23, 2006 12:33 AM
To: Eliot, Wireless and Server Administrator, Great Lakes Internet
Cc: Andreas Unterkircher; lartc@mailman.ds9a.nl
Subject: Re: [LARTC] iptables CLASSIFY and MARK not working?

On 5/22/06, Eliot, Wireless and Server Administrator, Great Lakes
Internet <support8@greatlakes.net> wrote:> You were exactly right here. Moving to the filters instead of the
> iptables classify solved the issue. As for performance, I have not yet
> benchmarked it to determine if the filters are fast enough for the
> number of users I need this to support.
>
>
And makes me wonder if its a bug or a design choice that iptables
classify doesn''t handle this. If the performance isn''t
acceptable, you
might want to look into that. Or look into tc filters and hashing
which can improve performance depending on the filters.

- Jody

Jason Boxman

2006-May-30 19:49 UTC

head link

RE: iptables CLASSIFY and MARK not working?

Eliot, Wireless and Server Administrator,  Great Lakes Internet
wrote:>
> Ok, I ran into a different issue with using the tc filters which
> basically puts me right back to using the iptables classify target --
> which means that I am running right back into the same problem I was on
> before.
>
<snip>>
> qdisc hfsc 5: default 2
>  Sent 593904 bytes 9198 pkt (dropped 0, overlimits 0 requeues 0)
>  rate 0bit 0pps backlog 0b 0p requeues 0
default 2 is why the traffic is ending up in 5:2.
>
> Well, there is only 1 qdisc. Since there are no other classes listed
> that say they are a child of 5:510 or 5:511, then obviously 5:510 must
> be a leaf node. Thus, option #4 is negated.
>
> Does anyone have any clues on this?
You may try assigning traffic to leaf qdiscs hanging off the leaf classes on
your hierarchy.  So, give 5:510 a pfifo or something to test with and target
that ID instead.

Luciano Ruete

2006-May-30 20:12 UTC

head link

Re: iptables CLASSIFY and MARK not working?

On Tuesday 30 May 2006 16:25, Eliot, Wireless and Server Administrator, Great 
Lakes Internet wrote:
[snip]> You''ll notice that the iptables rules show matches for class
5:510,
> 5:511, and others; yet, the only class taking traffic here is 5:2.
just to exaust possibilities... 

i think that 5:2 is working cause 
0x2==2(decimal), but 
0x510!=510(decimal)
0x1fe==510(decimal)

in my experience iptables output is in HEX wile tc otput is in DEC
So give a try with 
tc class==510
iptables MARK==1fe 
and so on...

-- 
Luciano

Eliot, Wireless and Server Administrator, Great Lakes Internet

2006-May-30 20:13 UTC

head link

RE: iptables CLASSIFY and MARK not working?

Ok, I tried this:

tc qdisc add dev wivl4 parent 5:510 handle 475:0 sfq
tc qdisc add dev wivl4 parent 5:511 handle 476:0 sfq
tc qdisc add dev wivl4 parent 5:512 handle 477:0 sfq

iptables -A POSTROUTING -t mangle -o wivl4 -m mark --mark 510 -j
CLASSIFY --set-class 475:0
iptables -A POSTROUTING -t mangle -o wivl4 -m mark --mark 511 -j
CLASSIFY --set-class 476:0
iptables -A POSTROUTING -t mangle -o wivl4 -m mark --mark 512 -j
CLASSIFY --set-class 477:0

Now I have:

Chain POSTROUTING (policy ACCEPT 190K packets, 141M bytes)
 pkts bytes target     prot opt in     out     source
destination
 1593 65864 CLASSIFY   all  --  *      br1     0.0.0.0/0
0.0.0.0/0           MARK match 0x1fe CLASSIFY set 455:0
    0     0 CLASSIFY   all  --  *      br1     0.0.0.0/0
0.0.0.0/0           MARK match 0x1ff CLASSIFY set 456:0
    0     0 CLASSIFY   all  --  *      br1     0.0.0.0/0
0.0.0.0/0           MARK match 0x200 CLASSIFY set 457:0
 2323 3226K CLASSIFY   all  --  *      wivl4   0.0.0.0/0
0.0.0.0/0           MARK match 0x1fe CLASSIFY set 475:0
    0     0 CLASSIFY   all  --  *      wivl4   0.0.0.0/0
0.0.0.0/0           MARK match 0x1ff CLASSIFY set 476:0
    0     0 CLASSIFY   all  --  *      wivl4   0.0.0.0/0
0.0.0.0/0           MARK match 0x200 CLASSIFY set 477:0

So, packets are still matching and being sent to 475:0. But, I get this
in my tc output:

wireless-r1 bwlimit # tc -s qdisc show dev wivl4
qdisc hfsc 5: default 2
 Sent 5632424 bytes 4070 pkt (dropped 6, overlimits 7 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
qdisc sfq 475: parent 5:510 limit 128p quantum 1514b
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
qdisc sfq 476: parent 5:511 limit 128p quantum 1514b
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
qdisc sfq 477: parent 5:512 limit 128p quantum 1514b
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
qdisc sfq 469: parent 5:504 limit 128p quantum 1514b
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
qdisc sfq 470: parent 5:505 limit 128p quantum 1514b
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
wireless-r1 bwlimit # tc -s class show dev wivl4
class hfsc 5: root
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 period 0 level 1

class hfsc 5:505 parent 5: leaf 470: sc m1 160000bit d 2.0s m2 0bit ul
m1 160000bit d 2.0s m2 0bit
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 period 0 level 0

class hfsc 5:1 parent 5: sc m1 0bit d 2.6ms m2 30000Kbit
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 period 0 level 0

class hfsc 5:504 parent 5: leaf 469: sc m1 400000bit d 30.0ms m2
128000bit
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 period 0 level 0

class hfsc 5:2 parent 5: ls m1 60000Kbit d 2.0s m2 60000Kbit ul m1
60000Kbit d 2.0s m2 60000Kbit
 Sent 8104251 bytes 6064 pkt (dropped 7, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 period 6064 work 8104251 bytes level 0

class hfsc 5:3 parent 5: ls m1 10000Kbit d 2.0s m2 10000Kbit
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 period 0 level 0

class hfsc 5:510 parent 5: leaf 475: sc m1 400000bit d 30.0ms m2
128000bit
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 period 0 level 0

class hfsc 5:511 parent 5: leaf 476: sc m1 2560Kbit d 2.0s m2 480000bit
ul m1 2560Kbit d 2.0s m2 1920Kbit
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 period 0 level 0

class hfsc 5:512 parent 5: leaf 477: ls m1 960000bit d 2.0s m2 960000bit
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 period 0 level 0


So, nothing is hitting 475:0, and everything is still hitting 5:2. As I
understand it, the default class is only used for packets that are not
explicitly given a calss. It should not be overriding explicitly set
classes. 



 
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: lartc-bounces@mailman.ds9a.nl
[mailto:lartc-bounces@mailman.ds9a.nl] On Behalf Of Jason Boxman
Sent: Tuesday, May 30, 2006 3:49 PM
To: lartc@mailman.ds9a.nl
Subject: RE: [LARTC] iptables CLASSIFY and MARK not working?

Eliot, Wireless and Server Administrator,  Great Lakes Internet
wrote:>
> Ok, I ran into a different issue with using the tc filters which
> basically puts me right back to using the iptables classify target --
> which means that I am running right back into the same problem I was
on> before.
>
<snip>>
> qdisc hfsc 5: default 2
>  Sent 593904 bytes 9198 pkt (dropped 0, overlimits 0 requeues 0)
>  rate 0bit 0pps backlog 0b 0p requeues 0
default 2 is why the traffic is ending up in 5:2.
>
> Well, there is only 1 qdisc. Since there are no other classes listed
> that say they are a child of 5:510 or 5:511, then obviously 5:510 must
> be a leaf node. Thus, option #4 is negated.
>
> Does anyone have any clues on this?
You may try assigning traffic to leaf qdiscs hanging off the leaf
classes on
your hierarchy.  So, give 5:510 a pfifo or something to test with and
target
that ID instead.



_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Eliot, Wireless and Server Administrator, Great Lakes Internet

2006-May-30 20:19 UTC

head link

RE: iptables CLASSIFY and MARK not working?

>From iptables libipt_classify.c:
static void
print_class(unsigned int priority, int numeric)
{
        printf("%x:%x ", TC_H_MAJ(priority)>>16,
TC_H_MIN(priority));
}

/* Prints out the targinfo. */
static void
print(const struct ipt_ip *ip,
      const struct ipt_entry_target *target,
      int numeric)
{
        const struct ipt_classify_target_info *clinfo                 (const
struct ipt_classify_target_info *)target->data;
        printf("CLASSIFY set ");
        print_class(clinfo->priority, numeric);
}                                         

It does appear to be printing in hex. It also appears to be reading in
hex:

int string_to_priority(const char *s, unsigned int *p)
{
        unsigned int i, j;

        if (sscanf(s, "%x:%x", &i, &j) != 2)
                return 1;

        *p = TC_H_MAKE(i<<16, j);
        return 0;
}

So, let''s see if that works.

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: lartc-bounces@mailman.ds9a.nl
[mailto:lartc-bounces@mailman.ds9a.nl] On Behalf Of Luciano Ruete
Sent: Tuesday, May 30, 2006 4:13 PM
To: lartc@mailman.ds9a.nl
Subject: Re: [LARTC] iptables CLASSIFY and MARK not working?

On Tuesday 30 May 2006 16:25, Eliot, Wireless and Server Administrator,
Great 
Lakes Internet wrote:
[snip]> You''ll notice that the iptables rules show matches for class
5:510,
> 5:511, and others; yet, the only class taking traffic here is 5:2.
just to exaust possibilities... 

i think that 5:2 is working cause 
0x2==2(decimal), but 
0x510!=510(decimal)
0x1fe==510(decimal)

in my experience iptables output is in HEX wile tc otput is in DEC
So give a try with 
tc class==510
iptables MARK==1fe 
and so on...

-- 
Luciano
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Eliot, Wireless and Server Administrator, Great Lakes Internet

2006-May-30 20:25 UTC

head link

RE: iptables CLASSIFY and MARK not working?

Chain POSTROUTING (policy ACCEPT 222K packets, 157M bytes)
 pkts bytes target     prot opt in     out     source
destination
 6401 3653K CLASSIFY   all  --  *      wivl4   0.0.0.0/0
0.0.0.0/0           MARK match 0x1fe CLASSIFY set 1db:0

It matches like normal, but this time is pointing to a hex classid.

wireless-r1 bwlimit # tc -s qdisc show dev wivl4
qdisc hfsc 5: default 2
 Sent 18976288 bytes 26059 pkt (dropped 3222, overlimits 5751 requeues
0)
 rate 0bit 0pps backlog 0b 0p requeues 0
qdisc sfq 475: parent 5:510 limit 128p quantum 1514b
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
qdisc sfq 476: parent 5:511 limit 128p quantum 1514b
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
qdisc sfq 477: parent 5:512 limit 128p quantum 1514b
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
qdisc sfq 469: parent 5:504 limit 128p quantum 1514b
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
qdisc sfq 470: parent 5:505 limit 128p quantum 1514b
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0               

But qdisc 475 is still not getting packets. Neither is its parent class:

class hfsc 5:510 parent 5: leaf 475: sc m1 400000bit d 30.0ms m2
128000bit
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 period 0 level 0

Any other 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: lartc-bounces@mailman.ds9a.nl
[mailto:lartc-bounces@mailman.ds9a.nl] On Behalf Of Eliot, Wireless and
Server Administrator, Great Lakes Internet
Sent: Tuesday, May 30, 2006 4:19 PM
To: Luciano Ruete; lartc@mailman.ds9a.nl
Subject: RE: [LARTC] iptables CLASSIFY and MARK not working?
>From iptables libipt_classify.c:
static void
print_class(unsigned int priority, int numeric)
{
        printf("%x:%x ", TC_H_MAJ(priority)>>16,
TC_H_MIN(priority));
}

/* Prints out the targinfo. */
static void
print(const struct ipt_ip *ip,
      const struct ipt_entry_target *target,
      int numeric)
{
        const struct ipt_classify_target_info *clinfo                 (const
struct ipt_classify_target_info *)target->data;
        printf("CLASSIFY set ");
        print_class(clinfo->priority, numeric);
}                                         

It does appear to be printing in hex. It also appears to be reading in
hex:

int string_to_priority(const char *s, unsigned int *p)
{
        unsigned int i, j;

        if (sscanf(s, "%x:%x", &i, &j) != 2)
                return 1;

        *p = TC_H_MAKE(i<<16, j);
        return 0;
}

So, let''s see if that works.

 
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: lartc-bounces@mailman.ds9a.nl
[mailto:lartc-bounces@mailman.ds9a.nl] On Behalf Of Luciano Ruete
Sent: Tuesday, May 30, 2006 4:13 PM
To: lartc@mailman.ds9a.nl
Subject: Re: [LARTC] iptables CLASSIFY and MARK not working?

On Tuesday 30 May 2006 16:25, Eliot, Wireless and Server Administrator,
Great 
Lakes Internet wrote:
[snip]> You''ll notice that the iptables rules show matches for class
5:510,
> 5:511, and others; yet, the only class taking traffic here is 5:2.
just to exaust possibilities... 

i think that 5:2 is working cause 
0x2==2(decimal), but 
0x510!=510(decimal)
0x1fe==510(decimal)

in my experience iptables output is in HEX wile tc otput is in DEC
So give a try with 
tc class==510
iptables MARK==1fe 
and so on...

-- 
Luciano
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Eliot, Wireless and Server Administrator, Great Lakes Internet

2006-Jun-01 18:13 UTC

head link

RE: iptables CLASSIFY and MARK not working?

> On Tuesday 30 May 2006 16:25, Eliot, Wireless and Server
Administrator, > Great Lakes Internet wrote:
> [snip]
> > You''ll notice that the iptables rules show matches for class
5:510,
> > 5:511, and others; yet, the only class taking traffic here is 5:2.
>
> just to exaust possibilities... 
>
> i think that 5:2 is working cause 
> 0x2==2(decimal), but 
> 0x510!=510(decimal)
> 0x1fe==510(decimal)
> 
> in my experience iptables output is in HEX wile tc otput is in DEC
> So give a try with 
> tc class==510
> iptables MARK==1fe 
> and so on...
Yes, iptables uses HEX:

int string_to_priority(const char *s, unsigned int *p)
{
  unsigned int i, j;

  if (sscanf(s, "%x:%x", &i, &j) != 2)
    return 1;

  *p = TC_H_MAKE(i<<16, j);
  return 0;
}


In fact, not only does iptables use HEX for input/output of these rules,
but so does TC (the strtoul explicitly states base 16):

int get_qdisc_handle(__u32 *h, const char *str)
{
  __u32 maj;
  char *p;

  maj = TC_H_UNSPEC;
  if (strcmp(str, "none") == 0)
    goto ok;
  maj = strtoul(str, &p, 16);
  if (p == str)
    return -1;
  maj <<= 16;
  if (*p != '':'' && *p!=0)
    return -1;
ok:
  *h = maj;
  return 0;
}

int get_tc_classid(__u32 *h, const char *str)
{
  __u32 maj, min;
  char *p;

  maj = TC_H_ROOT;
  if (strcmp(str, "root") == 0)
    goto ok;
  maj = TC_H_UNSPEC;
  if (strcmp(str, "none") == 0)
    goto ok;
  maj = strtoul(str, &p, 16);
  if (p == str) {
    maj = 0;
    if (*p != '':'')
      return -1;
  }
  if (*p == '':'') {
    if (maj >= (1<<16))
      return -1;
    maj <<= 16;
    str = p+1;
    min = strtoul(str, &p, 16);
    if (*p != 0)
      return -1;
    if (min >= (1<<16))
      return -1;
    maj |= min;
  } else if (*p != 0)
    return -1;

ok:
  *h = maj;
  return 0;
}

So, I have updated all my rules to use HEX instead of DEC. Here are my
new rules:


- Creating qdiscs on interfaces
  - tc qdisc add dev br1 root handle 1: hfsc default 2

  - tc class add dev br1 parent 1:0 classid 1:1 hfsc sc umax 1500b dmax
3ms rate 30Mbit                                                       
  - tc class add dev br1 parent 1:0 classid 1:2 hfsc ls m1 60Mbit d 2s
m2 60Mbit ul m1 60Mbit d 2s m2 60Mbit                                  
  - tc class add dev br1 parent 1:0 classid 1:3 hfsc ls m1 10Mbit d 2s
m2 10Mbit                                                              

  - tc qdisc add dev wivl4 root handle 5: hfsc default 2

  - tc class add dev wivl4 parent 5:0 classid 5:1 hfsc sc umax 1500b
dmax 3ms rate 30Mbit

  - tc class add dev wivl4 parent 5:0 classid 5:2 hfsc ls m1 60Mbit d 2s
m2 60Mbit ul m1 60Mbit d 2s m2 60Mbit                                
  - tc class add dev wivl4 parent 5:0 classid 5:3 hfsc ls m1 10Mbit d 2s
m2 10Mbit                                                            

- Starting bandwidth shaping for user
  - tc class add dev br1 parent 0x1:0 classid 0x1:0x1FE hfsc sc umax
1500b dmax 30ms rate 128Kbit

  - tc class add dev br1 parent 0x1:0 classid 0x1:0x1FF hfsc ls m1
640Kbit d 2000ms m2 128Kbit rt m1 640Kbit d 2000ms m2 128Kbit ul m1
640Kbit d 2000ms
m2 512Kbit

  - tc class add dev br1 parent 0x1:0 classid 0x1:0x200 hfsc ls m1
256Kbit d 2000ms m2 256Kbit



  - tc qdisc add dev br1 parent 0x1:0x1FE handle 0x1C7:0 sfq

  - tc qdisc add dev br1 parent 0x1:0x1FF handle 0x1C8:0 sfq

  - tc qdisc add dev br1 parent 0x1:0x200 handle 0x1C9:0 sfq




  - tc class add dev wivl4 parent 0x5:0 classid 0x5:0x1FE hfsc sc umax
1500b dmax 30ms rate 128Kbit                                           
  - tc class add dev wivl4 parent 0x5:0 classid 0x5:0x1FF hfsc ls m1
2560Kbit d 2000ms m2 512Kbit rt m1 2560Kbit d 2000ms m2 512Kbit ul m1
2560Kbit d 2000ms m2 2048Kbit

  - tc class add dev wivl4 parent 0x5:0 classid 0x5:0x200 hfsc ls m1
1024Kbit d 2000ms m2 1024Kbit



  - tc qdisc add dev wivl4 parent 0x5:0x1FE handle 0x1DB:0 sfq

  - tc qdisc add dev wivl4 parent 0x5:0x1FF handle 0x1DC:0 sfq

  - tc qdisc add dev wivl4 parent 0x5:0x200 handle 0x1DD:0 sfq


 

- Adding rules to classify traffic for 00:05:9E:81:3D:07
  - iptables -A macfilter -m mac --mac-source 00:05:9E:81:3D:07

  - iptables -I macfilter_nat -t nat -m mac --mac-source
00:05:9E:81:3D:07 -j ACCEPT



- Adding rules to flag General traffic
  - iptables -A PREROUTING -t mangle -m mac --mac-source
00:05:9E:81:3D:07 -j MARK --set-mark 0x1FF

  - iptables -A PREROUTING -t mangle -m mark --mark 0x1FF -j CONNMARK
--save-mark                                                             


- Adding rules to flag VoIP/Interactive traffic
  - iptables -A PREROUTING -t mangle -p udp -m mac --mac-source
00:05:9E:81:3D:07 -m multiport --ports 53,4569,5060,10000:20000 -j MARK
--set-mark 510
  - iptables -A PREROUTING -t mangle -p tcp -m mac --mac-source
00:05:9E:81:3D:07 -m multiport --ports 22,23,53 -j MARK --set-mark 0x1FE

  - iptables -A PREROUTING -t mangle -p icmp -m mac --mac-source
00:05:9E:81:3D:07 -j MARK --set-mark 0x1FE

  - iptables -A PREROUTING -t mangle -p tcp --tcp-flags ACK,PSH ACK -m
length --length 0:128 -m mac --mac-source 00:05:9E:81:3D:07 -j MARK
--set-mark 0x1FE
  - iptables -A PREROUTING -t mangle -p udp --dport 53 -m mac
--mac-source 00:05:9E:81:3D:07 -j MARK --set-mark 0x1FE

  - iptables -A PREROUTING -t mangle -p udp --sport 53 -m mac
--mac-source 00:05:9E:81:3D:07 -j MARK --set-mark 0x1FE

  - iptables -A PREROUTING -t mangle -m mark --mark 0x1FE -j CONNMARK
--save-mark                                                             


- Adding rules to flag P2P traffic
  - iptables -A PREROUTING -t mangle -m mac --mac-source
00:05:9E:81:3D:07 -m ipp2p --ipp2p -j MARK --set-mark 0x200

  - iptables -A PREROUTING -t mangle -m mark --mark 0x200 -j CONNMARK
--save-mark                                                             
  - iptables -I FORWARD -t mangle -m mark --mark 0x1FE -j ACCEPT

  - iptables -I FORWARD -t mangle -m mark --mark 0x1FF -j ACCEPT

  - iptables -I FORWARD -t mangle -m mark --mark 0x200 -j ACCEPT



- Adding rules to classify traffic on br1
  - iptables -A POSTROUTING -t mangle -o br1 -m mark --mark 0x1FE -j
CLASSIFY --set-class 0x1C7:0

  - iptables -A POSTROUTING -t mangle -o br1 -m mark --mark 0x1FF -j
CLASSIFY --set-class 0x1C8:0

  - iptables -A POSTROUTING -t mangle -o br1 -m mark --mark 0x200 -j
CLASSIFY --set-class 0x1C9:0



- Adding rules to classify traffic on wivl4
  - iptables -A POSTROUTING -t mangle -o wivl4 -m mark --mark 0x1FE -j
CLASSIFY --set-class 0x1DB:0                                           
  - iptables -A POSTROUTING -t mangle -o wivl4 -m mark --mark 0x1FF -j
CLASSIFY --set-class 0x1DC:0                                           
  - iptables -A POSTROUTING -t mangle -o wivl4 -m mark --mark 0x200 -j
CLASSIFY --set-class 0x1DD:0                                           





However, this still does not work:




Chain POSTROUTING (policy ACCEPT 812K packets, 441M bytes)
 pkts bytes target     prot opt in     out     source
destination
 2071  129K CLASSIFY   all  --  *      br1     0.0.0.0/0
0.0.0.0/0           MARK match 0x1fe CLASSIFY set 1c7:0
    2   521 CLASSIFY   all  --  *      br1     0.0.0.0/0
0.0.0.0/0           MARK match 0x1ff CLASSIFY set 1c8:0
    0     0 CLASSIFY   all  --  *      br1     0.0.0.0/0
0.0.0.0/0           MARK match 0x200 CLASSIFY set 1c9:0
 2760 4060K CLASSIFY   all  --  *      wivl4   0.0.0.0/0
0.0.0.0/0           MARK match 0x1fe CLASSIFY set 1db:0
    3   500 CLASSIFY   all  --  *      wivl4   0.0.0.0/0
0.0.0.0/0           MARK match 0x1ff CLASSIFY set 1dc:0
    0     0 CLASSIFY   all  --  *      wivl4   0.0.0.0/0
0.0.0.0/0           MARK match 0x200 CLASSIFY set 1dd:0


wireless-r1 bwlimit # tc -s qdisc show dev wivl4
qdisc hfsc 5: default 2
 Sent 8554815 bytes 7797 pkt (dropped 6, overlimits 13 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
qdisc sfq 1db: parent 5:1fe limit 128p quantum 1514b
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
qdisc sfq 1dc: parent 5:1ff limit 128p quantum 1514b
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
qdisc sfq 1dd: parent 5:200 limit 128p quantum 1514b
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0



I am really at a loss here. I am targeting a qdisc directly with the
classify command in iptables. I am using HEX throughout my rule base.
The numbers all line up correctly (iptables classify numbers match a
valid class/qdisc id in tc). Each classid is globally unique (it is used
only once). I am using the latest iptables, the latest tc, and the
latest kernel. I have even verified that both iptables and tc are
reading/writing to skb->priority in the code base.

Short of modifying the iptables and tc code in the kernel and in the
userspace programs to print out debugging information, I am not sure
what else to do. 

Can anyone at least verify that iptables CLASSIFY target actually works
on their system? That would at least be helpful. And if it works on your
system, can you try pasting my rules into your system and see if they
work? 

If anyone else has any more ideas, I would love to entertain them. 

 
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

Patrick McHardy

2006-Jun-01 18:22 UTC

head link

Re: iptables CLASSIFY and MARK not working?

Eliot, Wireless and Server Administrator, Great Lakes Internet
wrote:> However, this still does not work:
> 
> Chain POSTROUTING (policy ACCEPT 812K packets, 441M bytes)
>  pkts bytes target     prot opt in     out     source
> destination
>  2071  129K CLASSIFY   all  --  *      br1     0.0.0.0/0
> 0.0.0.0/0           MARK match 0x1fe CLASSIFY set 1c7:0
>     2   521 CLASSIFY   all  --  *      br1     0.0.0.0/0
> 0.0.0.0/0           MARK match 0x1ff CLASSIFY set 1c8:0
>     0     0 CLASSIFY   all  --  *      br1     0.0.0.0/0
> 0.0.0.0/0           MARK match 0x200 CLASSIFY set 1c9:0
>  2760 4060K CLASSIFY   all  --  *      wivl4   0.0.0.0/0
> 0.0.0.0/0           MARK match 0x1fe CLASSIFY set 1db:0
>     3   500 CLASSIFY   all  --  *      wivl4   0.0.0.0/0
> 0.0.0.0/0           MARK match 0x1ff CLASSIFY set 1dc:0
>     0     0 CLASSIFY   all  --  *      wivl4   0.0.0.0/0
> 0.0.0.0/0           MARK match 0x200 CLASSIFY set 1dd:0
> 
> 
> wireless-r1 bwlimit # tc -s qdisc show dev wivl4
> qdisc hfsc 5: default 2
>  Sent 8554815 bytes 7797 pkt (dropped 6, overlimits 13 requeues 0)
>  rate 0bit 0pps backlog 0b 0p requeues 0
> qdisc sfq 1db: parent 5:1fe limit 128p quantum 1514b
>  Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>  rate 0bit 0pps backlog 0b 0p requeues 0
> qdisc sfq 1dc: parent 5:1ff limit 128p quantum 1514b
>  Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>  rate 0bit 0pps backlog 0b 0p requeues 0
> qdisc sfq 1dd: parent 5:200 limit 128p quantum 1514b
>  Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>  rate 0bit 0pps backlog 0b 0p requeues 0

I already told you why this doesn''t work, you have to classify to
the _classes_, not the qdiscs.

Eliot, Wireless and Server Administrator, Great Lakes Internet

2006-Jun-01 18:49 UTC

head link

RE: iptables CLASSIFY and MARK not working?

-----Original Message-----
From: Patrick McHardy [mailto:kaber@trash.net] 
Sent: Thursday, June 01, 2006 2:23 PM
To: Eliot, Wireless and Server Administrator, Great Lakes Internet
Cc: lartc@mailman.ds9a.nl; Netfilter Development Mailinglist
Subject: Re: [LARTC] iptables CLASSIFY and MARK not working?
> Eliot, Wireless and Server Administrator, Great Lakes Internet wrote:
> > However, this still does not work:
> > 
> > Chain POSTROUTING (policy ACCEPT 812K packets, 441M bytes)
> >  pkts bytes target     prot opt in     out     source
> > destination
> >  2071  129K CLASSIFY   all  --  *      br1     0.0.0.0/0
> > 0.0.0.0/0           MARK match 0x1fe CLASSIFY set 1c7:0
> >     2   521 CLASSIFY   all  --  *      br1     0.0.0.0/0
> > 0.0.0.0/0           MARK match 0x1ff CLASSIFY set 1c8:0
> >     0     0 CLASSIFY   all  --  *      br1     0.0.0.0/0
> > 0.0.0.0/0           MARK match 0x200 CLASSIFY set 1c9:0
> >  2760 4060K CLASSIFY   all  --  *      wivl4   0.0.0.0/0
> > 0.0.0.0/0           MARK match 0x1fe CLASSIFY set 1db:0
> >     3   500 CLASSIFY   all  --  *      wivl4   0.0.0.0/0
> > 0.0.0.0/0           MARK match 0x1ff CLASSIFY set 1dc:0
> >     0     0 CLASSIFY   all  --  *      wivl4   0.0.0.0/0
> > 0.0.0.0/0           MARK match 0x200 CLASSIFY set 1dd:0
> > 
> > 
> > wireless-r1 bwlimit # tc -s qdisc show dev wivl4
> > qdisc hfsc 5: default 2
> >  Sent 8554815 bytes 7797 pkt (dropped 6, overlimits 13 requeues 0)
> >  rate 0bit 0pps backlog 0b 0p requeues 0
> > qdisc sfq 1db: parent 5:1fe limit 128p quantum 1514b
> >  Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
> >  rate 0bit 0pps backlog 0b 0p requeues 0
> > qdisc sfq 1dc: parent 5:1ff limit 128p quantum 1514b
> >  Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
> >  rate 0bit 0pps backlog 0b 0p requeues 0
> > qdisc sfq 1dd: parent 5:200 limit 128p quantum 1514b
> >  Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
> >  rate 0bit 0pps backlog 0b 0p requeues 0
>
> 
> I already told you why this doesn''t work, you have to classify to
> the _classes_, not the qdiscs.

These rules make it go to the classes instead of the qdisc:

- Adding rules to classify traffic on br1 ...
  - iptables -A POSTROUTING -t mangle -o br1 -m mark --mark 0x1FE -j
CLASSIFY --set-class 0x5:0x1FE
  - iptables -A POSTROUTING -t mangle -o br1 -m mark --mark 0x1FF -j
CLASSIFY --set-class 0x5:0x1FF
  - iptables -A POSTROUTING -t mangle -o br1 -m mark --mark 0x200 -j
CLASSIFY --set-class 0x5:0x200

- Adding rules to classify traffic on wivl4 ...
  - iptables -A POSTROUTING -t mangle -o wivl4 -m mark --mark 0x1FE -j
CLASSIFY --set-class 0x5:0x1FE
  - iptables -A POSTROUTING -t mangle -o wivl4 -m mark --mark 0x1FF -j
CLASSIFY --set-class 0x5:0x1FF
  - iptables -A POSTROUTING -t mangle -o wivl4 -m mark --mark 0x200 -j
CLASSIFY --set-class 0x5:0x200


Chain POSTROUTING (policy ACCEPT 887K packets, 495M bytes)
 pkts bytes target     prot opt in     out     source
destination
 8662  508K CLASSIFY   all  --  *      br1     0.0.0.0/0
0.0.0.0/0           MARK match 0x1fe CLASSIFY set 5:1fe
   14  8253 CLASSIFY   all  --  *      br1     0.0.0.0/0
0.0.0.0/0           MARK match 0x1ff CLASSIFY set 5:1ff
    0     0 CLASSIFY   all  --  *      br1     0.0.0.0/0
0.0.0.0/0           MARK match 0x200 CLASSIFY set 5:200
  845  222K CLASSIFY   all  --  *      wivl4   0.0.0.0/0
0.0.0.0/0           MARK match 0x1fe CLASSIFY set 5:1fe
   22  5286 CLASSIFY   all  --  *      wivl4   0.0.0.0/0
0.0.0.0/0           MARK match 0x1ff CLASSIFY set 5:1ff
    0     0 CLASSIFY   all  --  *      wivl4   0.0.0.0/0
0.0.0.0/0           MARK match 0x200 CLASSIFY set 5:200



And yet, still nothing hits the classes:



wireless-r1 ~ # tc -s class show dev wivl4
class hfsc 5: root
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 period 0 level 1

class hfsc 5:1fe parent 5: leaf 1db: sc m1 400000bit d 30.0ms m2
128000bit
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 period 0 level 0

class hfsc 5:1 parent 5: sc m1 0bit d 2.6ms m2 30000Kbit
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 period 0 level 0

class hfsc 5:1ff parent 5: leaf 1dc: sc m1 2560Kbit d 2.0s m2 512000bit
ul m1 2560Kbit d 2.0s m2 2048Kbit
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 period 0 level 0

class hfsc 5:2 parent 5: ls m1 60000Kbit d 2.0s m2 60000Kbit ul m1
60000Kbit d 2.0s m2 60000Kbit
 Sent 19906674 bytes 13396 pkt (dropped 9, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 period 13396 work 19906674 bytes level 0

class hfsc 5:200 parent 5: leaf 1dd: ls m1 1024Kbit d 2.0s m2 1024Kbit
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 period 0 level 0

class hfsc 5:3 parent 5: ls m1 10000Kbit d 2.0s m2 10000Kbit
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 period 0 level 0

class hfsc 5:1fa parent 5: leaf 1d7: ls m1 64000bit d 2.0s m2 64000bit
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 period 0 level 0

class hfsc 5:1f8 parent 5: leaf 1d5: sc m1 400000bit d 30.0ms m2
128000bit
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 period 0 level 0

class hfsc 5:1f9 parent 5: leaf 1d6: sc m1 160000bit d 2.0s m2 32000bit
ul m1 160000bit d 2.0s m2 128000bit
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 period 0 level 0


wireless-r1 ~ # tc -s class show dev br1
class hfsc 1: root
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 period 0 level 1

class hfsc 1:1fe parent 1: leaf 1c7: sc m1 400000bit d 30.0ms m2
128000bit
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 period 0 level 0

class hfsc 1:1 parent 1: sc m1 0bit d 2.6ms m2 30000Kbit
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 period 0 level 0

class hfsc 1:1ff parent 1: leaf 1c8: sc m1 640000bit d 2.0s m2 128000bit
ul m1 640000bit d 2.0s m2 512000bit
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 period 0 level 0

class hfsc 1:2 parent 1: ls m1 60000Kbit d 2.0s m2 60000Kbit ul m1
60000Kbit d 2.0s m2 60000Kbit
 Sent 856222 bytes 10041 pkt (dropped 13, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 period 10041 work 856222 bytes level 0

class hfsc 1:200 parent 1: leaf 1c9: ls m1 256000bit d 2.0s m2 256000bit
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 period 0 level 0

class hfsc 1:3 parent 1: ls m1 10000Kbit d 2.0s m2 10000Kbit
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 period 0 level 0

class hfsc 1:1fa parent 1: leaf 1c3: ls m1 32000bit d 2.0s m2 32000bit
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 period 0 level 0

class hfsc 1:1f8 parent 1: leaf 1c1: sc m1 400000bit d 30.0ms m2
128000bit
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 period 0 level 0

class hfsc 1:1f9 parent 1: leaf 1c2: sc m1 80000bit d 2.0s m2 16000bit
ul m1 80000bit d 2.0s m2 64000bit
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 period 0 level 0



No matter how I write these rules, it always still goes to the default
class (5:2 or 1:2). If this is still wrong, please give me an example of
what I should be writing. 


 
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

Patrick McHardy

2006-Jun-01 19:09 UTC

head link

Re: [LARTC] iptables CLASSIFY and MARK not working?

Eliot, Wireless and Server Administrator, Great Lakes Internet
wrote:> These rules make it go to the classes instead of the qdisc:
> 
> Chain POSTROUTING (policy ACCEPT 887K packets, 495M bytes)
>  pkts bytes target     prot opt in     out     source
> destination
>  8662  508K CLASSIFY   all  --  *      br1     0.0.0.0/0
> 0.0.0.0/0           MARK match 0x1fe CLASSIFY set 5:1fe
>    14  8253 CLASSIFY   all  --  *      br1     0.0.0.0/0
> 0.0.0.0/0           MARK match 0x1ff CLASSIFY set 5:1ff
>     0     0 CLASSIFY   all  --  *      br1     0.0.0.0/0
> 0.0.0.0/0           MARK match 0x200 CLASSIFY set 5:200
>   845  222K CLASSIFY   all  --  *      wivl4   0.0.0.0/0
> 0.0.0.0/0           MARK match 0x1fe CLASSIFY set 5:1fe
>    22  5286 CLASSIFY   all  --  *      wivl4   0.0.0.0/0
> 0.0.0.0/0           MARK match 0x1ff CLASSIFY set 5:1ff
>     0     0 CLASSIFY   all  --  *      wivl4   0.0.0.0/0
> 0.0.0.0/0           MARK match 0x200 CLASSIFY set 5:200
> 
> 
> 
> And yet, still nothing hits the classes:
> 
> 
> 
> wireless-r1 ~ # tc -s class show dev wivl4
> class hfsc 5: root
>  Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>  rate 0bit 0pps backlog 0b 0p requeues 0
>  period 0 level 1
> 
> class hfsc 5:1fe parent 5: leaf 1db: sc m1 400000bit d 30.0ms m2
> 128000bit
>  Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>  rate 0bit 0pps backlog 0b 0p requeues 0
>  period 0 level 0
> 
> class hfsc 5:1 parent 5: sc m1 0bit d 2.6ms m2 30000Kbit
>  Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>  rate 0bit 0pps backlog 0b 0p requeues 0
>  period 0 level 0
> 
> class hfsc 5:1ff parent 5: leaf 1dc: sc m1 2560Kbit d 2.0s m2 512000bit
> ul m1 2560Kbit d 2.0s m2 2048Kbit
>  Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>  rate 0bit 0pps backlog 0b 0p requeues 0
>  period 0 level 0
> 
> class hfsc 5:2 parent 5: ls m1 60000Kbit d 2.0s m2 60000Kbit ul m1
> 60000Kbit d 2.0s m2 60000Kbit
>  Sent 19906674 bytes 13396 pkt (dropped 9, overlimits 0 requeues 0)
>  rate 0bit 0pps backlog 0b 0p requeues 0
>  period 13396 work 19906674 bytes level 0
> 
> class hfsc 5:200 parent 5: leaf 1dd: ls m1 1024Kbit d 2.0s m2 1024Kbit
>  Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>  rate 0bit 0pps backlog 0b 0p requeues 0
>  period 0 level 0
> 
> class hfsc 5:3 parent 5: ls m1 10000Kbit d 2.0s m2 10000Kbit
>  Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>  rate 0bit 0pps backlog 0b 0p requeues 0
>  period 0 level 0
> 
> class hfsc 5:1fa parent 5: leaf 1d7: ls m1 64000bit d 2.0s m2 64000bit
>  Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>  rate 0bit 0pps backlog 0b 0p requeues 0
>  period 0 level 0
> 
> class hfsc 5:1f8 parent 5: leaf 1d5: sc m1 400000bit d 30.0ms m2
> 128000bit
>  Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>  rate 0bit 0pps backlog 0b 0p requeues 0
>  period 0 level 0
> 
> class hfsc 5:1f9 parent 5: leaf 1d6: sc m1 160000bit d 2.0s m2 32000bit
> ul m1 160000bit d 2.0s m2 128000bit
>  Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>  rate 0bit 0pps backlog 0b 0p requeues 0
>  period 0 level 0
> 
> 
> wireless-r1 ~ # tc -s class show dev br1
> class hfsc 1: root
>  Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>  rate 0bit 0pps backlog 0b 0p requeues 0
>  period 0 level 1
> 
> class hfsc 1:1fe parent 1: leaf 1c7: sc m1 400000bit d 30.0ms m2
> 128000bit
>  Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>  rate 0bit 0pps backlog 0b 0p requeues 0
>  period 0 level 0
> 
> class hfsc 1:1 parent 1: sc m1 0bit d 2.6ms m2 30000Kbit
>  Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>  rate 0bit 0pps backlog 0b 0p requeues 0
>  period 0 level 0
> 
> class hfsc 1:1ff parent 1: leaf 1c8: sc m1 640000bit d 2.0s m2 128000bit
> ul m1 640000bit d 2.0s m2 512000bit
>  Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>  rate 0bit 0pps backlog 0b 0p requeues 0
>  period 0 level 0
> 
> class hfsc 1:2 parent 1: ls m1 60000Kbit d 2.0s m2 60000Kbit ul m1
> 60000Kbit d 2.0s m2 60000Kbit
>  Sent 856222 bytes 10041 pkt (dropped 13, overlimits 0 requeues 0)
>  rate 0bit 0pps backlog 0b 0p requeues 0
>  period 10041 work 856222 bytes level 0
> 
> class hfsc 1:200 parent 1: leaf 1c9: ls m1 256000bit d 2.0s m2 256000bit
>  Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>  rate 0bit 0pps backlog 0b 0p requeues 0
>  period 0 level 0
> 
> class hfsc 1:3 parent 1: ls m1 10000Kbit d 2.0s m2 10000Kbit
>  Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>  rate 0bit 0pps backlog 0b 0p requeues 0
>  period 0 level 0
> 
> class hfsc 1:1fa parent 1: leaf 1c3: ls m1 32000bit d 2.0s m2 32000bit
>  Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>  rate 0bit 0pps backlog 0b 0p requeues 0
>  period 0 level 0
> 
> class hfsc 1:1f8 parent 1: leaf 1c1: sc m1 400000bit d 30.0ms m2
> 128000bit
>  Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>  rate 0bit 0pps backlog 0b 0p requeues 0
>  period 0 level 0
> 
> class hfsc 1:1f9 parent 1: leaf 1c2: sc m1 80000bit d 2.0s m2 16000bit
> ul m1 80000bit d 2.0s m2 64000bit
>  Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>  rate 0bit 0pps backlog 0b 0p requeues 0
>  period 0 level 0
> 
> 
> 
> No matter how I write these rules, it always still goes to the default
> class (5:2 or 1:2). If this is still wrong, please give me an example of
> what I should be writing. 
The bridge case doesn''t work because you''re using the wrong
major
number (5 instead of 1), the wivl4 rules look correct. I just tested
HFSC+CLASSIFY and it works fine for me. What kind of device is wivl4?

Eliot, Wireless and Server Administrator, Great Lakes Internet

2006-Jun-01 19:38 UTC

head link

RE: [LARTC] iptables CLASSIFY and MARK not working?

-----Original Message-----
From: Patrick McHardy [mailto:kaber@trash.net] 
Sent: Thursday, June 01, 2006 3:09 PM
To: Eliot, Wireless and Server Administrator, Great Lakes Internet
Cc: lartc@mailman.ds9a.nl; Netfilter Development Mailinglist
Subject: Re: [LARTC] iptables CLASSIFY and MARK not working?
> The bridge case doesn''t work because you''re using the
wrong major
> number (5 instead of 1), the wivl4 rules look correct. I just tested
> HFSC+CLASSIFY and it works fine for me. What kind of device is wivl4?
I knew I was going to typo something when I did all that hex conversion
this morning. Here is the corrected ruleset:


- Adding rules to classify traffic on br1 ...
  - iptables -A POSTROUTING -t mangle -o br1 -m mark --mark 0x1FE -j
CLASSIFY --set-class 0x1:0x1FE
  - iptables -A POSTROUTING -t mangle -o br1 -m mark --mark 0x1FF -j
CLASSIFY --set-class 0x1:0x1FF
  - iptables -A POSTROUTING -t mangle -o br1 -m mark --mark 0x200 -j
CLASSIFY --set-class 0x1:0x200

- Adding rules to classify traffic on wivl4 ...
  - iptables -A POSTROUTING -t mangle -o wivl4 -m mark --mark 0x1FE -j
CLASSIFY --set-class 0x5:0x1FE
  - iptables -A POSTROUTING -t mangle -o wivl4 -m mark --mark 0x1FF -j
CLASSIFY --set-class 0x5:0x1FF
  - iptables -A POSTROUTING -t mangle -o wivl4 -m mark --mark 0x200 -j
CLASSIFY --set-class 0x5:0x200


Here are the new test results:

Chain POSTROUTING (policy ACCEPT 900K packets, 496M bytes)
 pkts bytes target     prot opt in     out     source
destination
  865 67524 CLASSIFY   all  --  *      br1     0.0.0.0/0
0.0.0.0/0           MARK match 0x1fe CLASSIFY set 1:1fe
   16  1216 CLASSIFY   all  --  *      br1     0.0.0.0/0
0.0.0.0/0           MARK match 0x1ff CLASSIFY set 1:1ff
    0     0 CLASSIFY   all  --  *      br1     0.0.0.0/0
0.0.0.0/0           MARK match 0x200 CLASSIFY set 1:200
  840 91456 CLASSIFY   all  --  *      wivl4   0.0.0.0/0
0.0.0.0/0           MARK match 0x1fe CLASSIFY set 5:1fe
   16  1216 CLASSIFY   all  --  *      wivl4   0.0.0.0/0
0.0.0.0/0           MARK match 0x1ff CLASSIFY set 5:1ff
    0     0 CLASSIFY   all  --  *      wivl4   0.0.0.0/0
0.0.0.0/0           MARK match 0x200 CLASSIFY set 5:200


wireless-r1 bwlimit # tc -s class show dev br1
class hfsc 1: root
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 period 0 level 1

class hfsc 1:1fe parent 1: leaf 1c7: sc m1 400000bit d 30.0ms m2
128000bit
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 period 0 level 0

class hfsc 1:1 parent 1: sc m1 0bit d 2.6ms m2 30000Kbit
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 period 0 level 0

class hfsc 1:1ff parent 1: leaf 1c8: sc m1 640000bit d 2.0s m2 128000bit
ul m1 640000bit d 2.0s m2 512000bit
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 period 0 level 0

class hfsc 1:2 parent 1: ls m1 60000Kbit d 2.0s m2 60000Kbit ul m1
60000Kbit d 2.0s m2 60000Kbit
 Sent 187981 bytes 1698 pkt (dropped 3, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 period 1698 work 187981 bytes level 0

class hfsc 1:200 parent 1: leaf 1c9: ls m1 256000bit d 2.0s m2 256000bit
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 period 0 level 0

class hfsc 1:3 parent 1: ls m1 10000Kbit d 2.0s m2 10000Kbit
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 period 0 level 0

class hfsc 1:1fa parent 1: leaf 1c3: ls m1 32000bit d 2.0s m2 32000bit
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 period 0 level 0

class hfsc 1:1f8 parent 1: leaf 1c1: sc m1 400000bit d 30.0ms m2
128000bit
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 period 0 level 0

class hfsc 1:1f9 parent 1: leaf 1c2: sc m1 80000bit d 2.0s m2 16000bit
ul m1 80000bit d 2.0s m2 64000bit
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 period 0 level 0


Both devices (br1 and wivl4) are bridged interfaces with spanning tree
turned on. They also do VLANs. Specifically, vconfig was used to create
a VLAN (in this case, VLAN 4) on two interfaces: eth2 and eth3. These
two VLAN interfaces were called e2v4 and e3v4. Then, brctl was used to
bridge the two VLAN interfaces (e2v4 and e3v4) into a new interface
called wivl4. Spanning tree was then enabled on wivl4. The MTU size was
then adjusted -4 bytes to accommodate the VLAN tagging. 


Also, did you happen to try my specific rules (under different devices)
to see if they work? 

If possible, could you try creating a VLAN interface and test on that
interface? Then try a bridged interface. And finally, a bridged VLAN
interface. 

I will try to set this all up on a different machine without the bridged
VLANs and see if it works there.



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.

Patrick McHardy

2006-Jun-01 19:44 UTC

head link

Re: iptables CLASSIFY and MARK not working?

Eliot, Wireless and Server Administrator, Great Lakes Internet
wrote:> Both devices (br1 and wivl4) are bridged interfaces with spanning tree
> turned on. They also do VLANs. Specifically, vconfig was used to create
> a VLAN (in this case, VLAN 4) on two interfaces: eth2 and eth3. These
> two VLAN interfaces were called e2v4 and e3v4. Then, brctl was used to
> bridge the two VLAN interfaces (e2v4 and e3v4) into a new interface
> called wivl4. Spanning tree was then enabled on wivl4. The MTU size was
> then adjusted -4 bytes to accommodate the VLAN tagging. 
Any chance you got bridge netfilter enabled? If so please disable
it and try again (or set the bridge-nf-call-iptables sysctl to 0).
> Also, did you happen to try my specific rules (under different devices)
> to see if they work? 
No, just tried CLASSIFY with my own HFSC setup, which is pretty
similar.
> If possible, could you try creating a VLAN interface and test on that
> interface? Then try a bridged interface. And finally, a bridged VLAN
> interface. 
> 
> I will try to set this all up on a different machine without the bridged
> VLANs and see if it works there.
I checked the code, neither VLAN nor bridge should matter.

Eliot, Wireless and Server Administrator, Great Lakes Internet

2006-Jun-01 19:58 UTC

head link

RE: iptables CLASSIFY and MARK not working?

-----Original Message-----
From: Patrick McHardy [mailto:kaber@trash.net] 
Sent: Thursday, June 01, 2006 3:44 PM
To: Eliot, Wireless and Server Administrator, Great Lakes Internet
Cc: lartc@mailman.ds9a.nl; Netfilter Development Mailinglist
Subject: Re: [LARTC] iptables CLASSIFY and MARK not working?
> Eliot, Wireless and Server Administrator, Great Lakes Internet wrote:
> > Both devices (br1 and wivl4) are bridged interfaces with spanning
tree> > turned on. They also do VLANs. Specifically, vconfig was used to
create> > a VLAN (in this case, VLAN 4) on two interfaces: eth2 and eth3.
These> > two VLAN interfaces were called e2v4 and e3v4. Then, brctl was used
to> > bridge the two VLAN interfaces (e2v4 and e3v4) into a new interface
> > called wivl4. Spanning tree was then enabled on wivl4. The MTU size
was> > then adjusted -4 bytes to accommodate the VLAN tagging. 
> 
> Any chance you got bridge netfilter enabled? If so please disable
> it and try again (or set the bridge-nf-call-iptables sysctl to 0).
> 
> Also, did you happen to try my specific rules (under different
devices)> to see if they work? 
> 
> No, just tried CLASSIFY with my own HFSC setup, which is pretty
> similar.
> 
> > If possible, could you try creating a VLAN interface and test on
that> > interface? Then try a bridged interface. And finally, a bridged VLAN
> > interface. 
> > 
> > I will try to set this all up on a different machine without the
bridged> > VLANs and see if it works there.
> 
> I checked the code, neither VLAN nor bridge should matter.

Bridged iptables (ebtables) is not enabled in the kernel and I cannot
seem to find a variable "bridge-nf-call-iptables" to set with sysctl:

wireless-r1 linux # sysctl -w bridge-nf-call-iptables=0
error: "bridge-nf-call-iptables" is an unknown key

There is also no /proc/sys/net/*/bridge anything. I assume that means
this is not something I need to worry about?

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.

Patrick McHardy

2006-Jun-01 20:01 UTC

head link

Re: [LARTC] iptables CLASSIFY and MARK not working?

Eliot, Wireless and Server Administrator, Great Lakes Internet
wrote:> Bridged iptables (ebtables) is not enabled in the kernel and I cannot
> seem to find a variable "bridge-nf-call-iptables" to set with
sysctl:
> 
> wireless-r1 linux # sysctl -w bridge-nf-call-iptables=0
> error: "bridge-nf-call-iptables" is an unknown key
> 
> There is also no /proc/sys/net/*/bridge anything. I assume that means
> this is not something I need to worry about?
Not sure yet, the problem would be created by CONFIG_BRIDGE_NETFILTER,
not ebtables itself. Check for
"/proc/sys/net/bridge/bridge-nf-call-iptables".

I''m actually pretty sure that this is indeed what''s causing
the problem,
bridge netfilter defers calling the IP POST_ROUTING hook until the
packet was already transmitted over the device (and before it goes
out the underlying device), which means when it hits the CLASSIFY
target it already passed through the qdisc.

Eliot, Wireless and Server Administrator, Great Lakes Internet

2006-Jun-01 20:09 UTC

head link

RE: [LARTC] iptables CLASSIFY and MARK not working?

THANK YOU!

That solved the problem. I found the file you specified and it was
indeed enabled. After disabling it, it is now working!

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: Thursday, June 01, 2006 4:02 PM
To: Eliot, Wireless and Server Administrator, Great Lakes Internet
Cc: lartc@mailman.ds9a.nl; Netfilter Development Mailinglist
Subject: Re: [LARTC] iptables CLASSIFY and MARK not working?

Eliot, Wireless and Server Administrator, Great Lakes Internet
wrote:> Bridged iptables (ebtables) is not enabled in the kernel and I cannot
> seem to find a variable "bridge-nf-call-iptables" to set with
sysctl:
> 
> wireless-r1 linux # sysctl -w bridge-nf-call-iptables=0
> error: "bridge-nf-call-iptables" is an unknown key
> 
> There is also no /proc/sys/net/*/bridge anything. I assume that means
> this is not something I need to worry about?
Not sure yet, the problem would be created by CONFIG_BRIDGE_NETFILTER,
not ebtables itself. Check for
"/proc/sys/net/bridge/bridge-nf-call-iptables".

I''m actually pretty sure that this is indeed what''s causing
the problem,
bridge netfilter defers calling the IP POST_ROUTING hook until the
packet was already transmitted over the device (and before it goes
out the underlying device), which means when it hits the CLASSIFY
target it already passed through the qdisc.

Patrick McHardy

2006-Jun-01 20:10 UTC

head link

Re: [LARTC] iptables CLASSIFY and MARK not working?

Eliot, Wireless and Server Administrator, Great Lakes Internet
wrote:> THANK YOU!
> 
> That solved the problem. I found the file you specified and it was
> indeed enabled. After disabling it, it is now working!
Good to hear. This crap is causing one weird problem after another,
we really need to get rid of it.

Eliot, Wireless and Server Administrator, Great Lakes Internet

2006-Jun-03 16:43 UTC

head link

RE: [LARTC] iptables CLASSIFY and MARK not working?

> -----Original Message-----
> From: Patrick McHardy [mailto:kaber@trash.net]
> Sent: Thursday, June 01, 2006 4:02 PM
> To: Eliot, Wireless and Server Administrator, Great Lakes Internet
> Cc: lartc@mailman.ds9a.nl; Netfilter Development Mailinglist
> Subject: Re: [LARTC] iptables CLASSIFY and MARK not working?
> 
> Eliot, Wireless and Server Administrator, Great Lakes Internet wrote:
> > Bridged iptables (ebtables) is not enabled in the kernel and I
cannot> > seem to find a variable "bridge-nf-call-iptables" to set
with
sysctl:> >
> > wireless-r1 linux # sysctl -w bridge-nf-call-iptables=0
> > error: "bridge-nf-call-iptables" is an unknown key
> >
> > There is also no /proc/sys/net/*/bridge anything. I assume that
means> > this is not something I need to worry about?
> 
> Not sure yet, the problem would be created by CONFIG_BRIDGE_NETFILTER,
> not ebtables itself. Check for
> "/proc/sys/net/bridge/bridge-nf-call-iptables".
> 
> I''m actually pretty sure that this is indeed what''s
causing the
problem,> bridge netfilter defers calling the IP POST_ROUTING hook until the
> packet was already transmitted over the device (and before it goes
> out the underlying device), which means when it hits the CLASSIFY
> target it already passed through the qdisc.
Eh. What a pain. If I disable this, then ebtables will not call iptables
after the ebtables are finished running. I figured out that I could use
ebtables to match the destination MAC address like I needed for the
other problem I posted (See "Bi-directional packet classification with
ACK prioritization" thread for details). However, in order for that to
work, I have to have bridge-nf-call-iptables enabled. Essentially, I can
use the ebtables to flag the packets going to a destination MAC address
and then inside the iptables POSTROUTING mangle chain, I can pick up
that flag and reflag packets based on their Layer 3 and 4 information.
But, then I run right back into the problem of this thread in that the
packets are going through the TC qdiscs and classes before they hit the
POSTROUTING mangle chain. 

Now, what confuses me is that I have this nice big printout of the order
that the packets traverse ebtables, iptables, and tc which was made by
Josh over at ImageStream (see
http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png for the image)
which clearly shows that it should go through ebtables POSTROUTING nat,
then iptables POSTROUTING mangle, then iptables POSTROUTING nat, then TC
qdisc classification, then TC qdisc deque. Also, after reading
http://benix.tamu.edu/unix/linux-bridge-ebtables.htm, it seems pretty
clear that the image depiction should be correct. But, since this is not
happening, either the code has changed or both those sources are just
wrong. 

Do you happen to have any idea how I can get this straightened out? Do
we need to rewrite part of the code to make this work correctly? If that
is what it takes, I would be more than happy to look into doing that. 

Maybe we can write a --destination-mac option for the iptables MAC
matching module? Is that information available to iptables in the
POSTROUTING mangle or nat chains? If not, would it be at all possible to
make it available? That would solve this problem very nicely.

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.

Patrick McHardy

2006-Jun-08 07:41 UTC

head link

Re: [LARTC] iptables CLASSIFY and MARK not working?

Eliot, Wireless and Server Administrator, Great Lakes Internet
wrote:> Eh. What a pain. If I disable this, then ebtables will not call iptables
> after the ebtables are finished running. I figured out that I could use
> ebtables to match the destination MAC address like I needed for the
> other problem I posted (See "Bi-directional packet classification with
> ACK prioritization" thread for details). However, in order for that to
> work, I have to have bridge-nf-call-iptables enabled. Essentially, I can
> use the ebtables to flag the packets going to a destination MAC address
> and then inside the iptables POSTROUTING mangle chain, I can pick up
> that flag and reflag packets based on their Layer 3 and 4 information.
> But, then I run right back into the problem of this thread in that the
> packets are going through the TC qdiscs and classes before they hit the
> POSTROUTING mangle chain. 
> 
> Now, what confuses me is that I have this nice big printout of the order
> that the packets traverse ebtables, iptables, and tc which was made by
> Josh over at ImageStream (see
> http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png for the image)
> which clearly shows that it should go through ebtables POSTROUTING nat,
> then iptables POSTROUTING mangle, then iptables POSTROUTING nat, then TC
> qdisc classification, then TC qdisc deque. Also, after reading
> http://benix.tamu.edu/unix/linux-bridge-ebtables.htm, it seems pretty
> clear that the image depiction should be correct. But, since this is not
> happening, either the code has changed or both those sources are just
> wrong. 
I guess both are wrong.
> Do you happen to have any idea how I can get this straightened out? Do
> we need to rewrite part of the code to make this work correctly? If that
> is what it takes, I would be more than happy to look into doing that. 
Fixing this is one of my short-term TODO items, most likely before
2.6.18.
> Maybe we can write a --destination-mac option for the iptables MAC
> matching module? Is that information available to iptables in the
> POSTROUTING mangle or nat chains? If not, would it be at all possible to
> make it available? That would solve this problem very nicely.
No, iptables can''t reliably get at this information (it might need
to be resolved first).

lee weejin

2006-Jun-11 04:32 UTC

head link

Optimization on Bandwidth Management-L7 filtering?

Hi,

Recently i just set up a machine for bandwidth management based on layer 7
filtering, i have followed the instruction from
http://l7-filter.sourceforge.net/L7-HOWTO-Netfilter .

Since all the incoming packets was checked one by one-(it is time consuming and
will cause the processing delay if it is handling more than 50 PC at a time),
thus i am thinking that is there any way to have a random checking on incoming
packets ? Scipt or tools? so that it wont check all the incoming packets one
follow by another one.

If let say&gt; The incoming packets usage for http is 10 packets that need
to be sent in, thus i only check the 1st packet, and then skip the remaining 9
packets checking in order to provide faster processing time to the machine.

Is it my idea workable? Does it work in Linux box with Layer7 filtering ?

(P/s: my question might be a little bit silly, cause i am still new in this
environment)

Thanks in advance.

Regards,

JIN

Most of the important things in the world have been accomplished by people who
have kept on trying when there seemed to be no hope at all.


_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Andraz Sraka

2006-Jun-26 17:14 UTC

head link

Re: Optimization on Bandwidth Management-L7 filtering?

re

On Sun, 2006-06-11 at 04:32 +0000, lee weejin wrote:> Since all the incoming packets was checked one by one-(it is time
> consuming and will cause the processing delay if it is handling more
> than 50 PC at a time), thus i am thinking that is there any way to
> have a random checking on incoming packets ? Scipt or tools? so that
> it wont check all the incoming packets one follow by another one.
Try marking only first/new packages/connections, that will be analyzed
by layer-7 filter in another chain and there do whole connecting mark
(-j CONNMARK --mark XX). Those mark packages/connections can be then
picked up by ''tc'' for prioritizing traffic or netfilter for
rejecting/dropping/.. traffic.

regards,
 Andraz

-- 
BOFH excuse #62:

need to wrap system in aluminum foil to fix problem



_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

lee weejin

2006-Jul-06 16:35 UTC

head link

Re: Optimization on Bandwidth Management-L7 filtering?

>>>Try marking only first/new packages/connections, that will be
analyzed by
>>>layer-7 filterQuestion: Is it layer-7 filtering able to perform marking the first/new 
packages/connections? May I know how to do that? Thanks.

>From: Andraz Sraka <a@aufbix.org>
>To: lee weejin <leeweejin@hotmail.com>
>CC: lartc@mailman.ds9a.nl
>Subject: Re: [LARTC] Optimization on Bandwidth Management-L7 filtering?
>Date: Mon, 26 Jun 2006 19:14:26 +0200
>
>re
>
>On Sun, 2006-06-11 at 04:32 +0000, lee weejin wrote:
> > Since all the incoming packets was checked one by one-(it is time
> > consuming and will cause the processing delay if it is handling more
> > than 50 PC at a time), thus i am thinking that is there any way to
> > have a random checking on incoming packets ? Scipt or tools? so that
> > it wont check all the incoming packets one follow by another one.
>********************************************************************************
>Try marking only first/new packages/connections, that will be analyzed
>by layer-7 filter in another chain and there do whole connecting mark
>(-j CONNMARK --mark XX). Those mark packages/connections can be then
>picked up by ''tc'' for prioritizing traffic or netfilter
for
>rejecting/dropping/.. traffic.
>
>regards,
>  Andraz
>
>--
>BOFH excuse #62:
>
>need to wrap system in aluminum foil to fix problem
><< signature.asc >>


><< smime.p7s >>

Possibly Parallel Threads

Search for more reasonably related threads

LARTC - May 2006 - iptables CLASSIFY and MARK not working?

iptables CLASSIFY and MARK not working?

Re: iptables CLASSIFY and MARK not working?

Re: iptables CLASSIFY and MARK not working?

RE: iptables CLASSIFY and MARK not working?

Re: iptables CLASSIFY and MARK not working?

RE: iptables CLASSIFY and MARK not working?

RE: iptables CLASSIFY and MARK not working?

Re: iptables CLASSIFY and MARK not working?

RE: iptables CLASSIFY and MARK not working?

RE: iptables CLASSIFY and MARK not working?

RE: iptables CLASSIFY and MARK not working?

RE: iptables CLASSIFY and MARK not working?

Re: iptables CLASSIFY and MARK not working?

RE: iptables CLASSIFY and MARK not working?

Re: [LARTC] iptables CLASSIFY and MARK not working?

RE: [LARTC] iptables CLASSIFY and MARK not working?

Re: iptables CLASSIFY and MARK not working?

RE: iptables CLASSIFY and MARK not working?

Re: [LARTC] iptables CLASSIFY and MARK not working?

RE: [LARTC] iptables CLASSIFY and MARK not working?

Re: [LARTC] iptables CLASSIFY and MARK not working?

RE: [LARTC] iptables CLASSIFY and MARK not working?

Re: [LARTC] iptables CLASSIFY and MARK not working?

Optimization on Bandwidth Management-L7 filtering?

Re: Optimization on Bandwidth Management-L7 filtering?

Re: Optimization on Bandwidth Management-L7 filtering?

Possibly Parallel Threads