Parse errors on ampersand in remarks
-
jth
Same thing for characters: < , (
Presumably would've choked on > and ) had it reached that far. I don't see any periods in use within remarks, at least in this config, so I don't care about that one...
-
Craig Bugzefsky
Yah, this is a gonna be hairy to resolve in the RACC parser and lexer. I bet people have all kinds of characters there that are not allowed elsewhere in PIX configs. Once I get that fixed then I'll have to filter them out in the Flint::CiscoFirewall code that builds a model of access lists.
Congrats on being the first person to use remarks in a config that I've seen in a couple years!
-
jth
I'm not using them myself, but my four network admins do quite frequently. We're probably in the 15k-line range for our primary data center firewalls, and 10k for secondary. This is only one zone, but we use things like -Inside and -Outside in templates for the setup of new systems and zones. Impossible without remarks.
I'll grep out all remark lines and see what I get after that.
-
Craig Bugzefsky
Ok, Flint will churn on those for awhile. We were testing with 5k line configs and found it running about 5 minutes from start to finish. There is not very good UI feedback when running a large ruleset right now, so you'll get a spinner.
-
Craig Bugzefsky
- State changed from new to resolved
I just committed a fix for this. Pull from the repo to update, or grab http://runplaybook.com/storage/flint/flint-current.tgz
Which should be flint-1.0.1
This MAY also fix your other issue with the overlap? on NIL. Lemme know.
commit 866da35c3e39d3581a62513f45fc449d24a3d7d8
Author: Craig Brozefsky craig@snowtard.kokonino.net
Date: Fri Mar 5 22:23:33 2010 -0600Fill out handling of punctuation in remarks, and mark access-list remarks as such, distinguishing them from access-list commands
Please Sign in or create a free account to add a new ticket.
With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.