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: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jason Boxman
Sent: Tuesday, May 30, 2006 3:49 PM
To: [email protected]
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
[email protected]
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
_______________________________________________
LARTC mailing list
[email protected]
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
