Argus giving wrong bytes results ?

Mike Tancsa mike at sentex.ca
Thu Jul 22 16:13:19 EDT 2010


Hi Carter,
         I just confirmed on my other production machine the patched 
version from this afternoon works!  Thanks again for fixing!

         ---Mike

At 10:03 AM 7/22/2010, Carter Bullard wrote:
>Nooooo, this is not the good news I was looking forward to.
>Late last night, I was on a single machine running argus-clients-3.0.3.15,
>that demonstrated the error, and then I would run argus-clients-3.0.3.16 and
>the problem would go away.  I flipped them 10 times, at least, all with good
>results!!!
>
>Just using ./configure; make
>
>This should fix reading netflow from the wire.  The stored records 
>that have been
>'corrupted' are not going to be fixed with this.
>
>No luck reading netflow from the routers?   All records corrupted?
>
>Carter
>
>On Jul 22, 2010, at 9:52 AM, Mike Tancsa wrote:
>
> > At 11:39 PM 7/21/2010, Carter Bullard wrote:
> >> Hey Mike,
> >> With the aid and assistance of list members, we've got a fix for 
> the netflow record
> >> problem up on the 
> server.  http://qosient.com/argus/dev/argus-clients-3.0.3.16.tar.gz.
> >> Give it a try, and if you're cool, then I'll announce its 
> general availability.
> >
> > Hi Carter et al, what args are people on FreeBSD RELENG_7 i386 
> using for configure ? I am still seeing this problem on RELENG_7
> >
> >        ---Mike
> >
> >> Not at all sure why FreeBSD would have this problem and not 
> other machines.
> >> Briefly, problem involved writing past a struct with 
> uninitialized data, due to a
> >> miscalculated DSR length.  No reason why other machines should 
> have tolerated
> >> the extra data.  Maybe FreeBSD does something a bit differently 
> with struct alignment
> >> or possibly the stack?
> >>
> >> Hopefully this bug is now historical.
> >>
> >> Carter
> >>
> >> On Jul 20, 2010, at 3:01 PM, Mike Tancsa wrote:
> >>
> >> >
> >> > One more update. If I compile and run it on an AMD64 bit 
> freebsd box, it seems to work fine, but thats with a much newer 
> cisco box. Not sure if that makes a differences or not. So it would 
> appear its just broken on FreeBSD 32bit hosts, not 64bit.
> >> >
> >> > 0(offsite)# ./ra -N 20 -L0 -n -Zb -S cisco://67.43.129.252:9996
> >> >         StartTime    Flgs  Proto            SrcAddr  Sport 
> Dir         DstAddr  Dport  TotPkts   TotBytes State
> >> >   15:00:10.005000 
> Ne         tcp       64.7.134.190.2974     <? 
> 69.90.162.175.143           2        151  _FPA
> >> >   15:00:10.021000 
> Ne         tcp       64.7.152.157.4402     <? 
> 69.63.176.174.80           4        370  _FPA
> >> >   15:00:10.021000 
> Ne         tcp       64.7.134.190.2971     <? 
> 69.90.162.175.143           2        151  _FPA
> >> >   15:00:10.041000 
> Ne         tcp      72.26.192.194.80        -> 
> 64.7.134.136.61992        17      19212 FSPA_
> >> >   15:00:10.045000 
> Ne         tcp     206.220.42.181.80        -> 
> 67.43.140.4.60547        14      14400 FSPA_
> >> >   15:00:10.049000 
> Ne         tcp    219.149.138.230.42508     -> 
> 64.7.134.137.80           9        718 FSPA_
> >> >   15:00:10.049000 
> Ne         tcp       67.43.140.67.2293     <? 
> 65.55.242.32.80           1         40    _R
> >> >   15:00:10.069000 
> Ne         tcp       69.63.189.26.80        -> 
> 64.7.134.136.61994         6       3900 FSPA_
> >> >   15:00:10.077000 
> Ne         tcp      216.251.32.97.110       -> 
> 64.7.134.186.35255        11        693 FSPA_
> >> >   15:00:10.093000 
> Ne         tcp        84.0.20.202.1118      ?> 
> 67.43.140.158.63190         4       1123  FPA_
> >> >   15:00:10.093000 
> Ne         tcp       75.23.177.57.53522     ?> 
> 67.43.140.26.13460         1         40   RA_
> >> >   15:00:10.105000 
> Ne         tcp      207.38.101.11.80        -> 
> 64.7.134.136.61991         8       2633 FSPA_
> >> >   15:00:10.109000 
> Ne         tcp    206.214.222.214.80        -> 
> 67.43.137.133.3736          4        622 FSPA_
> >> >   15:00:10.113000 
> Ne         tcp    206.214.222.214.80        -> 
> 67.43.137.133.3737          4       1241 FSPA_
> >> >   15:00:10.113000 
> Ne         tcp      129.33.178.11.80        -> 
> 64.7.136.190.1092         72      93806 FSPA_
> >> >   15:00:10.113000 
> Ne         tcp     203.213.82.238.47673     -> 
> 67.43.140.234.52437         4        806 SRPA_
> >> >   15:00:10.121000 
> Ne         tcp       67.43.140.91.60920    <? 
> 66.114.49.23.80           1         40    _R
> >> >   15:00:10.145000 
> Ne         tcp     89.164.200.246.54735     -> 
> 67.43.140.202.2509          3        128  FSA_
> >> >   15:00:10.145000 
> Ne         tcp       89.151.99.84.80        -> 
> 64.7.134.136.61993         4       1779  FSA_
> >> >   15:00:10.153000 
> Ne         tcp       64.7.134.136.61931    <? 
> 209.8.115.152.80           2         80   _FA
> >> > 0(offsite)#
> >> >
> >> >
> >> > At 02:40 PM 7/20/2010, Mike Tancsa wrote:
> >> >> At 09:36 PM 7/15/2010, Carter Bullard wrote:
> >> >>> OK, well I've replayed your pcap file with the netflow 
> records to a redhat linux box 32-bit
> >> >>> and a netbsd 64 bit machine, a mac os x 64-bit and I can't 
> get any errors.
> >> >>>
> >> >>> I put a new version of 3.0.3.15 on the server this 
> afternoon, and i went through to make sure
> >> >>> that all the defines are correct etc....  If you haven't 
> grabbed it today, go get it and see if you
> >> >>> get any kind of relief.
> >> >>>
> >> >>> Seems like it must be an alignment problem.   If you still 
> get errors, send me your
> >> >>> ./include/argus_config.h file, and config.log.
> >>
>
>
>
>
>




More information about the argus mailing list