[Mr Dash Four <mr.dash.four@go...>]

>> 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.
>>     
>
> That's correct. There is *no* netfilter hook between the time that a packet enters the box and when it gets redirected to an IFB. That is the entire reason that /etc/shorewall/tcfilters was originally invented. At http://www.shorewall.net/traffic_shaping.htm#IFB, it clearly states that: "Entries in /etc/shorewall/tcrules have no effect on shaping traffic through an IFB. To allow classification of such traffic, the /etc/shorewall/tcfilters file has been added. Entries in that file create u32 classification rules."
>   
So, in other words there is no way on gods green Earth that I could 
shape incoming traffic by utilising ipsets and/or by using the tcrules 
file? If that is correct, then my only choice seems to be tcfilters and 
there I cannot use ipsets (yeah, catch22 that!).

>> 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 and :CI are included for completeness (the tcrules file is the only way to mark packets using Shorewall and packet marks are the "Swiss Army Knife" of Netfilter). Neither affect either policy routing or traffic shaping and I've made that clear in the online copies of the tcrules man pages.
>   
OK, could you show me a simple example when I can mark traffic in the 
INPUT chain (presumably by using the "I" or "CI" flags) and include it 
in tc classes for traffic shaping? Is that possible? Say incoming 
traffic destined to "+web-ports" ipset (web-ports ipset containing 80, 
8080-8082, 443 and 8443 as its values). i.e. traffic *->$FW:+wep-ports, 
and shape that traffic from 1mbit to full.

>> - I started by using classes, but gave up soon after as they work only on the postrouting chain,
>>     
>
> Completely not true. But then, it you are trying to shape incoming traffic with tcrules, I can understand your confusion.
>   
Well, that is what the man pages state (quoting the major:minor 
classification): "Classification occurs in the POSTROUTING chain except 
when the SOURCE is $FW[:address] in which case classification occurs in 
the OUTPUT chain."

So, by that I can only conclude that if I wish to use classes hierarchy 
(major:minor etc) the only choice open for me is POSTROUTING or OUTPUT, 
which is more or less what I wrote above (in other words flags "P", "F" 
and "I" are completely useless for this classification).

Following on from this, I see no sense whatsoever in applying that 
classification to ifb-type devices as there is NEVER going to be a match 
when these are included in the tcrules file as, to my understanding, ifb 
operates on the incoming/input chains and traffic.

If that is indeed the case, why are ifb-type devices allowed to be used 
in the tcrules file at all - what possible purpose would that serve 
(genuine question as I cannot figure out what sort of match could there 
be if ifb devices are used in tcrules)?

If that is also correct, then I also do not see much sense in using the 
"P", "F" and "I" flags with this kind of devices either (does shorewall 
gives an error if either of these are used - haven't tested that yet?).

>> 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.
>>     
>
> That only applies if you let Shorewall pick the class numbers; you are specifying them explicitly in tcclasses.
>   
Then perhaps the man page should be amended to make that clearer as this 
is a bit misleading.