[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-net
Subject:    IP Accounting bug?
From:       Jon Lewis <jlewis () inorganic5 ! fdt ! net>
Date:       1997-03-29 19:18:23
[Download RAW message or body]

I use IP Accounting via ipfwadm on a large number of systems, and have
noticed an odd trend.  Every night, I have crond run a script that uses
ipfwadm to email the Accounting info for all my systems to me, and reset
the counters.  On certain boxes, mostly the ones that are either rather
busy systems or have lots of Accounting rules, if I use ipfwadm -lAz to
list and simultaneously zero the counters, I occasionally get corruption
in the IP addresses in the accounting rules...i.e.: 

IP accounting rules
 pkts bytes dir prot source               destination          ports
[lines clipped]
    5   307 i/o all  0.0.48.139           anywhere             n/a
[lines clipped]

0.0.48.139 should have been 205.229.48.139...and if I do an ipfwadm -lA
later, it shows up properly.  I've found that by first piping ipfwadm -lA
to mail, then doing an ipfwadm -Az, I do not get address corruption in the
info emailed to me.  

I've read through the ipfwadm source and some kernel source...and I really
think there is a bug in the ip_fw.c file (where i->fw_pcnt and i->fw_bcnt
get reset) in the kernel source...but I can't figure out what the problem
is.  I've seen this corruption on multiple systems, some of which
regularly run several months between reboots/kernel upgrades, so I really
don't think it's bad RAM

Also, on the system with the most accounting rules (around 80 of them),
it was almost always the same address that got corrupted, and always one
of the ones near the top of the list.  On other systems with relatively
few (~10) rules, I've seen corruption toward the end of the list.

 12:00am  up 6 days,  6:43, 20 users,  load average: 1.26, 0.91, 0.92
IP accounting rules
 pkts bytes dir prot source               destination          ports
 385K  102M i/o all  yoda.fdt.net         na.ts1.gnv.fdt.net/24 n/a
 414K   38M i/o all  na.ts1.gnv.fdt.net/24 yoda.fdt.net         n/a
2821K  411M i/o all  anywhere             yoda.fdt.net         n/a
2567K 1015M i/o all  yoda.fdt.net         anywhere             n/a
 795K   96M i/o all  yoda.fdt.net         localnet/24          n/a
1050K  204M i/o all  localnet/24          yoda.fdt.net         n/a
 661K  515M i/o tcp  yoda.fdt.net         anywhere             www -> any
68300   75M i/o tcp  yoda.fdt.net         anywhere             20 -> any
 3551  273K i/o icmp anywhere             yoda.fdt.net         any
65500 6530K i/o icmp 13.229.48.17         anywhere             any

13.229.48.17 should have been 205.229.48.17 = yoda.fdt.net.

This is all with 2.0.x kernels, currently 2.0.2[7-9].

A closer look at my logs shows that when this sort of corruption happens,
it is always the 10th rule (no matter what that rule is)...at least it was
in the few dozen cases I just examined. 

------------------------------------------------------------------
 Jon Lewis <jlewis@fdt.net>  |  Unsolicited commercial e-mail will
 Network Administrator       |  be proof-read for $199/hr.
________Finger jlewis@inorganic5.fdt.net for PGP public key_______

[prev in list] [next in list] [prev in thread] [next in thread]