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()".)
Powered by MHonArc 2.6.10