re report of a bug
Carter Bullard
cbullard at nortelnetworks.com
Mon Mar 29 08:21:24 EST 1999
Hey Peter,
So I think I found the problem, and so
I have a patch for you to try. This is a portion of
a diff of the patched argus-1.8/common/argus_parse.c
against the argus-1.7beta.1e/common/argus_parse.c file.
You may have already applied a part of this patch,
so you may have to patch it by hand. Basically we are
testing for (errno == EAGAIN) which indicates that we
returned with an error, but we should go back and
read again, which we weren't doing.
Hope this helps,
Carter
#partial output of
#diff argus-1.7beta.1e/common/argus_parse.c argus-1.8/common/argus_parse.c
--------------diff file begins here----------------
1229c1248
< register int cnt, size, retn = 1;
---
> int cnt, size, reading = 1, retn = 1;
1235,1237c1254,1271
< while ((cnt = read (fd, &ptr, size)) > 0) {
< retn = 0;
< handle_datum (&ptr, bpfcode);
---
> while (reading) {
> cnt = 0;
> while (cnt < size) {
> if ((retn = read (fd, &ptr, (size - cnt))) > 0)
> cnt += retn;
> else {
> if (!((retn < 0) && (errno == EAGAIN))) {
> if (cnt)
> fprintf (stderr, "%s: read_file(): unexpected EOF read truncated!\n", progname);
> reading = 0;
> retn = 0;
> break;
> }
> }
> }
>
> if (reading)
> handle_datum (&ptr, bpfcode);
---------------cut here-------------------------------
-----Original Message-----
From: Peter Van Epp [mailto:vanepp at sfu.ca]
Sent: Tuesday, March 23, 1999 12:29 PM
To: argus at sei.cmu.edu
Subject: re report of a bug
Carter:
It looks to me like this last bug report may have fallen between the
cracks since no one has grabbed the file that exhibits the fault. As well
at the end is a simple patch to argus to make it compatable with FreeBSD 3.1
that may or may not have been included in 1.8.
Peter Van Epp / Operations and Technical Support
Simon Fraser University, Burnaby, B.C. Canada
Some reasonably good news for a change :-) by extracting just the port
31337 lines via ra -r argus_file -w t port 31337, I have a 9k file that
exhibits the problem (in a different place) by losing one line if processed
by zcat t.gz | ra -c -n against ra -r t -c -n. I have put the file up for
anon ftp on ftp.sfu.ca in /pub/newbridge-vivid/t.gz (again you will need to
cd /pub/newbridge-vivid then do the get).
Peter Van Epp / Operations and Technical Support
Simon Fraser University, Burnaby, B.C. Canada
>From vanepp Thu Mar 4 18:42:13 1999
Subject: Re: client problems on Linux (fwd)
To: cbullard at nortelnetworks.com (Carter Bullard)
Date: Thu, 4 Mar 1999 18:42:13 -0800 (PST)
In-Reply-To: <4DB1CB3B0091D111807600805FA718FB01BED99F at bayxbl02.corpeast.baynetworks.com> from "Carter Bullard" at Mar 4, 99 04:08:39 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 2275
The new argus_parse.c file works, but there is a strange one line
inconsistancy still:
-rw-r--r-- 1 vanepp wheel 163856460 Feb 10 08:06 argus.log.Feb10_08_06
-rw-r--r-- 1 root wheel 115824 Mar 3 08:35 argus.log.Feb10_08_06.ref
-rw-r--r-- 1 root wheel 115824 Mar 4 18:06 argus.log.Feb10_08_06.ref.n
-rw-r--r-- 1 root wheel 115710 Mar 4 18:03 argus.log.Feb10_08_06.t1
-rw-r--r-- 1 root wheel 115710 Mar 4 18:04 argus.log.Feb10_08_06.t2
The top one is the file (which was gzipped). argus.log.Feb10_08_06.ref
is ra run against the file yesterday (old argus_parse.c),
argus.log.Feb10_08_06.ref.n is ra -r argus.log.Feb10_08_06 -c -n port 31337
run against the file just now (new argus_parse.c) and compares identical to
the one from yesterday. argus.log.Feb10_08_06.t1 and argus.log.Feb10_08_06.t2
are the output from gzip argus.log.Feb10_08_06 | ra -c -n port 31337 >file.
The two of them match each other (which is one problem that Russel was having,
different runs didn't match) but there is one line in the middle of the file
missing in the piped input case, I'd guess a buffer filling bug of some kind:
r2d2# diff argus.log.Feb10_08_06.ref argus.log.Feb10_08_06.t1
265d264
< Tue 02/09 17:46:50 udp 142.58.25.7.31337 <- 208.253.123.143.1056 0 1 0 26 TIM
which may indicate a buffer losing a line in the pipe case:
argus.log.Feb10_08_06.ref (line 264-267)
Tue 02/09 17:46:50 udp 142.58.25.6.31337 <- 208.253.123.143.1056 0
1 0 26 TIM
Tue 02/09 17:46:50 udp 142.58.25.7.31337 <- 208.253.123.143.1056 0
1 0 26 TIM
Tue 02/09 17:46:50 udp 142.58.25.8.31337 <- 208.253.123.143.1056 0
1 0 26 TIM
argus.log.Feb10_08_06.t1 (lines 264 and 265, line 265 above is missing)
Tue 02/09 17:46:50 udp 142.58.25.6.31337 <- 208.253.123.143.1056 0
1 0 26 TIM
Tue 02/09 17:46:50 udp 142.58.25.8.31337 <- 208.253.123.143.1056 0
1 0 26 TIM
I can put the compressed file up for ftp if you like, but even
compressed it is some 66 megs.
Peter Van Epp / Operations and Technical Support
Simon Fraser University, Burnaby, B.C. Canada
Some reasonably good news for a change :-) by extracting just the port
31337 lines via ra -r argus_file -w t port 31337, I have a 9k file that
exhibits the problem (in a different place) by losing one line if processed
by zcat t.gz | ra -c -n against ra -r t -c -n. I have put the file up for
anon ftp on ftp.sfu.ca in /pub/newbridge-vivid/t.gz (again you will need to
cd /pub/newbridge-vivid then do the get).
Peter Van Epp / Operations and Technical Support
Simon Fraser University, Burnaby, B.C. Canada
>From vanepp Fri Jan 29 09:58:31 1999
Subject: Argus-1.7.beta.1e patches for FreeBSD 3.0
To: argus at lists.andrew.cmu.edu
Date: Fri, 29 Jan 1999 09:58:31 -0800 (PST)
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 2163
Below is a basically trivial patch (rename the udpcb structure to
udpcba because FreeBSD 3.0 has used udpcb for something else) to make argus
compile on FreeBSD 3.0 release.
While I'm here, has anyone used the FreeBSD HARP ATM support to attach
argus to an ATM PVC? I have a couple of Fore PCI cards and the necessary
servers on order, but I'd rather not reinvent the wheel if I don't have to.
Peter Van Epp / Operations and Technical Support
Simon Fraser University, Burnaby, B.C. Canada
in include:
*** cons_udp.h.orig Sat Jan 30 01:21:49 1999
--- cons_udp.h Sat Jan 30 01:30:10 1999
***************
*** 51,57 ****
arg_uint8 ttl, tos;
};
! struct udpcb {
struct argtimeval startime, lasttime;
arg_uint32 rev, status;
struct UDP_CON_OBJECT src, dst;
--- 51,57 ----
arg_uint8 ttl, tos;
};
! struct udpcba {
struct argtimeval startime, lasttime;
arg_uint32 rev, status;
struct UDP_CON_OBJECT src, dst;
***************
*** 62,68 ****
struct QUEUE_HEADER qhdr;
struct physLink link;
struct THA_OBJECT tha;
! struct udpcb udp_cb;
};
#define USEQ_HASHSIZE 9029
--- 62,68 ----
struct QUEUE_HEADER qhdr;
struct physLink link;
struct THA_OBJECT tha;
! struct udpcba udp_cb;
};
#define USEQ_HASHSIZE 9029
in server:
*** cons_udp.c.orig Fri Jan 29 06:44:26 1999
--- cons_udp.c Sat Jan 30 01:25:08 1999
***************
*** 209,215 ****
struct argtimeval *tvp;
int rev;
{
! struct udpcb *udpCb;
udpCb = &uh->udp_cb;
udpCb->lasttime = *tvp; uh->qhdr.last_time = *tvp;
--- 209,215 ----
struct argtimeval *tvp;
int rev;
{
! struct udpcba *udpCb;
udpCb = &uh->udp_cb;
udpCb->lasttime = *tvp; uh->qhdr.last_time = *tvp;
***************
*** 297,303 ****
int len;
{
struct UDP_OBJECT *ptr = NULL;
! struct udpcb *udpCb;
if (ptr = (struct UDP_OBJECT *) calloc (1, sizeof (*ptr))) {
udpCb = &ptr->udp_cb;
--- 297,303 ----
int len;
{
struct UDP_OBJECT *ptr = NULL;
! struct udpcba *udpCb;
if (ptr = (struct UDP_OBJECT *) calloc (1, sizeof (*ptr))) {
udpCb = &ptr->udp_cb;
More information about the argus
mailing list