"-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