[Snort-devel] spo_database & fragments

Joe McAlerney joey at ...63...
Mon Jan 22 18:50:03 EST 2001

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.

typedef enum _input_id{DEFAULT, RULE, DECODE, DEFRAG, HTTP_DECODE,

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
       case RULE:
          BuildRuleMessage(p, msg);
       case PORTSCAN:
          BuildPortscanMessage(p, msg);
       case SPADE:
          BuildSpadeMessage(p, msg, arg);
          BuildGenericMessage(p, msg);
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

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.


-Joe M.

+--                            --+
| Joe McAlerney, Silicon Defense |
| http://www.silicondefense.com/ |
+--                            --+

More information about the Snort-devel mailing list