Tom Eastep wrote:
> On 1/8/13 7:32 PM, "Mr Dash Four" <[email protected]> wrote:
>
>
>> Tom Eastep wrote:
>>
>>> On 01/06/2013 10:39 AM, Mr Dash Four wrote:
>>>
>>>>>> 1. ADD(setname:flags) (same with DEL) does not work with sets
>>>>>> containing the "-" character (such sets are accepted by shorewall
>>>>>> anywhere else):
>>>>>>
>>>>>> rules
>>>>>> ~~~~~
>>>>>> ADD(+mickey-mouse:dst,dst) $FW net
>>>>>>
>>>>>> Gives me "ERROR: Expected ipset name (mickey-mouse)".
>>>>>>
>>>>>>
>>>>> Hmmm - That rule compiles error-free for me; git shows that bug was
>>>>> corrected in a commit on October 2 of last year.
>>>>>
>>>>>
>>>> The patch I am attaching is how I fixed this particular issue when
>>>> compiling shorewall.
>>>>
>>>>
>>>>> Agreed. Change will be in Beta 4.
>>>>>
>>>>>
>>>> Thanks.
>>>>
>>> My patch is backward-compatible so existing rules that include '+' will
>>> not be rejected.
>>>
>> As I indicated in my previous response to you, the reason for attaching
>> the patch was to show you how I fixed that particular bug, which, lets
>> not forget "was corrected in a commit on October 2 of last year", despite
>> that rule compiling "error-free", apparently.
>>
>
> Your patch had nothing to do with dashes in ipset names. It rather removed
> the requirement for the ipset name to be preceded by '+'.
Oh, yeah? From the patch I already attached in that email:
- fatal_error "Expected ipset name ($setname)" unless $setname
=~ s/^\+// && $setname =~ /^(6_)?[a-zA-Z][-\w]*$/;
+ fatal_error "Expected ipset name ($setname)" unless $setname
=~ /^(6_)?[a-zA-Z][\-\w]*$/;
Pay close attention to the bit with "[\-\w]" at the end of the second
line and then come back and tell me whether my patch "had nothing to do
with dashes"?
> But it would
> break every existing configuration that actually included a '+', which is
> what I was pointing out.
>
Would you like me to repeat what I already written above? OK then, for
your own benefit (with the important bits highlighted this time):
"...the reason for attaching the patch was to show you how *I* fixed
that particular bug..."
In other words, this is how *I* fixed the bug on my own copy of
shorewall, so the notion of "existing configuration" is ... well,
non-existent, since this is my own copy of shorewall and I am well-aware
of what I have changed - I am not demented, you know (not yet anyway).
Finally, to repeat, yet again, if it isn't clear: the reason why I sent
you that patch wasn't so much to ask you to include it in any subsequent
betas/releases of shorewall, but to show you that:
a) the problem which "got fixed in October last year" does exists,
despite what you may have been thinking; and
b) to show you how *I* fixed it, on my own copy of shorewall;
so that you could devise a way to fix that bug ... again.
> I haven't tried to reproduce this in detail, but "@chain_" expands to
> nothing. You want "@{chain}_" there (which is behavior similar to the
> shell with which you have considerable familiarity).
>
Correct, I'll try again tonight with the curly braces to see if that
corrects the problem. I'll also try the alternative syntax as well (if
it works).
>> Passes without an error and closer inspection reveals that the AUDIT
>> ?IF/?ENDIF block has been completely ignored, which, I assume, is as a
>> result of shorewall taking into account the slash (\) in the comment line
>> above.
>>
>
> Yes -- Shorewall processes compiler directives before looking for
> comments.
Which doesn't make it right, does it, unless the notion of a "comment"
in shorewall is somewhat different from any other script languages - in
other words, that "a comment" in shorewall isn't really a comment and
its contents is not really "ignored", but still processed. If that is
so, you may want to highlight this so it is clear to everyone.
------------------------------------------------------------------------------
Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery
and much more. Keep your Java skills current with LearnJavaNow -
200+ hours of step-by-step video tutorials by Java experts.
SALE $49.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122612
_______________________________________________
Shorewall-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-devel
