On Sat, Mar 08, 2003 at 09:24:39PM +0100, Cedric Berger wrote:
> [EMAIL PROTECTED] 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 it
> >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
level).
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
[EMAIL PROTECTED] - [EMAIL PROTECTED]
Unix is very simple, but it takes a genius to understand the simplicity.
(Dennis Ritchie)
