Argus giving wrong bytes results ?

Carter Bullard carter at qosient.com
Wed Jul 21 23:39:24 EDT 2010


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.   

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3815 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20100721/bd35d1db/attachment.bin>


More information about the argus mailing list