new clients on the development server - netflow and ratop
Carter Bullard
carter at qosient.com
Thu Jul 22 16:41:21 EDT 2010
Gentle people,
New code on the server as a result of debugging the netflow collection bug
on FreeBSD. Problem was dealing with 64-bit integers on 32-bit little endian
architectures, we were running into an alignment problem.
http://qosient.com/argus/dev/argus-clients-3.0.3.16.tar.gz
This code also has a lot of fixes for memory leaks and uninitialized bytes, as
well as fixes for ratop() and rasql*() programs. There is still an outstanding
issue with regard to aggregation and transaction numbers, and
I should have a fix for that by the end of this week.
I'm hoping to release this code in the next few weeks. If there is something that
has not been addressed that you think needs fixing, please send some email
to the list or to me.
Hope all is most excellent, and thanks for all the effort and support!!!!!
Carter
On Jul 22, 2010, at 4:13 PM, Mike Tancsa wrote:
> 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.
>> >>
>>
-------------- 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/20100722/bb56290d/attachment.bin>
More information about the argus
mailing list