Commit Graph

16 Commits

Author SHA1 Message Date
Guy Harris 5f7868c7e0 Better handle errors from zlib:
Assign a range of Wiretap errors for zlib errors, and have
	"wtap_strerror()" use "zError()" to get an error message for
	them.

	Have the internal "file_error()" routine return 0 for no error
	and a Wiretap error code for an error.

svn path=/trunk/; revision=769
1999-10-05 07:06:08 +00:00
Guy Harris a9c36a4b69 Fix it so that it builds with "--disable-zlib".
The "fh" member of a "wtap" structure points to something constructed
from the "fd" member of that structure, so that closing the stream
referred to by "fh" also closes the underlying file descriptor; get rid
of an unnecessary close of "wth->fd".

svn path=/trunk/; revision=720
1999-09-24 05:49:53 +00:00
Ashok Narayanan 3dfa56c498 This commit contains support for reading capture files compressed using
gzip. The zLib library is used for this purpose. If zLib is not available
(or it's use is disabled by the --disable-zlib option to configure), you
can still compile Ethereal but it will be unable to read compressed capture
files.

IMPORTANT:

Now all file accesses to capture files should be done through special macros.
Specifically, for any use of the following functions on capture files, replace them.
The arguments for the right-side functions are exactly the same as for the
original stdio functions.

	fopen			file_open
	fdopen			filed_open
	fread			file_read
	fwrite			file_write
	fseek			file_seek
	fclose			file_close
	ferror			file_error

svn path=/trunk/; revision=695
1999-09-22 01:26:50 +00:00
Guy Harris ae53260d02 Keep in the "wtap" structure the current offset into the file being
read, and maintain it ourselves as we read through the file, rather than
calling "ftell()" for every packet we read - "ftell()" may involve an
"lseek()" call, which could add a noticeable CPU overhead when reading a
large file.

svn path=/trunk/; revision=596
1999-08-28 01:19:45 +00:00
Guy Harris 678b5fd6ff Add a new Wiretap encapsulation type WTAP_ENCAP_FDDI_BITSWAPPED, meaning
"FDDI with the MAC addresses bit-swapped"; whether the MAC addresses are
bit-swapped is a property of the machine on which the capture was taken,
not of the machine on which the capture is being read - right now, none
of the capture file formats we read indicate whether FDDI MAC addresses
are bit-swapped, but this does let us treat non-"libpcap" captures as
being bit-swapped or not bit-swapped independent of the machine on which
they're being read (and of the machine on which they were captured, but
I have the impression they're bit-swapped on most platforms), and allows
us to, if, as, and when we implement packet capture in Wiretap, mark
packets in a capture file written in Wiretap-native format based on the
machine on which they are captured (assuming the rule "Ultrix, Alpha,
and BSD/OS are the only platforms that don't bit-swap", or some other
compile-time rule, gets the right answer, or that some platform has
drivers that can tell us whether the addresses are bit-swapped).

(NOTE: if, for any of the capture file formats used only on one
platform, FDDI MAC addresses aren't bit-swapped, the code to read that
capture file format should be fixed to flag them as not bit-swapped.)

Use the encapsulation type to decide whether to bit-swap addresses in
"dissect_fddi()".

svn path=/trunk/; revision=557
1999-08-24 03:19:34 +00:00
Guy Harris 4b9ab6d1fc Get rid of some cruft left in by previous checkins as placeholders.
Get rid of WTAP_ENCAP_NONE; replace it with WTAP_ENCAP_UNKNOWN, which
means "I can't handle that file, it's using an encapsulation I don't
support".

Check for encapsulations we don't support, and return an error (as is
already done in "libpcap.c").

Check for too-large packet sizes, and return an error (as is already
done in "libpcap.c").

Print unsigned quantities in Wiretap messages with "%u", not "%d".

svn path=/trunk/; revision=544
1999-08-22 02:29:40 +00:00
Guy Harris 137ba48d18 Have the per-capture-file-type open routines "wtap_open_offline()" calls
return 1 on success, -1 if they got an error, and 0 if the file isn't of
the type that file is checking for, and supply an error code if they
return -1; have "wtap_open_offline()" use that error code.  Also, have
the per-capture-file-type open routines treat errors accessing the file
as errors, and return -1, rather than just returning 0 so that we try
another file type.

