On Fri, Apr 20, 2001 at 02:51:55AM +, Ton Hospel wrote:
> Resettable counters are evil.
Perhaps "evil" should be reserved to describe counters which automatically
reset as a side effect of being read.
> I really think cisco got this right: from the commandline interface
> you can reset count
On Tue, Apr 17, 2001 at 12:29:30PM +0200, Olaf Titz wrote:
> > Umm, no. Counters can be resetable - you just specify that accounting
> > programs should not reset them, ever.
> >
> > The ability to reset counters is extremely useful if you're a human
> > looking at the output of iptables -L -v.
On Tue, Apr 17, 2001 at 06:56:42AM +, Henning P. Schmiedehausen wrote:
>
> Resettable counters in a security sensitive environment are just a
> call for trouble. That's why you can't reset the SNMP counters on any
> Cisco device I've encountered today. They learned their lesson. Maybe
> you w
On Tue, Apr 17, 2001 at 11:13:19AM +1000, Manfred Bartz wrote:
> I had a brief look at MRTG. It seems to be a well written app and
> while it can handle counter reset (with potential loss of an unknown
> amount of data), it does not actively reset counters. It also doesn't
> use iptables.
Yes
In article <[EMAIL PROTECTED]>,
Alan Cox <[EMAIL PROTECTED]> writes:
>> > No he isnt confused, you are trying to dictate policy.
>>
>> What then *is* the policy?
>
> The policy is not to have policy. It works as well in kernel design as politics.
>
> Alan
>
Since my job is in fact main
At 10:16 AM +0200 2001-04-18, Kenneth Johansson wrote:
>Alan Cox wrote:
>
>> > > Fix your userspace applications to behave correctly. If _you_
>> > > require your userspace applications to not clear counters, then fix
>> > > the application.
>> >
>> > You are confused. What would you say if a cl
> I repeat myself, fighting is apparently so pleasant that
> you are stuck on
> fighting over dead-end technology:
>
> I seriously suggest that for the primary (subject given) topic
> you are SERIOUSLY OFF TARGET. Look around, counting hits on
> some fw rules is waste of time! (And mightl
Alan Cox wrote:
> > > Fix your userspace applications to behave correctly. If _you_
> > > require your userspace applications to not clear counters, then fix
> > > the application.
> >
> > You are confused. What would you say if a close() by another,
>
> No he isnt confused, you are trying to d
> > No he isnt confused, you are trying to dictate policy.
>
> What then *is* the policy?
The policy is not to have policy. It works as well in kernel design as politics.
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED
Alan Cox <[EMAIL PROTECTED]> writes:
> > > Fix your userspace applications to behave correctly. If _you_
> > > require your userspace applications to not clear counters, then fix
> > > the application.
> >
> > You are confused. What would you say if a close() by another,
>
> No he isnt confus
> > Fix your userspace applications to behave correctly. If _you_
> > require your userspace applications to not clear counters, then fix
> > the application.
>
> You are confused. What would you say if a close() by another,
No he isnt confused, you are trying to dictate policy.
> unrelated a
Leif Sawyer <[EMAIL PROTECTED]> writes:
> > > Jesse Pollard replies:
> > Removing/no-oping the reset code would make the module
> > SMALLER, and simpler.
> NO. Don't remove the functionality that is required.
Please explain where counter reset capability provides any
functionality that is
Leif Sawyer <[EMAIL PROTECTED]> writes:
> Jesse Pollard replies:
> to Leif Sawyer who wrote:
> > > Besides, what would be gained in making the counters RO, if
> > > they were cleared every time the module was loaded/unloaded?
> >
> > 1. Knowlege that the module was reloaded.
> > 2. Knowlege th
> > Jesse Pollard replies:
> > to Leif Sawyer who wrote:
> > >> Besides, what would be gained in making the counters RO, if
> > >> they were cleared every time the module was loaded/unloaded?
> > >
> > > 1. Knowlege that the module was reloaded.
> > > 2. Knowlege that the data being measured is
- Received message begins Here -
>
> Jesse Pollard replies:
> to Leif Sawyer who wrote:
> >> Besides, what would be gained in making the counters RO, if
> >> they were cleared every time the module was loaded/unloaded?
> >
> > 1. Knowlege that the module was reloaded.
> > 2.
I repeat myself, fighting is apparently so pleasant that you are stuck on
fighting over dead-end technology:
I seriously suggest that for the primary (subject given) topic
you are SERIOUSLY OFF TARGET. Look around, counting hits on
some fw rules is waste of time! (And mightly inaccurate!)
Jesse Pollard replies:
to Leif Sawyer who wrote:
>> Besides, what would be gained in making the counters RO, if
>> they were cleared every time the module was loaded/unloaded?
>
> 1. Knowlege that the module was reloaded.
> 2. Knowlege that the data being measured is correct
> 3. Having reliabl
Leif Sawyer <[EMAIL PROTECTED]>:
> > And that introduces errors in measurement. It also depends on
> > how frequently an uncontroled process is clearing the counters.
> > You may never be able to get a valid measurement.
>
> This is true. Which is why application programmers need to write
> cod
Jesse Pollard continues with:
> Leif Sawyer <[EMAIL PROTECTED]>:
>>> Ian Stirling [mailto:[EMAIL PROTECTED]]
Manfred Bartz responded to
> Russell King <[EMAIL PROTECTED]> who writes:
>
> You just illustrated my point. While there is a
> reset capability people will use it an
Leif Sawyer <[EMAIL PROTECTED]>:
> > From: Ian Stirling [mailto:[EMAIL PROTECTED]]
> > > Manfred Bartz responded to
> > > > Russell King <[EMAIL PROTECTED]> who writes:
> >
> > > > You just illustrated my point. While there is a reset capability
> > > > people will use it and accounting/logging
> Umm, no. Counters can be resetable - you just specify that accounting
> programs should not reset them, ever.
>
> The ability to reset counters is extremely useful if you're a human
> looking at the output of iptables -L -v. (I thus far know of no one
> who can memorise the counter values for
> Similarly, if my InPackets are at 102345 at one read, and 2345 the
> next read, and I know that my counter is 32 bits, then I know i've
> wrapped and can do my own math.
No. When you have resettable counters, you don't know if the counter
has wrapped or been reset. Either you have received 2345
Harald Welte <[EMAIL PROTECTED]> writes:
> On Mon, Apr 16, 2001 at 12:07:31PM +1000, Manfred Bartz wrote:
> > Resetable counters guarantee that no two programs can co-exists if
> > they happen to reset the same counters.
>
> That sounds like crap (sorry).
Care to explain how two independent ap
On Mon, Apr 16, 2001 at 12:07:31PM +1000, Manfred Bartz wrote:
>
> If there really is a performance issue with a few hundred rules, then
> it can be overcome by grouping rules in separate custom chains. F.e.
> if you have 1024 rules create 32 custom chains with 32 rules each.
> Then have 32 rule
On Tue, Apr 17, 2001 at 07:53:28AM +1000, David Findlay wrote:
> In the 2.5 series of kernels, working towards 2.6, could you please make the
> IP Accounting so that I can set a single rule that will make it watch all IP
> traffic going from the local network, through the masquerading service t
Leif Sawyer <[EMAIL PROTECTED]> writes:
> Manfred Bartz responded to
> > Russell King <[EMAIL PROTECTED]> who writes:
> >
> > > On Mon, Apr 16, 2001 at 12:07:31PM +1000, Manfred Bartz wrote:
> > > > There is another issue with logging in general:
> > > >
> > > > *COUNTERS MUST N
> From: Ian Stirling [mailto:[EMAIL PROTECTED]]
> > Manfred Bartz responded to
> > > Russell King <[EMAIL PROTECTED]> who writes:
>
> > > You just illustrated my point. While there is a reset capability
> > > people will use it and accounting/logging programs will get wrong
> > > data. Resetabl
>
> Manfred Bartz responded to
> > Russell King <[EMAIL PROTECTED]> who writes:
> > You just illustrated my point. While there is a reset capability
> > people will use it and accounting/logging programs will get wrong
> > data. Resetable counters might be a minor convenience when debugging
>
Manfred Bartz responded to
> Russell King <[EMAIL PROTECTED]> who writes:
>
> > On Mon, Apr 16, 2001 at 12:07:31PM +1000, Manfred Bartz wrote:
> > > There is another issue with logging in general:
> > >
> > > *COUNTERS MUST NOT BE RESETABLE!!!*
> >
> > Umm, no. Counters can be
Russell King <[EMAIL PROTECTED]> writes:
> On Mon, Apr 16, 2001 at 12:07:31PM +1000, Manfred Bartz wrote:
> > There is another issue with logging in general:
> >
> > *COUNTERS MUST NOT BE RESETABLE!!!*
>
> Umm, no. Counters can be resetable - you just specify that accounting
>
Hi,
On Tue, Apr 17, 2001 at 08:46:12AM +1000, David Findlay wrote:
>
> I suppose, but it would be so much easier if the kernel did it automatically.
> Having a rule to go through for each IP address to be logged would be slower
> than implementing one rule that would log all of them. Doing thi
On Mon, Apr 16, 2001 at 12:07:31PM +1000, Manfred Bartz wrote:
> There is another issue with logging in general:
>
> *COUNTERS MUST NOT BE RESETABLE!!!*
Umm, no. Counters can be resetable - you just specify that accounting
programs should not reset them, ever.
The ability to re
David Findlay said once upon a time (Tue, 17 Apr 2001):
> I am using the kernel IP Accounting in Linux to record the amount of data
> transfered via my Linux internet gateway from individual IP addresses. This
> currently requires me to set up an accounting rule for each IP address that I
> want
David Findlay <[EMAIL PROTECTED]> writes:
> On Monday 16 April 2001 10:40, you wrote:
> > Perhaps I misunderstand what it is exactly you are trying to do,
> > but I would think that this could be done entirely in userland by
> > software that just adds rules for you instead of you having to do
>
No, one rule would be MUCH faster. What's do you think would be faster of the two:
if ((ipaddr>=3232235521)&&(ipaddr<=3232235774))
return 1;
else
return 0;
or
for (a=0;a<(3232235774-3232235521);a++)
if (ipaddr==a)
return 1;
return 0;
Obviously it compares the 192.168.0.1 -
On Tue, Apr 17, 2001 at 08:46:12AM +1000, David Findlay wrote:
> On Monday 16 April 2001 10:40, you wrote:
> > Perhaps I misunderstand what it is exactly you are trying to do,
> > but I would think that this could be done entirely in userland by
> > software that just adds rules for you instead of
On Tue, 17 Apr 2001, David Findlay wrote:
>> Perhaps I misunderstand what it is exactly you are trying to do,
>> but I would think that this could be done entirely in userland by
>> software that just adds rules for you instead of you having to do
>> it manually.
>
>I suppose, but it would be so
On Monday 16 April 2001 10:40, you wrote:
> Perhaps I misunderstand what it is exactly you are trying to do,
> but I would think that this could be done entirely in userland by
> software that just adds rules for you instead of you having to do
> it manually.
I suppose, but it would be so much ea
On Tue, 17 Apr 2001, David Findlay wrote:
>I am using the kernel IP Accounting in Linux to record the amount of data
>transfered via my Linux internet gateway from individual IP addresses. This
>currently requires me to set up an accounting rule for each IP address that I
>want to record accounti
> In the 2.5 series of kernels, working towards 2.6, could you please make the
> IP Accounting so that I can set a single rule that will make it watch all IP
> traffic going from the local network, through the masquerading service to the
> internet, and log local IP Addresses using it? This would
I am using the kernel IP Accounting in Linux to record the amount of data
transfered via my Linux internet gateway from individual IP addresses. This
currently requires me to set up an accounting rule for each IP address that I
want to record accounting info for. If I had 200 machines to indivi
41 matches
Mail list logo
