Date: Mon, 15 Aug 2016 16:11:31 +1000 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: Lev Serebryakov <lev@freebsd.org> Cc: "Andrey V. Elsukov" <ae@freebsd.org>, freebsd-ipfw@freebsd.org Subject: Re: Named states in ipfw (and old rulesets) Message-ID: <20160815154037.P79687@sola.nimnet.asn.au> In-Reply-To: <1174736256.20160815022812@serebryakov.spb.ru> References: <1812167147.20160814202008@serebryakov.spb.ru> <1211733990.20160814202656@serebryakov.spb.ru> <2126139e-9c11-a55c-7573-8b4d3869bf87@FreeBSD.org> <516433114.20160815013243@serebryakov.spb.ru> <1174736256.20160815022812@serebryakov.spb.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 15 Aug 2016 02:20:19 +0300, Lev Serebryakov wrote: > > Please, change this to some prefix to state name (:name, @name or something > > like this) or to "state-action(name)" format. It will be much better: less > > error-prone and will work without ugly warnings on old rulesets. I like the idea of something like :name, @name or perhaps =name ? as a distinct state name identifier. (name) seems like overkill, especially since it requires escaping on the command line as \(name\), and while of course such escaping is required now to identify table names, we don't need anything that might tend to confuse table names with state names. > Or, maybe, state names should be pre-declared (except "default"), as > table's ones does. Like > > ipfw flow create my-name > ipfw add allow ip from an to any keep-state my-name I really hope that's not necessary; the assumption of 'default' name for existing rulesets is good, and requiring pre-declaration of state names - except default - would be less .. orthogonal :) and not necessary. One thing I wondered about earlier but didn't ask is that the order of options is generally not relevant, so for example the commonly used: ipfw add skipto $somewhere tcp from $a to $b setup keep-state would currently be equally valid as: ipfw add skipto $somewhere tcp from $a to $b keep-state setup with possibly other options following? And while 'setup' should be recognised as an existing keyword, not a state name - as will '//' when that's fixed I guess? - still I wondered whether the keyword 'setup' would get "pushed back" for later parsing? > This will be somewhat bullet-proof! I think existing rulesets working out of the box is vital too; the last thing needed on managed remote boxes is firewall breakage on upgrading. cheers, Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160815154037.P79687>