Have the per-capture-file-type read routines "wtap_loop()" calls return
-1 and supply an error code on error (and not, as they did in some
cases, call "g_error()" and abort), and have "wtap_loop()", if the read
routine returned an error, return FALSE (and pass an error-code-pointer
argument onto the read routines, so they fill it in), and return TRUE on
success.

Add some new error codes for them to return.

Now that "wtap_loop()" can return a success/failure indication and an
error code, in "read_cap_file()" put up a message box if we get an error
reading the file, and return the error code.

Handle the additional errors we can get when opening a capture file.

If the attempt to open a capture file succeeds, but the attempt to read
it fails, don't treat that as a complete failure - we may have managed
to read some of the capture file, and we should display what we managed
to read.

svn path=/trunk/; revision=516
1999-08-19 05:31:38 +00:00
Guy Harris df490a7085 Add to Wiretap the ability to write capture files; for now, it can only
write them in "libpcap" format, but the mechanism can have other formats
added.

When creating the temporary file for a capture, use "create_tempfile()",
to close a security hole opened by the fact that "tempnam()" creates a
temporary file, but doesn't open it, and we open the file with the name
it gives us - somebody could remove the file and plant a link to some
file, and, if as may well be the case when Ethereal is capturing
packets, it's running as "root", that means we write a capture on top of
that file....  (The aforementioned changes to Wiretap let you open a
capture file for writing given an file descriptor, "fdopen()"-style,
which this change requires.)

svn path=/trunk/; revision=509
1999-08-18 04:17:38 +00:00
Gilbert Ramirez 601c52f0fb Added support for compiling on win32 with Visual C and 'nmake'. It compiles,
but does not link. Perhaps someone who understands the MS tools can help
out. I made it link a few months ago, but with different version of glib/gtk+.
I can't remember how I made it link.

Most of the compatibility issues were resolved with adding
#ifdef HAVE_UNISTD_H the the source code. Please be sure to add this to all
future code.

svn path=/trunk/; revision=359
1999-07-13 02:53:26 +00:00
Guy Harris 6399732b86 Add support for Network Monitor 2.0 files, thanks to information
supplied by Tim Farley.

Tim also indicated that the Network Monitor network types may be NDIS
network types+1.  It also appears that NetXRay/Windows Sniffer network
types may be NDIS network types as well.

svn path=/trunk/; revision=284
1999-05-12 21:40:07 +00:00
Guy Harris 4932ef3dcc The program that produced the version 2.001 file was Sniffer Pro 2.50.05
(presumably a Windows version).

Note also that version 2.001 files appear to have microsecond time
stamps, like version 1.1 files.

svn path=/trunk/; revision=228
1999-03-25 06:34:32 +00:00
Gilbert Ramirez bdbd5ee203 Got rid of "hdr_size may not be initialized" warning, even though it was
innocuous.

svn path=/trunk/; revision=221
1999-03-22 15:02:25 +00:00
Guy Harris 56b5a15d5f Add support for file format version 2.001 (used by Sniffer Basic 2.0?).
This assumes that the time stamps are still in units of microseconds; I
don't yet have a text decode of the version-2.001 file from the program
that decoded it, so I can't check the time stamps.

svn path=/trunk/; revision=217
1999-03-20 09:10:49 +00:00
Guy Harris e2b7e1aba9 It turns out that the first of the unknown fields in the NetXRay header
appears to be the UNIX "time_t" when the capture started, so use that to
figure out the time when a packet was captured.

svn path=/trunk/; revision=204
1999-03-01 22:59:47 +00:00
Gilbert Ramirez 2dbd008ea5 Added display filters to wiretap.
svn path=/trunk/; revision=198
1999-03-01 18:57:07 +00:00
Guy Harris 3200c25437 Add support for Cinco Networks NetXRay - which is, after their acquision
by Network General (subsequently merged with McAfee Associates into
Network Associates), called "Sniffer Basic".

A similar format appears to be used by the Windows Sniffer Pro.

svn path=/trunk/; revision=194
1999-02-20 06:49:27 +00:00