Commit Graph

26 Commits

Author SHA1 Message Date
Gilbert Ramirez c74451becd Jochen Friedrich <jochen@nwe.de>
protocol type 0x0c in AIX iptrace is used for the IBM SP switch
devices. Encoding is RAW IP...

svn path=/trunk/; revision=1767
2000-03-30 21:41:11 +00:00
Guy Harris 585268e3e1 Use WTAP_ERR_UNSUPPORTED_ENCAP for all attempts to open or read a
capture file for an unsupported link-layer encapsulation type (as the
nettl reader does), and report it correctly if it occurs on an open or
read attempt rather than a save attempt.

svn path=/trunk/; revision=1647
2000-02-19 08:00:08 +00:00
Guy Harris 3e067b812c Fix files that had Gilbert's old e-mail address or that didn't have my
forwarding e-mail address.

svn path=/trunk/; revision=1522
2000-01-22 06:22:44 +00:00
Guy Harris 7a36bede0b We are obliged to define HAVE_UNISTD_H in "config.h"; to avoid the
hideous problem on FreeBSD 3.[23] (and perhaps other BSDs) if
HAVE_UNISTD_H is defined before "zlib.h" is included, turn "file_seek()"
into a subroutine defined in a file that *undefines* HAVE_UNISTD_H
before including "zlib.h", so that the *only* call to "gzseek()" is made
from a file that does not have HAVE_UNISTD_H defined when it includes
"zlib.h".

Move "file_error()" to that file while you're at it, so it holds all the
wrappers that hide the presence or absence of zlib from routines to read
capture files.

Turn "file.h", which declared those wrapper functions as well as wrapper
macros, into "file_wrapper.h" - it belongs with the "file_wrapper.c"
file that defines the wrapper functions, not with "file.c" which handles
higher-layer file access functions.

Remove the comment in "configure.in" that explained why defining
HAVE_UNISTD_H was a bad idea, as we're not obliged to define it and work
around the problem.  (The comment in "file_wrapper.c" explains the
workaround.)

