[Snort-devel] spo_database & fragments

Martin Roesch roesch at ...48...
Sat Jan 27 01:47:43 EST 2001


Joe McAlerney wrote:
> 
> Chris Green wrote:
> >
> > James Hoagland <hoagland at ...60...> writes:
> >
> > > As I mentioned, the way it is currently written is that it is a char
> > > *.  I think that using a symbolic constant is somewhat better though.
> > > char * is not that bad though I think as you would just need string
> > > compares.
> >
> > Yes the strcompares wouldn't be bad but it seems like a lot of
> > repeated work in every output plugin and since this is something not
> > yet implemented in general release, constants might be the way to go.
> >
> 
> Either way works for me.  I actually implemented it as a char * simply
> to reuse the "keyword", but it certainly isn't a problem to go the other
> way.  Unless there are any objections, I will go ahead and use an enum.

Sounds good to me, we just have to think of a scalable way of
implementing it so that we don't need to edit the source files everytime
we add a new preprocessor.

> typedef enum _input_id{DEFAULT, RULE, DECODE, DEFRAG, HTTP_DECODE,
> MINFRAG, PORTSCAN, SPADE} input_id;
> 
> void CallLogFuncs(Packet *, char *, ListHead *, input_id);
> void CallAlertFuncs(Packet *, char *, ListHead *, input_id);
> 
> ...
> 
> /* spp_portscan.c */
> 
> CallAlertFuncs(NULL, logMessage, NULL, PORTSCAN);
> 
> ...
> 
> /* spo_generic_plugin.c */
> 
> void mainGenericFunction(Packet *p, char *msg, void *arg, input_id
> caller)
> {
>     switch(caller)
>     {
>        case RULE:
>           BuildRuleMessage(p, msg);
>           break;
>        case PORTSCAN:
>           BuildPortscanMessage(p, msg);
>           break;
>        case SPADE:
>           BuildSpadeMessage(p, msg, arg);
>           break;
>        default:
>           BuildGenericMessage(p, msg);
>     }
>     return;
> }
> 
> Additionally, if we want to change the third parameter to the msg_info
> **msgs structure Jim described, that's a simple global search and
> replace procedure (complete with error checking and testing of course).
> Do people agree with that structure, or should it be discussed further?
> 
> On a side note, I had some issues implementing the above.  The addition
> of the fourth argument impacts functions in a number of files, notably
> log.h, rules.h and a number of output plugins of course.  To keep the
> enumeration definition in plugbase.h, I had to define it before all the
> #includes.  Otherwise, the header files that depend on it complained
> loudly.  If anyone knows a cleaner way around this, I'd be glad to hear
> it.

Define it globally and define it when needed?  I'm not sure if the
compiler would bitch much if you did that, I don't actually mess with
enums very often...

> I'll hold out on sending in the patches until we decide on a structure
> for the third parameter.  If anyone wants the diffs as they are now,
> please let me know.
> 
> Comments and suggestions are most welcome.

I wouldn't mind seeing the diffs.  Should arg just be a void* so we can
set it dynamically at run time?

   -Marty


--
Martin Roesch
roesch at ...48...
http://www.snort.org




More information about the Snort-devel mailing list