Argus 3.0.6 and dnaclusters

Carter Bullard carter at qosient.com
Thu Dec 13 18:36:11 EST 2012


Hey Chris,
argus should be getting its packets using the routine ArgusGetPacket(), reading
packets from a " notselectable " interface, which starts on line 3823 in ArgusSource.c.

So, argus should try to read 4 packets, using pcap_next_ex(), if its there, 
pcap_dispatch() it its not, and if we don't get any packets (pkts == 0), then
we're suppose to call nanosleep(), for 25 mSecs,  on line 3820.  

Interesting that it never hits this call ?

Carter


On Dec 13, 2012, at 5:37 PM, Chris Wakelin <c.d.wakelin at reading.ac.uk> wrote:

> Yes it's a bug in DNA. I can't remember seeing a commit that claimed to
> fix it; the last I saw, I think on the topic was the developer's reply to
> 
> http://listgateway.unipi.it/pipermail/ntop-misc/2012-September/003279.html
> 
> (and IPv6 is fine now BTW :-) )
> 
> As far as I remember, for some reason Bro IDS manages to use select()
> without hitting the problem, I think, perhaps by adding empty select()
> calls with a timeout:
> 
> From Bro's IOSource.cc:
> 
>>        if ( all_idle )
>>                {
>>                // Interesting: when all sources are dry, simply sleeping a
>>                // bit *without* watching for any fd becoming ready may
>>                // decrease CPU load. I guess that's because it allows
>>                // the kernel's packet buffers to fill. - Robin
>>                timeout.tv_sec = 0;
>>                timeout.tv_usec = 20; // SELECT_TIMEOUT;
>>                select(0, 0, 0, 0, &timeout);
>>                }
> 
> I had a go at doing that in ARGUS but it made no difference (perhaps I
> put it in the wrong place!).
> 
> I'm happy to try things out on the test server, now I've updated
> everything (I'm using tcpreplay of a 10GB pcap over a 1Gb link from
> another machine using Intel e1000e cards and the time-limited DNA demo
> licence, so I can only test for 5 mins at a time).
> 
> Best Wishes,
> Chris
> 
> On 13/12/12 22:11, Carter Bullard wrote:
>> If I remember, the 100% CPU was a bug in the DNA code itself?
>> Was there a resolution to that?
>> If you would be a guinea pig, we can play around with it?
>> 
>> Carter 
>> 
>> 
>> On Dec 13, 2012, at 4:30 PM, Chris Wakelin <c.d.wakelin at reading.ac.uk> wrote:
>> 
>>> I've just tried 3.0.7.2 with latest PF_RING svn (post v5.5.1) and DNA
>>> clusters on a test machine. It looks like we do still need the name
>>> change (added "dna" to the list of interfaces that includes "dag" and
>>> "napa") and it still uses 100% of CPU, but otherwise appears to work.
>>> 
>>> Best Wishes,
>>> Chris
> 
> -- 
> --+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+-
> Christopher Wakelin,                           c.d.wakelin at reading.ac.uk
> IT Services Centre, The University of Reading,  Tel: +44 (0)118 378 8439
> Whiteknights, Reading, RG6 2AF, UK              Fax: +44 (0)118 975 3094
> 

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


More information about the argus mailing list