> You didn't specify hfsc on ifb0; therefore, HTB does not accept the syntax > you have used for the guaranteed rate. > Yeah, I figured it out at the end, I assumed that because the ifb inherits the classify option it also inherits any other options from the redirected interface, which was wrong obviously.
>>> 2. >>> eth0 - 1mbit classify,hfsc (tcdevices) >>> eth0:1 - 10*full/100:50ms 20*full/100 1 tcp-ack (tcclases) >>> ERROR: Duplicate interface:class number (1:1} : /etc/shorewall/tcclasses >>> >>> 3. >>> 123:eth0 - 1mbit classify,hfsc (tcdevices) >>> 123:1 - 10*full/100:50ms 20*full/100 1 tcp-ack (tcclasses) >>> ERROR: Duplicate interface:class number (291:1} : >>> /etc/shorewall/tcclasses >>> > > I should make it more clear that '1' is a poor choice of class number, given > that '1' is the class number assigned to the root class of each interface. > This actually helped me discover what I think is a bug (see below). >>> 4. >>> A:eth0 - 1mbit classify,hfsc (tcdevices) >>> > > That syntax is completely wacky. What piece of the documentation led you to > that one? > "man shorewall-tcdevices" states that I could use hex numbers (A is a hex = 10 decimal, right?). So, strictly speaking, it should be able to accept that value. It gives an error instead. Anyway, it looks as though I cannot force traffic-shaping on incoming traffic by using tcrules AND use it on my INPUT chain AND use ipsets AND use user id - it seems impossible. The documentation on tcrules is, well lets just say, there is a lot to be desired from it (where and in what circumstances am I allowed to use "I" and "CI" for example?) - I started by using classes, but gave up soon after as they work only on the postrouting chain, which is not what I am after as I don't seem to be able to control incoming traffic at all. I then tried simple marking, but then I seem to be unable to specify the "I" flag anywhere in my tcrules to force it to shape the incoming traffic, so there... Finally there is, what I think a bug, in the latest shorewall version: eth0:1 - 10*full/100:50ms 20*full/100 1 tcp-ack eth0:2 - 80*full/100 full 2 eth0:2:21 - 20*full/100 full 3 eth0:2:22 - 20*full/100 full 4 eth0:2:23 - 20*full/100 full 5 eth0:2:24 - 20*full/100 full 6 eth0:2:25 - 20*full/100 full 7 eth0:3 - 10*full/100 full 8 default shorewall compile passes, but service shorewall (re)start ultimately fails with: shorewall[1493]: RTNETLINK answers: File exists shorewall[1493]: ERROR: Command "tc class add dev eth0 parent 1:1 classid 1:1 hfsc sc umax 1500b dmax 50ms rate 10000kbit ul rate 20000kbit" Failed The culprit seems to be the use of "1" (when replaced with "12" for example all seems OK) - this should have been caught during the shorewall compilation. One other thing which I found in man shorewall-tcrules: in the classid section it states that "the major class is the device number (the first device in shorewall-tcdevices[3](5) is major class 1, the second device is major class 2, and so on) and the minor class is the class's MARK value in shorewall-tcclasses[4](5) preceded by the number 1 (MARK 1 corresponds to minor class 11, MARK 5 corresponds to minor class 15, MARK 22 corresponds to minor class 122, etc.)." So, following that if I have a device with major 1, then a class defined in tcclasses as, say, 21, I should therefore use 121 in my tcrules file (as "1:121" in this case). That does not work and it gives me "Unknown Class" error. ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd _______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
