Age | Commit message (Collapse) | Author | Files | Lines |
|
is defined as 17.
svn path=/trunk/; revision=4617
|
|
logging virtual interface, from Mike Frantzen.
svn path=/trunk/; revision=4616
|
|
duration, from Thomas Wittwer and Matthias Nyffenegger.
svn path=/trunk/; revision=4322
|
|
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
|
|
Tim Newsham.
Add in missing item for WTAP_ENCAP_CISCO_IOS in the Wiretap
encapsulation type table.
svn path=/trunk/; revision=4290
|
|
*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
|
|
tcpdump and, if we think we've found one, strip off the 3 padding bytes
they put in front of the frame.
svn path=/trunk/; revision=4201
|
|
svn path=/trunk/; revision=4199
|
|
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
|
|
svn path=/trunk/; revision=4126
|
|
svn path=/trunk/; revision=4077
|
|
can handle capture files bigger than 2GB.
svn path=/trunk/; revision=3993
|
|
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
|
|
* 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
|
|
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
|
|
svn path=/trunk/; revision=3125
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
of Nokia box (firewall) - yep, it's yet *another* mutant libpcap format
that didn't change the magic number, sigh....
svn path=/trunk/; revision=2440
|
|
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
|
|
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
|
|
forwarding e-mail address.
svn path=/trunk/; revision=1522
|
|
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
|
|
byte order from the machine that's reading them.
svn path=/trunk/; revision=1338
|
|
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
|
|
svn path=/trunk/; revision=1203
|
|
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
|
|
svn path=/trunk/; revision=620
|
|
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
|