Re: pfctl(8): unclear docs
* Toni Mueller openbsd-m...@oeko.net [2010-03-15 12:59]: Not using -R is not too good, either, as on this particular box, reloading everything results in a severance of all existing connections. I don't believe you. pfctl -f /etc/pf.conf doesn't do that. ok, shouldn't, but I don't see where that could break. A clarification in the docs is imho the way to go. no, we'll kill that bullshit, soon. it is just leftover pf must be ipf alike goo. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
Re: pfctl(8): unclear docs
* Toni Mueller openbsd-m...@oeko.net [2010-03-15 10:52]:
I've just run into the following problem on a 4.6 box:
/etc/pf.conf (excerpt):
table rfc1918 const { 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 }
block out on $extif from rfc1918
# /sbin/pfctl -F rules -R -f pf.conf
rules cleared
pfctl: Must enable table loading for optimizations
# /sbin/pfctl -s r
#
Imho, this interaction should be documented in the man page. One needs
to specify '-Tl', or else no rules will be loaded.
-A, -O, -R are bullshit and I'll happily remove them. soon.
--
Henning Brauer, h...@bsws.de, henn...@openbsd.org
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting
Re: pfctl(8): unclear docs
Hi, On Wed, 17.03.2010 at 16:24:42 +0100, Henning Brauer lists-open...@bsws.de wrote: -A, -O, -R are bullshit and I'll happily remove them. soon. that's ok with me. I thought that changing the docs was the less-intrusive thing to do, and I have no experience with ipf, so that certainly wasn't on my mind. TIA! -- Kind regards, --Toni++
Re: pfctl(8): unclear docs
On Mon, Mar 15, 2010 at 10:35:23PM +0100, Toni Mueller wrote: Hi, On Mon, 15.03.2010 at 13:04:04 +, Jason McIntyre j...@kerhand.co.uk wrote: doesn;t Other rules and options are ignored. already cover this? may be. But then, you are possibly only too deeply entrenched in this stuff to see the problem. it is always possible, but i don't think so in this case. i didn't honestly know about this behaviour until reading your mail. now i have read your mail, and pfctl(8), and think that we have it covered. we have to strike a balance somewhere between documenting behaviour and not bogging ourselves down in answering every possible question. i admit that balance is somewhat arbitrary. but you, the reader, have some responsibility to go digging. and to be surprised too sometimes. so i'm asking myself whether your diff improves what we have. i don;t think it does. it's just my opinion - we cannot call wrong or right here. furthermore, since -T has a load command, should we really expect -R to load tables? Should it really need to? My guess was that tables would usually have been loaded already when one goes to selectively reloads the rules, and either of spelling out that they need to be loaded explicitly, stating that, by default, the already-loaded tables are being used, or that they are being ignored, or that the whole command fails would imho be a good thing. i think what you're looking at is the side-effect of tables being hacked into pf. it may be that you can see inconsistencies, i don't know. maybe just tell yourself that when you use pfctl to load rules, it will only load rules, not other stuff. like the doc says. Ok. I go out on a limb and say that explicit is better than implicit, in a lot of cases, and would welcome the short explanation OR the modification of the command to also load tables (which would require amending the man page, too). I admit that I was unaware of the rule optimizer until it bit me into my bottom half. I mean, I usually don't care, from a user perspective, whether there is something optimizing my stuff, and consider this kind of breakage as a (an almost) hidden gotcha. An optimizer (or any other such device) which is on by default and claims to not change semantics, should imho be transparent to the user, but this one isn't. If you have other uses of disabling the optimizer except for debugging pf, I'd really like to hear. sorry, you've lost me with the optimiser stuff ;) why are you discussing that? jmc
Re: pfctl(8): unclear docs
Hi, On Tue, 16.03.2010 at 07:37:42 +0001, Jason McIntyre j...@kerhand.co.uk wrote: On Mon, Mar 15, 2010 at 10:35:23PM +0100, Toni Mueller wrote: An optimizer (or any other such device) which is on by default and claims to not change semantics, should imho be transparent to the user, but this one isn't. If you have other uses of disabling the optimizer except for debugging pf, I'd really like to hear. sorry, you've lost me with the optimiser stuff ;) why are you discussing that? ok, I'll try again: matteo pointed me to an article which says that the problem can be bypassed by using an option to pfctl that disables the optimiser, which is enabled by default. I think that any device that automatically works on the user's input should not alter the documented semantics of what the user input, and on which the user relies. On the contrary, such devices should imho be transparent to the user, but obviously, this optimiser isn't because its use is not orthogonal to the other options of 'pfctl'. Also (I didn't mention this before), since the use of tables is advocated in about any docs (counting statements on this list in for this purpose) that I've read so far, with the optimiser being on by default, using '-R' alone should presently be impossible in the majority of real-world use cases. Therefore I advocate changing the documentation or the implementation to highlight this case of non-orthogonality. Better now? -- Kind regards, --Toni++
Re: pfctl(8): unclear docs
2010/3/16 Toni Mueller openbsd-m...@oeko.net Hi, On Tue, 16.03.2010 at 07:37:42 +0001, Jason McIntyre j...@kerhand.co.uk wrote: On Mon, Mar 15, 2010 at 10:35:23PM +0100, Toni Mueller wrote: An optimizer (or any other such device) which is on by default and claims to not change semantics, should imho be transparent to the user, but this one isn't. If you have other uses of disabling the optimizer except for debugging pf, I'd really like to hear. sorry, you've lost me with the optimiser stuff ;) why are you discussing that? ok, I'll try again: matteo pointed me to an article which says that the problem can be bypassed by using an option to pfctl that disables the optimiser, which is enabled by default. I think that any device that automatically works on the user's input should not alter the documented semantics of what the user input, and on which the user relies. On the contrary, such devices should imho be transparent to the user, but obviously, this optimiser isn't because its use is not orthogonal to the other options of 'pfctl'. Also (I didn't mention this before), since the use of tables is advocated in about any docs (counting statements on this list in for this purpose) that I've read so far, with the optimiser being on by default, using '-R' alone should presently be impossible in the majority of real-world use cases. Therefore I advocate changing the documentation or the implementation to highlight this case of non-orthogonality. Better now? -- Kind regards, --Toni++ Hi all, Toni, the article says that optimizer is enable by default on OpwnBSD 4.2 thus you don't need to pass option -R to pfctl. If you pass that option you get the warning. Best regards. -- Matteo Filippetto
pfctl(8): unclear docs
Hi,
I've just run into the following problem on a 4.6 box:
/etc/pf.conf (excerpt):
table rfc1918 const { 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 }
block out on $extif from rfc1918
# /sbin/pfctl -F rules -R -f pf.conf
rules cleared
pfctl: Must enable table loading for optimizations
# /sbin/pfctl -s r
#
Imho, this interaction should be documented in the man page. One needs
to specify '-Tl', or else no rules will be loaded.
TIA!
Kind regards,
--Toni++
Re: pfctl(8): unclear docs
2010/3/15 Toni Mueller openbsd-m...@oeko.net
Hi,
I've just run into the following problem on a 4.6 box:
/etc/pf.conf (excerpt):
table rfc1918 const { 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 }
block out on $extif from rfc1918
# /sbin/pfctl -F rules -R -f pf.conf
rules cleared
pfctl: Must enable table loading for optimizations
# /sbin/pfctl -s r
#
Imho, this interaction should be documented in the man page. One needs
to specify '-Tl', or else no rules will be loaded.
TIA!
Kind regards,
--Toni++
Hi,
for me it works good ... just don't use -R option
http://kerneltrap.org/mailarchive/openbsd-misc/2007/4/6/147502
--
Matteo Filippetto
Re: pfctl(8): unclear docs
Hi, On Mon, 15.03.2010 at 12:22:35 +0100, matteo filippetto matteo.filippe...@gmail.com wrote: for me it works good ... just don't use -R option http://kerneltrap.org/mailarchive/openbsd-misc/2007/4/6/147502 thanks for this link. Not using -R is not too good, either, as on this particular box, reloading everything results in a severance of all existing connections. A clarification in the docs is imho the way to go. My 'nroff' is almost nonexistant, but here's a diff: --- pfctl.8.origWed Jun 11 09:23:36 2008 +++ pfctl.8 Mon Mar 15 12:53:04 2010 @@ -354,7 +354,9 @@ Only print errors and warnings. .It Fl R Load only the filter rules present in the rule file. -Other rules and options are ignored. +Other rules and options are ignored. If you are using +tables, you need to also specify one of -T load or +-o none. .It Fl r Perform reverse DNS lookups on states when displaying them. .It Fl s Ar modifier Kind regards, --Toni++
Re: pfctl(8): unclear docs
On Mon, Mar 15, 2010 at 12:54:09PM +0100, Toni Mueller wrote: Not using -R is not too good, either, as on this particular box, reloading everything results in a severance of all existing connections. A clarification in the docs is imho the way to go. My 'nroff' is almost nonexistant, but here's a diff: --- pfctl.8.orig Wed Jun 11 09:23:36 2008 +++ pfctl.8 Mon Mar 15 12:53:04 2010 @@ -354,7 +354,9 @@ Only print errors and warnings. .It Fl R Load only the filter rules present in the rule file. -Other rules and options are ignored. +Other rules and options are ignored. If you are using +tables, you need to also specify one of -T load or +-o none. .It Fl r Perform reverse DNS lookups on states when displaying them. .It Fl s Ar modifier doesn;t Other rules and options are ignored. already cover this? furthermore, since -T has a load command, should we really expect -R to load tables? i don;t see that it needs to be more explicit. jmc
Re: pfctl(8): unclear docs
2010/3/15 Toni Mueller openbsd-m...@oeko.net Hi, On Mon, 15.03.2010 at 12:22:35 +0100, matteo filippetto matteo.filippe...@gmail.com wrote: for me it works good ... just don't use -R option http://kerneltrap.org/mailarchive/openbsd-misc/2007/4/6/147502 thanks for this link. Not using -R is not too good, either, as on this particular box, reloading everything results in a severance of all existing connections. A clarification in the docs is imho the way to go. My 'nroff' is almost nonexistant, but here's a diff: --- pfctl.8.origWed Jun 11 09:23:36 2008 +++ pfctl.8 Mon Mar 15 12:53:04 2010 @@ -354,7 +354,9 @@ Only print errors and warnings. .It Fl R Load only the filter rules present in the rule file. -Other rules and options are ignored. +Other rules and options are ignored. If you are using +tables, you need to also specify one of -T load or +-o none. .It Fl r Perform reverse DNS lookups on states when displaying them. .It Fl s Ar modifier Kind regards, --Toni++ Hi Toni, I find this Starting in OpenBSD 4.2, the default is basic. See pf.conf(5)http://www.openbsd.org/cgi-bin/man.cgi?query=pf.confsektion=5manpath=OpenBSD+4.6for a more complete description. on faq (http://www.openbsd.org/faq/pf/options.html) and also in the man pages http://www.openbsd.org/cgi-bin/man.cgi?query=pf.confsektion=5manpath=OpenBSD+4.6 Best regards -- Matteo Filippetto
Re: pfctl(8): unclear docs
Hi, On Mon, 15.03.2010 at 13:04:04 +, Jason McIntyre j...@kerhand.co.uk wrote: doesn;t Other rules and options are ignored. already cover this? may be. But then, you are possibly only too deeply entrenched in this stuff to see the problem. furthermore, since -T has a load command, should we really expect -R to load tables? Should it really need to? My guess was that tables would usually have been loaded already when one goes to selectively reloads the rules, and either of spelling out that they need to be loaded explicitly, stating that, by default, the already-loaded tables are being used, or that they are being ignored, or that the whole command fails would imho be a good thing. Ok. I go out on a limb and say that explicit is better than implicit, in a lot of cases, and would welcome the short explanation OR the modification of the command to also load tables (which would require amending the man page, too). I admit that I was unaware of the rule optimizer until it bit me into my bottom half. I mean, I usually don't care, from a user perspective, whether there is something optimizing my stuff, and consider this kind of breakage as a (an almost) hidden gotcha. An optimizer (or any other such device) which is on by default and claims to not change semantics, should imho be transparent to the user, but this one isn't. If you have other uses of disabling the optimizer except for debugging pf, I'd really like to hear. -- Kind regards, --Toni++
