On Mon, Apr 08, 2002 at 11:28:00AM +0200, Harald Welte wrote:
> there is an answer, but in [EMAIL PROTECTED] archive :)

Yes, sorry - the netfilter website is a bit slow, so I refused to
download 'the wole mailinglist archive' until now, but since I've
done it, I found the answers :)

> > i use iptables with kernel 2.4.14 on Sparc Architecture.
> To be precise: on 64bit ultrasparc architecture

Yes :)

> I was unable to see where we are doing wrong and postponed the problem
> since there seem to be relatively few people using iptables on ultrasparc,
> at least counting by the complaints we've seen so far.
> 
> If you are in the mood to do some debugging your self, I'm happy to receive
> a patch :)  Maybe this needs to be discussed with the ultralinx developers,
> they should be aware of all the 32/64 implications.

Well, I'm not really proof with the iptables concepts and/or iptables
code, but I'm in the mood, however, to have a look :)

At first I have some notices about the problem occuring (which are
also visible in the example I pasted):

Nothing else but the counters are incorrect.

The counters are not always wrong, sometimes, they are correct.

One can 'correct' the counters (the policy counters as well as the
packet counters) by inserting a few dummy rules in the beginning
of a chain - and: one can simply remove them again, if the counters
are correct once and they will keep correct.

If I create a fresh, clean and empty chain, and I append rules to it:
1. After appending the first rule, their counters will be correct.
2. After appending the second rule, the counters of the first rule
   will be wrong, the ones of the second rule will be correct.
3. After appending the third rule, the counters of the first rule
   keep being wrong, the ones of the second and third will be correct.
4. Adding the fourth rule, destroys the counters of the third.
5. Adding any more rules, changes nothing, their counters will be
   correct at all.
6. Removing the first three rules, results in a chain where all rules
   have correct counters.
7. Adding one more rule then, results in again destroyed counters
   of the first and third rule.

Do you agree with me so far?

>From now on, my knowledge of internal iptables structures management
is too few to conicide those notices with them :)


regards,
   Mario
-- 
Programmieren in C++ haelt die grauen Zellen am Leben. Es schaerft
alle fuenf Sinne: den Schwachsinn, den Bloedsinn, den Wahnsinn, den
Unsinn und den Stumpfsinn.
                                 [Holger Veit in doc]

Reply via email to