"config.guess" and "config.sub" vefore running "libtool", and restore
them after running "libtool", so that it doesn't gratuitously "help" us
by installing whatever old versions of those scripts happen to be part
of the version of libtool on the machine.
svn path=/trunk/; revision=4369
"returns an invalid file handle, if used in a Windows program,
that will cause the program to hang indefinitely"), so we can't
use a pipe to a print command to print to a printer.
Eventually, we should try to use the native Win32 printing API
for this (and also use various UNIX printing APIs, when present?).
For now, we support only printing to a file in Windows.
svn path=/trunk/; revision=4366
will override our versions of "config.guess" and "config.sub", which we
don't want. (We don't use "--force" with "automake --add-missing".)
svn path=/trunk/; revision=4363
specifies how the selector values used as keys in those tables are to be
displayed, and the title to use when displaying the table.
Use that information in the code to display the initial and current
entries of various dissector tables.
Have the dissector for BACnet APDUs register itself by name, and have
the BACnet NPDU dissector call it iff the BAC_CONTROL_NET bit isn't set,
rather than doing it with a dissector table.
svn path=/trunk/; revision=4358
the "The Compiler and Tools" section on
http://fink.sourceforge.net/doc/porting/basics.php
Do so on MacOS X regardless of whether the compiler is called "gcc" or
not, as that page also indicates that the compiler is installed as "cc".
svn path=/trunk/; revision=4354
the parent under which the field was registered.
This is the *unoptimized* version, to give developers something
to use while the optimized version is being created.
svn path=/trunk/; revision=4351
add "dissect_ndr_ctx_hnd()" for dissecting context handles, and
use it in various DCERPC dissectors;
beef up the MS Security Account Manager dissector.
Also, export "NT_errors[]" for use by that dissector.
svn path=/trunk/; revision=4350
you're doing NetBIOS-over-TCP (yes, I've seen that, with one response
being a Transaction and the other being a Read and X), so the frame
number is insufficient as a key in the hash table of matched
request/response pairs; use the frame number and the MID.
svn path=/trunk/; revision=4344
already contain a pointer to an epan_dissect_t, which contains
the proto_tree.
Routines calling epan_dissect_new() do not create their own
proto_tree via proto_tree_create_root(); instead, they pass a boolean
to epan_dissect_new() telling it whether it should create the root
proto_tree.
svn path=/trunk/; revision=4343
libpcap format, and say that it's also used by "other tools" (tcpdump
and Ethereal/Tethereal aren't the only tools that write captures in that
format).
Weaken the claim that we read Etherpeek files to say only that we read
Etherpeek versions 5, 6, and 7 for Macintosh, so people don't conclude
that we read Etherpeek-for-Windows captures (we don't).
svn path=/trunk/; revision=4337
files would put a 32-bit quantity on a 16-bit boundary without padding;
this means that many compilers will insert the padding and thus make the
structure not match what's in the file.
Instead of using a C structure, #define values for the offsets of
fields, read the header into an array of bytes, and extract values using
the offsets.
svn path=/trunk/; revision=4334
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
formats we can read (and to put them in the order in which they're
mentioned in the man pages, to make it easier to make sure the lists are
the same).
svn path=/trunk/; revision=4330
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
insensitive, make its label sensitive or insensitive too.
When "update list of packets in real time" mode is on, make the ring
buffer mode toggle button, and the "number of ring buffer files" spin
button, insensitive, as ring buffer mode is not supported in "update
list of packets in real time" captures.
When "update list of packets in real time" mode is off, make the
auto-scroll mode button insensitive, as auto-scroll mode is meaningless
unless you're doing an "update list of packets in real time" capture.
Bundle all the sensitivity setting into a single common routine.
Make "ring buffer" two words.
svn path=/trunk/; revision=4325
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=4324
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
Guy Harris