[PATCH] Re: Using the argus server as a NetFlow listener

[Carter Bullard]

Hey Terry,
If you make these changes to ./common/argus_client.c, this should
fix your problem, at least this current problem ;o)  The idea is that
the test as to whether we should sleep for a while or not, should also
test if the variable "retn" is zero or not (didn't get anything from
a client?).  So we need to add that to the conditional.
However, the current declaration of "retn" needs to move
out of the conditional scope to the function scope, so you have to
move the declaration of "retn" higher up in the function.  Hopefully,
this makes sense :o)

I'll have new code up maybe on Sunday night, so if you can give
this patch a try, until then, that would be great!!

Carter


==== //depot/argus/clients/common/argus_client.c#86 - /home/carter/ 
argus/clients/common/argus_client.c ====
1947a1948
 >    int retn = 0;
1956c1957
<       int retn = 0, width = 0, i;
---
 >       int width = 0, i;
2031d2031
<
2070c2070,2071
<       if (!parser->RaParseDone && ArgusParser- 
 >ArgusReliableConnection)
---
 >
 >       if (!parser->RaParseDone && ArgusParser- 
 >ArgusReliableConnection && !retn)



On Oct 26, 2007, at 11:58 AM, Terry Burton wrote:

> On 10/24/07, Carter Bullard <carter at qosient.com> wrote:
>> Thanks for the patches.  I'll take a look and integrated as needed.
>> The -d option on radium "toggles" the daemon flag, so if the
>> /etc/radium.conf file has the DAEMON variable set to "on", then
>> the -d option will turn it off, so check that.
>
> Hi Carter,
>
> I noticed that was the case but that the behaviour differed from  
> that of argus.
>
>> I know you had the -X option, so I'll make sure that the
>> DAEMON flag setting is cleared when you use the -X option.
>
> Excellent, that would seem to be the best solution. Thanks.
>
>> If you have any problems, don't hesitate to send to the list.
>
> A short while after running radium -X -C -S 1006 I noticed that the
> receive queues for the sockets bound to the NetFlow port had grew to
> their maximum size without radium occupying any notable CPU resource.
>
> Upon investigating I found that the ArgusReadStream function was
> invoking ArgusReadCiscoDatagramSocket which reads via recvfrom only
> one single message/packet from the NetFlow UDP socket. After this
> ArgusReadStream exits and radium sleeps for some ~0.5sec interval.
> Since our router generates significantly more netflow packets than
> ~2/sec, the incoming UDP queue is not consumed fast enough to keep up.
>
> Presumably there ought to be a conditional loop around the either the
> recvfrom or select system calls for this socket to detect the
> instances when a single read is insufficient to entirely drain the
> queue. Since I am unsure at what level you would think that this
> conditional should be placed (ArgusReadCiscoDatagramSocket,
> ArgusReadStream, or even further out) I have not attempted to fix this
> myself.
>
> Please let me know if I am thinking along the right lines and if you
> would like me to provide any further information or testing for this.
>
>
> Warm regards,
>
> Tez
>