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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Gilbert Ramirez