Commit Graph

30 Commits

Author SHA1 Message Date
Guy Harris 6db77b000f Allow wtap_read() and wtap_seek_read() to return records other than packets.
Add a "record type" field to "struct wtap_pkthdr"; currently, it can be
REC_TYPE_PACKET, for a record containing a packet, or
REC_TYPE_FILE_TYPE_SPECIFIC, for records containing file-type-specific
data.

Modify code that reads packets to be able to handle non-packet records,
even if that just means ignoring them.

Rename some routines to indicate that they handle more than just
packets.

We don't yet have any libwiretap code that supplies records other than
REC_TYPE_PACKET or that supporting writing records other than
REC_TYPE_PACKET, or any code to support plugins for handling
REC_TYPE_FILE_TYPE_SPECIFIC records; this is just the first step for bug
8590.

Change-Id: Idb40b78f17c2c3aea72031bcd252abf9bc11c813
Reviewed-on: https://code.wireshark.org/review/1773
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2014-05-24 18:31:25 +00:00
Guy Harris a344c9736e Revert "Allow wtap_read() and wtap_seek_read() to return non-packet records."
This reverts commit c0c480d08c.

A better way to do this is to have the record type be part of struct wtap_pkthdr; that keeps the metadata for the record together and requires fewer API changes.  That is in-progress.

Change-Id: Ic558f163a48e2c6d0df7f55e81a35a5e24b53bc6
Reviewed-on: https://code.wireshark.org/review/1741
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2014-05-23 10:50:10 +00:00
Guy Harris c0c480d08c Allow wtap_read() and wtap_seek_read() to return non-packet records.
This is the first step towards implementing the mechanisms requestd in
bug 8590; currently, we don't return any records other than packet
records from libwiretap, and just ignore non-packet records in the rest
of Wireshark, but this at least gets the ball rolling.

Change-Id: I34a45b54dd361f69fdad1a758d8ca4f42d67d574
Reviewed-on: https://code.wireshark.org/review/1736
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2014-05-23 03:02:32 +00:00
Guy Harris a1b1c8bed5 Revert "Refactor Wiretap"
This reverts commit 1abeb277f5.

This isn't building, and looks as if it requires significant work to fix.

Change-Id: I622b1bb243e353e874883a302ab419532b7601f2
Reviewed-on: https://code.wireshark.org/review/1568
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2014-05-09 05:21:01 +00:00
Michael Mann 1abeb277f5 Refactor Wiretap
Start of refactoring Wiretap and breaking structures down into "generally useful fields for dissection" and "capture specific". Since this in intended as a "base" for Wiretap and Filetap, the "wft" prefix is used for "common" functionality.

The "architectural" changes can be found in cfile.h, wtap.h, wtap-int.h and (new file) wftap-int.h. Most of the other (painstaking) changes were really just the result of compiling those new architecture changes.

bug:9607
Change-Id: Ife858a61760d7a8a03be073546c0e7e582cab2ae
Reviewed-on: https://code.wireshark.org/review/1485
Reviewed-by: Michael Mann <mmann78@netscape.net>
2014-05-09 03:04:39 +00:00
Alexis La Goutte 296591399f Remove all $Id$ from top of file
(Using sed : sed -i '/^ \* \$Id\$/,+1 d')

Fix manually some typo (in export_object_dicom.c and crc16-plain.c)

Change-Id: I4c1ae68d1c4afeace8cb195b53c715cf9e1227a8
Reviewed-on: https://code.wireshark.org/review/497
Reviewed-by: Anders Broman <a.broman58@gmail.com>
2014-03-04 14:27:33 +00:00
Guy Harris 9d41c658fe No seek-read routines use the length argument, so eliminate it from
wtap_seek_read().

svn path=/trunk/; revision=54570
2014-01-02 20:47:21 +00:00
Guy Harris 853da2eb9b The "file types" we have are actually combinations of types and
subtypes, e.g. Network Monitor version 1 and Network Monitor version 2
are separate "file types", even though they both come from Network
Monitor.

Rename various functions, #defines, and variables appropriately.

svn path=/trunk/; revision=53166
2013-11-08 09:53:01 +00:00
Guy Harris 32b95570df Merge "read record header" and "read packet data" routines into a single
routine, used both by read and seek-read routines.

svn path=/trunk/; revision=49988
2013-06-17 21:18:47 +00:00
Guy Harris 8c9edf1280 Have the seek-read routines take a Buffer rather than a guint8 pointer
as the "where to put the packet data" argument.

This lets more of the libwiretap code be common between the read and
seek-read code paths, and also allows for more flexibility in the "fill
in the data" path - we can expand the buffer as needed in both cases.

svn path=/trunk/; revision=49949
2013-06-16 00:20:00 +00:00
Guy Harris a335cd8d87 Pull code to fill in a wtap_pkthdr into a hcidump_process_header()
routine, and use it in both the read and seek-read routines.

