trying to read the frame table, return -1 with "*err" set to
WTAP_ERR_SHORT_READ, don't return 0 - we've already decided that the
file is a NetMon file, so we shouldn't return a "this isn't a NetMon
file" indication, we should return a "this file is too short" error, as
that's what the problem is.
Fix up the error messages for WTAP_ERR_SHORT_READ to indicate that the
read might have gotten cut short in the middle of data other than a
packet.
svn path=/trunk/; revision=4331
Nisbet.
Make a comment in "wiretap/file.c" clearer, so people know where to put
the entries for their capture file type.
svn path=/trunk/; revision=4328
files to get that big.
From Thomas Wittwer and Matthias Nyffenegger:
Support for "ring buffer mode", wherein there's a ring buffer of N
capture files; as each capture file reaches its maximum size (the ring
buffer works only with a maximum capture file size specified), Ethereal
rolls over to the next capture file in the ring buffer, replacing
whatever packets might be in it with new packets.
svn path=/trunk/; revision=4323
Rename WTAP_ENCAP_PRISM to WTAP_ENCAP_PRISM_HEADER, to match
DLT_PRISM_HEADER.
Add in missing capture support for WTAP_ENCAP_PRISM_HEADER when
capturing with "pcap_open_live()" rather than reading the capture from a
pipe.
svn path=/trunk/; revision=4299
*always* zero, so it won't always work, and it's somewhat gross. The
right answer is "don't use Digital/Tru64 UNIX's tcpdump, use
tcpdump.org's".
svn path=/trunk/; revision=4202
for AIX 5.x's non-standard libpcap, where "pcap_datalink()" doesn't
return DLT_ values, it returns RFC 1573 ifType values.
Put that wrapper, and the routine to get the interface list, in a
separate file, for packet-capture utility routines, so not everybody who
includes "util.h" needs to include <pcap.h>.
Fix up the Wiretap hack for dealing with said incompatibility to use the
correct ifType value for Token Ring.
svn path=/trunk/; revision=4184
No, Nokia *weren't* kind enough to change the major or minor version
number in the capture file when they changed the format, just as they
weren't kind enough to change the magic number.
svn path=/trunk/; revision=4173
with one capture I've seen, but perhaps that was done with an old
version of AIX, and newer versions use a minor version number, in the
file, of 4.
However, libpcap hasn't used a minor version of 2 for ages, so perhaps
AIX hasn't updated their libpcap in ages, and aren't about to do so
soon. If they do, let's hope they change the magic number. The capture
file in question *does* have the capture length and real length in the
old, pre-2.3, order, so it really looks as if it's an old version,
rather than IBM trying to be "helpful" by using a different minor
version number so that you can distinguish between normal libpcap and
AIX libpcap formats.)
svn path=/trunk/; revision=4164
Update the lists of known capture file formats in the Tethereal,
editcap, and mergecap man pages to match the current list (as found in
the Ethereal man page).
svn path=/trunk/; revision=4039
the specified encapsulation with the specified capture file type, and
that we can allocate a "wtap_dumper *".
If we could do all that, and could create the dump file, but the
file-type-specific create routine fails (e.g., because there's not
enough disk space to write out the header), remove the dump file.
svn path=/trunk/; revision=4032
don't need to check whether zlib has them. We *do*, however, have to
check for "gzseek()", as we don't have our own version of that.
svn path=/trunk/; revision=3963
versions of these commands in file_wrappers.c. This allows us to
compile successfully even on platforms where X has an older zlib built
in.
Removed this restriction from acinclude.m4
svn path=/trunk/; revision=3948
which we store it a "size_t", and then fix up the bugs that were
revealed by the compiler warnings that produced - "fwrite()" returns 0,
not a negative number, on an I/O error.
Fix up some other items to have type "size_t", or to have various
unsigned types, while we're at it, to squelch compiler warnings.
svn path=/trunk/; revision=3867
were just DLPI data link types, and didn't know that the list had
expanded at some point and that Sun *used* some of the new types (e.g.,
in atmsnoop), or decided on their own to go beyond those types to encode
an Oh-So-Useful link speed indication, or just didn't *care* that they
were just DLPI data link types.
Therefore, we have to map Shomiti link types to wiretap types using a
different mapping table. For now, we assume files with a version number
of 2 are snoop files, and version numbers of 3, 4, and 5 are Shomiti
files; Shomiti claims to use a version number of 2 as well, but to
determine whether a file with a version number of 2 is a snoop file or a
Shomiti file requires that we look at the header of the first packet and
assume that if there's more than 3 bytes of padding it's a Shomiti file.
The return value from "fwrite()" is a "size_t"; make the variable into
which we store it a "size_t", and then fix up the bugs that were
revealed by the compiler warnings that produced - "fwrite()" returns 0,
not a negative number, on an I/O error.
svn path=/trunk/; revision=3866
Optimize use of AC_CHECK_FUNC in wiretap/acinclude.m4
Move #include "config.h" to be first include in some files.
From albert chin (china@thewrittenword.com)
svn path=/trunk/; revision=3857
checking for "gzgets()" in zlib.
If there is a "zlib.h" header, and there is a "gzgets()" in zlib, check
whether we find "gzgets()" in zlib when we link with the GTK+ link
flags, and, if not, fail. People often grab XFree86 source and build
and install it on their systems, and they appear sometimes to
misconfigure XFree86 so that, even on systems with zlib, it assumes
there is no zlib, so the XFree86 build process builds and installs its
own "mini-zlib" in the X11 library directory. The "mini-zlib" lacks
"gzgets()", and that's the zlib with which Ethereal gets linked, so the
build of Ethereal fails.
svn path=/trunk/; revision=3849
"--with-pcap", it adds the "include" subdirectory of that directory to
the list of directories to search for include files, rather than adding
the directory itself.
Check whether libpcap defines "pcap_version", and define
HAVE_PCAP_VERSION if it does. Use "pcap_version" iff HAVE_PCAP_VERSION
is defined, rather than special-casing MacOS X.
Don't #define a string for the WinPcap version; just leave
HAVE_PCAP_VERSION undefined on Windows, as WinPcap 2.2beta is out, so we
can no longer assume that the Windows version of Ethereal is using
WinPcap 2.1.
svn path=/trunk/; revision=3792
replace "--with-plugindir" with "--with-plugins", and have the
plugin directory optional - this allows plugins to be disabled;
add "--traditional-cpp" on MacOS X/Darwin (Apple's "cc" compiler
requires it, for some annoying reason, even though it is, as far
as I know, GCC-based, and other GCC's don't require it);
on MacOS X, don't use "pcap_version[]", as, for some annoying
reason, libpcap on MacOS X doesn't define it.
Clean up some whitespace in the help messages for the configure script.
Move the AM_CONDITIONAL for SETUID_INSTALL after the point at which
"enable_setuid_install" is set, as it tests "enable_setuid_install".
svn path=/trunk/; revision=3788
* gcc 3.0 warning fixes:
- text2pcap.c: The number of characters to scan should probably not be 0
- wiretap/csids.c: using preincrement on a variable used on both
sides of an assignment might be undefined by the C99(?) standard
* turn on additional warnings for epan and wiretap too
- epan/configure.in
- wiretap/configure.in
* Fix some warnings (missing includes, signed/unsigned, missing
initializers) found by turning on the warnings
- all other files :-)
svn path=/trunk/; revision=3709
compressed Sniffer files by sequentially moving forward, and we no
longer seek backward by seeking to the beginning and then seeking
forward to the new position, we now seek to the beginning of the
compressed block that contains the target position, if we're not already
in that block, and then move to the appropriate position in that block.
svn path=/trunk/; revision=3658
get from calling "wtap_file()", so get rid of the call and the
(otherwise unused) variable to which its result gets assigned.
That lets us get rid of "wtap_file()" in Wiretap.
It also lets us get rid of the include of "zlib.h" in "file.h"; the
#defines of "file_open()", "filed_open()", and "file_close()" are also
unnecessary, so we get rid of those as well.
However, that means we need to include <zlib.h> in "gtk/main.c" and
"tethereal.c", so that the version number of libz is defined and can
show up in the version string.
svn path=/trunk/; revision=3652
specified to "--with-pcap", add that directory to the include file and
library search paths, so that you can use "--with-pcap=DIR" to search
for libpcap in a directory other than the standard ones (either because
it was installed somewhere other than under "/usr" or "/usr/local", or
because you want to use a special version you've installed rather than
the standard one).
svn path=/trunk/; revision=3611
"-L/usr/local/lib" added to CFLAGS and LDFLAGS merely as a result of
running AM_PATH_GLIB, as 1.2.9 and later don't install headers directly
under "/usr/local/include". Therefore, we have to put
"-I/usr/local/include" into CFLAGS ourselves, just as we do in the
top-level configure script, or we run the risk of not being able to find
other packages (libpcap, zlib, etc.) if it's installed under
"/usr/local".
svn path=/trunk/; revision=3318
that the loop in "lanalyzer_open()" is an infinite loop, so the "return
0;" at the end isn't necessary to suppress a compiler warning with that
compiler - and Sun C not only figures it out, it warns that the
"g_assert_not_reached()" and the "return 0;" are unreachable, so I'll
take them out for now (and put them back if my older GCC at home still
requires it to suppress warnings).
svn path=/trunk/; revision=3310
simply PPP data that doesn't have a username associated with it, e.g. for
a dedicated WAN link as opposed to a dialup link.
svn path=/trunk/; revision=3274
Pre-compiled zlib provided at
http://www.ethereal.com/distribution/win32/zlib-1.1.3-fixed.zip
"fixed" because the pre-compiled version in the "extralibs" package
from the Gimp/Win32 page has a fault zlib.lib in it.
Add note about zlib in README.win32; more work needs to be done to
this file to mention new packaging method.
svn path=/trunk/; revision=3263
We us $(VERSION), defined in the top-level config.nmake, to replace
@VERSION@ in various files. $(RC_VERSION) and $(WTAP_VERSION) are
similarly used.
svn path=/trunk/; revision=3258
this, as
1) we still need to handle platforms that don't support 64-bit
integral data types, so we still needed the old stuff in some
fashion anyway
and
2) MSVC appears to treat structures as requiring 8-byte
alignment in some cases, and "guint64"s require 8-byte
alignment on at least some platforms, forcing structures
containing those 64-bit time stamps to have a size that's a
multiple of 8 bytes, which *isn't* the correct size for the
data record header.
svn path=/trunk/; revision=3177
DLT_HDLC to it.
Make a separate dissector for Cisco HDLC, and add a dissector for Cisco
SLARP. Have the PPP dissector call the Cisco HDLC dissector if the
address field is the Cisco HDLC unicast or multicast address. Use the
Cisco HDLC dissector for the Cisco HDLC Wiretap encapsulation type.
Add a new dissector table "chdlctype", for Cisco HDLC packet types
(they're *almost* the same as Ethernet types, but 0x8035 is SLARP, not
Reverse ARP, and 0x2000 is the Cisco Discovery protocol, for example),
replacing "fr.chdlc".
Have a "chdlctype()" routine, similar to "ethertype()", used both by the
Cisco HDLC and Frame Relay dissectors. Have a "chdlc_vals[]"
"value_string" table for Cisco HDLC types and protocol names. Split the
packet type field in the Frame Relay dissector into separate SNAP and
Cisco HDLC fields, and give them the Ethernet type and Cisco HDLC type
"value_string" tables, respectively.
svn path=/trunk/; revision=3133
beginning of the file before reading anything from the file is bogus -
do that in the loop that tries each of the open routines, instead.
(They may have to reset the seek pointer later if, for example, the
capture file begins with the first packet, and the "open()" routine
looks at that packet to try to guess whether the packet is in the file
format in question.)
Set "wth->data_offset" to 0 while you're at it, so capture file readers
don't have to do that, either.
svn path=/trunk/; revision=3123
- it only allows you to convert a *signed* 64-bit integer to a "double".
Cast the result of "pletohll()" to "gint64" before returning it from a
function that returns a "double".
svn path=/trunk/; revision=3033
in some places use "guint64", on plaforms where it's available,
rather than floating point (we don't yet use it universally, as
we'd have to provide code to do 64-bit arithmetic on
platforms/compilers where 64-bit integral types aren't
supported);
use .838096 microseconds rather than 1 microseconds as the time
stamp units for NetXRay 2.x format, as those capture files seem
to use that time stamp (that's the Sniffer "PC" time stamp;
perhaps when Network Associates assimilated Cinco, they changed
the time stamp units).
svn path=/trunk/; revision=3027
HAVE_XXX_H if xxx.h is present, but doesn't recognize AC_CHECK_HEADER as
such, and thus doesn't put anything about HAVE_XXX_H into "config.h.in",
and thus HAVE_XXX_H doesn't get defined even if xxx.h is present.
svn path=/trunk/; revision=2942
(We really need to put in some rudimentary 64-bit integer support, for
the benefit of platforms+compilers that don't support it; the
floating-point calculations we're doing now appear not to get exactly
the right answer, from an experiment at reading a NetMon 2.x file and
writing it back out as NetMon 2.x with editcap.)
svn path=/trunk/; revision=2939
REC_HEADER2 encapsulation type.
Modified skip_header_records to accept REC_HEADER3-REC_HEADER7.
These header records would cause file read error if the capture file was
compressed.
svn path=/trunk/; revision=2910
"Internetwork analyzer" capture, from Jeff Foster. (It's not a
replacement for the heuristics, as
1) at least one PPP capture doesn't have a type 7 record
and
2) LAPB/X.25 and LAPD/ISDN might both be "HDLC" captures and
we'd need to figure out how to tell them apart.)
svn path=/trunk/; revision=2902
version of libpcap; that's used on Linux for captures on the "any"
device (which captures from all interfaces simultaneously) and for
captures on devices whose link-layer type libpcap doesn't (yet) support
natively.
The spanning tree code, when checking for GV{M,R,...}P packets, must
first check whether the link-layer destination address is, in fact, an
Ethernet-style address; on Linux cooked captures, there *is* no
destination address, so it's of type AT_NONE, not AT_ETHER.
svn path=/trunk/; revision=2772
packet is too small to contain all the data that the frame header claims
was captured for the packet; treat that as a bad record, and return an
error.
svn path=/trunk/; revision=2711
in order to check whether to use ANSI C features such as "const".
GCC defines it as 1 even if extensions that render the implementation
non-conformant are enabled; Sun's C compiler (and, I think, other
AT&T-derived C compilers) define it as 0 if extensions that render
the implementation non-conformant are enabled; Microsoft Visual C++
6.0 doesn't define it at all if extensions that render the implementation
non-conformant are enabled.
We define it as 0 in "config.h.win32", so that those generated files will use
those features (and thus not get type warnings when compiled with
MSVC++).
svn path=/trunk/; revision=2698
just an EOF, it should set "*err" to 0. Fix up a bunch of read routines
for various capture file types to set "*err" appropriately.
svn path=/trunk/; revision=2667
Add in stuff for a bunch of libpcap formats either in libpcap 0.5.2 or
in the current CVS version; we don't implement all of them in
Ethereal/Wiretap (those are "#if 0"ed out), but we do implement the IEEE
802.11 stuff (which isn't yet in libpcap or tcpdump, but the CVS version
of libpcap *does* reserve 105 as the encapsulation type number for
802.11).
svn path=/trunk/; revision=2646
don't need to work around that.
The offset, for a given packet, at which "ascend_seek()" should start
searching for that packet's header must be computed separately from the
offset, for that packet, at which "ascend_seek()" should start searching
for the *next* packet - if the file is a "wdd" capture, and the packet
has a "Date:" header and a WD_DIALOUT_DISP header, the search for that
packet should start at the beginning of the "Date:" header, but the
search for the next packet should start after the WD_DIALOUT_DISP
header, as if we start it after the "Date:" header, the search will stop
at the packet's own WD_DIALOUT_DISP header, as a packet could have a
WD_DIALOUT_DISP header but no "Date:" header.
svn path=/trunk/; revision=2620
place call to" header (I presume this can happen if there was a call in
progress when the packet was sent or received); don't require the
Date: 01/12/1990. Time: 12:22:33
Cause an attempt to place call to 14082750382
to be present in every packet.
(Only the date on the first packet is used, and only if it's present in
the first packet; if the first packet doesn't have a date, we can't
easily go back and fix up the previous packets, *especially* in programs
such as Tethereal and editcap which make only one pass through the
capture.
We set the called number to a null string if that's the case; we could
assume, in the sequential pass, that it's the phone number from the last
call, and remember that for use when doing random access.)
svn path=/trunk/; revision=2617
is WTAP_ENCAP_LAPB *or* WTAP_ENCAP_V120, and we have to set "p2p.sent"
in the capture file for *all* WTAP_ENCAP_LAPD captures; fix the
i4btrace and Sniffer capture file readers to do so.
(XXX - should we eliminate "x25.flags", and use "p2p.sent" instead? The
directions for X.25 are DTE->DCE and DCE->DTE, not "sent" and
"received", but I suspect that "sent" and "received" should be thought
of from the point of view of the DTE, so DTE->DCE is "sent" and DCE->DTE
is "received"; the directions for ISDN are user->network and
network->user, but I suspect that "sent" and "received" should be
thought of from the standpoint of the user equipment, so user->network
is "sent" and network->user is "received".)
svn path=/trunk/; revision=2606
fix the interpretation of the date and time reported in capture
files;
use that date and time only to set the start date and time of
the capture, not to generate the time stamp for every packet.
Make the "struct tm" used for that local to the code to handle that
production in the grammar, rather than global.
For all captures, we *can* now fstat a compressed file (and have been
able to do so for a while, in fact), so revert to doing so and using the
ctime of the capture file if we can't get a date and time from the
file's contents.
svn path=/trunk/; revision=2605
Remove what appear to be a pair of dangling "else"s.
Before calling "mktime()" on a "struct tm", you have to set "tm_isdst",
so it knows what to do about daylight savings time; set it to -1, so it
picks the appropriate time (except, presumably, for those times that
don't exist, when the clock is moved forward, where there is no
appropriate time, and those times that exist twice, when the clock is
moved backward, where there are *two* times and you can't tell which is
appropriate).
svn path=/trunk/; revision=2604
these other than a trace file a client sent me. The header appears to
be similar to frame2 and frame4 records, but with extra bytes at the end.
The trace file also contains record types 13 - 17 which appear to contain
metainformation such as retransmit counts.
svn path=/trunk/; revision=2508
bundled with GTK+ 1.0[.x]), it works only with 1.2[.x] and later, so we
no longer need to check for 1.0[.x] and define HAVE_GLIB10.
svn path=/trunk/; revision=2500
8, which is NDIS's ATM type. At least one capture appears to have
LLC-encapsulated frames in it; for now, we'll map it to
WTAP_ENCAP_ATM_RFC1483 - and make Ethereal dissect
WTAP_ENCAP_ATM_RFC1483 by handing the frames to "dissect_llc()".
While we're at it, we'll have Ethereal panic if handed a Wiretap packet
type it doesn't dissect, rather than giving you a rather blank
dissection.
svn path=/trunk/; revision=2457
pseudo_header.
Use generic "p2p_phdr" instead of "lapd_phdr". Modify toshiba.c and
packet-lapd.c to take that into account.
Add frame.p2p_dir, a filterable field, 0=sent, 1=recvd
Make p2p_dir available in packe_info, as I think it will be needed
in VJ COMP and UNCOMP dissection.
Rename WTAP_ENCAP_TR to WTAP_ENCAP_TOKEN_RING.
Mention pppd-log support in man page.
Mention atmsnoop in README.
svn path=/trunk/; revision=2455
file header to 4; fortunately, as they appear to put their extensions to
snoop into the padding at the end of the record, all their capture files
look alike to programs such as snoop and Ethereal that ignore the
padding, so we can just treat version 4 just like version 2 (unless and
until Brent decides a new snoop format is called for, changes the record
header, and picks a version number that's the same as one used by
Shomiti).
svn path=/trunk/; revision=2447
objects are reference-counted so that won't make it disappear if
Ethereal is also linked with it as a shared SNMP library.
svn path=/trunk/; revision=2444
is, for now, handled as WTAP_ENCAP_PPP (although we may have to split
WTAP_ENCAP_PPP into more than one type at some point).
svn path=/trunk/; revision=2423
a "keep reading" boolean value is returned from the function.
This avoids having to hack around the fact that some file formats truly
do have records that start at offset 0. (i4btrace and csids have no
file header. Neither does the pppdump-style file that I'm looking at right now).
svn path=/trunk/; revision=2392
that these calls work on Win32. I still don't have a good reason as to
why this is necessary, but it fixes the problem. I'll continue looking
for a reason.
svn path=/trunk/; revision=2386
encapsulation type codes - for those libpcap type codes whose numerical
value is interpreted differently by different versions of libpcap,
include <pcap.h> if you can and, if you can, use what it defines to
control which Wiretap code we map those type codes to.
Also, map the new libpcap type codes introduced by libpcap 0.5.
svn path=/trunk/; revision=2369
Set "current_blob" when the first read is done from the random file, as
"current_blob" is the current blob in the random file.
svn path=/trunk/; revision=2262
- add <stdarg.h> or <varargs.h> in snprintf.h
and remove those inclusions in the other #ifdef NEED_SNPRINTF_H codes
- remove the check of multiple inclusions in source (.c) code
(there is a bit loss of _cpp_ performance, but I prefer the gain of
code reading and maintenance; and nowadays, disk caches and VM are
correctly optimized ;-).
- protect all (well almost) header files against multiple inclusions
- add header (i.e. GPL license) in some include files
- reorganize a bit the way header files are included:
First:
#include <system_include_files>
#include <external_package_include_files (e.g. gtk, glib etc.)>
Then
#include "ethereal_include_files"
with the correct HAVE_XXX or NEED_XXX protections.
- add some HAVE_XXX checks before including some system header files
- add the same HAVE_XXX in wiretap as in ethereal
Please forgive me, if I break something (I've only compiled and regression
tested on Linux).
svn path=/trunk/; revision=2254
sequential pass through the file build a list of information about the
compressed blobs, with the starting offset in the compressed file and in
the uncompressed byte stream for each blob.
When seeking on the random stream, check whether the target location is
within the uncompressed buffer we currently have; if not, use that list
to figure out which blob contains the target location, and read that
blob into the buffer. Then, as we now know that the target location is
within the uncompressed buffer we currently have, just move the current
pointer into that buffer to the target location.
This means we don't have to read forwards through any uninteresting
blobs in order to seek forwards, and don't have to go all the way back
to the beginning and seek forwards in order to seek backwards.
svn path=/trunk/; revision=2251
the C run-time library sets "statb.st_mode" appropriately, at least for
plain files and directories; it just doesn't offer the POSIX "S_ISxxx()"
macros to test the file type.
If those macros aren't defined (which might also be the case on really
ancient UNIX systems), define them appropriately, and use them even on
Win32 systems, so that we can properly report attempts by a user to read
from a directory on Win32, just as we do on UNIX.
svn path=/trunk/; revision=2188
defined on Win32 systems - it's not defined in <sys/types.h> on those
systems.
In "buffer.c", include "config.h", to cause HAVE_WINSOCK_H to be
defined, on systems that have it, so that we include it in <buffer.h>.
svn path=/trunk/; revision=2187
capture.c :
- modified capture() to try to open an interface as a pipe if pcap_open_live()
failed, and then read data in libpcap format from this pipe ;
- add new functions used by capture() : pipe_open_live() and pipe_dispatch()
which are equivalents to the pcap_ functions.
libpcap.[ch] :
- moved the MAGIC and headers definitions from libpcap.c to libpcap.h
because capture() now needs it.
svn path=/trunk/; revision=2181
1) aclocal expects autoconf/automake macros to be hidden;
2) GTK+ hid its autoconf/automake macros;
and, if both places exist but aren't the same directory, returns a "-I"
flag to tell aclocal to look in GTK+'s directory.
Then have "autogen.sh", and Makefiles in directories with "acinclude.m4"
files, use that script and pass what flag it supplies, if any, to
aclocal.
This should, I hope, avoid problems such as those FreeBSD systems where
GTK+ was installed from a port or package (and thus stuck its macros in
"/usr/X11R6/share/aclocal") but aclocal doesn't look there.
(It doesn't solve the problem of somebody downloading and installing,
say, libtool from source - which means it probably shows up under
"/usr/local", with its macros in "/usr/local/share/aclocal" - on a
system that comes with aclocal (meaning it probably just looks in
"/usr/share/aclocal", but that may be best fixed by, whenever you
download a source tarball for something that's part of your OS,
configuring it to install in the standard system directories and
*overwriting* your OS's version.)
svn path=/trunk/; revision=2165
is finally dead, and you're walking away, it springs up again and
attacks.
It appears that the ss990915 version of Alexey Kuznetzov's libpcap patch
has some extra stuff in the per-packet header for some sort of SMP
debugging, and that SuSE Linux 6.3 picked it up.
Thus, even if a libpcap file has the modified magic number, we *still*
have to go through the usual heuristic hell to figure out what type of
file it is.
svn path=/trunk/; revision=2164
When capturing, report errors trying to create the output file
with "file_open_error_message()".
Make the "for_writing" argument to "file_open_error_message()" a
"gboolean", as it's either TRUE (if the file is being opened for
writing) or FALSE (if it's being opened for reading).
Report EISDIR as "XXX is a directory (folder), not a file.".
When checking whether an "open()" of a capture file succeeded, check
whether "open()" returns a negative number, not whether it returns 0.
In "wtap_open_offline()", if the file to be opened is a directory,
return EISDIR, not WTAP_ERR_NOT_REGULAR_FILE, so that the error message
can say "that's a directory, not a file".
If "wtap_open_offline()" returns WTAP_ERR_NOT_REGULAR_FILE, don't just
say the file is "invalid", say it's a "special file" or socket or some
other weird type of file.
svn path=/trunk/; revision=2144
a pointer to the "wtap_pkthdr" structure for an open capture
file;
a pointer to the "wtap_pseudo_header" union for an open capture
file;
a pointer to the packet buffer for an open capture file;
so that a program using "wtap_read()" in a loop can get at those items.
Keep, in a "capture_file" structure, an indicator of whether:
no file is open;
a file is open, and being read;
a file is open, and is being read, but the user tried to quit
out of reading the file (e.g., by doing "File/Quit");
a file is open, and has been completely read.
Abort if we try to close a capture that's being read if the user hasn't
tried to quit out of the read.
Have "File/Quit" check if a file is being read; if so, just set the
state indicator to "user tried to quit out of it", so that the code
reading the file can do what's appropriate to clean up, rather than
closing the file out from under that code and causing crashes.
Have "read_cap_file()" read the capture file with a loop using
"wtap_read()", rather than by using "wtap_loop()"; have it check after
reading each packet whether the user tried to abort the read and, if so,
close the capture and return an indication that the read was aborted by
the user. Otherwise, return an indication of whether the read
completely succeeded or failed in the middle (and, if it failed, return
the error code through a pointer).
Have "continue_tail_cap_file()" read the capture file with a loop using
"wtap_read()", rather than by using "wtap_loop()"; have it check after
reading each packet whether the user tried to abort the read and, if so,
quit the loop, and after the loop finishes (even if it read no packets),
return an indication that the read was aborted by the user if that
happened. Otherwise, return an indication of whether the read
completely succeeded or failed in the middle (and, if it failed, return
the error code through a pointer).
Have "finish_tail_cap_file()" read the capture file with a loop using
"wtap_read()", rather than by using "wtap_loop()"; have it check after
reading each packet whether the user tried to abort the read and, if so,
quit the loop, and after the loop finishes (even if it read no packets),
close the capture and return an indication that the read was aborted by
the user if that happened. Otherwise, return an indication of whether
the read completely succeeded or failed in the middle (and, if it
failed, return the error code through a pointer).
Have their callers check whether the read was aborted or not and, if it
was, bail out in the appropriate fashion (exit if it's reading a file
specified by "-r" on the command line; exit the main loop if it's
reading a file specified with File->Open; kill the capture child if it's
"continue_tail_cap_file()"; exit the main loop if it's
"finish_tail_cap_file()".
svn path=/trunk/; revision=2095
2.002, as used by release 3.50 of the Network Associates Sniffer for
Windows; currently, we treat it just like the 2.001 version, so we
rename the version #define WTAP_FILE_NETXRAY_2_001 to
WTAP_FILE_NETXRAY_2_00x and use that for both 2.001 and 2.002.
svn path=/trunk/; revision=2087
Differentiate between LAPB and LAPD sync sniffer traces.
Personally I think there must be a better way to find out which
protocol is in the trace but I currently lack the time to look
at the remaining frame info.
svn path=/trunk/; revision=2072
When trying to decode a sample trace from the NG offline sniffer
installation, one trace resulted in a "corrupted" error. The
reason was, that the file was a version 2 file format. That
format used type 8 for header purposes while version 4 uses it
for FRAME4.
svn path=/trunk/; revision=2071
to that file, leave public definitions in wtap.h.
Rename "union pseudo_header" to "union wtap_pseudo_header".
Make the wtap_pseudo_header pointer available in packet_info struct.
svn path=/trunk/; revision=1989
"FILE_T" is either a "gzFile" or a "FILE *", depending on whether zlib
support is enabled or not). Fix various function declarations and
definitions.
svn path=/trunk/; revision=1984
there's no need to keep it around in memory - when the frame data is
read in when handing a frame, read in the information, if any, necessary
to reconstruct the frame header, and reconstruct it. This saves some
memory.
This requires that the seek-and-read function be implemented inside
Wiretap, and that the Wiretap handle remain open even after we've
finished reading the file sequentially.
This also points out that we can't really do X.25-over-Ethernet
correctly, as we don't know where the direction (DTE->DCE or DCE->DTE)
flag is stored; it's not clear how the Ethernet type 0x0805 for X.25
Layer 3 is supposed to be handled in any case. We eliminate
X.25-over-Ethernet support (until we find out what we're supposed to
do).
svn path=/trunk/; revision=1975
to little-endian shorts - and to convert host-byte-order longs to
little-endian shorts (if the host-byte-order long will fit into a short,
"htoles()" does the right thing; if it doesn't, there is no right thing
to do - perhaps we should return a wiretap error, although, at least at
present, it's unlikely that we'll have packets bigger than 65535 bytes,
so it's unlikely that the values won't fit into a short).
svn path=/trunk/; revision=1953
Tethereal was dying on me because err was initialized to some random value.
It was this section of code that would exit even if wtap_loop was successful
(returned TRUE) because err was never initialized or set to anything.
err = load_cap_file(&cf, out_file_type);
if (err != 0) {
dissect_cleanup();
exit(2);
}
<BIGGER sheepish grin>
Fixed even more errors in LLC dissector. I had inadvertantly used the
wrong tvbuff_t* when calling dissect_data_tvb(). There is no way we are going
to be successful in this tvbuff conversion w/o regression testing. I'm
working on setting up a simple Makefile for regression testing tonight.
That's why I'm finding so many bugs in my LLC conversion.
</BIGGER sheepish grin>
svn path=/trunk/; revision=1946
build "register.c" in the top-level Makefile;
set path in "config.nmake" to include the Cygwin directory for
tools - those tools are needed to build "register.c";
remove constructed source files, and some additional object
files, when doing "nmake clean".
svn path=/trunk/; revision=1896
and nettl captures - a "start" field is used for capture files where the
time stamps on packets are relative to some initial time stamp, e.g. the
time the capture started, but those file formats use absolute time
stamps, so no "start" field is needed.
Make the "this is an HP-UX 11.x nettl capture" flag a member of the
private data structure for a nettl capture, rather than a global - it's
per-capture-file state.
Once the "start" field is removed from the RADCOM private data
structure, there's nothing left, so eliminate the private data
structure.
svn path=/trunk/; revision=1863
standard output, in the rules to get Flex to produce scanner code; that
way, if Flex fails to run for some reason, we don't leave around a
zero-length or otherwise incorrect "XXX-scanner.c" file that might
keep a subsequent make from thinking it has to generate that file.
svn path=/trunk/; revision=1808
be built as multi-threaded programs; add "/MT" to the list of compiler
flags.
Add "clean" rules in subdirectories, and run subdirectory "nmake -f
Makefile.nmake clean" when "nmake -f Makefile.nmake clean" is done in
the top-level directory, so that "nmake -f Makefile.nmake clean" cleans
everything up.
svn path=/trunk/; revision=1791
standard output, in the rules to get Flex to produce scanner code; that
way, if Flex fails to run for some reason, we don't leave around a
zero-length or otherwise incorrect "XXX-scanner.c" file that might
keep a subsequent make from thinking it has to generate that file.
svn path=/trunk/; revision=1763
Free it as soon as we're at the end of the sequential pass through the
file; that way, if we keep the capture file open with Wiretap even after
that's done (as I may do as part of some stuff I'm working on), we
at least aren't hanging on to the frame table memory after that point.
svn path=/trunk/; revision=1741
from the frame table - Network Monitor 2.x, at least, doesn't always
write frame N+1 right after frame N.
To do that, we need to mallocate a big array to hold the frame table,
and free it when we close the capture file; this requires that we have
capture-file-type-specific close routines as well as
capture-file-type-specific read routines - we let it the pointer to that
routine be null if it's not needed. Given that, we might as well get
rid of the switch statement in "wtap_close()", in favor of using
capture-file-type-specific close routines, as per the comment before
that switch statement.
svn path=/trunk/; revision=1740
unlike FreeBSD and older versions of NetBSD, which give "gzseek()" and
"gztell()" signatures with "long" file-offset arguments, and thus, on
some versions, requires that "HAVE_UNISTD_H" *not* be defined before
including "zlib.h" if you want the functions declared with a signature
that matches what's actually in the library, it requires that it *be*
defined before including "zlib.h" if you want the functions declared
with a signature that matches what's actually in the library.
svn path=/trunk/; revision=1719
"save session" feature in many Windows-based telnet apps. CRT, by VanDyke,
in particular, will put in newlines at 80 columns.
svn path=/trunk/; revision=1692
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
This change allows you to add a new packet-*.c file and not cause a
recompilation of everything that #include's packet.h
Add the plugin_api.[ch] files ot the plugins/Makefile.am packaging list.
Add #define YY_NO_UNPUT 1 to the lex source so that the yyunput symbol
is not defined, squelching a compiler complaint when compiling the generated
C file.
svn path=/trunk/; revision=1637
eliminated the check in the top-level "configure.in", and leaving it in
the Wiretap one means that, on NetBSD, Ethereal gets built with zlib
support if zlib is present, but Wiretap doesn't - now they both get
built with zlib support. Thanks to Itojun for catching this one.
Put into the Wiretap "configure.in" code to note that, if the test for
"gzgets()" in zlib fails, we're disabling compressed capture file
support, as is done in the top-level "configure.in".
svn path=/trunk/; revision=1625
have top-level Makefile.nmake call Makefile.nmake's in subdirectories.
Build plugins, and build generated source (lex, yacc). The only thing we
can't build is register.c; I need to re-work the top-level Makefile.nmake
because it lists object files, not C files, which make-reg-dotc needs.
svn path=/trunk/; revision=1608
traces. The trace we got from Tom Poe (tomp@intrex.net) contains PPP
data which NetXRay has transformed into looking like Ethernet frames.
The hardware addresses are the bytes for the ASCII reprsentation of
"SRC" and "DEST", with null pad bytes at the end. Interesting.
svn path=/trunk/; revision=1576
supposed to look like "ftell()".
If you don't have zlib, just define "file_seek" as an alias for "fseek",
rather than defining it as a routine.
svn path=/trunk/; revision=1571
is bigger than a "long"; this is itojun's fix for that, turning
"file_tell()" into a wrapper function in "file_wrappers.c", just like
"file_seek()".
svn path=/trunk/; revision=1554
with MSVC 6.0 and 'nmake', the make tool that comes with MSVC.
It compiles, links, and runs. It doesn't run correctly. There's a problem
when reading files. I'm getting short reads. I'm not linking in zlib or
libsnmp because it first needs to be debugged.
I changed the plugin code to use gmodule instead of libltdl, but the
Unix build still links ethereal against libltdl. I'll fix that tonight; sorry
about leaving it in such a sad state, but I wanted to check in this code
before I left work on a Friday night. Ethereal still works, but the
building is less than optimal.
svn path=/trunk/; revision=1479
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
Added lots of #ifdef HAVE_*_H wrappers.
Added some #defines in config.h.win32
Check for more headers in configure.in
Added prototype for inet_aton() in inet_v6defs.h.
Changed "BYTE" token (i.e., #define) in ascend-gramamr.y because it
conflicts with a windows definition. Use HEXBYTE instead.
svn path=/trunk/; revision=1448
Linux systems with the isdn4linux patches; they help make DLT types even
less useful than they were after the various flavors of BSD proceeded to
add their own types past 14, with no coordination whatosever, so that
they overlapped, rendering it impossible to read a libpcap capture file
without knowing what particular OS generated it.
svn path=/trunk/; revision=1442
as the Ascend routers; those little buggers don't remember time very well.
The only timestamp available in the trace is relative to the beginning
of the trace.
So, right now I'm just using this relative timestamp as the absoulte time.
All my times are in 1969 (my timezone is GMT - 6), but all I care about
for now is the relative time, which is preserved even if the absolute time
is in the wrong decade.
svn path=/trunk/; revision=1404
the capture; set it to that when writing the capture.
Support Token Ring and FDDI captures (as per the network type in the
file header appearing to be either the NDIS network type, or the NDIS
network type minus 1 - I forget whether Ethernet has an NDIS type of 0
or 1).
Don't write the file header twice, keeping a static copy of it around,
as Wiretap code isn't supposed to keep any static data around; instead,
write it only when we're done writing out all the records (as we do on
Network Monitor captures).
Compute the time stamps when writing the file.
Give Windows Sniffer 1.1-format a short name, so "editcap" doesn't dump
core or print "(null)" in its usage message.
WTAP_ENCAP_NULL isn't supported by NetMon; don't write it.
svn path=/trunk/; revision=1336
instead of from DCE).
I can now open a RADCOM X.25 capture in ethereal, save it as sniffer, and
read it with a sniffer. The frame directions are correct. (BTW, the
snifconv.exe tool provided by RADCOM doesn't work with X.25 captures).
svn path=/trunk/; revision=1331
It's very basic, and doesn't write out the timestamps currently. It also
only handles WTAP_ENCAP_ETHERNET, although it can probably do the others,
but I don't have a good way to test them. This code has not yet been tested
against a Sniffer Pro, although wiretap can read the files just fine.
svn path=/trunk/; revision=1318
the "this is the first frame" flag, and the time stamp of the first
frame, used when writing Sniffer files, so that more than one could be
open at a time (Wiretap doesn't forbid that) and so that they're
initialized when you start writing a capture.
svn path=/trunk/; revision=1292
files (the former have a different per-packet header, and a different
magic number, from the standard "libpcap"; the latter have the same
per-packet header as "modified" "libpcap" files, but the same magic
number as standard "libpcap" files, sigh).
Support writing "libpcap" captures in all three formats (so that, for
example, people running Ethereal on RH 6.1 can write out captures that
the "tcpdump" that comes with RH 6.1 can read, although that's not the
default format we save in - there's no way to tell whether you're
running on RH 6.1, as far as I know; "uname()" just tells you, on Linux
systems, that the kernel is Linux 2.x, and what "x" is, it doesn't say
what the *rest* of the system is).
Fix the table in "file.c" to use Olivier's code for writing Sniffer
files.
svn path=/trunk/; revision=1288
I'm using 4.0 as the version in the REC_VERS record. It seems to work
with sniffer versions 4.40 and 5.0
No ATM support yet.
svn path=/trunk/; revision=1270
encapsulation types, and routines to translate encapsulation types to
names and short names to encapsulation types, for the benefit of
"editcap".
svn path=/trunk/; revision=1212
to, for example, specify on a command line the format that a program
should write; provide a routine to translate a file type to its short
name, and to translate a short name to the corresponding file type.
svn path=/trunk/; revision=1207
"wtap_file_type_string()" take, as its argument, a file type, rather
than a "wtap *".
Fix some range checks of file types to check against WTAP_NUM_FILE_TYPES
rather than WTAP_NUM_ENCAP_TYPES.
svn path=/trunk/; revision=1201
of all the file types in which a file can be saved.
Giving each dumpable file type a routine that checks whether a file of a
given file type and encapsulation can be written lets us hoist some
checks into common code from out of the open routines.
If the "dump close" routine for a dump stream is NULL, have that mean
that there's no action that needs to be taken on a close by the code to
handle that file type; some file types don't need that, as they can be
written purely sequentially.
svn path=/trunk/; revision=1200
structure before calling the "dump_open" routine for the file type; it
either has to be null or point to something that can be freed, as the
dump close routine frees what it points to if it's not null.
svn path=/trunk/; revision=1196
files.
Make the return type of a number of routines that return 1 (for "true")
on success and 0 (for "false") on failure to "gboolean", and make the 1's
and 0's TRUEs and FALSEs.
svn path=/trunk/; revision=1195
files.
Make the return type of a number of routines that return 1 (for "true")
on success and 0 (for "false") on failure to "gboolean", and make the 1's
and 0's TRUEs and FALSEs.
svn path=/trunk/; revision=1194
by pre-2.13 "autoconf", and there may be other problems with pre-2.12
"autoconf" as well; require "autoconf" 2.13 or later.
svn path=/trunk/; revision=1187
"gzgets()" is the one most recently added; it was added in 1.0.9.
Check for it, rather than for a list of functions, when checking for
"zlib" support - if you check for N functions, and they're all there,
you get N "-lz"s added to the list of libraries with which to link.
Indicate in the README that "zlib" versions prior to 1.0.9 definitely
won't work.
svn path=/trunk/; revision=1144
"gzseek()" *and* "gztell()" *and* "gzgets()" *and* "zError()" are all in
Zlib - we use all of them, and it appears that some older versions of
Zlib that some users had on their systems don't have some of them.
svn path=/trunk/; revision=1134
both LAPB and PPP captures get written out with that network type.
Flag it as WTAP_ENCAP_UNKNOWN when the file is opened, and, when we see
the first packet, check whether the address field is 0xFF, in which case
we flag it as PPP, or anything else, in which case we flag it as LAPB.
svn path=/trunk/; revision=1129
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
necessarily start at an offset of 128 into the file; we have to read the
first entry in the frame table to find the offset in the file of the
first frame. (That also works on NetMon 1.0.)
Keep the header size around, though, as we'll need it if we add code to
*write* NetMon files.
svn path=/trunk/; revision=1119
<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
warnings about multiple declaration of "pseudo_header" as a common.
Instead, define it only in "ascend-grammar.y", and declare it in
"ascend-int.h" as an "extern".
svn path=/trunk/; revision=1103
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
Also, explicitly compare the result of "memcmp()" against 0 - the
appearance of a comparison operator in the expression makes it clearer
what test is being done.
svn path=/trunk/; revision=1061
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
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
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
colors.c wasn't freeing path in one place
main.c wasn't freeing rc_file
the frame_buffer fix in wtap.c didn't clear everything.
svn path=/trunk/; revision=1001
and aligned g_malloc calls with g_free calls (i.e, we no longer mix-and-match
C-library malloc with GLIB g_free, and vice-versa).
svn path=/trunk/; revision=1000
of the "libpcap" patch that changes the per-packet header but not the
magic number - it seems to work on at least one capture file I tried it
on.
Give the modified "libpcap" format a WTAP_FILE type of its own (so that,
in the future, we could support writing captures out in that format,
possibly).
svn path=/trunk/; revision=987
Kuznetsov's modified "libpcap" *as long as you have the ss990915 or
later patch*; the 990417 patch, alas, changes the per-packet header but
*doesn't* change the magic number, so you can't just look at the magic
number to see that it's Not Standard Libpcap. (Even more unfortunately,
Red Hat appears to have picked up *that* patch for Red Hat 6.1; I've
filed bug 6773 with Bugzilla on their site - hopefully, if I'm not
misremembering the RH 6.1 code I've seen, and they really *did* pick up
the older patch, they'll fix it ASAP to use the new magic number, and
will make updates available.)
svn path=/trunk/; revision=986
overwritten here?" is probably "because I was cutting-and-pasting text
to insert the error-handling code, and didn't remove the "*err = errno"
from that particular case. Remove it now.
svn path=/trunk/; revision=955
Fix the error checking ("file_error()" returns an "errno" value *if*
there's an error and it's a UNIX error, but it may also return a
non-"errno" value for non-UNIX errors, so its return value should be
passed back through the "err" pointer).
svn path=/trunk/; revision=954
line of ISDN routers. Much like the ascend reader, this module reads an
ASCII hex dump of trace data.
Rearranged the order in which wiretap tries trace files, to keep the
ASCII-readers (ascend and toshiba) at the end, and put the binary-readers
(everything else) at the front of the list. If a telnet session of
and ascend trace or toshiba trace were captured near the beginning of
another trace, wiretap might think the trace was ascend or toshiba if it
tried that module first.
Fixed the way wtap_seek_read() selects functions to call. It was using
the encap type instead of the file type. We got lucky because
WTAP_ENCAP_ASCEND == WTAP_FILE_ASCEND
svn path=/trunk/; revision=952
more display filters for X.25;
no LCN in X.25 RESTART / DIAGNOSTIC / REGISTRATION packets;
support for nettl file format (nettl is a trace tool for HP-UX).
For now, it only supports traces for X.25 interfaces (tested
with HP-UX 10.20).
svn path=/trunk/; revision=879
for ip.ip_p and ip6.ip6_nxt (and other IPv6 header chain).
use val_to_str() as much as possible in dissect_{ipv6,pim,ripng}().
make --disable-zlib a default for netbsd (temporary workaround).
svn path=/trunk/; revision=827
parser/lexical analyzer in question are needed only in the ".c" files
for the generated parser and lexical analyzer, and Flex and Byacc/Bison
put them there; don't bother putting them in a header file, just
directly declare the functions with the right names.
svn path=/trunk/; revision=801
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