Re: [LARTC] iptables CLASSIFY and MARK not working?
Eliot, Wireless and Server Administrator, Great Lakes Internet wrote: > Eh. What a pain. If I disable this, then ebtables will not call iptables > after the ebtables are finished running. I figured out that I could use > ebtables to match the destination MAC address like I needed for the > other problem I posted (See "Bi-directional packet classification with > ACK prioritization" thread for details). However, in order for that to > work, I have to have bridge-nf-call-iptables enabled. Essentially, I can > use the ebtables to flag the packets going to a destination MAC address > and then inside the iptables POSTROUTING mangle chain, I can pick up > that flag and reflag packets based on their Layer 3 and 4 information. > But, then I run right back into the problem of this thread in that the > packets are going through the TC qdiscs and classes before they hit the > POSTROUTING mangle chain. > > Now, what confuses me is that I have this nice big printout of the order > that the packets traverse ebtables, iptables, and tc which was made by > Josh over at ImageStream (see > http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png for the image) > which clearly shows that it should go through ebtables POSTROUTING nat, > then iptables POSTROUTING mangle, then iptables POSTROUTING nat, then TC > qdisc classification, then TC qdisc deque. Also, after reading > http://benix.tamu.edu/unix/linux-bridge-ebtables.htm, it seems pretty > clear that the image depiction should be correct. But, since this is not > happening, either the code has changed or both those sources are just > wrong. I guess both are wrong. > Do you happen to have any idea how I can get this straightened out? Do > we need to rewrite part of the code to make this work correctly? If that > is what it takes, I would be more than happy to look into doing that. Fixing this is one of my short-term TODO items, most likely before 2.6.18. > Maybe we can write a --destination-mac option for the iptables MAC > matching module? Is that information available to iptables in the > POSTROUTING mangle or nat chains? If not, would it be at all possible to > make it available? That would solve this problem very nicely. No, iptables can't reliably get at this information (it might need to be resolved first). ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] iptables CLASSIFY and MARK not working?
Eliot, Wireless and Server Administrator, Great Lakes Internet wrote: > THANK YOU! > > That solved the problem. I found the file you specified and it was > indeed enabled. After disabling it, it is now working! Good to hear. This crap is causing one weird problem after another, we really need to get rid of it. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
RE: [LARTC] iptables CLASSIFY and MARK not working?
THANK YOU! That solved the problem. I found the file you specified and it was indeed enabled. After disabling it, it is now working! Eliot Gable Certified Wireless Network Administrator (CWNA) Certified Wireless Security Professional (CWSP) Cisco Certified Network Associate (CCNA) CompTIA Security+ Certified CompTIA Network+ Certified Network and System Engineer Great Lakes Internet, Inc. 112 North Howard Croswell, MI 48422 (810) 679-3395 (877) 558-8324 Now offering Broadband Wireless Internet access in Croswell, Lexington, Brown City, Yale, Worth Township, and Sandusky. Call for details. -Original Message- From: Patrick McHardy [mailto:[EMAIL PROTECTED] 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
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
RE: [LARTC] iptables CLASSIFY and MARK not working?
-Original Message- From: Patrick McHardy [mailto:[EMAIL PROTECTED] 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
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. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
RE: [LARTC] iptables CLASSIFY and MARK not working?
-Original Message- From: Patrick McHardy [mailto:[EMAIL PROTECTED] 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 40bit 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 3Kbit 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 64bit d 2.0s m2 128000bit ul m1 64bit 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 6Kbit d 2.0s m2 6Kbit ul m1 6Kbit d 2.0s m2 6Kbit 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 1Kbit d 2.0s m2 1Kbit 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 40bit 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 8bit d 2.0s m2 16000bit ul m1 8bit 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
Re: [LARTC] iptables CLASSIFY and MARK not working?
Eliot, Wireless and Server Administrator, Great Lakes Internet wrote: > These rules make it go to the classes instead of the qdisc: > > Chain POSTROUTING (policy ACCEPT 887K packets, 495M bytes) > pkts bytes target prot opt in out source > destination > 8662 508K CLASSIFY all -- * br1 0.0.0.0/0 > 0.0.0.0/0 MARK match 0x1fe CLASSIFY set 5:1fe >14 8253 CLASSIFY all -- * br1 0.0.0.0/0 > 0.0.0.0/0 MARK match 0x1ff CLASSIFY set 5:1ff > 0 0 CLASSIFY all -- * br1 0.0.0.0/0 > 0.0.0.0/0 MARK match 0x200 CLASSIFY set 5:200 > 845 222K CLASSIFY all -- * wivl4 0.0.0.0/0 > 0.0.0.0/0 MARK match 0x1fe CLASSIFY set 5:1fe >22 5286 CLASSIFY all -- * wivl4 0.0.0.0/0 > 0.0.0.0/0 MARK match 0x1ff CLASSIFY set 5:1ff > 0 0 CLASSIFY all -- * wivl4 0.0.0.0/0 > 0.0.0.0/0 MARK match 0x200 CLASSIFY set 5:200 > > > > And yet, still nothing hits the classes: > > > > wireless-r1 ~ # tc -s class show dev wivl4 > class hfsc 5: root > Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) > rate 0bit 0pps backlog 0b 0p requeues 0 > period 0 level 1 > > class hfsc 5:1fe parent 5: leaf 1db: sc m1 40bit 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 3Kbit > 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 6Kbit d 2.0s m2 6Kbit ul m1 > 6Kbit d 2.0s m2 6Kbit > 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 1Kbit d 2.0s m2 1Kbit > 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 40bit 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 16bit d 2.0s m2 32000bit > ul m1 16bit 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 40bit 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 3Kbit > 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 64bit d 2.0s m2 128000bit > ul m1 64bit 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 6Kbit d 2.0s m2 6Kbit ul m1 > 6Kbit d 2.0s m2 6Kbit > 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 1Kbit d 2.0s m2 1Kbit > 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 40bit 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 > > cl
RE: [LARTC] iptables CLASSIFY and MARK not working?
-Original Message- From: Patrick McHardy [mailto:[EMAIL PROTECTED] 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 40bit 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 3Kbit 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 6Kbit d 2.0s m2 6Kbit ul m1 6Kbit d 2.0s m2 6Kbit 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 1024K
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. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
RE: [LARTC] iptables CLASSIFY and MARK not working?
> On Tuesday 30 May 2006 16:25, Eliot, Wireless and Server
Administrator,
> Great Lakes Internet wrote:
> [snip]
> > You'll notice that the iptables rules show matches for class 5:510,
> > 5:511, and others; yet, the only class taking traffic here is 5:2.
>
> just to exaust possibilities...
>
> i think that 5:2 is working cause
> 0x2==2(decimal), but
> 0x510!=510(decimal)
> 0x1fe==510(decimal)
>
> in my experience iptables output is in HEX wile tc otput is in DEC
> So give a try with
> tc class==510
> iptables MARK==1fe
> and so on...
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,1:2 -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,
RE: [LARTC] iptables CLASSIFY and MARK not working?
Chain POSTROUTING (policy ACCEPT 222K packets, 157M bytes)
pkts bytes target prot opt in out source
destination
6401 3653K CLASSIFY all -- * wivl4 0.0.0.0/0
0.0.0.0/0 MARK match 0x1fe CLASSIFY set 1db:0
It matches like normal, but this time is pointing to a hex classid.
wireless-r1 bwlimit # tc -s qdisc show dev wivl4
qdisc hfsc 5: default 2
Sent 18976288 bytes 26059 pkt (dropped 3222, overlimits 5751 requeues
0)
rate 0bit 0pps backlog 0b 0p requeues 0
qdisc sfq 475: parent 5:510 limit 128p quantum 1514b
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0
qdisc sfq 476: parent 5:511 limit 128p quantum 1514b
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0
qdisc sfq 477: parent 5:512 limit 128p quantum 1514b
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0
qdisc sfq 469: parent 5:504 limit 128p quantum 1514b
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0
qdisc sfq 470: parent 5:505 limit 128p quantum 1514b
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0
But qdisc 475 is still not getting packets. Neither is its parent class:
class hfsc 5:510 parent 5: leaf 475: sc m1 40bit 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: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] 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: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Luciano Ruete
Sent: Tuesday, May 30, 2006 4:13 PM
To: lartc@mailman.ds9a.nl
Subject: Re: [LARTC] iptables CLASSIFY and MARK not working?
On Tuesday 30 May 2006 16:25, Eliot, Wireless and Server Administrator,
Great
Lakes Internet wrote:
[snip]
> You'll notice that the iptables rules show matches for class 5:510,
> 5:511, and others; yet, the only class taking traffic here is 5:2.
just to exaust possibilities...
i think that 5:2 is working cause
0x2==2(decimal), but
0x510!=510(decimal)
0x1fe==510(decimal)
in my experience iptables output is in HEX wile tc otput is in DEC
So give a try with
tc class==510
iptables MARK==1fe
and so on...
--
Luciano
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
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: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Luciano Ruete
Sent: Tuesday, May 30, 2006 4:13 PM
To: lartc@mailman.ds9a.nl
Subject: Re: [LARTC] iptables CLASSIFY and MARK not working?
On Tuesday 30 May 2006 16:25, Eliot, Wireless and Server Administrator,
Great
Lakes Internet wrote:
[snip]
> You'll notice that the iptables rules show matches for class 5:510,
> 5:511, and others; yet, the only class taking traffic here is 5:2.
just to exaust possibilities...
i think that 5:2 is working cause
0x2==2(decimal), but
0x510!=510(decimal)
0x1fe==510(decimal)
in my experience iptables output is in HEX wile tc otput is in DEC
So give a try with
tc class==510
iptables MARK==1fe
and so on...
--
Luciano
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
RE: [LARTC] iptables CLASSIFY and MARK not working?
Ok, I tried this: tc qdisc add dev wivl4 parent 5:510 handle 475:0 sfq tc qdisc add dev wivl4 parent 5:511 handle 476:0 sfq tc qdisc add dev wivl4 parent 5:512 handle 477:0 sfq iptables -A POSTROUTING -t mangle -o wivl4 -m mark --mark 510 -j CLASSIFY --set-class 475:0 iptables -A POSTROUTING -t mangle -o wivl4 -m mark --mark 511 -j CLASSIFY --set-class 476:0 iptables -A POSTROUTING -t mangle -o wivl4 -m mark --mark 512 -j CLASSIFY --set-class 477:0 Now I have: Chain POSTROUTING (policy ACCEPT 190K packets, 141M bytes) pkts bytes target prot opt in out source destination 1593 65864 CLASSIFY all -- * br1 0.0.0.0/0 0.0.0.0/0 MARK match 0x1fe CLASSIFY set 455:0 0 0 CLASSIFY all -- * br1 0.0.0.0/0 0.0.0.0/0 MARK match 0x1ff CLASSIFY set 456:0 0 0 CLASSIFY all -- * br1 0.0.0.0/0 0.0.0.0/0 MARK match 0x200 CLASSIFY set 457:0 2323 3226K CLASSIFY all -- * wivl4 0.0.0.0/0 0.0.0.0/0 MARK match 0x1fe CLASSIFY set 475:0 0 0 CLASSIFY all -- * wivl4 0.0.0.0/0 0.0.0.0/0 MARK match 0x1ff CLASSIFY set 476:0 0 0 CLASSIFY all -- * wivl4 0.0.0.0/0 0.0.0.0/0 MARK match 0x200 CLASSIFY set 477:0 So, packets are still matching and being sent to 475:0. But, I get this in my tc output: wireless-r1 bwlimit # tc -s qdisc show dev wivl4 qdisc hfsc 5: default 2 Sent 5632424 bytes 4070 pkt (dropped 6, overlimits 7 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 qdisc sfq 475: parent 5:510 limit 128p quantum 1514b Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 qdisc sfq 476: parent 5:511 limit 128p quantum 1514b Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 qdisc sfq 477: parent 5:512 limit 128p quantum 1514b Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 qdisc sfq 469: parent 5:504 limit 128p quantum 1514b Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 qdisc sfq 470: parent 5:505 limit 128p quantum 1514b Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 wireless-r1 bwlimit # tc -s class show dev wivl4 class hfsc 5: root Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 period 0 level 1 class hfsc 5:505 parent 5: leaf 470: sc m1 16bit d 2.0s m2 0bit ul m1 16bit 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 3Kbit 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 40bit 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 6Kbit d 2.0s m2 6Kbit ul m1 6Kbit d 2.0s m2 6Kbit 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 1Kbit d 2.0s m2 1Kbit 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 40bit 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 48bit 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 96bit d 2.0s m2 96bit 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: lartc@mailman.ds9a.nl Subject: RE: [LARTC] iptables CLASSIFY and
Re: [LARTC] iptables CLASSIFY and MARK not working?
On Tuesday 30 May 2006 16:25, Eliot, Wireless and Server Administrator, Great Lakes Internet wrote: [snip] > You'll notice that the iptables rules show matches for class 5:510, > 5:511, and others; yet, the only class taking traffic here is 5:2. just to exaust possibilities... i think that 5:2 is working cause 0x2==2(decimal), but 0x510!=510(decimal) 0x1fe==510(decimal) in my experience iptables output is in HEX wile tc otput is in DEC So give a try with tc class==510 iptables MARK==1fe and so on... -- Luciano ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
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. > > > 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
RE: [LARTC] iptables CLASSIFY and MARK not working?
mits 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 3Kbit 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 40bit 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 6Kbit d 2.0s m2 6Kbit ul m1 6Kbit d 2.0s m2 6Kbit 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 1Kbit d 2.0s m2 1Kbit 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 40bit 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 48bit 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 96bit d 2.0s m2 96bit 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:[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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
Re: [LARTC] iptables CLASSIFY and MARK not working?
On 5/22/06, Eliot, Wireless and Server Administrator, Great Lakes Internet <[EMAIL PROTECTED]> 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
RE: [LARTC] iptables CLASSIFY and MARK not working?
You were exactly right here. Moving to the filters instead of the iptables classify solved the issue. As for performance, I have not yet benchmarked it to determine if the filters are fast enough for the number of users I need this to support. Eliot Gable Certified Wireless Network Administrator (CWNA) Certified Wireless Security Professional (CWSP) Cisco Certified Network Associate (CCNA) CompTIA Security+ Certified CompTIA Network+ Certified Network and System Engineer Great Lakes Internet, Inc. 112 North Howard Croswell, MI 48422 (810) 679-3395 (877) 558-8324 Now offering Broadband Wireless Internet access in Croswell, Lexington, Brown City, Yale, Worth Township, and Sandusky. Call for details. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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
Re: [LARTC] iptables CLASSIFY and MARK not working?
On 5/19/06, Andreas Unterkircher <[EMAIL PROTECTED]> 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
Re: [LARTC] iptables CLASSIFY and MARK not working?
Have you checked that the ip_conntrack module is loaded or compiled into the kernel? If not the mark is lost... Cheers, Andreas Eliot, Wireless and Server Administrator, Great Lakes Internet schrieb: I have to match my packets based on MAC address, which I cannot do in the POSTROUTING chain, so I do it in PREROUTING using MARK. Then, I match on the MARK in the POSTROUTING chain to do a CLASSIFY. But this does not seem to work: wireless-r1 bwlimit # iptables -L -v -n -t mangle Chain PREROUTING (policy ACCEPT 3353K packets, 941M bytes) pkts bytes target prot opt in out source destination 12527 11M CONNMARK all -- * * 0.0.0.0/0 0.0.0.0/0 CONNMARK restore 3227 130K MARK all -- * * 0.0.0.0/0 0.0.0.0/0 MAC 00:05:9E:81:3D:07 MARK set 0x30 3231 132K CONNMARK all -- * * 0.0.0.0/0 0.0.0.0/0 MARK match 0x30 CONNMARK save 0 0 MARK udp -- * * 0.0.0.0/0 0.0.0.0/0 MAC 00:05:9E:81:3D:07 multiport ports 53,4569,5060,1:2 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 3Kbit ceil 3Kbit 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 6Kbit ceil 6Kbit burst 31590b cburst 31590b Sent 54187 bytes 790 pkt (dropped 0, ove
