[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Log Tickets was >> RE: set loginterface

um...is it raining where you are Henning? snow? I agree only one interface
is best - more is against the Unix idea. Stats on an interface come from the
filtering rules - no reason for PF to report more than is requested by the
rules. (bet that would make a slow PF)
1)monitoring traffic on an interface must be written into the PF filer
2)traffic for an interface is extracted from pflog0 output, typically by
rule#, using tools at hand (grep,perl etc)
I can't say I thought trough the consequences - I took the shortcut and
recognized the value in simplicity.
(this was a couple weeks ago when I picked up this old bone)
but I am definitely taking notes!...about how many interfaces are there in a
(GENERIC) kernel? I hadn't even though about them.(ruff estimate's ok, a
specific answer would just be a wasted on me) ~=)
A Question: is it of value for PF to log to pflog0 'ticket' activity - maybe
based on a switch in rc.conf? pf=[YES|NO|TICKET] ?
	with TICKET=YES+log tickets* to pflog
if I understand, additions and deletions of rules involve a ticket mechanism
to maintain PF coherency. (from man pf)
When a ticket is issued, could PF log the ticket or the change that prompted
the ticket out to pflog0 - if the switch in rc.conf had been set.
*the rule and its new rule number and a timestamp would be BOAW (best of all
is the 'ticket' the best place to do this?
and - Good morning - I hope it's a sunny day in .de  - at least a break in
the clouds (could happen in the south)
ps - I will definitely add this FAQ to the Wiki (penance!) ;>
thx - Ed
-----Original Message-----
From: Henning Brauer [mailto:henning@openbsd.org]
Sent: Saturday, March 08, 2003 2:32 PM
To: pf@benzedrine.cx
Subject: Re: set loginterface
On Sat, Mar 08, 2003 at 09:24:39PM +0100, Cedric Berger wrote:
> PF@0x1b.com wrote:
> >you only want one because - In order to keep with the *nix ethic of one 
> >tool
> >one job - a singular loginterface gives you one point of contact for your
> >tool of choice for splitting out your various types of logs - i.e.. pipe
> >through grep & tee or....see?
> >
> I'm looking at the left, at the right, before me, but I still didn't see.
It just doesn't make sense.
Obviously, nobody of you has thought through the consequences of collecting
the stats on each interface.
Now, it is very very very simple:
	if (ifp == status_ifp) {
		pf_status.bcounters[0][dir == PF_OUT] += pd.tot_len;
		pf_status.pcounters[0][dir == PF_OUT][action]++;
in the IPv4 case, and s/[0]/[1]/ in the v6 case.
so you might say "just add a level for the interface", something like this:
		pf_status.bcounters[ifp][0][dir == PF_OUT] += pd.tot_len;
		pf_status.pcounters[ifp][0][dir == PF_OUT][action]++;
(of course, ifp isn't te right thing here, this is just to illustrate)
and this gets ugly.
Do you guys have an idea about the freakin number of interfaces we have in a
usual (GENERIC) kernel?
Did you ever think about the issues with the interface indexes we'd need in
this array? we've had our issues with that before, and trust me, that is not
that easy.
Then think further: Do you really want pfctl -si output fill 10 screen
pages? surely not. we need to invent something else in pfctl to show stats
for one interface at a time or so.
This is obviously quite some effort. It has obviously quite some issues.
What for?
You can get ALL this data with minimal efforts on the rules itself.
obviously, with a ruleset written this in mind, thus having no packet match
the implicit default pass rule, you can get ALL this information on the
RULES ITSELF. this is MUCH more powerfull, and already there. the rule
labels are the prime candidate for this. In fact, I do all accounting using
them, pfctl -sl output and little perl magic to parse that here.
the current loginterface stuff makes sense for a quick overview, especially
for a quick view on the "external interface" in the usual setup. That's it.
If you need more info, it is all there. pfctl -vsr and especially pfctl -sl
are the prime candidates.
If you just want interface statistics, there are numerous tools in th eports
tree for that. This is not pf's purpose.
It is just bullshit and nonsense to implement something because it is
possible. If you want that, use leenucks. There you have all the useless
options, and can even have bogus filters on strings in packets and packet
size... pah humbug (think about fragmentation, on tcp or even application
I do not want this bloat in pf. 
I will not extend the loginterface stuff, and I will not agree on any diff
extending it like this.
Henning Brauer, BS Web Services, http://bsws.de
hb@bsws.de - henning@openbsd.org
Unix is very simple, but it takes a genius to understand the simplicity.
(Dennis Ritchie)