On Wed, Aug 10, 2011 at 21:49 +0900, Ryan McBride wrote: > On Wed, Aug 10, 2011 at 01:07:28PM +0200, Henning Brauer wrote: > > this is indeed the way it was supposed to work. > > I dissagree. This is not at all what my understanding was of how it was > supposed to work. You'd have to talk to dhartmei about his original > intent, but as far as I recall the current behaviour was a conscious > decision at least when I implemented 'max-src-conn' and > 'max-src-states'. I'll admit that the manpage is wrong, though. > > One of my greatest ongoing frustrations is the rampant inconsistency in > the pf.conf syntax, so: > > 1) I strongly oppose changing the behaviour of the existing 'max' state > option. Nothing else there, or in any of the other ( ) 'option' setions, > applies until AFTER that rule has been selected as the last-matching > rule, and I think we should keep it that way. > > 2) whatever you do to 'max' should also be done to 'max-src-conn' and > 'max-src-states'. >
i thought about it actually, but this is more involved and is not directly related to the max_states. i get your point though. > > If we want this functionality, I think it should be done as a separate > keyword, with the rest of the parameters: > > pass in on em0 from any to $webhost states = 0 > > or > > pass in on em0 from any to $webhost src-states > 500 rdr-to $tarpit > > > But it's not clear to me that this is actually what's wanted here. > mikeb, can you explain a little more clearly what you're trying to > accomplish with these 'match only one state' rules? > they are not match only one state - they are rules that create only one state and don't apply afterwards. my application is a proxy server. at this moment it's impossible to write one because of this misfeature. what saves ftp-proxy is that destination port is always different. but it's not always the case, as for example with rpc. the workaround would be to know that anchor tree is sorted in alphabetical order by the anchor name and insert anchors with names like "9999", "9998" and so on. sounds nice, eh? but i don't think that i'll refrain to this ugliness. also i don't think that not using "quick" will save me anyhow. > > P.S. Is it really worth slowing down the inner evaluation pf_test_rule() > loop for this relatively little-used feature?
