On 12/1/12 9:32 AM, Mr Dash Four wrote:
> I've just finished testing this release and found the following issues:
>
> 1. Actions/SWITCH naming conventions
>
> actions
> ~~~~~~~
> C_ACTION inline
> fw2net # this action is not inline!
>
> action.fw2net
> ~~~~~~~~~~~~~
> LOG:info ; switch:${0}_action
>
> action.C_ACTION
> ~~~~~~~~~~~~~~~
> LOG:info ; switch:${0}_c_action
You are using ${0} -- if you use @{0} then it works (but you will need
to wait until RC 1; in Beta3, just use @).
Within a SWITCH, @{0} (@ in Beta 3) expands to the name of the current
chain with non-alphanumeric characters except '_' and '-' suppressed.
${0} always expands to the full name of the chain.
>
> rules
> ~~~~~
> fw2net $FW net
>
> results in "ERROR: Invalid switch name (%fw2net_action)" message
>
> Further to this, if I add the following:
>
> blrules
> ~~~~~~~
> C_ACTION:info all all
>
> I get "ERROR: Invalid switch name (fw2net~_c_action)"
Same issue.
>
> 2. action.template needs to be updated to include the SWITCH column
Updated; thanks
>
> 3. Action circular reference undetected and/or error message displayed
> incomplete/wrong:
>
> action.circ1
> ~~~~~~~~~~~~
> $1
>
> rules
> ~~~~~
> circ1(circ1):info $FW net
>
> Gets me "ERROR: Undefined parameter ($1)"
You are not getting far enough for the recursion to be discovered. If
you change:
action.circ1
^^^^^^^^^^^^
$1($1)
Then you get
ERROR: Action circ1 invoked Recursively
(circ1(circ1):info->circ1(circ1):info)
The way you have coded the action, you are invoking circ1 with no
parameters; as a result, expansion of $1 fails in the pre-processor.
>
> Also:
>
> action.circ2
> ~~~~~~~~~~~~
> circ1
>
> rules
> ~~~~~
> circ1(circ2):info $FW net
>
> Gets me "ERROR: Undefined parameter ($1)"
Again, you are invoking circ1 without an argument.
>
> When I have action.circ2 the same as action.circ1 as well as:
>
> rules
> ~~~~~
> circ1(circ2(circ1)):info $FW net
>
> The message is "ERROR: Invalid Action (%1:info) in inline action" (when
> any of the 2 actions are inline) or "ERROR: Unknown ACTION (%1)" if not.
>
> All of the above messages should have given me circular reference error,
> like when I reference the actions directly, i.e. something like "ERROR:
> Action circ2 invoked Recursively
> (circ1(circ2):info->circ2:info->circ1:info->circ2:info)" or like the
> message I am getting when both actions are set as 'inline':
> "ERROR: Macro/Inline invocations nested too deeply
> /etc/shorewall/action.circ2"
Again, if the body of the two actions is
$1($1)
then the error message is:
ERROR: Action circ1 invoked Recursively
(circ1(circ1):info->circ1(circ1):info) /home/teastep/shorewall
/regressionLibrary/4.5.10/inline2/action.circ1 (line 1)
from /home/teastep/shorewall/regressionLibrary/4.5.10/inline2
/rules (line 46)
Given that variable expansion is done in the pre-processor which has no
knowledge of the context, there isn't much I can do about this.
>
> 4. Further to the "forbidden or not" discussion earlier, I am not sure
> whether the above can be considered a bug, but, at the very least, there
> seems to be inconsistency in reporting of errors/allowing inlined
> actions. The following actions appear on the "forbidden" list, but are
> allowed in for invocation inline: Broadcast*, Invalid, RST and TCPFlags*
>
> In case where DropSmurfs is used inline, the error I am getting is
> "ERROR: Bareword "IPv6_MULTICAST" not allowed while "strict subs" in use
> at /usr/share/shorewall/action.DropSmurfs line 80" instead of the
> "ERROR: Invalid Action (XXX) in inline action"
>
> * - This invocation is translated to a straight jump (-j <action_name>)
> - inline - instead of emitting an error message.
This is a non-issue now that 'inline' is ignored for these actions.
>
> 5. Minor issue, which could be improved upon as far as optimisation of
> inline actions goes:
>
> rules
> ~~~~~
> circ1(dropBcast) $FW net
> dropBcast $FW net
>
> generates something like:
>
> :~comb2 [0:0]
> [...]
> -A fw2net -j ~comb2
> -A fw2net -j ~comb2
> [...]
> -A ~comb2 -m addrtype --dst-type BROADCAST -j DROP
> -A ~comb2 -d 224.0.0.0/4 -j DROP
>
> Both statements for "-A fw2net ..." above should have been combined into
> a single one.
Doesn't setting OPTIMIZE=31 remove the duplicate rule?
>
> Finally, two suggestions:
>
> 1. I don't seem to be able to invoke action with parameters *and* log
> level specified as action parameter. In other words, something like:
> "circ1(circ2(whatever):debug):info". It would be nice to have that ability.
>
> 2. Having looked at "Creating an Action using an Extension Script"
> (http://shorewall.net/Actions.html), it would be nice if $level and $tag
> are added to the "system parameters" passed to user-defined actions
> ($chainref is already present there as $0). If that is possible, then
> the @{XX} notation is definitely going to be needed.
>
I'll add these to the list of things to look at for 4.5.11.
Regards,
-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 \________________________________________________
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Keep yourself connected to Go Parallel: INSIGHTS What's next for parallel hardware, programming and related areas? Interviews and blogs by thought leaders keep you ahead of the curve. http://goparallel.sourceforge.net
_______________________________________________ Shorewall-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-devel
