[Snort-devel] Snort as a library

Michael Richardson Michael.Richardson at ...2449...
Tue Jul 20 14:07:33 EDT 2004

Hash: SHA1

>>>>> "Daniel" == Daniel Roelker <droelker at ...402...> writes:
    Daniel> Again, this patch doesn't affect functionality and is not a
    Daniel> security issue, so it's still in the queue of submitted
    Daniel> patches.  I'm not saying that this type of checking isn't
    Daniel> valid, but I am saying that there are higher priority
    Daniel> patches that we are looking at.

  Yeah, but there is an order of operations issue here, because once
you turn on -Werror, you have to revise other things. On the other hand,
if you apply other things first, then you have to revise -Werror.

  Except that you can apply all of the patches that involve code that
is not affected by the other queued patches as soon as you like. 

  If you can give me an idea when you want to integrate the -Werror
patch, I will revise it for whatever code is in HEAD.

    Daniel> Just to give everyone an idea, we're still reviewing the
    Daniel> massive wireless patch and we are pretty excited about it.
    Daniel> In addition, we just got sp_respond2 (with libdnet) from

  Could you make your patch queue public?
  That would be very useful to everyone involved.

    Daniel> However, my main concern about adding this patch was that
    Daniel> there was no clear game plan for what you were doing.  You
    Daniel> had eluded that this patch could be used for adding multiple
    Daniel> interface functionality, but this was the first time that I
    Daniel> had heard about this from you.

  The goal is to be able to port various pieces of snort to an embedded
processor that connects to a piece of hardware that does TCP reassembly.
  The system is a PCI-X card that plugs into a Linux host.

  Our game plan is to:
      1) make snort more modular, such that there are few or no
	 globals. This means passing a number of things around as
	 parameters. The exact split between PV and TV changed four
	 times as I was working on it. I expect it to change some more.

      2) better split between generation of logging/alerts and recording
         of them. I think that this is mostly all done, but I found a 
	 number of difficult places, particularly with calls to pcap
	 functions for the pcap logger.

	 Basically, all of the recording functions need to be abstracted
	 so that they can go over inter-processor IPC.

	 Based upon the need for barnyard and friends for high speed
	 logging, I think that making this more streamlined would be

      3) splitting up processing of configuration files from collecting
	 of packets.
	 This isn't a huge task either --- it is mostly already done,
	 but there are some corner cases that we think we can fix.

      4) offload of TCP-reassembly function from layer 5-7 searching.
	 This might not be of general interest. The layer 2-4 code is
	 clearly of great value, since there are lots of attacks at that
	 level as well.

    Daniel> may not be the same changes that you would make.  We do try
    Daniel> to clean up code when we can, believe it or not, and adding
    Daniel> this feature would give us a good chance to revamp our
    Daniel> initialization code and variables.  So most likely, the
    Daniel> changes we would make would be completely different, since
    Daniel> you just took the existing initialization code and put it
    Daniel> into structure form.

  Yes, I did.
  It wasn't because I was lazy -- but because I wanted to make sure that
the change had as few conceptual changes as possible. Once the major
"change" is done, moving stuff around again is actually quite easy. XP

    Daniel> And as a developer, I always ask for requirements and design
    Daniel> first before we even start writing code, whether it be
    Daniel> structural or functional.  Multi-interface sniffing is a
    Daniel> substantial feature and we are not going to just take a
    Daniel> first time contributor's patch that changes core code and
    Daniel> add it into our repository because they say it works fine
    Daniel> against their test suite.

  Please publish your test suite.

    Daniel> Brian Caswell is the best person to explain what this
    Daniel> testing scheme is covering, perhaps he can respond here or
    Daniel> you can mail him directly?

  I look forward to having him explain what your test suite is doing.
  I understand how critical it is --- I would never dream of submitting
patches without test cases, when there is a test case system.

- --
]       ON HUMILITY: to err is human. To moo, bovine.                         [
]   Michael Richardson,            Seaway Networks Corporation                [
]   michael at ...2449...     http://www.seawaynetworks.com/             [
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Finger me for keys


More information about the Snort-devel mailing list