Re: pf weirdness with pfctl -f nonexistent.file
On Fri, 11 Nov 2005, Daniel Hartmeier wrote: > I'm pretty sure your theory is correct. You can query the list of > interfaces with pfctl -vsI, which prints '(skip)' on those that are > currently being skipped. ah, yes, thank you. i did check, and yes, it's the skip flag that gets cleared. > Reloading the ruleset does (and should) clear the 'set skip' set, as we > agreed that there should be no (or as little as possible) state in the > kernel that persists across ruleset reloads. Other options are similarly > cleared on reload (and then re-instated, if you reload a ruleset similar > to the old one). So loading an empty ruleset should clear all such > options. > > Now, if the ruleset doesn't exist at all (I assume you didn't have a > file called 'all' lying in the cwd when running pfctl -f all), I guess > nothing should happen except for the error message. I'll check about > that. > > Or what would you prefer instea > exactly that. unless there's some master idea i'm not aware of (or can't think of), that seems to be the most reasonable behavior, no? -- [-] mkdir /nonexistent
Re: pf weirdness with pfctl -f nonexistent.file
I'm pretty sure your theory is correct. You can query the list of interfaces with pfctl -vsI, which prints '(skip)' on those that are currently being skipped. Reloading the ruleset does (and should) clear the 'set skip' set, as we agreed that there should be no (or as little as possible) state in the kernel that persists across ruleset reloads. Other options are similarly cleared on reload (and then re-instated, if you reload a ruleset similar to the old one). So loading an empty ruleset should clear all such options. Now, if the ruleset doesn't exist at all (I assume you didn't have a file called 'all' lying in the cwd when running pfctl -f all), I guess nothing should happen except for the error message. I'll check about that. Or what would you prefer instead? Daniel
pf weirdness with pfctl -f nonexistent.file
hi, i just observed a strange phenomenon, which, if it's intended behavior, i could not really find it documented anywhere (or failed to understand the doc, if it is). in its simplest form, it is as follows. given is a machine with a de0, part of a simple lan. the following configuration is loaded into pf: -- set skip on de0 block log all pass in on de0 from 192.168.1.10 to any keep state -- i'm logged in from 192.168.1.12 via de0, make a fat-fingered typo of `pfctl -f all' (instead of -F all), poof, get thrown out (connection reset by peer). from 192.168.1.10, the box is accessible. logged in from 1.10, looked around, generally everything looks ok, pfctl -sa shows the rules, shows pf enabled, whatnot, but it acts as if the `set skip on de0' part was somehow forgotten. i can not verify my suspicion as i couldn't find a way to get the current (as in `loaded into the kernel') `skip these interfaces' list (shouldn't that be included in -sr anyway?), but i couldn't find any other explanations. reproducible on 3.8-stable i386 and -current (as of 2-3 days ago) alpha. what's that? thanks, -- [-] mkdir /nonexistent
