On 05/15/2011 05:51 AM, Mr Dash Four wrote: > >>> 1. >>> tcfilters >>> ba:25 - - all >>> (ba is on ifb0) >>> >>> Passes compilation, but then I get this: >>> >>> RTNETLINK answers: Invalid argument >>> We have an error talking to the kernel >>> ERROR: Command "tc filter add dev ifb0 protocol ip parent be:0 prio 10 u32 >>> flowid ba:25" Failed >>> >> >> >> This is not enough information to understand the problem. Please include a >> tarball of /etc/shorewall (with capabilities file) so that I can reproduce >> the problem. Thanks. >> > The class in question is created on ifbX device. The statement I > included above is from tcfilters - it lists nothing specific in terms of > source and destination (address or subnet) and the protocol is specified > as "all". That passes check/compilation, but gives the error I indicated > above when shorewall (tries to) restart/reload. If you bother to try it > out my guess is that you will run into the same error.
It would have been helpful to simply point out that any degenerate
tcfilter produces this result. I've reproduced the problem and the
attached patch ignores such tcfulters with a warning.
>
>
>>> 2.
>>> tcrules
>>> bb:12 $FW +[mickey-mouse,ip-port] tcp
>>>
>>> "shorewall check/compile" passes, but it fails when shorewall
>>> reload/restart is executed with "...Set mickey-mouse doesn't exist.". In
>>> other words, shorewall don't capture this error. I am not sure whether
>>> shorewall used to capture this before - i.e. the (non)existence of insets.
>>>
>>
>> Shorewall hasn't, doesn't and won't verify the existence of ipsets.
>> Shorewall rulesets can be compiled on one system and executed on another
>> system running shorewall-lite. Or, as you do, the /etc/shorewall/init file
>> can create and load ipsets that don't exist before the script runs. I'm sure
>> that if the Shorewall compiler generated a compile-time error or warning
>> message about a missing ipset, you would be on this list pointing out how
>> stupid the product is.
>>
> And you know this how exactly? I wasn't aware that you became Mystic
> bloody Meg all of a sudden!
Your track record speaks for itself.
>
>
>>> 3.
>>> tcfilters
>>> ba:12 212.... - tcp 17001 1193:2193
>>>
>>> The above has absolutely *no* chance on gods green Earth to produce a match
>>> - EVER! Unless the destination IP address is also specified, that is! I
>>> don't know why that is, but if it is some sort of misconfiguration error
>>> then I should at least be given a warning.
>>>
>>
>> Why could no packet ever match that? Is there an RFC that prohibits sending
>> TCP packets to address 212.., port 17001 when the source port is in the
>> range 1193:2193? If so, I am not familiar with it.
>>
> Try it out and see if you are ever going to get any matches! My guess is
> that you won't!
Works fine for me:
tcdevices:
ba:ifb0 - 1000mbit hfsc,classify eth2
tcclasses:
ba:25 - 500mbit:50ms full 1 default
tcfilter:
ba:25 172.20.1.146 - all
I pinged this host from 172.20.1.146 and:
Device ifb0:
filter parent ba: protocol ip pref 10 u32
filter parent ba: protocol ip pref 10 u32 fh 800: ht divisor 1
filter parent ba: protocol ip pref 10 u32 fh 800::800 order 2048 key ht
filter parent ba: protocol ip pref 10 u32 fh 800::801 order 2049 key ht
800 bkt 0 flowid ba:25 (rule hit 29 success 9)
match ac140192/ffffffff at 12 (success 9 )
----------
>>> 4. dmax values
>>> When I have dmax=375ms the resulting flow (as seen with
>>> shorewall
show tc ethX/ifbX) is set as 75ms. In other places where I have
dmax=100ms the actual value is 0 - it looks as though the first digit of
what I specified in tcclasses seems to be "eaten up" by shorewall.
>>>
>>
>> Have you confirmed that Shorewall is doing the truncation? My
>> reading of the code indicates that Shorewall doesn't alter the user-supplied
>> value.
>>
> How do I confirm that? I have specified 100ms and 375ms in my tcclasses
> and when I run "shorewall show tc <device>" I see 0 and 75ms
> respectively, so I do not know what else might have truncated these
> values apart from shorewall? If you know, please do elaborate!
I changed the tcclasses entry to this:
tcclasses:
ba:25 - 500mbit:350ms full 1 default
And the compiler emits this command (which you can find by looking at
the /var/lib/shorewall/firewall file after a successful start/restart or
compile command).
tc class add dev ifb0 parent ba:1 classid ba:25 hfsc sc umax
${ifb0_mtu}b dmax 350ms rate 500000kbit ul rate 1000000kbit
----------
>
>>> 5. Not a bug, just a query: When I have not specified umax
shorewall/tc assumes some spectacularly wrong values - I had anything
ranging from 2500b to 20000b! Why is that and how can this be corrected?
>>
>> Why do you believe that Shorewall is supplying this value? Have
>> you generated a script that includes this 'spectacularly wrong' value'?
>>
> I have no idea who specifies what as I am not intimately involved with
> the development of shorewall to know its internal routines and
> peculiarities. The classes in question have no specific dmax and umax
> values set (though the bandwidth available to them is quite a lot I have
> to admit) so when I look at these with "shorewall show tc <device>" I
> see them as they appear on my screen. As I pointed out above, they
> differ very wildly. Why is that? I have always assumed that if umax is
> not specified the default value would be taken from the MTU value of the
> device this class relates to, but, evidently, this is not the case here
> and I wonder why that is?
I had originally mis-read your post and thought that it was dmax that
was not supplied. Shorewall does supply the mtu as umax if it is
omitted. From the above tcclass, the actual command executed is:
tc class add dev ifb0 parent ba:1 classid ba:25 hfsc sc umax 1500b dmax
----------
350ms rate 500000kbit ul rate 1000000kbit
You can see what 'tc class add' commands Shorewall is executing by:
/var/lib/shorewall/firewall trace restart 2> trace
fgrep 'class add' trace
-Tom
--
Tom Eastep \ When I die, I want to go like my Grandfather who
Shoreline, \ died peacefully in his sleep. Not screaming like
Washington, USA \ all of the passengers in his car
http://shorewall.net \________________________________________________
diff --git a/Shorewall/Perl/Shorewall/Tc.pm b/Shorewall/Perl/Shorewall/Tc.pm
index f2dfb7a..cfee6a6 100644
--- a/Shorewall/Perl/Shorewall/Tc.pm
+++ b/Shorewall/Perl/Shorewall/Tc.pm
@@ -863,6 +863,7 @@ sub validate_tc_class( ) {
$dmax = convert_delay( $dmax );
$umax = convert_size( $umax );
fatal_error "DMAX must be specified when UMAX is specified" if $umax && ! $dmax;
+ $parentclass ||= 1;
} else {
$rate = convert_rate ( $ratemax, $rate, 'RATE' , $ratename );
}
@@ -1022,6 +1023,8 @@ sub process_tc_filter() {
return;
}
+ my $have_rule = 0;
+
if ( $devref->{physical} ne $lastdevice ) {
if ( $lastdevice ) {
pop_indent;
@@ -1038,11 +1041,13 @@ sub process_tc_filter() {
if ( $source ne '-' ) {
my ( $net , $mask ) = decompose_net( $source );
$rule .= "\\\n match $ip32 src $net/$mask";
+ $have_rule = 1;
}
if ( $dest ne '-' ) {
my ( $net , $mask ) = decompose_net( $dest );
$rule .= "\\\n match $ip32 dst $net/$mask";
+ $have_rule = 1;
}
if ( $tos ne '-' ) {
@@ -1061,6 +1066,7 @@ sub process_tc_filter() {
}
$rule .= "\\\n match $ip32 tos $tosval $mask";
+ $have_rule = 1;
}
if ( $length ne '-' ) {
@@ -1068,6 +1074,7 @@ sub process_tc_filter() {
my $mask = $validlengths{$len};
fatal_error "Invalid LENGTH ($length)" unless $mask;
$rule .="\\\n match u16 0x0000 $mask at $lo";
+ $have_rule = 1;
}
my $protonumber = 0;
@@ -1075,13 +1082,20 @@ sub process_tc_filter() {
unless ( $proto eq '-' ) {
$protonumber = resolve_proto $proto;
fatal_error "Unknown PROTO ($proto)" unless defined $protonumber;
- $rule .= "\\\n match $ip32 protocol $protonumber 0xff" if $protonumber;
+ if ( $protonumber ) {
+ $rule .= "\\\n match $ip32 protocol $protonumber 0xff";
+ $have_rule = 1;
+ }
}
if ( $portlist eq '-' && $sportlist eq '-' ) {
- emit( "\nrun_tc $rule\\" ,
- " flowid $devnum:$class" ,
- '' );
+ if ( $have_rule ) {
+ emit( "\nrun_tc $rule\\" ,
+ " flowid $devnum:$class" ,
+ '' );
+ } else {
+ warning_message "Degenerate tcfilter ignored";
+ }
} else {
fatal_error "Ports may not be specified without a PROTO" unless $protonumber;
our $lastrule;
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