svn path=/trunk/; revision=49365
2013-05-17 05:31:21 +00:00
Guy Harris 88e9d1c1e5 Do not call wtap_file_read_unknown_bytes() or
wtap_file_read_expected_bytes() from an open routine - open routines are
supposed to return -1 on error, 0 if the file doesn't appear to be a
file of the specified type, or 1 if the file does appear to be a file of
the specified type, but those macros will cause the caller to return
FALSE on errors (so that, even if there's an I/O error, it reports "the
file isn't a file of the specified type" rather than "we got an error
trying to read the file").

When doing reads in an open routine before we've concluded that the file
is probably of the right type, return 0, rather than -1, if we get
WTAP_ERR_SHORT_READ - if we don't have enough data to check whether a
file is of a given type, we should keep trying other types, not give up.
For reads done *after* we've concluded the file is probably of the right
type, if a read doesn't return the number of bytes we asked for, but
returns an error of 0, return WTAP_ERR_SHORT_READ - the file is
apparently cut short.

For NetMon and NetXRay/Windows Sniffer files, use a #define for the
magic number size, and use that for both magic numbers.

svn path=/trunk/; revision=46803
2012-12-27 12:19:25 +00:00
Jakub Zawadzki 78631020b8 Add wtap_pseudo_header union to wtap_pkthdr structure.
Use pkthdr instead of pseudo_header as argument for dissecting.

svn path=/trunk/; revision=45601
2012-10-16 21:50:57 +00:00
Jeff Morriss 3551a86c36 We always HAVE_CONFIG_H so don't bother checking whether we have it or not.
svn path=/trunk/; revision=45015
2012-09-20 01:29:52 +00:00
Jakub Zawadzki bf81b42e1e Update Free Software Foundation address.
(COPYING will be updated in next commit)

svn path=/trunk/; revision=43536
2012-06-28 22:56:06 +00:00
Guy Harris 33bb54a945 file_seek() used to be a wrapper around fseek() or gzseek(), both of
which could use lseek() and were thus expensive due to system call
overhead.  To avoid making a system call for every packet on a
sequential read, we maintained a data_offset field in the wtap structure
for sequential reads.

It's now a routine that just returns information from the FILE_T data
structure, so it's cheap.  Use it, rather than maintaining the data_offset
field.

Readers for some file formats need to maintain file offset themselves;
have them do so in their private data structures.

svn path=/trunk/; revision=42423
2012-05-04 16:56:18 +00:00
Guy Harris b6ff142f60 Add a presence flag field to the packet information structure filled in
by Wiretap, to indicate whether certain fields in that structure
actually have data in them.

Use the "time stamp present" flag to omit showing time stamp information
for packets (and "packets") that don't have time stamps; don't bother
working very hard to "fake" a time stamp for data files.

Use the "interface ID present" flag to omit the interface ID for packets
that don't have an interface ID.

We don't use the "captured length, separate from packet length, present"
flag to omit the captured length; that flag might be present but equal
to the packet length, and if you want to know if a packet was cut short
by a snapshot length, comparing the values would be the way to do that.

More work is needed to have wiretap/pcapng.c properly report the flags,
e.g. reporting no time stamp being present for a Simple Packet Block.

svn path=/trunk/; revision=41185
2012-02-25 23:24:34 +00:00
Guy Harris d94bd07f99 Rename WTAP_ERR_BAD_RECORD to WTAP_ERR_BAD_FILE; it really reports any
form of corruption/bogosity in a file, including in a file header as
well as in records in the file.  Change the error message
wtap_strerror() returns for it to reflect that.

Use it for some file header problems for which it wasn't already being
used - WTAP_ERR_UNSUPPORTED shouldn't be used for that, it should only
be used for files that we have no reason to believe are invalid but that
have a version number we don't know about or some other
non-link-layer-encapsulation-type value we don't know about.

svn path=/trunk/; revision=40175
2011-12-13 09:53:50 +00:00
Guy Harris 6cbf6ce16c Add a new WTAP_ERR_DECOMPRESS error, and use that for errors discovered
by the gunzipping code.  Have it also supply a err_info string, and
report it.  Have file_error() supply an err_info string.

Put "the file" - or, for WTAP_ERR_DECOMPRESS, "the compressed file", to
suggest a decompression error - into the rawshark and tshark errors,
along the lines of what other programs print.

Fix a case in the Netscaler code where we weren't fetching the error
code on a read failure.

svn path=/trunk/; revision=36748
2011-04-21 09:41:52 +00:00
Guy Harris 4c93827e34 From Jakub Zawadzki:
file_read(buf, bsize, count, file) macro is compilant with fread
function and takes elements count+ size of each element, however to make
it compilant with gzread() it always returns number of bytes.

In wiretap file_read() this is not really used, file_read is called
either with bsize set to 1 or count to 1.

Attached patch remove bsize argument from macro.

svn path=/trunk/; revision=36491
2011-04-06 06:51:19 +00:00
Guy Harris a595f69ce4 The lack of _WITH_PHDR in WTAP_ENCAP_BLUETOOTH_H4 means there's no
pseudo-header, and hence there's no direction indication. Don't set
pinfo->p2p_dir for it.  Use WTAP_ENCAP_BLUETOOTH_H4_WITH_PHDR, not
WTAP_ENCAP_BLUETOOTH_H4, for capture files where we have the direction.

Don't assume pinfo->p2p_dir is either P2P_DIR_SENT or P2P_DIR_RECV when
setting the info column in various Bluetooth dissectors; it might be
unknown.

In the HCI H4 dissector, put the direction into the info column
regardless of whether we have a type match or not; the dissectors for
HCI packet types appear to assume it's been set (as they put a blank at
the beginning of the stuff they append to the direction).

