Developing an Argus client

[Harry Bock]

Hey Carter,

On further inspection, you are correct, everything is in host byte order - I
forgot that inet_ntop(3) expects its argument to be in network byte order,
so I've been using ntohl where I shouldn't be :) Thanks!

That sounds very simple - I'll look through the headers for more info and do
some wireshark analysis to make sure I understand it correctly.  Being able
to implement the protocol myself would make arranging the data structures
more flexible for a separate set of bindings.  I'll keep you up-to-date on
that front and provide the source, in case you might be interested in having
it available to other application devs in the main Argus distribution.

Thanks again for your help,
Harry

On Wed, May 27, 2009 at 4:29 PM, Carter Bullard <carter at qosient.com> wrote:

> Hey Harry,Everything in the ArgusRecordStruct should be in host byte
> order.  If this is not the
> case, then there is a problem.
>
> The protocol is really pretty simple, except when security services are
> turned on.
> You connect, and receive a 128 byte ArgusMarStruct, based on the contents
> of
> that record, you will negotiate security or not.  After the security is
> negotiated
> using sasl(), you can send a "FILTER:" and receive an "OK", and then you
> can
> send either a "FILE:...." command and receive a stream of argus data, or
> you
> can send a "START" and receive a stream of argus data.  You will
> occasionally
> get ArgusMarStruct records, which are transport session keep alives, and
> then
> when you get a STOP ArgusMarStruct record, you close, or if you want to
> close,
> you send a "STOP" string, and the far side will send a ArgusMarStruct that
> has a CLOSE causecode, and you're done.
>
> A few other things to deal with, but basically thats it.
>
> Carter
>
> On May 27, 2009, at 4:15 PM, Harry Bock wrote:
>
> Hey Carter,
>
> Sorry for the late reply.  I've been extremely busy for the last week and
> haven't had a whole lot of time to work on this.
>
> That's fine that you can't integrate it right now; in the meantime, I've
> cobbled together a temporary solution, where I create a shared library of my
> wrappers that directly includes argus_client.a and argus_common.a using
> libtool, and that seems to be working fine on Linux systems (although
> libtool complains it's nonportable, I'm not concerned about it at this
> time).
>
> A few questions on using the library.
>   - Some of the data in ArgusRecordStruct is in network byte order, and
> some is not - for example, in struct ArgusFlow, flow->ip_flow.ip_src and
> ip_dst are both in NBO, but sport and dport are both in HBO.  Is this
> anomaly common?
>  - How complicated is the Argus server protocol (version 3)?  I'm
> interested in implementing it entirely in Lisp, which would give me some
> more flexibility data-structure wise.  Does the on-disk format Argus uses
> match the protocol well? I'm not sure if I'll do it, but I want to know what
> I'm getting myself into first :)
>
> Thanks,
> Harry
>
> On Fri, May 22, 2009 at 10:56 AM, Carter Bullard <carter at qosient.com>wrote:
>
>> Hey Harry,If you want shared libraries, and it has to run on 21
>> platforms,
>> libtool is the only way to go.  I haven't put it in, because, up until
>> about 5-6 years ago, it was  hard to have a make file that would
>> do the right thing on Linux, Solaris, IRIX, Mach, UNICOS, all the
>> BSD's, AIX, HPUX, etc....  Now its time to do this.
>>
>> Also, the library routines are not well documented (no
>> user serviceable software parts inside), so easier to avoid
>> the hard part if you just don't let them get to the routines ;o)
>>
>> I already have hand cobbled a set of make files that do the right
>> thing.  I just have to integrate the changes into configure.in, which
>> will take some time, with my schedule, maybe a month, so if you
>> need it now, you may have to do something on your side.
>>
>> Carter
>>
>> On May 22, 2009, at 10:32 AM, Harry Bock wrote:
>>
>> Hey Carter,
>>
>> Unfortunately, I don't have very much experience with autotools, just some
>> basic stuff with autoconf/automake, and none at all with GNU libtool.  I
>> prefer CMake for projects like this, but that doesn't help :)
>>
>> I hope this change won't cause any headaches for you; I really appreciate
>> the help!
>>
>> Harry
>>
>> On Wed, May 20, 2009 at 2:53 PM, Carter Bullard <carter at qosient.com>wrote:
>>
>>> Hey Harry,I don't want to keep you from doing anything, but I think I
>>> should probably
>>> do this thing that you are seeking.
>>>
>>> Do you have any experience with gnu's libtool?
>>>
>>> Carter
>>>
>>> On May 20, 2009, at 2:19 PM, Harry Bock wrote:
>>>
>>> Thanks again for your help Carter; I've fixed the reference to QoSient on
>>> our project page and
>>> have progressed a bit more since my last email.
>>>
>>> In my current copy of the argus-clients source tree, I've broken
>>> Periscope out into its own directory, akin to ramysql and co., with a
>>> slightly modified Makefile.in.  I'm building a small framework atop Argus to
>>> make it more convenient for non-C programs to access data within Argus
>>> records, and I've added a callback layer on top of the current scheme for
>>> RaParseComplete/RaArgusInputComplete/etc., since the report-generating part
>>> of Periscope won't be directly compiled against the Argus client libraries.
>>>
>>> The most critical thing that I need to do at this point is to build a
>>> shared lib of the Argus client library; I know how to do this for autotools
>>> when the input files are for automake, but not for pure autoconf.  Any
>>> suggestions on how to do this without breaking linking the other
>>> applications to the static Argus libraries?  That would make it extremely
>>> easy to do something similar to:
>>>
>>> gcc periscope.c -o periscope -I/usr/include/argus-client -largus_client
>>> -largus_common -largus_event
>>>
>>> As shared library support might be useful to other developers working on
>>> Argus clients, I'd suggest enabling this support in the default distribution
>>> of argus-clients, so users can build applications like Periscope against
>>> their distribution's build of Argus without needing a copy of these
>>> modifications to the vanilla source tree.  I'd assume it'd be proper to make
>>> the initial SOVERSION 3.0.2 for libargus_client, etc.?
>>>
>>> Harry
>>>
>>>
>>>
>>
>
>
> --
> Harry Bock
> Software Developer, Package Maintainer
> OSHEAN, Inc.
> Email: harry at oshean.org
> PGP Key ID: 546CC353
>
>
>


-- 
Harry Bock
Software Developer, Package Maintainer
OSHEAN, Inc.
Email: harry at oshean.org
PGP Key ID: 546CC353
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20090527/9e8ff21c/attachment.html>