Ethereal-dev: Re: [Ethereal-dev] Firestorm Network Intrusion Detection support for Ethereal
On Wed, Mar 05, 2003 at 10:13:41AM +0000, John Leach wrote:
> I've added support to Ethereal 0.9.9 for the Firestorm Network Intrusion
> Detection System. Ethereal can now open and display the Firestorm elog
> files,
...on operating systems that support "mmap()".
Unfortunately, some of the more popular platforms on which people run
Ethereal:
http://www.microsoft.com/windows95/
http://www.microsoft.com/windows98/
http://www.microsoft.com/windowsme/
http://www.microsoft.com/ntworkstation/
http://www.microsoft.com/ntserver/
http://www.microsoft.com/windows2000/
http://www.microsoft.com/windowsxp/
http://www.microsoft.com/Windowsserver2003/
do not support "mmap()" (even though they do support memory-mapped
files).
In addition, there *might* be some older versions of UNIX on which
people run Ethereal that don't support it, either.
In addition, not all OSes guarantee consistency between the
memory-mapped view of a file and the view from ordinary reading and
writing (the Win32 documentation explicitly says it's *not* guaranteed,
even though the "Inside Windows NT" books *appear* to indicate that
NT/2K have a unified buffer cache/page pool - perhaps that's there for
the benefit of Windows OT, or perhaps the buffer cache really isn't
unified with the page pool, and some versions of UNIXes definitely don't
have a unified buffer cache), which *might* lead to surprises.
At minimum, it needs to use MapViewOfFile on Win32, and to have the
configure script test whether "mmap()" exists and not use it (even if
that means not supporting reading elog files) if it's not present.
I'd suggest re-implementing it without memory-mapping the file, which
obviates the need to worry about either of those.
The WTAP_ENCAP_MMSLL is not actually used anywhere as a Wiretap
encapsulation type - the mmsll dissector registers itself by name, and
the elog dissector finds it by looking it up by name. As such,
WTAP_ENCAP_MMSLL should be eliminated.
In addition, whenever a new WTAP_ENCAP_ type is added, a new entry must
be added for it to the "encap_table[]" array in "wiretap/wtap.c", so
you'd need to add an entry for WTAP_ENCAP_ELOG.
Note also that if "wth->file_encap" is set to a value other than
WTAP_ENCAP_PER_PACKET, there's no need to have the "_read" routine for
the capture file type set "wth->phdr.pkt_encap" - it's initially set to
match the file encapsulation type.
Also, "ntohl()" and "ntohs()" shouldn't be used - use "g_ntohl()" and
"g_ntohs()" instead, as we then don't have to worry about pulling in
various system include files to get "ntohl()" and "ntohs()" defined.
(The same applies to "htonl()" and "htons()".)