svn path=/trunk/; revision=35933
2011-02-12 19:59:41 +00:00
Ulf Lamping 59d6c8ea33 change all file offsets from long to gint64 so we can - theoretically - handle files > 2GB correct.
Please distclean Win32 builds!

svn path=/trunk/; revision=19814
2006-11-05 22:46:44 +00:00
Guy Harris 2646996a82 Fail if *any* of the fields in the per-packet header of the first record
aren't sane, rather than requiring them *all* to have invalid values.

svn path=/trunk/; revision=16610
2005-11-27 12:10:03 +00:00
Ulf Lamping 723c80ea90 timestamp display precision:
- automatic adjustment depending on file format
- manual adjustment through menu items

save the setting in the recent file

svn path=/trunk/; revision=15534
2005-08-25 21:29:54 +00:00
Ulf Lamping 6f43fbb2f0 EVERYTHING IN THE BUILDBOT IS GOING TO BE RED!!! Sorry!
I've done more than a day to change the timestamp resolution from microseconds to nanoseconds. As I really don't want to loose those changes, I'm going to check in the changes I've done so far. Hopefully someone else will give me a helping hand with the things left ...

What's done: I've changed the timestamp resolution from usec to nsec in almost any place in the sources. I've changed parts of the implementation in nstime.s/.h and a lot of places elsewhere.

As I don't understand the editcap source (well, I'm maybe just too tired right now), hopefully someone else might be able to fix this soon.

Doing all those changes, we get native nanosecond timestamp resolution in Ethereal. After fixing all the remaining issues, I'll take a look how to display this in a convenient way...

As I've also changed the wiretap timestamp resolution from usec to nsec we might want to change the wiretap version number...

svn path=/trunk/; revision=15520
2005-08-24 21:31:56 +00:00
Guy Harris 8a8b883450 Set the svn:eol-style property on all text files to "native", so that
they have LF at the end of the line on UN*X and CR/LF on Windows;
hopefully this means that if a CR/LF version is checked in on Windows,
the CRs will be stripped so that they show up only when checked out on
Windows, not on UN*X.

svn path=/trunk/; revision=11400
2004-07-18 00:24:25 +00:00
Guy Harris ba72e955dc Have "wtap_read()" set "wth->phdr.pkt_encap" to "wth->file_encap",
rather than requiring individual capture file type handlers to do it
(unless they're doing per-packet encapsulation, in which case we check
to make sure they didn't *leave* it as WTAP_ENCAP_PER_PACKET).

svn path=/trunk/; revision=10290
2004-03-03 22:24:53 +00:00
Guy Harris d6cd61061e Have the Wiretap open, read, and seek-and-read routines return, in
addition to an error code, an error info string, for
WTAP_ERR_UNSUPPORTED, WTAP_ERR_UNSUPPORTED_ENCAP, and
WTAP_ERR_BAD_RECORD errors.  Replace the error messages logged with
"g_message()" for those errors with g_strdup()ed or g_strdup_printf()ed
strings returned as the error info string, and change the callers of
those routines to, for those errors, put the info string into the
printed message or alert box for the error.

Add messages for cases where those errors were returned without printing
an additional message.

Nobody uses the error code from "cf_read()" - "cf_read()" puts up the
alert box itself for failures; get rid of the error code, so it just
returns a success/failure indication.

Rename "file_read_error_message()" to "cf_read_error_message()", as it
handles read errors from Wiretap, and have it take an error info string
as an argument.  (That handles a lot of the work of putting the info
string into the error message.)

Make some variables in "ascend-grammar.y" static.

Check the return value of "erf_read_header()" in "erf_seek_read()".

Get rid of an unused #define in "i4btrace.c".

svn path=/trunk/; revision=9852
2004-01-25 21:55:17 +00:00
Guy Harris 305afc4e97 The quantities in the hcidump header are little-endian, not big-endian.
svn path=/trunk/; revision=8831
2003-10-30 11:53:48 +00:00
Guy Harris 95c1f2f7c9 From Marcel Holtmann: support for reading Linux Bluez Bluetooth stack
"hcidump -w" traces.

Note that Jesper Peterson contributed support for reading Endace ERF
files.

svn path=/trunk/; revision=8824
2003-10-30 03:11:03 +00:00