Direction and IP/TCP timeout settings
Carter Bullard
carter at qosient.com
Fri Jul 19 00:57:35 EDT 2013
Grab argus-3.0.7.3 from here
http://qosient.com/argus/dev/argus-latest.tar.gz
Still need to apply the patch.
Carter
On Jul 19, 2013, at 12:19 AM, Craig Merchant <cmerchant at responsys.com> wrote:
> We're running 3.0.7.2.
>
> I'll give the patch a try tomorrow and let you know what change (if anything).
>
> Thanks!
>
> Craig
>
> -----Original Message-----
> From: Carter Bullard [mailto:carter at qosient.com]
> Sent: Thursday, July 18, 2013 7:44 PM
> To: Craig Merchant
> Cc: Argus (argus-info at lists.andrew.cmu.edu)
> Subject: Re: [ARGUS] Direction and IP/TCP timeout settings
>
> Hey Craig,
> OK, so I went through this complete thread, and I apologize for
> the rudimentary question, but...
>
> What version of argus are you running ???
>
> We identified that one of the nanosleep() calls in the packet ingest
> engine was a little long in earlier emails, and we took the call
> out. It is possible that the other nanosleep()s need adjustment,
> or removal.
>
> Try this type of patch, so see if things get better. Your line numbers
> may not match, as this is from a modified ArgusSource.c. The specific
> line is in the routine ArgusGetPackets().
>
> ==== //depot/argus/argus/argus/ArgusSource.c#110 - /Volumes/Users/carter/argus/argus/argus/ArgusSource.c ====
> 3816c3825
> < struct timespec tsbuf = {0, 250000}, *ts = &tsbuf;
> ---
>> struct timespec tsbuf = {0, 2500}, *ts = &tsbuf;
>
> This nanosleep() is in the notselectable() branch of the basic packet engine,
> so should be the one that your pf_ring() code is using.
>
> If there is benefit, and argus isn't eating an entire core, then even 250 maybe
> a good number.
>
> Carter
>
> On Jul 18, 2013, at 8:43 PM, Craig Merchant <cmerchant at responsys.com> wrote:
>
>> Just wanted to give you another data point...
>>
>> During a sample period, racluster found 448391 flows that contained 5,266,137 packets. It was unsure of the direction of about 60% of those flows. So if Argus missed both the SYN and SYNACK for those 60% because those packets were dropped, we should see around 538,069 dropped packets. Which would be a little over 10% of the total packet volume. Yet the interface is showing something like 0.1% packet drop.
>>
>> I recorded about 10m packets using tcpdump (tcpdump -i eth3 -w tcpdump.pcap). I tried to convert them to argus format by running: argus -r tcpdump.pcap -A -J -R -Z -w tcpdump.argus
>>
>> I got the following:
>>
>> *** glibc detected *** argus: double free or corruption (fasttop): 0x00000000025 bc610 ***
>> ======= Backtrace: =========
>> /lib64/libc.so.6(+0x760e6)[0x7fa22635e0e6]
>> argus[0x42b465]
>> argus[0x41b5fc]
>> argus[0x40458b]
>> argus[0x4070f6]
>> /lib64/libc.so.6(__libc_start_main+0xfd)[0x7fa226306cdd]
>> argus[0x403bd9]
>> ======= Memory map: ========
>> 00400000-00461000 r-xp 00000000 fd:00 71223417 /usr/lo cal/sbin/argus
>> 00660000-00664000 rw-p 00060000 fd:00 71223417 /usr/lo cal/sbin/argus
>> 00664000-0066a000 rw-p 00000000 00:00 0
>> 025bc000-025dd000 rw-p 00000000 00:00 0 [heap]
>> 7fa225a98000-7fa225aae000 r-xp 00000000 fd:00 78233953 /lib64/ libgcc_s-4.4.7-20120601.so.1
>> 7fa225aae000-7fa225cad000 ---p 00016000 fd:00 78233953 /lib64/ libgcc_s-4.4.7-20120601.so.1
>> 7fa225cad000-7fa225cae000 rw-p 00015000 fd:00 78233953 /lib64/ libgcc_s-4.4.7-20120601.so.1
>> 7fa225cb5000-7fa2260c0000 rw-p 00000000 00:00 0
>> 7fa2260c0000-7fa2260e3000 r-xp 00000000 fd:00 9388269 /opt/rb /lib/libpfring.so
>> 7fa2260e3000-7fa2262e2000 ---p 00023000 fd:00 9388269 /opt/rb /lib/libpfring.so
>> 7fa2262e2000-7fa2262e4000 rw-p 00022000 fd:00 9388269 /opt/rb /lib/libpfring.so
>> 7fa2262e8000-7fa226472000 r-xp 00000000 fd:00 78233613 /lib64/ libc-2.12.so
>> 7fa226472000-7fa226671000 ---p 0018a000 fd:00 78233613 /lib64/ libc-2.12.so
>> 7fa226671000-7fa226675000 r--p 00189000 fd:00 78233613 /lib64/ libc-2.12.so
>> 7fa226675000-7fa226676000 rw-p 0018d000 fd:00 78233613 /lib64/ libc-2.12.so
>> 7fa226676000-7fa22667b000 rw-p 00000000 00:00 0
>> 7fa226680000-7fa226703000 r-xp 00000000 fd:00 78233621 /lib64/ libm-2.12.so
>> 7fa226703000-7fa226902000 ---p 00083000 fd:00 78233621 /lib64/ libm-2.12.so
>> 7fa226902000-7fa226903000 r--p 00082000 fd:00 78233621 /lib64/ libm-2.12.so
>> 7fa226903000-7fa226904000 rw-p 00083000 fd:00 78233621 /lib64/ libm-2.12.so
>> 7fa226908000-7fa22691f000 r-xp 00000000 fd:00 78233637 /lib64/ libpthread-2.12.so
>> 7fa22691f000-7fa226b1f000 ---p 00017000 fd:00 78233637 /lib64/ libpthread-2.12.so
>> 7fa226b1f000-7fa226b20000 r--p 00017000 fd:00 78233637 /lib64/ libpthread-2.12.so
>> 7fa226b20000-7fa226b21000 rw-p 00018000 fd:00 78233637 /lib64/ libpthread-2.12.so
>> 7fa226b21000-7fa226b25000 rw-p 00000000 00:00 0
>> 7fa226b28000-7fa226b5f000 r-xp 00000000 fd:00 9388267 /opt/rb /lib/libpcap.so.1.1.1
>> 7fa226b5f000-7fa226d5f000 ---p 00037000 fd:00 9388267 /opt/rb /lib/libpcap.so.1.1.1
>> 7fa226d5f000-7fa226d61000 rw-p 00037000 fd:00 9388267 /opt/rb /lib/libpcap.so.1.1.1
>> 7fa226d61000-7fa226d62000 rw-p 00000000 00:00 0
>> 7fa226d68000-7fa226d88000 r-xp 00000000 fd:00 78233603 /lib64/ ld-2.12.so
>> 7fa226efd000-7fa226f80000 rw-p 00000000 00:00 0
>> 7fa226f85000-7fa226f87000 rw-p 00000000 00:00 0
>> 7fa226f87000-7fa226f88000 r--p 0001f000 fd:00 78233603 /lib64/ ld-2.12.so
>> 7fa226f88000-7fa226f89000 rw-p 00020000 fd:00 78233603 /lib64/ ld-2.12.so
>> 7fa226f89000-7fa226f8b000 rw-p 00000000 00:00 0
>> 7fa226f8b000-7fa226f8d000 rw-p 00000000 00:00 0
>> 7fff11d0c000-7fff11d21000 rw-p 00000000 00:00 0 [stack]
>> 7fff11d70000-7fff11d71000 r-xp 00000000 00:00 0 [vdso]
>> ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsysca ll]
>> Aborted
>>
>> I've got no idea what that means...
>>
>> Am I following the right steps to convert the output of tcpdump into something ra clients can read?
>>
>> Thanks.
>>
>> Craig
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6837 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20130719/298a2735/attachment.bin>
More information about the argus
mailing list