svn path=/trunk/; revision=1463
2000-01-13 07:09:20 +00:00
Guy Harris 48d5f6de4d Move the "guess what type of ATM traffic this is" stuff into the ATM
dissector; I don't think it's guaranteed that even a Sniffer will tell
you that (there may be situations where it can't figure it out, and
where the user didn't tell it), we may need it for "atmsnoop" traffic
and other types of ATM traffic as well, we will probably want to add to
it the ability to let the user specify "virtual circuit X.Y is this kind
of traffic", and we may also have Ethereal try to intuit it based on
previous traffic in the capture (Q.2931 call setup, LANE traffic, etc.).

Don't show the cell count if it's zero - assume that means we don't know
how many cells made up the packet.  Also don't show the AAL5 trailer if
the cell count is zero - the ATM Sniffer *might* sometimes supply a cell
count of 0 even if it has the AAL5 trailer, I guess, and we *might* see
some other capture file format that has the AAL5 trailer but no cell
count, but we'll cross that bridge when we come to it.

Add support for "atmsnoop" captures to the code to handle "snoop"
captures.

Use the field in "iptrace" headers that appears to be, in ATM captures,
a direction indicator - we may have the direction backwards, but, as an
STP packet was tagged as a DCE->DTE packet, and as the capturing
machine, which also was presumably the recipient of the packet, was an
AIX box, not a switch or bridge or some piece of networking equipment
such as that, it *probably* wasn't sending the STP packet, it was
probably receiving it.

svn path=/trunk/; revision=1120
1999-11-27 01:55:44 +00:00
Gilbert Ramirez 9b6369af4b Support for iptrace 1.0 traces (AIX 3). Thanks to Florian Lohoff
<flo@rfc822.org> for the sample traces.

It turns out that the iptrace 2.0 header is simply an extension to
the iptrace 1.0 header. It also appears that iptrace 1.0 has only tv_sec, but
not tv_usec, which explains why the fields are separated in the iptrace 2.0
header, but doesn't explain why the iptrace 2.0 header has tv_sec copied
in two places.

I changed iptrace.c to detect FDDI captures via if_type, even though I
don't have a trace to substantiate this. If *should* work, given that
loopback, ethernet, token-ring, and X.25 work. If it doesn't work, someone
will let me know.

svn path=/trunk/; revision=1117
1999-11-26 17:57:14 +00:00
Gilbert Ramirez d68a8709c7 Detect x.25 and loopback traces via if_type field, not the
interface name. Thanks to Olivier for testing this. The only link type
detected by interface name is FDDI.

svn path=/trunk/; revision=1094
1999-11-22 15:55:08 +00:00
Gilbert Ramirez f7cf81e479 Add comments showing IFT names for the IFT-to-Wiretap encapsulation array.
If a interface type is not recognized, set error to WTAP_ERR_UNSUPPORTED
instead of WTAP_BAD_RECORD.

Continue to check for X.25, FDDI, and loopback traces via the interface
name instead of the newly-discovered if_type field in the packet header.
Once Olivier confirms that his traces still work by checking only if_type,
I'll change the code. But he's on vacation right now. ATM, Ethernet, and
Token-Ring are discovered via the if_type field.

svn path=/trunk/; revision=1063
1999-11-19 05:48:21 +00:00
Guy Harris ef8ff95ac8 (AppTrafType & ATT_HLTYPE) is the type of high-level traffic, and
AppHLType is the subtype of that type; set them appropriately (as best
we can, given that we can only *guess* what kind of traffic it is) for
"iptrace" captures in Wiretap.  (Alas, more work is needed to
distinguish Ethernet from Token-Ring LANE traffic....)

Handle VPI = 0, VCI = 5 as the Signalling AAL in "iptrace" captures.

svn path=/trunk/; revision=1058
1999-11-18 09:39:12 +00:00
Gilbert Ramirez 32e13732c0 Check in my work so far on enabling the ATM iptrace capability. Not
all packets are recognized yet, but ILMI and Classical IP (LLCMX) are.
The ATM iptrace facility uses the ngsniffer_atm_phdr pseudo header so that
ethereal doesn't have to worry about yet another psuedo header.

svn path=/trunk/; revision=1057
1999-11-18 08:50:37 +00:00
Guy Harris 2937a86a62 Add some comment based on some spelunking done in some capture files,
and on a comment that "libpcap"/BPF on AIX appears to return 6 as the
network type for an Ethernet device - the BSD IFT_ETHER is 6.

svn path=/trunk/; revision=1048
1999-11-17 07:50:33 +00:00
Guy Harris d86ecc2302 Whitespace cleanup.
svn path=/trunk/; revision=773
1999-10-06 03:30:21 +00:00
Guy Harris 0d43b16fdd Add "wtap_file_encap()", to return the encapsulation of packets in the
file (which could be WTAP_ENCAP_UNKNOWN, if we couldn't determine it, or
WTAP_ENCAP_PER_PACKET, if we could determine the encapsulation of
packets in the file, but they didn't all have the same encapsulation).
This may be useful in the future, if we allow files to be saved in
different capture file formats - we'd have to specify, when creating the
capture file, the per-file encapsulation, for those formats that don't
support per-packet encapsulations (we wouldn't be able to save a
multi-encapsulation capture in those formats).

Make the code to read "iptrace" files set the per-file packet
encapsulation - set it to the type of the first packet seen, and, if any
subsequent packets have a different encapsulation, set it to
WTAP_ENCAP_PER_PACKET.

svn path=/trunk/; revision=772
1999-10-06 03:29:36 +00:00
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
Gilbert Ramirez 49388049d3 Made iptrace wiretap module return error on partial packets, instead of
expecting it as normal. Added paragraph about iptrace oddities to README.
I also added a section to the README about how to report bugs.

svn path=/trunk/; revision=519
1999-08-20 04:07:09 +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
Gerald Combs c7e8a7e855 Added a patch from Olivier Abad to handle X.25 iptrace captures.
svn path=/trunk/; revision=390
1999-07-28 01:35:34 +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
Gilbert Ramirez 2dbd008ea5 Added display filters to wiretap.
svn path=/trunk/; revision=198
1999-03-01 18:57:07 +00:00
Gilbert Ramirez 7757b2e72b I removed the per-file encapsulation type from wiretap, and make all filetypes
provide a per-packet encapsulation type. this required minor modifications to
ethereal.

svn path=/trunk/; revision=162
1999-01-07 16:15:37 +00:00
Gilbert Ramirez efa3b6ff41 Added files to handle AIX iptrace 2.0 files in wiretap.
svn path=/trunk/; revision=148
1999-01-03 04:30:13 +00:00