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
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
Sniffer trace, and printout therefrom, sent to me by Jeff Foster. (The
Sniffer manuals I'd had a chance to read didn't say what the units
were.)
svn path=/trunk/; revision=744
same (which raises the question "so why the heck are there two types?" -
note that the way you're supposed to tell Ethernet from 802.3 packets is
by looking at the value of the type/length field; both of them can be
transmitted on the same wire), so we'll treat them the same.
svn path=/trunk/; revision=733
"zlib" was built in FreeBSD 3.2 (and possibly other 4.4-Lite-derived
BSDs), if HAVE_UNISTD_H is defined before "zlib.h" is included, the
declaration of "gzseek()" in "zlib.h" expands to something that doesn't
match what's in the OS's "zlib".
svn path=/trunk/; revision=721
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
not, so it's OK to use "zlib" to read capture files, as it handles
uncompressed files correctly.
When *writing* capture files, however, we can't detect automatically
whether the user wanted to write the file out as a compressed file or
not, so we should *NOT* use "zlib" until we add a flag to the API
specifying whether to write the file out as a compressed file or not.
Furthermore, the code in Ethereal that implements the "-S" flag depends
on being able to get the "FILE *" for a capture file being written, so
that it can "fflush()" it.
svn path=/trunk/; revision=703
bounce bar for compressed file support). Note that the progress bar may
not grow smoothly for compressed files, but it should be reasonably accurate
for files which are large enough to matter.
svn path=/trunk/; revision=701
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
not like #preprocessor_macros that do not start at
the first column.
So write:
#ifdef FOO
# include <dummy1.h>
# define DUMMY 1
#else
# include <dummy2.h>
# define DUMMY 2
#endif
instead of
#ifdef FOO
#include <dummy1.h>
#define DUMMY 1
#else
#include <dummy2.h>
#define DUMMY 2
#endif
svn path=/trunk/; revision=668
family has a set of debug commands that allow you to log the traffic on a
WAN or dialup connection as text, e.g.
RECV-iguana:241:(task: B04E12C0, time: 1975358.50) 15 octets @ 8003D634
[0000]: FF 03 00 3D C0 06 C9 96 2D 04 C1 72 00 05 B8
Created wtap_seek_read() which parses the textual data for and Ascend
trace, and does a normal fseek() and fread() for any other file type.
The fseek()/fread() pairs in file.c were replaced with the new function.
svn path=/trunk/; revision=652
this causes "Makefile.in" to have two GPL notices - "Makefile.in" and
the "Makefile" generated from it are generated files, so maybe that's
OK).
svn path=/trunk/; revision=639
don't seek around it - some implementations of the standard I/O library
routines (e.g., the ones in Solaris 2.5.1, at least) appear not to be
clever enough to handle seeks that occur within the buffer by moving the
current buffer position; instead, they do a seek on the underlying file
descriptor *and* appear to throw out the buffer, forcing them to do
another read.
Instead, read it into a buffer.
svn path=/trunk/; revision=626
header fields we don't look at - some implementations of the standard
I/O library routines (e.g., the ones in Solaris 2.5.1, at least) appear
not to be clever enough to handle seeks that occur within the buffer by
moving the current buffer position; instead, they do a seek on the
underlying file descriptor *and* appear to throw out the buffer, forcing
them to do another read.
Instead, read the entire record header into a structure, and pick the
relevant bits out of it.
Also, skip over the FCS in LAPB captures by reading it rather than
seeking around it (should we put it in the pseudo-header?).
svn path=/trunk/; revision=625
Use "pletohs()" and "pletohl()" to access 16-bit and 32-bit fields in
the file and packet headers, as those fields are little-endian.
svn path=/trunk/; revision=612
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
"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
Have the code that opens "libpcap" files for writing check to make sure
that the Wiretap encapsulation can be written to a "libpcap" file, and
return -1 and supply a new WTAP_ERR_UNSUPPORTED_ENCAP error code if it
can't.
Handle that new error code in "wtap_strerror()".
svn path=/trunk/; revision=546
code supplied by a Wiretap routine (whether a positive UNIX "errno" code
or a negative Wiretap error code), and returns an error message
corresponding to it.
Use that to construct the message Ethereal put up in a message box for
those errors for which we don't have Ethereal put up a message of its
choice.
svn path=/trunk/; revision=545
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
and in different capture files; throw in some heuristics to try to
figure out whether the 4-byte header is:
1) PPP-over-HDLC (some version of ISDN4BSD?);
2) big-endian AF_ value (BSD on big-endian platforms);
3) little-endian AF_ value (BSD on little-endian platforms);
4) two octets of 0 followed by an Ethernet type (Linux, at least
on little-endian platforms, as mutated by "libpcap").
Make a separate Wiretap encapsulation type, WTAP_ENCAP_NULL,
corresponding to DLT_NULL.
Have the PPP code dissect the frame if it's PPP-over-HDLC, and have
"ethertype()" dissect the Ethernet type and the rest of the packet if
it's a Linux-style header; dissect it ourselves only if it's an AF_
value.
Have Wiretap impose a maximum packet size of 65535 bytes, so that it
fails more gracefully when handed a corrupt "libpcap" capture file
(other capture file formats with more than a 16-bit capture length
field, if any, will have that check added later), and put that size in
"wtap.h" and have Ethereal use it as its notion of a maximum packet
size.
Have Ethereal put up a "this file appears to be damaged or corrupt"
message box if Wiretap returns a WTAP_ERR_BAD_RECORD error when opening
or reading a capture file.
Include loopback interfaces in the list of interfaces offered by the
"Capture" dialog box, but put them at the end of the list so that it
doesn't default to a loopback interface unless there are no other
interfaces. Also, don't require that an interface in the list have an
IP address associated with it, and only put one entry in the list for a
given interface (SIOCGIFCONF returns one entry per interface *address*,
not per *interface* - and even if you were to use only IP addresses, an
interface could conceivably have more than one IP address).
Exclusively use Wiretap encapsulation types internally, even when
capturing; don't use DLT_ types.
svn path=/trunk/; revision=540
from RADCOM WAN/LAN Analyzers.
(BTW, the previous checkin also removed the comments about the hack
wherein we pretended that ATM Sniffer captures were really Ethernet,
Token-Ring, or RFC 1483 captures, given that said hack was itself
removed.)
svn path=/trunk/; revision=526
washed out to sea the code that used to pretend that an ATM Sniffer
capture was an Ethernet or Token-Ring Sniffer capture.
svn path=/trunk/; revision=524
file, instead of throwing out all but LANE or RFC 1483 data frames and
pretending that the former are just Ethernet or Token-Ring frames.
Add some level of decoding for ATM LANE, but not all of it; the rest,
including decoding non-LANE frames, is left as an exercise for somebody
who has captures they want to decode, an interest in decoding them, ATM
expertise, and time....
svn path=/trunk/; revision=523
variable from lanalyzer_t (plus an additional variable which wasn't being
used). While I was in there I cleaned up some comments and renamed a couple
variables to make more sense.
svn path=/trunk/; revision=521
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
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=518
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
the variable for the return value of "wtap_dump_close()", just check it
against EOF; shoving it into "ret" means it gets set to 0 on a
successful close, but a return value of 0 means "wtap_dump_close()"
failed.
svn path=/trunk/; revision=514
can't translate the encapsulation type, it should return an
encapsulation type; we add a new one, WTAP_ENCAP_UNKNOWN. and have it
return that.
Have "capture()" handle "wtap_pcap_encap_to_wtap_encap()" returning that
encapsulation type (if it happens, we need to add a new Wiretap
encapsulation type to handle the new "libpcap" encapsulation type).
svn path=/trunk/; revision=513
for errors when closing a file to which we've written packets (we don't
bother checking if we're giving up on a capture).
Add some more error checks in Wiretap.
Make a single list of all Wiretap error codes, giving them all different
values (some can be returned by more than one routine, so they shouldn't
be per-routine).
svn path=/trunk/; revision=510
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
reason for the failure, and have it do the checks to make sure the file
being opened is a plain file or a pipe.
Have "open_cap_file()" make use of that.
Don't automatically set "last_open_dir" if a "-r" flag was specified on
the command line - do so only if the file in question could actually be
opened.
svn path=/trunk/; revision=495
support for RADCOM Ltd.'s WAN/LAN analyzers (see
http://www.radcom-inc.com/
). Note: a
Make "S" a mnemonic for "Summary" in the "Tools" menu.
Move the routine, used for the "Tools/Summary" display, that turns a
wiretap file type into a descriptive string for it into the wiretap
library itself, expand on some of its descriptions, and add an entry for
files from a RADCOM analyzer.
Have "Tools/Summary" display the snapshot length for the capture.
svn path=/trunk/; revision=417
wiretap support for RADCOM Ltd.'s WAN/LAN analyzers (see
http://www.radcom-inc.com/
). Note: as I remember, IEEE 802.2/ISO 8022 LLC has somewhat of an SDLC
flavor to it, just as I think LAP, LAPB, LAPD, and so on do, so we may
be able to combine some of the LLC dissection and the LAPB dissection
into common code that could, conceivably be used for other SDLC-flavored
protocols.
Make "S" a mnemonic for "Summary" in the "Tools" menu.
Move the routine, used for the "Tools/Summary" display, that turns a
wiretap file type into a descriptive string for it into the wiretap
library itself, expand on some of its descriptions, and add an entry for
files from a RADCOM analyzer.
Have "Tools/Summary" display the snapshot length for the capture.
svn path=/trunk/; revision=416
- read only the real number of packets that have been written
by the child process. That's avoid incomplete packet read.
- special timeout handling no more necessary and the whole
real time capture and display behavior is much more
satisfying with this patch.
- wiretap modified to allow the reading of 'count' packets
with wtap_loop.
svn path=/trunk/; revision=398
others are copied into the build-tree by 'automake -a'. The autogen.sh
script runs autoheader, automake, and autoconf for the developer in order
to populate a fresh CVS image with the generated build tools.
svn path=/trunk/; revision=388
suggestion, this new method using a static array should use less memory
and be faster. It also has a nice side-effect of making the source-code
more readble, IMHO.
Changed the print routines to look for protocol proto_data instead of
looking at the text label as they did before, hoping that the data hex
dump field item starts with "Data (".
Added the -G keyword to ethereal to make it dump a glossary of display
filter keywords to stdout and exit. This data is then formatted with
the doc/dfilter2pod perl program to pod format, which is combined
with doc/ethereal.pod.template to create doc/ethereal.pod, from which
the ethereal manpage is created. This way we can keep the manpage up-to-date
with a list of fields that can be filtered on.
svn path=/trunk/; revision=364
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
new proto_tree routines. I also removed the check for lex and yacc from
wiretap's configure script. The IP dissector now uses
proto_register_field_array().
svn path=/trunk/; revision=348
operators that I had thrown in at the last moment. Sorry! But I'm trying
to get rid of those embarrassing shift/reduce and reduce/reduce warnings.
I also removed wiretap/wiretap.c, which is no longer needed.
svn path=/trunk/; revision=345
mechanism that is built into ethereal. Wiretap is now used to read all
file formats. Libpcap is used only for capturing.
svn path=/trunk/; revision=342
NetMon statistic packets for now. We might fix that problem with wiretap,
either filtering out those packets, and/or providing the summary
information through a new wiretap API.
svn path=/trunk/; revision=326
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
proto*() functions. The configure script tries to use ipv6 name resolution if
it knows the type of ipv6 stack the user has (this can be avoided with the
--disable-ipv6 switch) Additionally, the configure script now deals with wiretap
better. If the user doesn't want to compile wiretap, the wiretap is never
visited. A few unnecessary #includes were removed from some wiretap files, and
a CPP macro was moved from bpf.c to wtap.h.
svn path=/trunk/; revision=229
(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
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=218
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
It seems that a stable version of the library received a new function. This
should help RedHat folks, since they seem to have glib-1.0.1.
svn path=/trunk/; revision=216
and use them to extract stuff in "bpf_mk_bytecmp()", so as to avoid core
dumps on processors that require strict alignment.
svn path=/trunk/; revision=214
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
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
filename as the parameter. So far all the filetypes that wiretap can read
can be inferred from the first few bytes of the file, so we never
have to give wiretap a hint as to the file type.
svn path=/trunk/; revision=173
to add ssh to their firewall rules, so he's out of CVS for a few days.
This adds support for MS Network Monitor files to wiretap.
svn path=/trunk/; revision=172
This necessitated a change in ethereal because iptrace supports multi-NIC
packet capturing, including multi-datalink-type capturing.
svn path=/trunk/; revision=145
Tests for GTK versions are done during compilation, not during "./configure".
The big problems have been taken care of in this patch (functional change
in the packet clist and conversion of menu_factory to item_factory), but
plenty of smaller problems with dialogue boxes abound. I have fixed
a small problem with file_open*(), but have left 2 comments in just in case
I'm not going about this the right way. Can someone verify?
svn path=/trunk/; revision=127
"wiretap" subdirectory, and thus leave a "config.status" file around so
that one of the "auto{make,configure,header}" guys doesn't complain when
rebuilding stuff that it can't open "config.status". (The
"automake"-generated Makefile will recurse into "wiretap", and, at least
if you're doing builds from a tree freshly checked out from CVS, "XXX"
files will probably have been checked out before "XXX.in", so "make"
will try to reconstruct the "XXX" files from the "XXX.in" files.)
That also obviates the need to make "wiretap/Makefile" here.
We can also re-delete "wiretap/Makefile" from CVS - the problem that
caused me to bring it back wasn't caused by its absence, it was caused
by the above. As "Makefile"s generated by "configure" scripts depend on
the particular system on which you ran "configure", there's no One True
Makefile so "Makefile" should'n't be under CVS.
svn path=/trunk/; revision=95
the many complaints you get if you do a "configure" followed by a "make"
in a freshly-checked-out Ethereal source tree (it bitches when, or maybe
after, "automake"ing it, complaining about not being able to open
"config.status" - the right fix might be to make the "configure" script
recurse).
svn path=/trunk/; revision=94
CVS; it's generated by the "configure" script, and the resulting
Makefile is platform-dependent, so there's no One True Makefile to put
under CVS.
svn path=/trunk/; revision=93
That requires that, in the packet-reading loop, we pass to the callback
routine the offset in the file of a packet's data, because we can no
longer compute that offset by subtracting the size of the captured
packet data from the offset in the file after the data was read -
"snoop" may stick padding in after the packet data to align packet
headers on 4-byte boundaries.
Doing that required that we arrange that we do that for "libpcap"
capture files as well; the cleanest way to do that was to write our own
code for reading "libpcap" capture files, rather than using the
"libpcap" code to do it.
Make "wtap_dispatch_cb()" and "pcap_dispatch_cb()" static to "file.c",
as they're not used elsewhere.
If we're using wiretap, don't define in "file.h" stuff used only when
we're not using wiretap.
Update the wiretap README to reflect Gilbert's and my recent changes.
Clean up some memory leaks in "wiretap/lanalyzer.c" and
"wiretap/ngsniffer.c", where the capture-file-format-specific data
wasn't freed if the open failed.
svn path=/trunk/; revision=91
packet. The date is still not taken into account, so all the traces appear to
start on Jan 1, 1970. But the time of day is correct, so at least you get good
delta times.
svn path=/trunk/; revision=89
wiretap functions to be more generic and therefore allow an easier integration
of more packet-capture file types. I also put in all the GPL copyrights in the
wiretap code.
svn path=/trunk/; revision=83
because it is still in its infancy, but it can be compiled in optionally.
The library exists in its own subdirectory ethereal/wiretap. This patch also
edits all the packet-*.c files to remove the #include <pcap.h> line which is
unnecessary in these files. In the ethereal code, file.c is the most heavily
modified with #ifdef WITH_WIRETAP lines for the optional library.
svn path=/trunk/; revision=82
Guy Harris