beta.13 (and beta.12) insect

[Peter Van Epp]

	Ironically the 1.8.1 machine that is outside my gateway (and thus 
seeing the ping floods) survived fine (although my perl scripts didn't, they
run out of memory trying to process all the data :-)). This 2.0.6 server is
inside my net where it doesn't see that traffic. I expect the problem is that
I haven't boosted whatever Linux uses for the bpf equivielent buffer and it
is overflowing and causing massive packet loss and possibly indeed overflowing
the signed int with losses. I'll poke at it more (including adding a kernel
patch to boost the BFP equiv buffer size under Linux and see if that helps).
I may also put a FreeBSD box in place (where I already know how and how much
I can boost the BPF buffer) and see how it does. I've been meaning to point
tcpreplay at the linux box and see how it does at load but haven't gotten to
it yet :-).

Peter Van Epp / Operations and Technical Support 
Simon Fraser University, Burnaby, B.C. Canada


On Mon, Aug 25, 2003 at 05:12:34PM +0100, Neil Long wrote:
> 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
> >>
>