[Snort-devel] Duplicate/similar struct definitions between src/decoder.h and src/dynamic_plugins/sf_engine/sf_snort_packet.h?

Joshua.Kinard at ...3108... Joshua.Kinard at ...3108...
Thu Aug 11 20:20:12 EDT 2011

Sounds sensible, like the old separation that existed in Linux Kernel
headers before they abstracted the headers so that a userspace-safe copy
was buildable.  A lot of distros had some really bad hacks that were run
on a vanilla kernel tree to produce headers.  Now it's just a simple
'make headers' these days.

If it is legacy, is there any harm in creating a central header
collection for new protocols, such as src/protocols/*.h?  I am taking a
stab at adding SCTP support to src/decoder.c (finally found two pcaps
with full IP/SCTP sessions in them for testing, not SIGTRAN stuff).
This would allow me to avoid duplicating common SCTP macros all over the
place (like the chunk types).



-----Original Message-----
From: Steven Sturges [mailto:ssturges at ...402...] 
Sent: Thursday, August 11, 2011 12:33 PM
To: Kinard, Joshua A
Cc: snort-devel at lists.sourceforge.net
Subject: Re: [Snort-devel] Duplicate/similar struct definitions between
src/decoder.h and src/dynamic_plugins/sf_engine/sf_snort_packet.h?

Hi Joshua--

There are definitely some legacy reasons for this.  :)

When we added the .so's (dynamic rule engine & .so rules, and the 
dynamic preprocessors) to Snort, circa 2.6, there was a desire to be
able to decouple them from the main Snort.  So, the data structures
that were shared (packet, protocol headers, etc) were replicated to
allow for independent building of those dynamic components, without
having to change everything that was already in Snort -- packet
decoder, preprocessors (Frag, Stream, etc), pattern matcher, rules 
engine, output plugins, etc.

Over time things have evolved even more, and there is code that is
shared between Snort and the dynamic components via direct build.
Those elements get built in the module where its needed.  An example of
that is the memory pool that is used in the SMTP preprocessor as well
as other places within Snort.


On 8/11/11 12:55 AM, Joshua.Kinard at ...3108... wrote:
> Hi snort-devel,
> Looking through src/decoder.h at the typedef/struct for 'Packet', a
> comment says that if any changes were made, to update the similar
> definition in sf_snort_packet.h.  Opening that file up, pretty much,
> the same data structures from decoder.h are duplicated, just with
> variations (like u_int32_t versus uint32_t).
> My question is why?
> Wouldn't it be better to have a single, common definition in a central
> header file for all the various protocol headers (IPv4, IPv6, TCP,
> MPLS, etc), rather than re-defining multiple variants?  Aside from the
> changes in the data types (which I am sure are just typedefs of each
> other) and the names, everything looks the exact same.
> Example:
> src/decoder.h:
>      typedef struct _UDPHdr
>      {
>          uint16_t uh_sport;
>          uint16_t uh_dport;
>          uint16_t uh_len;
>          uint16_t uh_chk;
>      }       UDPHdr;
> src/dynamic_plugins/sf_engine/sf_snort_packet.h:
>      typedef struct _UDPHeader
>      {
>          u_int16_t source_port;
>          u_int16_t destination_port;
>          u_int16_t data_length;
>          u_int16_t checksum;
>      } UDPHeader;
> Seems wasteful, but maybe there is some kind of legacy issue that is
> undocumented?
> --J
> Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
> user administration capabilities and model configuration. Take
> the hassle out of deploying and managing Subversion and the
> tools developers use with it.
> http://p.sf.net/sfu/wandisco-dev2dev
> _______________________________________________
> Snort-devel mailing list
> Snort-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/snort-devel

More information about the Snort-devel mailing list