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
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
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
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
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
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
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
Set "current_blob" when the first read is done from the random file, as
"current_blob" is the current blob in the random file.
svn path=/trunk/; revision=2262
sequential pass through the file build a list of information about the
compressed blobs, with the starting offset in the compressed file and in
the uncompressed byte stream for each blob.
When seeking on the random stream, check whether the target location is
within the uncompressed buffer we currently have; if not, use that list
to figure out which blob contains the target location, and read that
blob into the buffer. Then, as we now know that the target location is
within the uncompressed buffer we currently have, just move the current
pointer into that buffer to the target location.
This means we don't have to read forwards through any uninteresting
blobs in order to seek forwards, and don't have to go all the way back
to the beginning and seek forwards in order to seek backwards.
svn path=/trunk/; revision=2251
Differentiate between LAPB and LAPD sync sniffer traces.
Personally I think there must be a better way to find out which
protocol is in the trace but I currently lack the time to look
at the remaining frame info.
svn path=/trunk/; revision=2072
When trying to decode a sample trace from the NG offline sniffer
installation, one trace resulted in a "corrupted" error. The
reason was, that the file was a version 2 file format. That
format used type 8 for header purposes while version 4 uses it
for FRAME4.
svn path=/trunk/; revision=2071
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
"FILE_T" is either a "gzFile" or a "FILE *", depending on whether zlib
support is enabled or not). Fix various function declarations and
definitions.
svn path=/trunk/; revision=1984
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
to little-endian shorts - and to convert host-byte-order longs to
little-endian shorts (if the host-byte-order long will fit into a short,
"htoles()" does the right thing; if it doesn't, there is no right thing
to do - perhaps we should return a wiretap error, although, at least at
present, it's unlikely that we'll have packets bigger than 65535 bytes,
so it's unlikely that the values won't fit into a short).
svn path=/trunk/; revision=1953
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
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
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
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
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
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
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
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
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
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
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
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
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