> I'd suggest re-implementing it without memory-mapping the file, which > obviates the need to worry about either of those. ...and also means that it would be able to handle gzipped elog files. Note also that if Makefile.am is modified to include a new source file, the equivalent Makefile.nmake should be modified as well, to make sure that Windows MSVC++ builds also get it (unless the file is UNIX-specific, which neither a dissector nor a Wiretap file reader should be). Also, in packet-mmsll.c, the dissector tries to infer the byte order of the interface index (as it's presumably just raw data from the Linux kernel, and thus in the byte order of the host that wrote the file), but it neither tries to infer the byte order of, for example, the hatype or prototype fields nor use the inferred interface-index byte order to interpret those fields. Make sure you test this by capturing on a machine with one byte order and reading the resulting file on a machine with a different byte order.
Powered by MHonArc 2.6.10