Argus 3.0.6.1/2 on BiviOS 5.1.6 issues

[Carter Bullard]

Hey Eric,
I found the problem with the argus-3.0.6.1 code.  We're missing this line:

p4 diff -dc ArgusOutput.c
==== //depot/argus-3.0.6/argus/argus/ArgusOutput.c#2 - /Volumes/Users/carter/argus/release/argus-3.0.6/argus/argus/ArgusOutput.c ====
***************
*** 1075,1080 ****
--- 1075,1081 ----
                    ArgusLog (LOG_ERR, "ArgusCheckClientStatus: ArgusCalloc %s", strerror(errno));
  
                 client->fd = fd;
+                client->startime = output->ArgusGlobalTime;
  #ifdef ARGUSDEBUG
                 ArgusDebug (2, "ArgusCheckClientStatus() new client\n");
  #endif

Somehow, this got past our testing.  I will put out argus-3.0.6.2 almost immediately, since this will
cause a lot of problems for a lot of people.

Sorry for the inconvenience !!!!!!

Carter

On Jun 19, 2012, at 3:07 PM, Carter Bullard wrote:

> Hey Eric,
> If you apply this patch to the argus code, it will turn off the idle client checks.
> That should get us past the first road block.  Seems that ArgusGlobalTime,
> isn't set up properly?  If output->ArgusGlobalTime is just zero, then there is
> a better fix, but I need to know why the global timer is messed up.
> 
> ==== //depot/argus-3.0.6/argus/argus/ArgusOutput.c#2 - /Volumes/Users/carter/argus/release/argus-3.0.6/argus/argus/ArgusOutput.c ====
> ***************
> *** 735,740 ****
> --- 735,741 ----
>                             }
> 
>                          } else {
> + /*
>                             struct timeval tvbuf, *tvp = &tvbuf;
>  #ifdef ARGUSDEBUG
>                             ArgusDebug (5, "ArgusOutputProcess() %d client(s) not ready fd %d sock 0x%x start %d", output->ArgusClients->count, client->fd, client->sock, client->ArgusClientStart);
> ***************
> *** 747,752 ****
> --- 748,754 ----
>                                }
>                                client->ArgusClientStart = 1;
>                             }
> + */
>                          }
>                          client = (void *) client->qhdr.nxt;
>                       }
> 
> 
> Carter
> 
> 
> On Jun 19, 2012, at 3:00 PM, Carter Bullard wrote:
> 
>> Hey Eric,
>> These messages are saying that radium is connecting to the various
>> argus instances, but it never requests data from the argus.
>> The argus transport protocol is pretty simple, you connect to argus,
>> it sends an argus management record to the client, that has a bunch
>> of information about what it is, how often it sends management records,
>> if it requires security, etc…  Radium, has the option of sending a filter,
>> to argus (remote filtering), or requesting data outside of the current
>> data stream, but if all is ready, radium should send a "START" to argus.
>> Once argus gets the "START", it blow argus records down the pipe.
>> 
>> So we normally have a 10 second timer before we time out the
>> session, but you don't seem to be waiting at all.
>> 
>>> Jun 19 10:13:08 CPU-1c0 argus[29290]: 19 Jun 12 10:13:07.028468
>>> connect from CPU-X
>>> Jun 19 10:13:08 CPU-1c0 argus[29290]: 19 Jun 12 10:13:07.029010
>>> ArgusCheckClientMessage: client (null) never started: timed out
>> 
>> So you waited approximately 500 uSec.  We should take out the
>> check or extend the time.  Not sure how this could be screwing up,
>> but let me see what code to comment out to see if we can get it to work.
>> 
>> Carter
>> 
>> On Jun 19, 2012, at 1:32 PM, Eric Gustafson wrote:
>> 
>>> Hi Carter and friends,
>>> I saw in a recent email to the list that there are some Bivio-related
>>> Argus fixes coming, but I wasn't sure if this was related or not.
>>> Here's the backstory:
>>> Recently, our Bivio tech upgraded a few of our Bivio 7500 boxes to the
>>> latest rev of BiviOS, moving us from 5.1.4 to 5.1.6 to take care of
>>> security patches.  This, unfortunately, seems to have broken Argus,
>>> and both versions 3.0.2 and 3.0.6.1 (pre-6/15, I believe) were unable
>>> to capture any traffic from the 10G fiber interface.
>>> After consulting the mailing list archive, I grabbed, right before
>>> your announcement this morning, the latest argus and argus-clients,
>>> dated 6/15. I can, intermittently, grab data from the argus daemon
>>> running on each application CPU, but it otherwise produces errors like
>>> the ones I pasted below.
>>> 
>>> Our boxes are set up in what I assume is the typical fashion, with
>>> argus running on each Bivio application CPU, and radium running on
>>> CPU-X to merge all the flows together.
>>> If this helps any, the box we're testing currently is plugged into a
>>> rather noisy but not saturated 10G fiber link.  It also happens to be
>>> listening just outside a firewall, so there are a _lot_ of small flows
>>> from stuff that eventually gets blocked.
>>> 
>>> Here are the sort of log messages we get when starting radium or ra:
>>> Jun 19 10:13:08 CPU-1c0 argus[29290]: 19 Jun 12 10:13:07.028468
>>> connect from CPU-X
>>> Jun 19 10:13:08 CPU-1c0 argus[29290]: 19 Jun 12 10:13:07.029010
>>> ArgusCheckClientMessage: client (null) never started: timed out
>>> Jun 19 10:13:09 CPU-1c1 argus[29120]: 19 Jun 12 10:13:08.554611
>>> connect from CPU-X
>>> Jun 19 10:13:09 CPU-1c1 argus[29120]: 19 Jun 12 10:13:08.555118
>>> ArgusCheckClientMessage: client (null) never started: timed out
>>> 
>>> Let me know if you need any more info.
>>> 
>>> Thanks,
>>> - Eric
>> 
> 

-------------- 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/20120620/ef6957a1/attachment.bin>