[Snort-devel] questions coming out of my paengine work
tlewis at ...120...
Sat Dec 9 17:54:30 EST 2000
Some of these questions are in the README.paengine which was part of
my patch, but I figured that they probably wouldn't get answered unless
I asked them here.
I am really excited about the work that I'm doing on snort, and I hope
that it turns out well. The more feedback that I can get from other
developers, the better of a job I can do integrating my work smoothly.
So, I really urge all the other devs out there to consider these questions
and post their thoughts on them. (See, I can prod without yelling!)
1) Any thoughts on how to pass configuration information into the
paengines? If the config file were an XML doc, which I would really
like, then we could just pass the DOM node into the paengine, or tell
it the name of the paengine-specific xml config file in the snort
config directory, and then that be that. I am thinking that, given
how varied the configurations of these paengines' are going to be,
they will pretty much have to be in the config file. I.e., passing
in their configuration on the command line won't really be possible.
If command-line configuration is chosen, then we'll see stuff like this:
snort -E pcap -e "mode=readfile infile=/tmp/bpffile outfile=/tmp/bpffile.filtered"
I can't really see us doing this, but I'm open.
2) Any volunteers to separate out the pcap-specific stuff from the
general configuration struct? If you look at how much paengine_pcap
reaches back into the global snort configuration in my patch, you'll
see that the separation is far from complete. I would really like
to see those options that are pcap-specific moved to the paengine_pcap
configuration and away from the global snort config. I can do this work,
but someone with some more experience than I have with snort would be a
better choice to do this work, I think, since I'll probably misunderstand
parts of it and make the wrong decision. However, if no one volunteers,
then I will do it.
3) OpenPcap() doesn't really use intf except for opening files. It should
use it for all pcap opens, right?
4) I was thinking that pcap's readfile support should be a pcap
configuration option, however we decide to do that (see 1, 2, above).
This means removing it from the general command-line options. Objections?
5) pcap_dump is a tough feature for me to incorporate into the new system.
May I discard it? If someone wants to keep it, then do you have
any suggestions for how it should integrate into the paengine setup?
Maybe some sort of modularised output code that logging and dumping
could both plug into?
6) Use of printf, fprintf, #ifdef DEBUG, ErrorMessage, exit and
FatalMessage seems haphazard. Would anyone mind if I clean them up?
As more code is modularised, this problem will get worse. Marty, if
you could write up some guidelines for how this is all supposed to work,
then it would make life much easier for new developers like myself.
Even crappy, hastily-written standards are preferrable to no standards
on stuff like this.
Todd Lewis tlewis at ...120...
God grant me the courage not to give up what I think is right, even
though I think it is hopeless. - Admiral Chester W. Nimitz
More information about the Snort-devel