* Re: [LARTC] iptables CLASSIFY and MARK not working?
2006-05-19 14:31 Eliot, Wireless and Server Administrator, Great Lakes Internet
@ 2006-05-19 17:31 ` Andreas Unterkircher
2006-05-19 19:26 ` Jody Shumaker
` (13 subsequent siblings)
14 siblings, 0 replies; 29+ messages in thread
From: Andreas Unterkircher @ 2006-05-19 17:31 UTC (permalink / raw)
To: lartc
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
>
>
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: [LARTC] iptables CLASSIFY and MARK not working?
2006-05-19 14:31 Eliot, Wireless and Server Administrator, Great Lakes Internet
2006-05-19 17:31 ` Andreas Unterkircher
@ 2006-05-19 19:26 ` Jody Shumaker
2006-05-22 21:56 ` Eliot, Wireless and Server Administrator, Great Lakes Internet
` (12 subsequent siblings)
14 siblings, 0 replies; 29+ messages in thread
From: Jody Shumaker @ 2006-05-19 19:26 UTC (permalink / raw)
To: lartc
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
^ permalink raw reply [flat|nested] 29+ messages in thread* RE: [LARTC] iptables CLASSIFY and MARK not working?
2006-05-19 14:31 Eliot, Wireless and Server Administrator, Great Lakes Internet
2006-05-19 17:31 ` Andreas Unterkircher
2006-05-19 19:26 ` Jody Shumaker
@ 2006-05-22 21:56 ` Eliot, Wireless and Server Administrator, Great Lakes Internet
2006-05-23 4:32 ` Jody Shumaker
` (11 subsequent siblings)
14 siblings, 0 replies; 29+ messages in thread
From: Eliot, Wireless and Server Administrator, Great Lakes Internet @ 2006-05-22 21:56 UTC (permalink / raw)
To: lartc
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
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: [LARTC] iptables CLASSIFY and MARK not working?
2006-05-19 14:31 Eliot, Wireless and Server Administrator, Great Lakes Internet
` (2 preceding siblings ...)
2006-05-22 21:56 ` Eliot, Wireless and Server Administrator, Great Lakes Internet
@ 2006-05-23 4:32 ` Jody Shumaker
2006-05-30 19:25 ` Eliot, Wireless and Server Administrator, Great Lakes Internet
` (10 subsequent siblings)
14 siblings, 0 replies; 29+ messages in thread
From: Jody Shumaker @ 2006-05-23 4:32 UTC (permalink / raw)
To: lartc
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
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply [flat|nested] 29+ messages in thread* RE: [LARTC] iptables CLASSIFY and MARK not working?
2006-05-19 14:31 Eliot, Wireless and Server Administrator, Great Lakes Internet
` (3 preceding siblings ...)
2006-05-23 4:32 ` Jody Shumaker
@ 2006-05-30 19:25 ` Eliot, Wireless and Server Administrator, Great Lakes Internet
2006-05-30 19:49 ` Jason Boxman
` (9 subsequent siblings)
14 siblings, 0 replies; 29+ messages in thread
From: Eliot, Wireless and Server Administrator, Great Lakes Internet @ 2006-05-30 19:25 UTC (permalink / raw)
To: lartc
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
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply [flat|nested] 29+ messages in thread* RE: [LARTC] iptables CLASSIFY and MARK not working?
2006-05-19 14:31 Eliot, Wireless and Server Administrator, Great Lakes Internet
` (4 preceding siblings ...)
2006-05-30 19:25 ` Eliot, Wireless and Server Administrator, Great Lakes Internet
@ 2006-05-30 19:49 ` Jason Boxman
2006-05-30 20:12 ` Luciano Ruete
` (8 subsequent siblings)
14 siblings, 0 replies; 29+ messages in thread
From: Jason Boxman @ 2006-05-30 19:49 UTC (permalink / raw)
To: lartc
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
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: [LARTC] iptables CLASSIFY and MARK not working?
2006-05-19 14:31 Eliot, Wireless and Server Administrator, Great Lakes Internet
` (5 preceding siblings ...)
2006-05-30 19:49 ` Jason Boxman
@ 2006-05-30 20:12 ` Luciano Ruete
2006-05-30 20:13 ` Eliot, Wireless and Server Administrator, Great Lakes Internet
` (7 subsequent siblings)
14 siblings, 0 replies; 29+ messages in thread
From: Luciano Ruete @ 2006-05-30 20:12 UTC (permalink / raw)
To: lartc
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!Q0(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
^ permalink raw reply [flat|nested] 29+ messages in thread* RE: [LARTC] iptables CLASSIFY and MARK not working?
2006-05-19 14:31 Eliot, Wireless and Server Administrator, Great Lakes Internet
` (6 preceding siblings ...)
2006-05-30 20:12 ` Luciano Ruete
@ 2006-05-30 20:13 ` Eliot, Wireless and Server Administrator, Great Lakes Internet
2006-05-30 20:19 ` Eliot, Wireless and Server Administrator, Great Lakes Internet
` (6 subsequent siblings)
14 siblings, 0 replies; 29+ messages in thread
From: Eliot, Wireless and Server Administrator, Great Lakes Internet @ 2006-05-30 20:13 UTC (permalink / raw)
To: lartc
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
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply [flat|nested] 29+ messages in thread* RE: [LARTC] iptables CLASSIFY and MARK not working?
2006-05-19 14:31 Eliot, Wireless and Server Administrator, Great Lakes Internet
` (7 preceding siblings ...)
2006-05-30 20:13 ` Eliot, Wireless and Server Administrator, Great Lakes Internet
@ 2006-05-30 20:19 ` Eliot, Wireless and Server Administrator, Great Lakes Internet
2006-05-30 20:25 ` Eliot, Wireless and Server Administrator, Great Lakes Internet
` (5 subsequent siblings)
14 siblings, 0 replies; 29+ messages in thread
From: Eliot, Wireless and Server Administrator, Great Lakes Internet @ 2006-05-30 20:19 UTC (permalink / raw)
To: lartc
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!Q0(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
^ permalink raw reply [flat|nested] 29+ messages in thread* RE: [LARTC] iptables CLASSIFY and MARK not working?
2006-05-19 14:31 Eliot, Wireless and Server Administrator, Great Lakes Internet
` (8 preceding siblings ...)
2006-05-30 20:19 ` Eliot, Wireless and Server Administrator, Great Lakes Internet
@ 2006-05-30 20:25 ` Eliot, Wireless and Server Administrator, Great Lakes Internet
2006-06-01 18:13 ` Eliot, Wireless and Server Administrator, Great Lakes Internet
` (4 subsequent siblings)
14 siblings, 0 replies; 29+ messages in thread
From: Eliot, Wireless and Server Administrator, Great Lakes Internet @ 2006-05-30 20:25 UTC (permalink / raw)
To: lartc
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!Q0(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
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply [flat|nested] 29+ messages in thread* RE: [LARTC] iptables CLASSIFY and MARK not working?
2006-05-19 14:31 Eliot, Wireless and Server Administrator, Great Lakes Internet
` (9 preceding siblings ...)
2006-05-30 20:25 ` Eliot, Wireless and Server Administrator, Great Lakes Internet
@ 2006-06-01 18:13 ` Eliot, Wireless and Server Administrator, Great Lakes Internet
2006-06-01 18:22 ` Patrick McHardy
2006-06-01 18:49 ` Eliot, Wireless and Server Administrator, Great Lakes Internet
` (3 subsequent siblings)
14 siblings, 1 reply; 29+ messages in thread
From: Eliot, Wireless and Server Administrator, Great Lakes Internet @ 2006-06-01 18:13 UTC (permalink / raw)
To: lartc
> 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!Q0(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
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: [LARTC] iptables CLASSIFY and MARK not working?
2006-06-01 18:13 ` Eliot, Wireless and Server Administrator, Great Lakes Internet
@ 2006-06-01 18:22 ` Patrick McHardy
0 siblings, 0 replies; 29+ messages in thread
From: Patrick McHardy @ 2006-06-01 18:22 UTC (permalink / raw)
To: Eliot, Wireless and Server Administrator, Great Lakes Internet
Cc: lartc, Netfilter Development Mailinglist
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.
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply [flat|nested] 29+ messages in thread
* RE: [LARTC] iptables CLASSIFY and MARK not working?
2006-05-19 14:31 Eliot, Wireless and Server Administrator, Great Lakes Internet
` (10 preceding siblings ...)
2006-06-01 18:13 ` Eliot, Wireless and Server Administrator, Great Lakes Internet
@ 2006-06-01 18:49 ` Eliot, Wireless and Server Administrator, Great Lakes Internet
2006-06-01 19:09 ` Patrick McHardy
2006-06-01 19:38 ` Eliot, Wireless and Server Administrator, Great Lakes Internet
` (2 subsequent siblings)
14 siblings, 1 reply; 29+ messages in thread
From: Eliot, Wireless and Server Administrator, Great Lakes Internet @ 2006-06-01 18:49 UTC (permalink / raw)
To: Patrick McHardy; +Cc: lartc, Netfilter Development Mailinglist
-----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
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: [LARTC] iptables CLASSIFY and MARK not working?
2006-06-01 18:49 ` Eliot, Wireless and Server Administrator, Great Lakes Internet
@ 2006-06-01 19:09 ` Patrick McHardy
0 siblings, 0 replies; 29+ messages in thread
From: Patrick McHardy @ 2006-06-01 19:09 UTC (permalink / raw)
To: Eliot, Wireless and Server Administrator, Great Lakes Internet
Cc: lartc, Netfilter Development Mailinglist
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?
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [LARTC] iptables CLASSIFY and MARK not working?
@ 2006-06-01 19:09 ` Patrick McHardy
0 siblings, 0 replies; 29+ messages in thread
From: Patrick McHardy @ 2006-06-01 19:09 UTC (permalink / raw)
To: Eliot, Wireless and Server Administrator, Great Lakes Internet
Cc: lartc, Netfilter Development Mailinglist
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?
^ permalink raw reply [flat|nested] 29+ messages in thread
* RE: [LARTC] iptables CLASSIFY and MARK not working?
@ 2006-06-01 19:38 ` Eliot, Wireless and Server Administrator, Great Lakes Internet
0 siblings, 0 replies; 29+ messages in thread
From: Eliot, Wireless and Server Administrator, Great Lakes Internet @ 2006-06-01 19:38 UTC (permalink / raw)
To: Patrick McHardy; +Cc: lartc, Netfilter Development Mailinglist
-----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.
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply [flat|nested] 29+ messages in thread* RE: [LARTC] iptables CLASSIFY and MARK not working?
@ 2006-06-01 19:38 ` Eliot, Wireless and Server Administrator, Great Lakes Internet
0 siblings, 0 replies; 29+ messages in thread
From: Eliot, Wireless and Server Administrator, Great Lakes Internet @ 2006-06-01 19:38 UTC (permalink / raw)
To: Patrick McHardy; +Cc: lartc, Netfilter Development Mailinglist
-----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.
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: [LARTC] iptables CLASSIFY and MARK not working?
2006-06-01 19:38 ` Eliot, Wireless and Server Administrator, Great Lakes Internet
(?)
@ 2006-06-01 19:44 ` Patrick McHardy
-1 siblings, 0 replies; 29+ messages in thread
From: Patrick McHardy @ 2006-06-01 19:44 UTC (permalink / raw)
To: Eliot, Wireless and Server Administrator, Great Lakes Internet
Cc: lartc, Netfilter Development Mailinglist
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.
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply [flat|nested] 29+ messages in thread
* RE: [LARTC] iptables CLASSIFY and MARK not working?
2006-05-19 14:31 Eliot, Wireless and Server Administrator, Great Lakes Internet
` (12 preceding siblings ...)
2006-06-01 19:38 ` Eliot, Wireless and Server Administrator, Great Lakes Internet
@ 2006-06-01 19:58 ` Eliot, Wireless and Server Administrator, Great Lakes Internet
2006-06-01 20:01 ` Patrick McHardy
2006-06-01 20:09 ` Eliot, Wireless and Server Administrator, Great Lakes Internet
14 siblings, 1 reply; 29+ messages in thread
From: Eliot, Wireless and Server Administrator, Great Lakes Internet @ 2006-06-01 19:58 UTC (permalink / raw)
To: Patrick McHardy; +Cc: lartc, Netfilter Development Mailinglist
-----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.
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: [LARTC] iptables CLASSIFY and MARK not working?
2006-06-01 19:58 ` Eliot, Wireless and Server Administrator, Great Lakes Internet
@ 2006-06-01 20:01 ` Patrick McHardy
0 siblings, 0 replies; 29+ messages in thread
From: Patrick McHardy @ 2006-06-01 20:01 UTC (permalink / raw)
To: Eliot, Wireless and Server Administrator, Great Lakes Internet
Cc: lartc, Netfilter Development Mailinglist
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.
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [LARTC] iptables CLASSIFY and MARK not working?
@ 2006-06-01 20:01 ` Patrick McHardy
0 siblings, 0 replies; 29+ messages in thread
From: Patrick McHardy @ 2006-06-01 20:01 UTC (permalink / raw)
To: Eliot, Wireless and Server Administrator, Great Lakes Internet
Cc: lartc, Netfilter Development Mailinglist
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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* RE: [LARTC] iptables CLASSIFY and MARK not working?
@ 2006-06-01 20:09 ` Eliot, Wireless and Server Administrator, Great Lakes Internet
0 siblings, 0 replies; 29+ messages in thread
From: Eliot, Wireless and Server Administrator, Great Lakes Internet @ 2006-06-01 20:09 UTC (permalink / raw)
To: Patrick McHardy; +Cc: lartc, Netfilter Development Mailinglist
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.
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply [flat|nested] 29+ messages in thread
* RE: [LARTC] iptables CLASSIFY and MARK not working?
@ 2006-06-01 20:09 ` Eliot, Wireless and Server Administrator, Great Lakes Internet
0 siblings, 0 replies; 29+ messages in thread
From: Eliot, Wireless and Server Administrator, Great Lakes Internet @ 2006-06-01 20:09 UTC (permalink / raw)
To: Patrick McHardy; +Cc: lartc, Netfilter Development Mailinglist
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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [LARTC] iptables CLASSIFY and MARK not working?
2006-06-01 20:09 ` Eliot, Wireless and Server Administrator, Great Lakes Internet
@ 2006-06-01 20:10 ` Patrick McHardy
-1 siblings, 0 replies; 29+ messages in thread
From: Patrick McHardy @ 2006-06-01 20:10 UTC (permalink / raw)
To: Eliot, Wireless and Server Administrator, Great Lakes Internet
Cc: lartc, Netfilter Development Mailinglist
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.
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [LARTC] iptables CLASSIFY and MARK not working?
@ 2006-06-01 20:10 ` Patrick McHardy
0 siblings, 0 replies; 29+ messages in thread
From: Patrick McHardy @ 2006-06-01 20:10 UTC (permalink / raw)
To: Eliot, Wireless and Server Administrator, Great Lakes Internet
Cc: lartc, Netfilter Development Mailinglist
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.
^ permalink raw reply [flat|nested] 29+ messages in thread
