headers
Phillip Deneault | 4 Mar 2011 19:29
Favicon

Re: Radium dropping connections to argi

Carter,

I didn't forget about you.  I've been letting this run for a while then
ran it for a little more when you released .23.  It seems to have fixed
the bug as I still have not had any problems.

Thanks,
Phil

On 2/4/2011 4:10 PM, Carter Bullard wrote:
> Hey Phillip,
> I did find a problem, and this patch should fix radium() apparently not attempting to reconnect
> after a while.  I've got it in the distribution but give it a try on your machine to see if it doesn't
> correct the problem.
> 
> Carter
> 
> ==== //depot/argus/clients/common/argus_client.c#204 -
/Users/carter/argus/clients/common/argus_client.c ====
> 2523a2524,2525
>>
>>                      input->status &= ~ARGUS_CLOSED;
> 
> 
> On Feb 4, 2011, at 4:01 PM, Carter Bullard wrote:
> 
>> Hey Phillip,
>> radium() doesn't have a retry counter, it should keep trying every 5 seconds if threaded and every 1
second if
>> non-thread, and it should try forever.  I've recreated a problem where radium(), after the far side has gone
(Continue reading)

Permalink | Reply | 6 comments |
headers
Carter Bullard | 5 Mar 2011 17:13

Re: Radium dropping connections to argi

Excerrent !!!!   That is great news !!!!
Carter

On Mar 4, 2011, at 1:29 PM, Phillip Deneault <deneault <at> WPI.EDU> wrote:

> Carter,
> 
> I didn't forget about you.  I've been letting this run for a while then
> ran it for a little more when you released .23.  It seems to have fixed
> the bug as I still have not had any problems.
> 
> Thanks,
> Phil
> 
> On 2/4/2011 4:10 PM, Carter Bullard wrote:
>> Hey Phillip,
>> I did find a problem, and this patch should fix radium() apparently not attempting to reconnect
>> after a while.  I've got it in the distribution but give it a try on your machine to see if it doesn't
>> correct the problem.
>> 
>> Carter
>> 
>> ==== //depot/argus/clients/common/argus_client.c#204 -
/Users/carter/argus/clients/common/argus_client.c ====
>> 2523a2524,2525
>>> 
>>>                     input->status &= ~ARGUS_CLOSED;
>> 
>> 
>> On Feb 4, 2011, at 4:01 PM, Carter Bullard wrote:
(Continue reading)

Permalink | Reply | 5 comments |
headers
Phillip G Deneault | 6 Mar 2011 00:08
Favicon

Re: Radium dropping connections to argi

Actually, I spoke to soon.  It happened again last night after not 
happening for weeks.  I'm going to see if I can simulate this behavior 
tomorrow or Monday and try to get a packet capture of the behavior as it 
occurs.

Thanks,
Phil

On Sat, 5 Mar 2011, Carter Bullard wrote:

> Excerrent !!!!   That is great news !!!!
> Carter
>
> On Mar 4, 2011, at 1:29 PM, Phillip Deneault <deneault <at> WPI.EDU> wrote:
>
>> Carter,
>>
>> I didn't forget about you.  I've been letting this run for a while then
>> ran it for a little more when you released .23.  It seems to have fixed
>> the bug as I still have not had any problems.
>>
>> Thanks,
>> Phil
>>
>> On 2/4/2011 4:10 PM, Carter Bullard wrote:
>>> Hey Phillip,
>>> I did find a problem, and this patch should fix radium() apparently not attempting to reconnect
>>> after a while.  I've got it in the distribution but give it a try on your machine to see if it doesn't
>>> correct the problem.
>>>
(Continue reading)

Permalink | Reply | 4 comments |
headers
Carter Bullard | 7 Mar 2011 15:11

new algorithm annoucement for argus-3.0.4

Gentle people,
I just uploaded new argus news to the web server that describes new algorithm support for 3.0.4,
which should be released this week.  We've implemented a keystroke detection system for
TCP streams, implemented for SSH, with full client support.  This is in the current argus-3.0.3.23
developers release, so you can be testing it, even now as I type, so to speak.

The "Latest News" entry at http://qosient.com/argus has references to the published paper, and
links to video, etc..., that describe the algorithm.

Please take a look, and any comments are very welcome,
Thanks for all the support,

Carter
Attachment (smime.p7s): application/pkcs7-signature, 3815 bytes
Permalink | Reply | 0 comments |
headers
Carter Bullard | 7 Mar 2011 17:58

new man pages and documentation for 3.0.4

Gentle people,
Getting ready for argus-3.0.4 release.
I've created man pages for all the C programs in the argus and argus-client distributions,
converted them to pdf's and uploaded them to http://qosient.com/argus/manuals.shtml
web page "argus -> Documentation -> manuals".

Please take a look and if there is something askew, or I've missed something, please holler.
Some of these may be too brief to be useful, but now we have starting points.
Thanks for all the assistance,

Carter
Attachment (smime.p7s): application/pkcs7-signature, 3815 bytes
Permalink | Reply | 0 comments |
headers
Carter Bullard | 7 Mar 2011 18:16

argus[-clients]-3.0.4 on development server

