I''ve been able to work on Shorewall in the evenings and have uploaded
4.5.13 RC 3. I believe that it addresses all of the issues that testers
have identified in RC 2.
Changes since RC 2:
1) The syntax error in action.Untracked has been corrected.
2) A number of corrections have been made in suppressing unmatchable
rules.
3) Superfluous cruft was removed from action.New and action.Untracked.
4) Rules in the NEW section that are conditioned by a connection
tracking state are no longer suppressed when there is a RETURN in
the state''s corresponding SECTION.
5) The ''-g'' iptables option is avoided when generating
SECTION-ending
rules.
6) The legacy ''dropInvalid'' and
''allowInvalid'' built-in actions have
been converted to inline standard actions that invoke the Invalid
action.
Thank you for testing,
-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 \________________________________________________
------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
> I''ve been able to work on Shorewall in the evenings and have uploaded > 4.5.13 RC 3. I believe that it addresses all of the issues that testers > have identified in RC 2. >I''ll give it all another go later today (Saturday) or in the early part of Sunday and report back then.> Changes since RC 2: > > 1) The syntax error in action.Untracked has been corrected. > > 2) A number of corrections have been made in suppressing unmatchable > rules. > > 3) Superfluous cruft was removed from action.New and action.Untracked. > > 4) Rules in the NEW section that are conditioned by a connection > tracking state are no longer suppressed when there is a RETURN in > the state''s corresponding SECTION. > > 5) The ''-g'' iptables option is avoided when generating SECTION-ending > rules. > > 6) The legacy ''dropInvalid'' and ''allowInvalid'' built-in actions have > been converted to inline standard actions that invoke the Invalid > action. >I take it, ESTABLISHED isn''t optimised (in other words, things are the same as before), is that correct?> Thank you for testing, >One suggestion on your todo list if/when you have the time: Suppose I have this: action1 with, say, 2 parameters which in turn calls action2 with the same number of parameters. In other words: action1 ~~~~~ action2($1,$2) As things stand, if I execute action1(-,something), the first parameter doesn''t have a value (and rightly so), but that in effect screws up the action2 call. So, what I currently have to do is this: action1 ~~~~~ IF $1 ?SET p1 $1 ?ELSE ?SET p1 "-" ?ENDIF IF $2 ?SET p2 $2 ?ELSE ?SET p2 "-" ?ENDIF action2($p1,$p2) The above isn''t very nice. Perhaps you may thing of allowing a call like "action2(,something) (first parameter is not specified) to avoid this - just a suggestion. ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb
On 02/08/2013 07:18 PM, Mr Dash Four wrote:> >> I''ve been able to work on Shorewall in the evenings and have uploaded >> 4.5.13 RC 3. I believe that it addresses all of the issues that testers >> have identified in RC 2. >> > I''ll give it all another go later today (Saturday) or in the early part > of Sunday and report back then.Thanks.>> >> 6) The legacy ''dropInvalid'' and ''allowInvalid'' built-in actions have >> been converted to inline standard actions that invoke the Invalid >> action. >> > I take it, ESTABLISHED isn''t optimised (in other words, things are the > same as before), is that correct?Yes.> >> Thank you for testing, >> > One suggestion on your todo list if/when you have the time: > > Suppose I have this: action1 with, say, 2 parameters which in turn calls > action2 with the same number of parameters. In other words: > > action1 > ~~~~~ > action2($1,$2) > > As things stand, if I execute action1(-,something), the first parameter > doesn''t have a value (and rightly so), but that in effect screws up the > action2 call. So, what I currently have to do is this: > > action1 > ~~~~~ > IF $1 > ?SET p1 $1 > ?ELSE > ?SET p1 "-" > ?ENDIF > IF $2 > ?SET p2 $2 > ?ELSE > ?SET p2 "-" > ?ENDIF > action2($p1,$p2) > > The above isn''t very nice. Perhaps you may thing of allowing a call like > "action2(,something) (first parameter is not specified) to avoid this - > just a suggestion.Why don''t you simply use the ''DEFAULTS'' feature in action2? -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 \________________________________________________ ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb
On 02/08/2013 08:08 PM, Tom Eastep wrote:>> One suggestion on your todo list if/when you have the time: >> >> Suppose I have this: action1 with, say, 2 parameters which in turn calls >> action2 with the same number of parameters. In other words: >> >> action1 >> ~~~~~ >> action2($1,$2) >> >> As things stand, if I execute action1(-,something), the first parameter >> doesn''t have a value (and rightly so), but that in effect screws up the >> action2 call. So, what I currently have to do is this: >> >> action1 >> ~~~~~ >> IF $1 >> ?SET p1 $1 >> ?ELSE >> ?SET p1 "-" >> ?ENDIF >> IF $2 >> ?SET p2 $2 >> ?ELSE >> ?SET p2 "-" >> ?ENDIF >> action2($p1,$p2) >> >> The above isn''t very nice. Perhaps you may thing of allowing a call like >> "action2(,something) (first parameter is not specified) to avoid this - >> just a suggestion. > > Why don''t you simply use the ''DEFAULTS'' feature in action2?Don''t mind that. Rather: ?set $p1 $1 ? $1 : ''-'' ?set $p2 $2 ? $2 : ''-'' action2( $p1, $p2 ) Still not perfect but simpler than what you suggested. -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 \________________________________________________ ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb
On 02/08/2013 08:23 PM, Tom Eastep wrote:> On 02/08/2013 08:08 PM, Tom Eastep wrote: > >>> One suggestion on your todo list if/when you have the time: >>> >>> Suppose I have this: action1 with, say, 2 parameters which in turn calls >>> action2 with the same number of parameters. In other words: >>> >>> action1 >>> ~~~~~ >>> action2($1,$2) >>> >>> As things stand, if I execute action1(-,something), the first parameter >>> doesn''t have a value (and rightly so), but that in effect screws up the >>> action2 call. So, what I currently have to do is this: >>> >>> action1 >>> ~~~~~ >>> IF $1 >>> ?SET p1 $1 >>> ?ELSE >>> ?SET p1 "-" >>> ?ENDIF >>> IF $2 >>> ?SET p2 $2 >>> ?ELSE >>> ?SET p2 "-" >>> ?ENDIF >>> action2($p1,$p2) >>> >>> The above isn''t very nice. Perhaps you may thing of allowing a call like >>> "action2(,something) (first parameter is not specified) to avoid this - >>> just a suggestion. >> >> Why don''t you simply use the ''DEFAULTS'' feature in action2? > > Don''t mind that. > > Rather: > > ?set $p1 $1 ? $1 : ''-'' > ?set $p2 $2 ? $2 : ''-'' > action2( $p1, $p2 ) > > Still not perfect but simpler than what you suggested.Patch attached -- it allows parameters to be omitted in action invocations. -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 \________________________________________________ ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb
> Patch attached -- it allows parameters to be omitted in action invocations.Yep, that now works, thanks! ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb
On 2/8/13 8:08 PM, "Tom Eastep" <teastep@shorewall.net> wrote:>On 02/08/2013 07:18 PM, Mr Dash Four wrote: >> I take it, ESTABLISHED isn''t optimised (in other words, things are the >> same as before), is that correct? > >Yes.I have that working but I''m going to hold the change until 4.5.14, so that folks that have tested satisfactorily on RC 3 don''t have to re-test. -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb
> I have that working but I''m going to hold the change until 4.5.14, so that > folks that have tested satisfactorily on RC 3 don''t have to re-test.No problem. ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb
> Thank you for testing,OK, I''ve tried to test-run this on another machine where I get this internal error: shorewall[824]: Compiling MAC Filtration -- Phase 2... shorewall[824]: Applying Policies... shorewall[824]: ERROR: Internal error in Shorewall::Rules::createactionchain at /usr/share/perl5/Shorewall/Rules.pm line 1246 at /usr/share/perl5/Shorewall/Config.pm line 1215 shorewall[824]: #011Shorewall::Config::fatal_error(''Internal error in Shorewall::Rules::createactionchain at /usr...'') called at /usr/share/perl5/Shorewall/Config.pm line 1255 shorewall[824]: #011Shorewall::Config::assert('''') called at /usr/share/perl5/Shorewall/Rules.pm line 1246 shorewall[824]: #011Shorewall::Rules::createactionchain(''ELOG(-,1,2,-,Drop)'') called at /usr/share/perl5/Shorewall/Rules.pm line 1267 shorewall[824]: #011Shorewall::Rules::use_action(''ELOG(-,1,2,-,Drop)'') called at /usr/share/perl5/Shorewall/Rules.pm line 1764 shorewall[824]: #011Shorewall::Rules::use_policy_action(''ELOG(-,1,2,-,Drop)'', ''fw2net'') called at /usr/share/perl5/Shorewall/Rules.pm line 707 shorewall[824]: #011Shorewall::Rules::policy_rules(''HASH(0x8b770c8)'', ''DROP'', '''', ''ELOG(-,1,2,-,Drop)'', '''') called at /usr/share/perl5/Shorewall/Rules.pm line 736 shorewall[824]: #011Shorewall::Rules::default_policy(''HASH(0x8b770c8)'', ''fw'', ''net'') called at /usr/share/perl5/Shorewall/Rules.pm line 810 shorewall[824]: #011Shorewall::Rules::apply_policy_rules() called at /usr/share/perl5/Shorewall/Compiler.pm line 839 shorewall[824]: #011Shorewall::Compiler::compiler(''script'', ''/var/lib/shorewall/.start'', ''directory'', ''/etc/shorewall'', ''verbosity'', 1, ''timestamp'', 0, ''debug'', ...) called at /usr/libexec/shorewall/compiler.pl line 142 logger: ERROR:Shorewall start failed params ~~~~~~ NF_A=1 NF_V=2 NF_ALL="NFLOG(5,0,1)" policy ~~~~~~ $FW net DROP:ELOG(-,$NF_A,$NF_V,-,Drop) [...] all all DROP:ELOG(-,$NF_A,$NF_V,-,Drop) action.ELOG ~~~~~~~~~~~ ?IF $1 ?SET p1 $1 ?ELSE ?SET p1 "-" ?ENDIF ?IF $2 ?SET p2 $2 ?ELSE ?SET p2 "-" ?ENDIF ?IF $3 ?SET p3 $3 ?ELSE ?SET p3 "-" ?ENDIF ?IF $4 ?SET p4 $4 ?ELSE ?SET p4 "-" ?ENDIF ?IF $5 ?SET p5 $5 ?ELSE ?SET p5 "-" ?ENDIF ?IF $6 ?SET p6 $6 ?ELSE ?SET p6 "-" ?ENDIF ALOG($p1,$p2,$p3,$p4,$p5,$p6) ?IF $5 && (! ($5 eq ''Drop'')) $5 ?ENDIF action.ALOG ~~~~~~~~~~~ ?IF $5 ?SET @disposition $5 ?ENDIF ?IF $6 ?SET @chain $6 ?ENDIF ?IF $1 $NF_ALL ?ENDIF ?IF $2 NFLOG($2,0,1) ?ENDIF ?IF $3 NFLOG($3,0,1) ?ENDIF ?IF $4 AUDIT($4) ?ENDIF ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb
>> Rather: >> >> ?set $p1 $1 ? $1 : ''-'' >> ?set $p2 $2 ? $2 : ''-'' >> action2( $p1, $p2 ) >> >> Still not perfect but simpler than what you suggested. > > Patch attached -- it allows parameters to be omitted in action invocations.action1 ~~~~~~~ action2($1,$2,$3,$4) rules ~~~~~ action1(one,two,three) I get: "ERROR: Invalid action parameter ($4) /etc/shorewall/action.action1" ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb
On 2/9/13 6:42 PM, "Mr Dash Four" <mr.dash.four@googlemail.com> wrote:> >>> Rather: >>> >>> ?set $p1 $1 ? $1 : ''-'' >>> ?set $p2 $2 ? $2 : ''-'' >>> action2( $p1, $p2 ) >>> >>> Still not perfect but simpler than what you suggested. >> >> Patch attached -- it allows parameters to be omitted in action >>invocations. >action1 >~~~~~~~ >action2($1,$2,$3,$4) > >rules >~~~~~ >action1(one,two,three) > > >I get: "ERROR: Invalid action parameter ($4) >/etc/shorewall/action.action1"If you don''t pass a parameter to an action, but refer to the parameter in the body then you must specify a default value using a DEFAULTS entry. -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb
>>> Patch attached -- it allows parameters to be omitted in action >>> invocations. >> action1 >> ~~~~~~~ >> action2($1,$2,$3,$4) >> >> rules >> ~~~~~ >> action1(one,two,three) >> >> >> I get: "ERROR: Invalid action parameter ($4) >> /etc/shorewall/action.action1" > > If you don''t pass a parameter to an action, but refer to the parameter in > the body then you must specify a default value using a DEFAULTS entry.I thought the whole point of your patch was that "it allows parameters to be omitted", so by extension, if $4 doesn''t have a value, then the "action2($1,$2,$3,$4)" call should be the equivalent of "action2(one,two,three,)" like it is with any bash variables - if you refer to them and they do not have a value then no value should be assigned/printed. You have a similar arrangement with action variables (IGNOREUNKNOWNVARIABLES), so I don''t see how is this any different. If that cannot be accomplished, then I see little use of your patch to be honest and I may as well revert back to my ?IF ?ELSE ?ENDIF statements I''ve had before and get it over with. ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb
On 2/9/13 7:22 PM, "Mr Dash Four" <mr.dash.four@googlemail.com> wrote:> >>>> Patch attached -- it allows parameters to be omitted in action >>>> invocations. >>> action1 >>> ~~~~~~~ >>> action2($1,$2,$3,$4) >>> >>> rules >>> ~~~~~ >>> action1(one,two,three) >>> >>> >>> I get: "ERROR: Invalid action parameter ($4) >>> /etc/shorewall/action.action1" >> >> If you don''t pass a parameter to an action, but refer to the parameter >>in >> the body then you must specify a default value using a DEFAULTS entry. >I thought the whole point of your patch was that "it allows parameters to >be omitted", so by extension, if $4 doesn''t have a value, then the >"action2($1,$2,$3,$4)" call should be the equivalent of >"action2(one,two,three,)" like it is with any bash variables - if you >refer to them and they do not have a value then no value should be >assigned/printed. You have a similar arrangement with action variables >(IGNOREUNKNOWNVARIABLES), so I don''t see how is this any different. > >If that cannot be accomplished, then I see little use of your patch to be >honest and I may as well revert back to my ?IF ?ELSE ?ENDIF statements >I''ve had before and get it over with.Well, it isn''t happening in 4.5.13. So if you think it is better to code your ?if?else mess than adding a single "DEFAULTS -,-,-,-" at the beginning of action.action1, then that is certainly your choice. But I know what I would choose to do. -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb
>>>>> Patch attached -- it allows parameters to be omitted in action >>>>> invocations. >>>> action1 >>>> ~~~~~~~ >>>> action2($1,$2,$3,$4) >>>> >>>> rules >>>> ~~~~~ >>>> action1(one,two,three) >>>> >>>> >>>> I get: "ERROR: Invalid action parameter ($4) >>>> /etc/shorewall/action.action1" >>> If you don't pass a parameter to an action, but refer to the parameter >>> in >>> the body then you must specify a default value using a DEFAULTS entry. >> I thought the whole point of your patch was that "it allows parameters to >> be omitted", so by extension, if $4 doesn't have a value, then the >> "action2($1,$2,$3,$4)" call should be the equivalent of >> "action2(one,two,three,)" like it is with any bash variables - if you >> refer to them and they do not have a value then no value should be >> assigned/printed. You have a similar arrangement with action variables >> (IGNOREUNKNOWNVARIABLES), so I don't see how is this any different. >> >> If that cannot be accomplished, then I see little use of your patch to be >> honest and I may as well revert back to my ?IF ?ELSE ?ENDIF statements >> I've had before and get it over with. > > Well, it isn't happening in 4.5.13. So if you think it is better to code > your ?ifŠ?else mess than adding a single "DEFAULTS -,-,-,-" at the > beginning of action.action1, then that is certainly your choice. But I > know what I would choose to do.So the patch you offered isn't allowing parameters to be omitted at the end and we are back to square one - glad we've cleared that one up. ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb _______________________________________________ Shorewall-devel mailing list Shorewall-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-devel
On 2/9/13 7:51 PM, "Mr Dash Four" <mr.dash.four@googlemail.com> wrote:> > >>>>>> Patch attached -- it allows parameters to be omitted in action >>>>>> invocations. >>>>> action1 >>>>> ~~~~~~~ >>>>> action2($1,$2,$3,$4) >>>>> >>>>> rules >>>>> ~~~~~ >>>>> action1(one,two,three) >>>>> >>>>> >>>>> I get: "ERROR: Invalid action parameter ($4) >>>>> /etc/shorewall/action.action1" >>>> If you don''t pass a parameter to an action, but refer to the parameter >>>> in >>>> the body then you must specify a default value using a DEFAULTS entry. >>> I thought the whole point of your patch was that "it allows parameters >>>to >>> be omitted", so by extension, if $4 doesn''t have a value, then the >>> "action2($1,$2,$3,$4)" call should be the equivalent of >>> "action2(one,two,three,)" like it is with any bash variables - if you >>> refer to them and they do not have a value then no value should be >>> assigned/printed. You have a similar arrangement with action variables >>> (IGNOREUNKNOWNVARIABLES), so I don''t see how is this any different. >>> >>> If that cannot be accomplished, then I see little use of your patch to >>>be >>> honest and I may as well revert back to my ?IF ?ELSE ?ENDIF statements >>> I''ve had before and get it over with. >> >> Well, it isn''t happening in 4.5.13. So if you think it is better to code >> your ?ifŠ?else mess than adding a single "DEFAULTS -,-,-,-" at the >> beginning of action.action1, then that is certainly your choice. But I >> know what I would choose to do. >So the patch you offered isn''t allowing parameters to be omitted at the >end and we are back to square one - glad we''ve cleared that one up.It does if you change the rules entry to: action1(one,two,three,) Next time you ask for a change late in my release cycle, the answer will clearly be "No!" -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb
On 02/09/2013 08:03 PM, Tom Eastep wrote:>>>> If that cannot be accomplished, then I see little use of your patch to >>>> be >>>> honest and I may as well revert back to my ?IF ?ELSE ?ENDIF statements >>>> I''ve had before and get it over with. >>> >>> Well, it isn''t happening in 4.5.13. So if you think it is better to code >>> your ?ifŠ?else mess than adding a single "DEFAULTS -,-,-,-" at the >>> beginning of action.action1, then that is certainly your choice. But I >>> know what I would choose to do. >> So the patch you offered isn''t allowing parameters to be omitted at the >> end and we are back to square one - glad we''ve cleared that one up. > > It does if you change the rules entry to: > > action1(one,two,three,) > > Next time you ask for a change late in my release cycle, the answer will > clearly be "No!" >Patch attached. When IGNOREUNKNOWNVARIABLES=Yes, you can enter $345698764 if it strikes your fancy. Incidentally, you can enter @345698764 without this patch and the compiler won''t complain. -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 \________________________________________________ ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb
On 2/9/13 5:59 PM, "Mr Dash Four" <mr.dash.four@googlemail.com> wrote:> >> Thank you for testing, > >OK, I''ve tried to test-run this on another machine where I get this >internal error: > >shorewall[824]: Compiling MAC Filtration -- Phase 2... >shorewall[824]: Applying Policies... >shorewall[824]: ERROR: Internal error in >Shorewall::Rules::createactionchain at >/usr/share/perl5/Shorewall/Rules.pm line 1246 at >/usr/share/perl5/Shorewall/Config.pm line 1215 >shorewall[824]: #011Shorewall::Config::fatal_error(''Internal error in >Shorewall::Rules::createactionchain at /usr...'') called at >/usr/share/perl5/Shorewall/Config.pm line 1255 >shorewall[824]: #011Shorewall::Config::assert('''') called at >/usr/share/perl5/Shorewall/Rules.pm line 1246 >shorewall[824]: >#011Shorewall::Rules::createactionchain(''ELOG(-,1,2,-,Drop)'') called at >/usr/share/perl5/Shorewall/Rules.pm line 1267 >shorewall[824]: #011Shorewall::Rules::use_action(''ELOG(-,1,2,-,Drop)'') >called at /usr/share/perl5/Shorewall/Rules.pm line 1764 >shorewall[824]: >#011Shorewall::Rules::use_policy_action(''ELOG(-,1,2,-,Drop)'', ''fw2net'') >called at /usr/share/perl5/Shorewall/Rules.pm line 707 >shorewall[824]: #011Shorewall::Rules::policy_rules(''HASH(0x8b770c8)'', >''DROP'', '''', ''ELOG(-,1,2,-,Drop)'', '''') called at >/usr/share/perl5/Shorewall/Rules.pm line 736 >shorewall[824]: #011Shorewall::Rules::default_policy(''HASH(0x8b770c8)'', >''fw'', ''net'') called at /usr/share/perl5/Shorewall/Rules.pm line 810 >shorewall[824]: #011Shorewall::Rules::apply_policy_rules() called at >/usr/share/perl5/Shorewall/Compiler.pm line 839 >shorewall[824]: #011Shorewall::Compiler::compiler(''script'', >''/var/lib/shorewall/.start'', ''directory'', ''/etc/shorewall'', ''verbosity'', >1, ''timestamp'', 0, ''debug'', ...) called at >/usr/libexec/shorewall/compiler.pl line 142 >logger: ERROR:Shorewall start failedI don''t understand what is going on on your system. If I recreate your test configuration and set a breakpoint at Shorewall::Rules::use_policy_action, I see this stack trace: DB<2> T $ = Shorewall::Rules::use_policy_action(''ELOG:none::-,1,2,-,Drop'', ''fw2loc'') called from file `/usr/share/shorewall/Shorewall/Rules.pm'' line 707 . = Shorewall::Rules::policy_rules(ref(HASH), ''DROP'', '''', ''ELOG:none::-,1,2,-,Drop'', '''') called from file `/usr/share/shorewall/Shorewall/Rules.pm'' line 737 . = Shorewall::Rules::default_policy(ref(HASH), ''fw'', ''net'') called from file `/usr/share/shorewall/Shorewall/Rules.pm'' line 810 . = Shorewall::Rules::apply_policy_rules() called from file `/usr/share/shorewall/Shorewall/Compiler.pm'' line 839 . = Shorewall::Compiler::compiler(''script'', '''', ''directory'', ''/home/teastep/shorewall/regressionLibrary/4.5.13/defaultaction/'', ''verbosity'', 1, ''timestamp'', 0, ''debug'', 0, ''export'', 0, ''chains'', '':none:'', ''log'', '''', ''log_verbosity'', -1, ''test'', 0, ''preview'', 1, ''family'', 4, ''confess'', 0, ''update'', 0, ''convert'', 0, ''annotate'', 0, ''directives'', 0, ''config_path'', ''/home/teastep/shorewall/regressionLibrary/4.5.13/defaultaction/:/u... called from file `/usr/share/shorewall/compiler.pl'' line 142 DB<2> Note the difference in the first argument to use_policy_action. In your case, it is the raw action specified in your policy file; in my case, it has been normalized into <action>:<loglevel>:<tag>:<parameters>. The latter is what use_policy_action is expecting. The normalization should have occurred when the policy file was processed. Are you specifying any options for ELOG in /etc/shorewall/actions? -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb
On Sunday 10 Feb 2013 16:26:38 Tom Eastep wrote:> On 2/9/13 5:59 PM, "Mr Dash Four" <mr.dash.four@googlemail.com> wrote: > >> Thank you for testing, > > > >OK, I''ve tried to test-run this on another machine where I get this > >internal error: > > > >shorewall[824]: Compiling MAC Filtration -- Phase 2... > >shorewall[824]: Applying Policies... > >shorewall[824]: ERROR: Internal error in > >Shorewall::Rules::createactionchain at > >/usr/share/perl5/Shorewall/Rules.pm line 1246 at > >/usr/share/perl5/Shorewall/Config.pm line 1215 > >shorewall[824]: #011Shorewall::Config::fatal_error(''Internal error in > >Shorewall::Rules::createactionchain at /usr...'') called at > >/usr/share/perl5/Shorewall/Config.pm line 1255 > >shorewall[824]: #011Shorewall::Config::assert('''') called at > >/usr/share/perl5/Shorewall/Rules.pm line 1246 > >shorewall[824]: > >#011Shorewall::Rules::createactionchain(''ELOG(-,1,2,-,Drop)'') called at > >/usr/share/perl5/Shorewall/Rules.pm line 1267 > >shorewall[824]: #011Shorewall::Rules::use_action(''ELOG(-,1,2,-,Drop)'') > >called at /usr/share/perl5/Shorewall/Rules.pm line 1764 > >shorewall[824]: > >#011Shorewall::Rules::use_policy_action(''ELOG(-,1,2,-,Drop)'', ''fw2net'') > >called at /usr/share/perl5/Shorewall/Rules.pm line 707 > >shorewall[824]: #011Shorewall::Rules::policy_rules(''HASH(0x8b770c8)'', > >''DROP'', '''', ''ELOG(-,1,2,-,Drop)'', '''') called at > >/usr/share/perl5/Shorewall/Rules.pm line 736 > >shorewall[824]: #011Shorewall::Rules::default_policy(''HASH(0x8b770c8)'', > >''fw'', ''net'') called at /usr/share/perl5/Shorewall/Rules.pm line 810 > >shorewall[824]: #011Shorewall::Rules::apply_policy_rules() called at > >/usr/share/perl5/Shorewall/Compiler.pm line 839 > >shorewall[824]: #011Shorewall::Compiler::compiler(''script'', > >''/var/lib/shorewall/.start'', ''directory'', ''/etc/shorewall'', ''verbosity'', > >1, ''timestamp'', 0, ''debug'', ...) called at > >/usr/libexec/shorewall/compiler.pl line 142 > >logger: ERROR:Shorewall start failed > > I don''t understand what is going on on your system. > > If I recreate your test configuration and set a breakpoint at > Shorewall::Rules::use_policy_action, I see this stack trace: > > DB<2> T > $ = Shorewall::Rules::use_policy_action(''ELOG:none::-,1,2,-,Drop'', > ''fw2loc'') called from file `/usr/share/shorewall/Shorewall/Rules.pm'' line > 707 > . = Shorewall::Rules::policy_rules(ref(HASH), ''DROP'', '''', > ''ELOG:none::-,1,2,-,Drop'', '''') called from file > `/usr/share/shorewall/Shorewall/Rules.pm'' line 737 > . = Shorewall::Rules::default_policy(ref(HASH), ''fw'', ''net'') called from > file `/usr/share/shorewall/Shorewall/Rules.pm'' line 810 > . = Shorewall::Rules::apply_policy_rules() called from file > `/usr/share/shorewall/Shorewall/Compiler.pm'' line 839 > . = Shorewall::Compiler::compiler(''script'', '''', ''directory'', > ''/home/teastep/shorewall/regressionLibrary/4.5.13/defaultaction/'', > ''verbosity'', 1, ''timestamp'', 0, ''debug'', 0, ''export'', 0, ''chains'', > '':none:'', ''log'', '''', ''log_verbosity'', -1, ''test'', 0, ''preview'', 1, > ''family'', 4, ''confess'', 0, ''update'', 0, ''convert'', 0, ''annotate'', 0, > ''directives'', 0, ''config_path'', > ''/home/teastep/shorewall/regressionLibrary/4.5.13/defaultaction/:/u... > called from file `/usr/share/shorewall/compiler.pl'' line 142 > DB<2> > > Note the difference in the first argument to use_policy_action. In your > case, it is the raw action specified in your policy file; in my case, it > has been normalized into <action>:<loglevel>:<tag>:<parameters>. The > latter is what use_policy_action is expecting. The normalization should > have occurred when the policy file was processed. > > > Are you specifying any options for ELOG in /etc/shorewall/actions? >Tom I have recreated the problem in the attached config: Steven. ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb
On 02/10/2013 08:35 AM, Steven Jan Springl wrote:> > I have recreated the problem in the attached config: >Thank you Steven. Patch attached. -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 \________________________________________________ ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb
> action.ELOG > ~~~~~~~~~~~ > ?IF $1 > ?SET p1 $1 > ?ELSE > ?SET p1 "-" > ?ENDIF > ?IF $2 > ?SET p2 $2 > ?ELSE > ?SET p2 "-" > ?ENDIF > ?IF $3 > ?SET p3 $3 > ?ELSE > ?SET p3 "-" > ?ENDIF > ?IF $4 > ?SET p4 $4 > ?ELSE > ?SET p4 "-" > ?ENDIF > ?IF $5 > ?SET p5 $5 > ?ELSE > ?SET p5 "-" > ?ENDIF > ?IF $6 > ?SET p6 $6 > ?ELSE > ?SET p6 "-" > ?ENDIF > ALOG($p1,$p2,$p3,$p4,$p5,$p6) > ?IF $5 && (! ($5 eq ''Drop'')) > $5 > ?ENDIF >At the beginning of action.ELOG I have missed this bit: ?IF $5 eq ''Drop'' $5 ?ENDIF In other words, "Drop", if specified as the 5th parameter, gets executed first before anything else (thus preventing clutter in the subsequent log statements). I suspect it won''t make any difference to the outcome, but still... ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb
On 02/10/2013 09:03 AM, Mr Dash Four wrote:> At the beginning of action.ELOG I have missed this bit: > > ?IF $5 eq ''Drop'' > $5 > ?ENDIF > > In other words, "Drop", if specified as the 5th parameter, gets executed > first before anything else (thus preventing clutter in the subsequent > log statements). I suspect it won''t make any difference to the outcome, > but still...Please confirm that ELOG is ''inline''. If so, the patch that I just posted should correct this. -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 \________________________________________________ ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb
> Please confirm that ELOG is ''inline''. If so, the patch that I just > posted should correct this. >It is and it does - I''ve just tested it on the remote machine. ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb
On Sunday 10 Feb 2013 16:57:27 Tom Eastep wrote:> On 02/10/2013 08:35 AM, Steven Jan Springl wrote: > > I have recreated the problem in the attached config: > Thank you Steven. > > Patch attached. > > -TomTom Confirmed, the patch fixes the issue. Thanks. Steven. ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb
On 02/10/2013 09:13 AM, Mr Dash Four wrote:> >> Please confirm that ELOG is ''inline''. If so, the patch that I just >> posted should correct this. >> > It is and it does - I''ve just tested it on the remote machine. >Thanks. -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 \________________________________________________ ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb
> Patch attached. When IGNOREUNKNOWNVARIABLES=Yes, you can enter > $345698764 if it strikes your fancy. > > Incidentally, you can enter @345698764 without this patch and the > compiler won''t complain. >That one works too. I did, however, find another optimisation-related issue (very similar to the single-rule blacklist chain) - let me know if you wish to fix it in this release so that I could prepare a small test case, or if this is going to wait until .14? ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb
On 02/10/2013 09:15 AM, Steven Jan Springl wrote:> > Confirmed, the patch fixes the issue. >Thanks, Steven -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 \________________________________________________ ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb
On 02/10/2013 09:24 AM, Mr Dash Four wrote:> >> Patch attached. When IGNOREUNKNOWNVARIABLES=Yes, you can enter >> $345698764 if it strikes your fancy. >> >> Incidentally, you can enter @345698764 without this patch and the >> compiler won''t complain. >> > That one works too. I did, however, find another optimisation-related > issue (very similar to the single-rule blacklist chain) - let me know if > you wish to fix it in this release so that I could prepare a small test > case, or if this is going to wait until .14?Please send me a test case. If the fix is simple enough, I can include it in this release. Thanks, -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 \________________________________________________ ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb
> Please send me a test case. If the fix is simple enough, I can include > it in this release. >rules ~~~~~ SECTION RELATED ESLOG(log,-,-,-,ACCEPT,-,log_ssh_related=0) $FW net:+ssh-local-hosts action.ESLOG ~~~~~~~~~~~~~~ ?IF $5 eq ''Drop'' $5 ?ENDIF ?IF $6 ?SET p6 $6 ?ELSE ?SET p6 @{chain} ?ENDIF ALOG($1,$2,$3,$4,$5,$p6) ; switch:${p6}_${7} ?IF $5 && (! ($5 eq ''Drop'')) $5 ?ENDIF action.ALOG ~~~~~~~~~~~~~~ ?IF $5 ?SET @disposition $5 ?ENDIF ?IF $6 ?SET @chain $6 ?ENDIF ?IF $1 LOG:$LOG_OPTIONS ?ENDIF ?IF $2 NFLOG($2,0,1) ?ENDIF ?IF $3 NFLOG($3,0,1) ?ENDIF ?IF $4 AUDIT($4) ?ENDIF produces: :%ALOG10 - [0:0] [...] -A %ALOG10 -j LOG --log-tcp-options --log-ip-options --log-macdecode --log-tcp-sequence --log-uid --log-level 6 --log-prefix "Shorewall:fw2net:ACCEPT:" [...] -A +fw2net -m condition --condition fw2net_log_ssh_related -m set --match-set ssh-local-hosts dst -j %ALOG10 This can be optimised to: -A +fw2net -m condition --condition fw2net_log_ssh_related -m set --match-set ssh-local-hosts dst -j LOG --log-tcp-options --log-ip-options --log-macdecode --log-tcp-sequence --log-uid --log-level 6 --log-prefix "Shorewall:fw2net:ACCEPT:" and the whole %ALOG10 chain (plus the additional jump to it) wiped out. ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb
> This can be optimised to: > > -A +fw2net -m condition --condition fw2net_log_ssh_related -m set > --match-set ssh-local-hosts dst -j LOG --log-tcp-options > --log-ip-options --log-macdecode --log-tcp-sequence --log-uid > --log-level 6 --log-prefix "Shorewall:fw2net:ACCEPT:" > > and the whole %ALOG10 chain (plus the additional jump to it) wiped out.Please ignore this - I just realised that ALOG is not inline... ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb
On 02/10/2013 09:38 AM, Mr Dash Four wrote:> >> Please send me a test case. If the fix is simple enough, I can include >> it in this release. >> > rules > ~~~~~ > SECTION RELATED > ESLOG(log,-,-,-,ACCEPT,-,log_ssh_related=0) $FW net:+ssh-local-hosts > > action.ESLOG > ~~~~~~~~~~~~~~ > ?IF $5 eq ''Drop'' > $5 > ?ENDIF > ?IF $6 > ?SET p6 $6 > ?ELSE > ?SET p6 @{chain} > ?ENDIF > ALOG($1,$2,$3,$4,$5,$p6) ; switch:${p6}_${7} > ?IF $5 && (! ($5 eq ''Drop'')) > $5 > ?ENDIF > > action.ALOG > ~~~~~~~~~~~~~~ > ?IF $5 > ?SET @disposition $5 > ?ENDIF > ?IF $6 > ?SET @chain $6 > ?ENDIF > ?IF $1 > LOG:$LOG_OPTIONS > ?ENDIF > ?IF $2 > NFLOG($2,0,1) > ?ENDIF > ?IF $3 > NFLOG($3,0,1) > ?ENDIF > ?IF $4 > AUDIT($4) > ?ENDIF > > produces: > > :%ALOG10 - [0:0] > [...] > -A %ALOG10 -j LOG --log-tcp-options --log-ip-options --log-macdecode > --log-tcp-sequence --log-uid --log-level 6 --log-prefix > "Shorewall:fw2net:ACCEPT:" > [...] > -A +fw2net -m condition --condition fw2net_log_ssh_related -m set > --match-set ssh-local-hosts dst -j %ALOG10 > > This can be optimised to: > > -A +fw2net -m condition --condition fw2net_log_ssh_related -m set > --match-set ssh-local-hosts dst -j LOG --log-tcp-options > --log-ip-options --log-macdecode --log-tcp-sequence --log-uid > --log-level 6 --log-prefix "Shorewall:fw2net:ACCEPT:" > > and the whole %ALOG10 chain (plus the additional jump to it) wiped out.The compiler has historically set the ''DONT_OPTIMIZE'' flag on non-inline action chains. This prevents that sort of optimization. -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 \________________________________________________ ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb
> The compiler has historically set the ''DONT_OPTIMIZE'' flag on non-inline > action chains. This prevents that sort of optimization. >I am trying to do that optimisation from the calling action (ELOG) since I have access to all the parameters and can determine whether the action to be executed will have signel or multiple statements. If I see that there will be only one statement (as was with the case posted previously) I call ALOG''s inline equivalent - IALOG (both action.ALOG and action.IALOG are the same - symlinked on the file system), but I am struggling with two things: 1. How do I use arithmetic operations on variables? Doing the following: ?SET one 1 ?SET two 2 ?SET sum @{one} + @{two} doesn''t get me anywhere (I get ''Argument "" isn''t numeric in addition (+)'' message). 2. Similar to 1 above - how do I use logical operations on variables? Doing the following: ?SET one 1 ?SET two ?SET logical_or @{one} | @{two} is simply ignored by shorewall (same goes if I apply logical and - "@{one} & @{two}"). ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb
> I am trying to do that optimisation from the calling action (ELOG) > since I have access to all the parameters and can determine whether > the action to be executed will have signel or multiple statements. If > I see that there will be only one statement (as was with the case > posted previously) I call ALOG''s inline equivalent - IALOG (both > action.ALOG and action.IALOG are the same - symlinked on the file > system), but I am struggling with two things: > > 1. How do I use arithmetic operations on variables? Doing the following: > > ?SET one 1 > ?SET two 2 > ?SET sum @{one} + @{two} > > doesn''t get me anywhere (I get ''Argument "" isn''t numeric in addition > (+)'' message). > > 2. Similar to 1 above - how do I use logical operations on variables? > Doing the following: > > ?SET one 1 > ?SET two > ?SET logical_or @{one} | @{two} > > is simply ignored by shorewall (same goes if I apply logical and - > "@{one} & @{two}"). >From http://www.shorewall.net/configuration_file_basics.htm#Conditional:"Beginning with Shorewall 4.5.6, rather than a simple variable in ?IF directives, Perl-compatible expressions are allowed (after the Shorewall compiler expands all variables, the resulting expression is then evaluated by Perl). Variables in the expressions are as described above.". So, according to this, if I have something like: ?SET c1 1 ?SET c2 1 ?IF @c1 + @c2 > 1 [...] ?ENDIF should work, but it doesn''t (I get the same obnoxious ''Argument "" isn''t numeric in addition (+)'' message), unless addition between c1 and c2 is not specified with the plus sign (+) in perl or there is yet another bug in shorewall! Go figure... ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb
On 2/10/13 11:10 AM, "Mr Dash Four" <mr.dash.four@googlemail.com> wrote:> >> I am trying to do that optimisation from the calling action (ELOG) >> since I have access to all the parameters and can determine whether >> the action to be executed will have signel or multiple statements. If >> I see that there will be only one statement (as was with the case >> posted previously) I call ALOG''s inline equivalent - IALOG (both >> action.ALOG and action.IALOG are the same - symlinked on the file >> system), but I am struggling with two things: >> >> 1. How do I use arithmetic operations on variables? Doing the following: >> >> ?SET one 1 >> ?SET two 2 >> ?SET sum @{one} + @{two} >> >> doesn''t get me anywhere (I get ''Argument "" isn''t numeric in addition >> (+)'' message). >> >> 2. Similar to 1 above - how do I use logical operations on variables? >> Doing the following: >> >> ?SET one 1 >> ?SET two >> ?SET logical_or @{one} | @{two} >> >> is simply ignored by shorewall (same goes if I apply logical and - >> "@{one} & @{two}"). >>From http://www.shorewall.net/configuration_file_basics.htm#Conditional: > >"Beginning with Shorewall 4.5.6, rather than a simple variable in ?IF >directives, Perl-compatible expressions are allowed (after the Shorewall >compiler expands all variables, the resulting expression is then >evaluated by Perl). Variables in the expressions are as described >above.". So, according to this, if I have something like: > >?SET c1 1 >?SET c2 1 >?IF @c1 + @c2 > 1 >[...] >?ENDIF > >should work, but it doesn''t (I get the same obnoxious ''Argument "" isn''t >numeric in addition (+)'' message), unless addition between c1 and c2 is >not specified with the plus sign (+) in perl or there is yet another bug >in shorewall! Go figure...Try the attached patch. There was a silly bug in processing expressions consisting of a single number. -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb
> Try the attached patch. There was a silly bug in processing expressions > consisting of a single number. >Nope, same error. ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb
On 2/10/13 3:29 PM, "Mr Dash Four" <mr.dash.four@googlemail.com> wrote:> >> Try the attached patch. There was a silly bug in processing expressions >> consisting of a single number. >> >Nope, same error.You must use $var rather than @var for variables set using the ?SET directive. -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb
On 2/10/13 3:39 PM, "Tom Eastep" <teastep@shorewall.net> wrote:>On 2/10/13 3:29 PM, "Mr Dash Four" <mr.dash.four@googlemail.com> wrote: > >> >>> Try the attached patch. There was a silly bug in processing expressions >>> consisting of a single number. >>> >>Nope, same error. > >You must use $var rather than @var for variables set using the ?SET >directive.Unless the variable names a parameter (variable name is numeric) or the variable defined by Shorewall (@chain, @disposition, etc.). -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb
> Unless the variable names a parameter (variable name is numeric) or the > variable defined by Shorewall (@chain, @disposition, etc.). >Interesting, didn''t know that - is this distinction documented anywhere? The patch now works though. Many thanks! ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb
On 2/10/13 3:47 PM, "Mr Dash Four" <mr.dash.four@googlemail.com> wrote:> >> Unless the variable names a parameter (variable name is numeric) or the >> variable defined by Shorewall (@chain, @disposition, etc.). >> >Interesting, didn''t know that - is this distinction documented anywhere? >The patch now works though. Many thanks!''@'' variables are documented at http://ipv6.shorewall.net/configuration_file_basics.htm#ShorewallVariables. -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb