beta.13 (and beta.12) insect

[Neil Long]

Just a thought - are you having major icmp floods with these MS-RPC worms?

Until we filtered them my argus collector was dropping vast amounts of 
packets as reported
by tcpdump and friends

regards
Neil

At 15:28 25/08/2003, Carter Bullard wrote:
>Hey Peter,
>    I'm printing out a %d, rather than a %u.  Its changed
>now, but the unsigned int version suggests you dropped a
>huge amount of packets.  I've gone over the code that generates
>the metric, and it hasn't changed, and it looks good.
>
>5 x a second, argus fetches the pcap_stats() and accumulates
>the values that it returns until a Man record is generated,
>but default that is every 300 seconds.  Argus is tallying the
>dropped packets on each monitored interface, as a long long, and
>then converts that to an unsigned int to package the value in
>the status man record.  The byte and packet counts are sent as
>long long's.  We're not checking if the drop value is larger
>than an unsigned int when we package it, so there is a
>potential gotcha, but the error here will be that we
>always underreport drops.
>
>But the code hasn't changed in at least a few years.
>
>Carter
>
>
> > -----Original Message-----
> > From: owner-argus-info at lists.andrew.cmu.edu
> > [mailto:owner-argus-info at lists.andrew.cmu.edu] On Behalf Of
> > Peter Van Epp
> > Sent: Monday, August 18, 2003 3:17 PM
> > To: argus-info at lists.andrew.cmu.edu
> > Subject: beta.13 (and beta.12) insect
> >
> >
> >       Argus-2.0.beta13 (and 12) on RedHat 9.0 looks to have a
> > drop problem:
> >
> > [vanepp at sniffer data]$ ra -r argus.out -n -- man
> > 18 Aug 03 12:12:11    man version=2.0     probeid=3848370891
> >               STA
> > 18 Aug 03 12:57:11    man  pkts   2199227  bytes    913750320
> >  drops -124767  CON
> > 18 Aug 03 13:02:11    man  pkts   2779115  bytes    922022496
> >  drops 172160  CON
> >
> >       There shouldn't be a negative number of drops (unless
> > argus has been
> > creating packets of course :-)). Haven't checked the BSDs for
> > this one yet.
> >
> > Peter Van Epp / Operations and Technical Support
> >