Gentle people,
A pre-release of argus-3.0.4 and argus-clients-3.0.4 is now on the development server.
My plan is to officially release 3.0.4 this week,  unless we find something that really needs
attention.  I believe that the rpm spec file is ready to go, all configure.ac and m4 macros
are ready, most documentation is ready, pkg-config support for new client support, and
argus seems very stable in the official test sites, etc.....

If you've got a bug, we'll start fixing them in argus-3.0.5 starting next week.  I apologize if
I haven't gotten to your specific bug in this release.  Please resend if it you think your
problem fell off the table, so to speak.   If you see installation or documentation problems, 
these are very important and should be fixed, etc......

Thanks for all the attention and support !!!!!!

Carter
Attachment (smime.p7s): application/pkcs7-signature, 3815 bytes
Permalink | Reply | 0 comments |
headers
Carter Bullard | 10 Mar 2011 13:18

argus-3.0.4 release eminent

Gentle people,
If there are no objections, I'll be releasing argus-3.0.4 and its clients
tomorrow (Friday Mar 11).  I've made a lot of changes to the web site
getting ready, such as documentation changes, official man pages on
the web site, updates to the FAQ, etc.....

The biggest changes for 3.0.4 is enhanced multi-threaded support, new
interface specification in the /etc/argus.conf, richer wirelss monitoring
support, argus events, UDP transport and native multicast transport of
flow records.  And of course a very large number of bugs.

Client support includes major improvements and modifications to ratop(),
re-introduction of ragrep(), new URL specifications for "-w " options,
enhanced database functionality, the addition of raservices() and
rauserdata() for processing/analyzing user data buffers, raconvert() to
change ascii text to argus binary records, and a full set of man pages.

If there is anything that you would like to see changed/modified/improved
on/thrown away/whatever, please consider now a good time to holler.

Thanks for all the effort and support !!!!!!

Carter
Attachment (smime.p7s): application/pkcs7-signature, 3815 bytes
Permalink | Reply | 1 comment |
headers
Wolfgang Barth | 10 Mar 2011 19:58
Picon

Re: argus-3.0.4 release eminent

Hey Carter,

> If there are no objections, I'll be releasing argus-3.0.4 and its clients
> tomorrow (Friday Mar 11).  I've made a lot of changes to the web site
> getting ready, such as documentation changes, official man pages on
> the web site, updates to the FAQ, etc.....

I always have a problem with  rabins -t yyyy/mm/dd on 32-bit ubuntu, but
this can wait for further minor release. I'm using a workaround: do not
specify the first two digits of the year. -t **11/03/10 will work. I have
no time for extensive testing yet, so from my point of view feel free to
release 3.0.4 tomorrow.

Last but not least: many thanx for this great stuff of software. I really
love it ;-)

Wolfgang
--

-- 
<wob (at) swobspace de> * http://www.swobspace.de
Permalink | Reply | 0 comments |
headers
Phillip Deneault | 10 Mar 2011 20:38
Favicon

Re: Radium dropping connections to argi

I managed to repeat this problem with a sniffer running.  It didn't turn
up as much useful information as I would have liked.

For my test, I set up all of my sensors to restart argus once a day at
the same time via a init.d stop/start and set my tcpdump filter to look
like this:
port 561 and tcp[tcpflags] & (tcp-syn|tcp-fin|tcp-rst) != 0

I can see two sets of shutdowns, one the 9th for which all my sensors
came back, and one on the 10th when only 17 came back.  All the Argus
daemons did restart and come online, but basically for some hosts,
radium never even attempted to restart the connection.

tcpdump available upon request.

Thanks,
Phil

On 3/5/2011 6:08 PM, Phillip G Deneault wrote:
> Actually, I spoke to soon.  It happened again last night after not
> happening for weeks.  I'm going to see if I can simulate this behavior
> tomorrow or Monday and try to get a packet capture of the behavior as it
> occurs.
> 
> Thanks,
> Phil
> 
> On Sat, 5 Mar 2011, Carter Bullard wrote:
> 
>> Excerrent !!!!   That is great news !!!!
(Continue reading)

Permalink | Reply | 3 comments |
headers
Carter Bullard | 11 Mar 2011 00:04

Re: Radium dropping connections to argi

Hey Phillip,
How many remote clients are you connecting to?
Should not be an issue but you never know.
Carter

On Mar 10, 2011, at 2:38 PM, Phillip Deneault <deneault <at> WPI.EDU> wrote:

> I managed to repeat this problem with a sniffer running.  It didn't turn
> up as much useful information as I would have liked.
> 
> For my test, I set up all of my sensors to restart argus once a day at
> the same time via a init.d stop/start and set my tcpdump filter to look
> like this:
> port 561 and tcp[tcpflags] & (tcp-syn|tcp-fin|tcp-rst) != 0
> 
> I can see two sets of shutdowns, one the 9th for which all my sensors
> came back, and one on the 10th when only 17 came back.  All the Argus
> daemons did restart and come online, but basically for some hosts,
> radium never even attempted to restart the connection.
> 
> tcpdump available upon request.
> 
> Thanks,
> Phil
> 
> 
> On 3/5/2011 6:08 PM, Phillip G Deneault wrote:
>> Actually, I spoke to soon.  It happened again last night after not
>> happening for weeks.  I'm going to see if I can simulate this behavior
>> tomorrow or Monday and try to get a packet capture of the behavior as it
(Continue reading)

Permalink | Reply | 2 comments |

Gmane