Without that, you could add a comment to a record in a file format the
reading code for which doesn't allocate blocks, but the comment doesn't
get saved, as there's no block in which to save the comment option.
This simplifies some code paths, as we're either using the record's
modified block or we're using the block as read from the file, there's
no third possibility.
If we attempt to read a record, and we get an error, and a block was
allocated for the record, unreference it, so the individual file readers
don't have to worry about it.
It only registers one file type/subtype, so rename it to
wtap_register_file_type_subtype().
That will also force plugins to be recompiled; that will produce compile
errors for some plugins that didn't change to match the new contents of
the file_type_subtype_info structure.
Also check to make sure that the registered file type/subtype supports
at least one type of block; a file type/subtype that doesn't return
*any* blocks and doesn't permit *any* block types to be written is not
very useful. That should also catch most if not all other plugins that
didn't change to match the new contents of the file_type_subtype_info
structure.
Don't make errors registering a file type/subtype fatal; just complain,
don't register the bogus file type/subtype, and drive on.
Instead of a "supports name resolution" Boolean and bitflags for types of
comments supported, provide a list of block types that the file
type/subtype supports, with each block type having a list of options
supported. Indicate whether "supported" means "one instance" or
"multiple instances".
"Supports" doesn't just mean "can be written", it also means "could be
read".
Rename WTAP_BLOCK_IF_DESCRIPTION to WTAP_BLOCK_IF_ID_AND_INFO, to
indicate that it provides, in addition to information about the
interface, an ID (implicitly, in pcapng files, by its ordinal number)
that is associated with every packet in the file. Emphasize that in
comments - just because your capture file format can list the interfaces
on which a capture was done, that doesn't mean it supports this; it
doesn't do so if the file doesn't indicate, for every packet, on which
of those interfaces it was captured (I'm looking at *you*, Microsoft
Network Monitor...).
Use APIs to query that information to do what the "does this file
type/subtype support name resolution information", "does this file
type/subtype support all of these comment types", and "does this file
type/subtype support - and require - interface IDs" APIs did.
Provide backwards compatibility for Lua.
This allows us to eliminate the WTAP_FILE_TYPE_SUBTYPE_ values for IBM's
iptrace; do so.
Provide a wiretap routine to get an array of all savable file
type/subtypes, sorted with pcap and pcapng at the top, followed by the
other types, sorted either by the name or the description.
Use that routine to list options for the -F flag for various commands
Rename wtap_get_savable_file_types_subtypes() to
wtap_get_savable_file_types_subtypes_for_file(), to indicate that it
provides an array of all file type/subtypes in which a given file can be
saved. Have it sort all types, other than the default type/subtype and,
if there is one, the "other" type (both of which are put at the top), by
the name or the description.
Don't allow wtap_register_file_type_subtypes() to override any existing
registrations; have them always register a new type. In that routine,
if there are any emply slots in the table, due to an entry being
unregistered, use it rather than allocating a new slot.
Don't allow unregistration of built-in types.
Rename the "dump open table" to the "file type/subtype table", as it has
entries for all types/subtypes, even if we can't write them.
Initialize that table in a routine that pre-allocates the GArray before
filling it with built-in types/subtypes, so it doesn't keep getting
reallocated.
Get rid of wtap_num_file_types_subtypes - it's just a copy of the size
of the GArray.
Don't have wtap_file_type_subtype_description() crash if handed an
file type/subtype that isn't a valid array index - just return NULL, as
we do with wtap_file_type_subtype_name().
In wtap_name_to_file_type_subtype(), don't use WTAP_FILE_TYPE_SUBTYPE_
names for the backwards-compatibility names - map those names to the
current names, and then look them up. This reduces the number of
uses of hardwired WTAP_FILE_TYPE_SUBTYPE_ values.
Clean up the type of wtap_module_count - it has no need to be a gulong.
Have built-in wiretap file handlers register names to be used for their
file type/subtypes, rather than building the table in init.lua.
Add a new Lua C function get_wtap_filetypes() to construct the
wtap_filetypes table, based on the registered names, and use it in
init.lua.
Add a #define WSLUA_INTERNAL_FUNCTION to register functions intended
only for internal use in init.lua, so they can be made available from
Lua without being documented.
Get rid of WTAP_NUM_FILE_TYPES_SUBTYPES - most code has no need to use
it, as it can just request arrays of types, and the space of
type/subtype codes can be sparse due to registration in any case, so
code has to be careful using it.
wtap_get_num_file_types_subtypes() is no longer used, so remove it. It
returns the number of elements in the file type/subtype array, which is
not necessarily the name of known file type/subtypes, as there may have
been some deregistered types, and those types do *not* get removed from
the array, they just get cleared so that they're available for future
allocation (we don't want the indices of any registered types to changes
if another type is deregistered, as those indicates are the type/subtype
values, so we can't shrink the array).
Clean up white space and remove some comments that shouldn't have been
added.
Remove most of the built-in file types from the table in
wiretap/file_access.c and, instead, have the file types register
themselves, using wtap_register_file_type_subtypes().
This reduces the source code changes needed to add a new file type from
three (add the handler, add the file type to the table in file_access.c,
add a #define for the file type in wiretap/wtap.h) to one (add the
handler). (It also requires adding the handler's source file to
wiretap/CMakeLists.txt, but that's required in both cases.)
A few remain because the WTAP_FILE_TYPE_SUBTYPE_ #define is used
elsewhere; that needs to be fixed.
Fix the wiretap/CMakefile.txt file to scan k12text.l, as that now
contains a registration routine. In the process, avoid scanning files
that don't implement a file type and won't ever have a registration
routine.
Add a Lua routine to fetch the total number of file types; we use that
in some code to construct the wtap_filetypes table, which we need to do
in order to continue to have all the values that used to come from the
WTAP_FILE_TYPE_SUBTYPE_ types.
While we're at it, add modelines to a file that lacked them.
That makes them work as input to a mergecap that writes pcapng files.
File types that don't have a single per-file encapsulation type need
more work, with multiple fake IDBs, one for each packet encapsulation
type seen in the file, unless we can generate real IDBs.
Change-Id: I2859e4f7fb15ec0c0f31a4044dc15638e5db7826
Reviewed-on: https://code.wireshark.org/review/37983
Petri-Dish: Guy Harris <gharris@sonic.net>
Tested-by: Petri Dish Buildbot
Reviewed-by: Guy Harris <gharris@sonic.net>
The time stamps are calculated by sequential processing, not read from a
value in the packet record, so we don't supply them when reading
randomly. Make sure the presence flags are 0 in that case (our callers
currently don't look at time stamps when reading randomly, because
some other file formats also don't supply time stamps for random reads,
but we should make it clean).
Change-Id: Ic035cc7d4eb36f76beefcfd98a389af09365d363
Reviewed-on: https://code.wireshark.org/review/37004
Reviewed-by: Guy Harris <gharris@sonic.net>
wtap_read_bytes() returns TRUE on *success*, so if we're in the loop,
the last read succeeded, and no error code was supplied. When we *exit*
the loop, the read didn't succeed; check for the status then. If we got
a short read, we ran out of file data, so check the heuristics (even if
it's not an integral number of 2-byte blocks, treat it as a CAM
Inspector file - it might have gotten cut short); if we got a real read
error, report that to our caller.
Bug: 16458
Change-Id: Ia1e838006744dadbc2883459aec16d0d11b732e1
Reviewed-on: https://code.wireshark.org/review/36795
Petri-Dish: Guy Harris <gharris@sonic.net>
Tested-by: Petri Dish Buildbot
Reviewed-by: Guy Harris <gharris@sonic.net>
Fall back on the Wayback Machine for some links.
Change-Id: I6a44a2caaeb4fa521c2f08196e7c36069e3bb842
Reviewed-on: https://code.wireshark.org/review/34103
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Change all wireshark.org URLs to use https.
Fix some broken links while we're at it.
Change-Id: I161bf8eeca43b8027605acea666032da86f5ea1c
Reviewed-on: https://code.wireshark.org/review/34089
Reviewed-by: Guy Harris <guy@alum.mit.edu>
That makes it - and the routines that implement it - work more like the
seek-read routine.
Change-Id: I0cace2d0e4c9ebfc21ac98fd1af1ec70f60a240d
Reviewed-on: https://code.wireshark.org/review/32727
Petri-Dish: Guy Harris <guy@alum.mit.edu>
Tested-by: Petri Dish Buildbot
Reviewed-by: Guy Harris <guy@alum.mit.edu>
A CAM inspector file maintains a global time counter in units of
1us. Set the correct resolution for the packet timestamps.
Keep track of the time counter when the file is loaded and we walk
through the file from start to end. Process timestamp blocks in the
file. Each of those blocks updates a part of the overall time counter.
Change-Id: I138cd8fb287e591b078babc2403a599287df1397
Reviewed-on: https://code.wireshark.org/review/27904
Reviewed-by: Martin Kaiser <wireshark@kaiser.cx>
Petri-Dish: Martin Kaiser <wireshark@kaiser.cx>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Separate the stuff that any record could have from the stuff that only
particular record types have; put the latter into a union, and put all
that into a wtap_rec structure.
Add some record-type checks as necessary.
Change-Id: Id6b3486858f826fce4b096c59231f463e44bfaa2
Reviewed-on: https://code.wireshark.org/review/25696
Reviewed-by: Guy Harris <guy@alum.mit.edu>
The first is deprecated, as per https://spdx.org/licenses/.
Change-Id: I8e21e1d32d09b8b94b93a2dc9fbdde5ffeba6bed
Reviewed-on: https://code.wireshark.org/review/25661
Petri-Dish: Anders Broman <a.broman58@gmail.com>
Petri-Dish: Dario Lombardo <lomato@gmail.com>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Use WTAP_MAX_PACKET_SIZE_STANDARD, set to 256KB, for everything except
for D-Bus captures. Use WTAP_MAX_PACKET_SIZE_DBUS, set to 128MB, for
them, because that's the largest possible D-Bus message size. See
https://bugs.freedesktop.org/show_bug.cgi?id=100220
for an example of the problems caused by limiting the snapshot length to
256KB for D-Bus.
Have a snapshot length of 0 in a capture_file structure mean "there is
no snapshot length for the file"; we don't need the has_snap field in
that case, a value of 0 mean "no, we don't have a snapshot length".
In dumpcap, start out with a pipe buffer size of 2KB, and grow it as
necessary. When checking for a too-big packet from a pipe, check
against the appropriate maximum - 128MB for DLT_DBUS, 256KB for
everything else.
Change-Id: Ib2ce7a0cf37b971fbc0318024fd011e18add8b20
Reviewed-on: https://code.wireshark.org/review/21952
Petri-Dish: Guy Harris <guy@alum.mit.edu>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Guy Harris <guy@alum.mit.edu>
The current mechanism that reads the first 20 blocks looking for a headerd
oesn't work in all cases. I was given sample files that consist of
data blocks only and have no header.
Use a new approach to detect a .camins file by searching for pairs of
size high + size low blocks, either read or write. Go through the
entire file. If we have significantly more pairs than single, non-matching
blocks, this is a camins file.
Change-Id: Ic91e7db7149b105e26896d1a89cad4a2a73d0f13
Reviewed-on: https://code.wireshark.org/review/19603
Reviewed-by: Martin Kaiser <wireshark@kaiser.cx>
Petri-Dish: Martin Kaiser <wireshark@kaiser.cx>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Roland Knall <rknall@gmail.com>
These file formats have 16-bit packet lengths, so, even with some extra
metadata added, the packet data length will never be bigger than
WTAP_MAX_PACKET_SIZE. (No, we won't ever reduce WTAP_MAX_PACKET_SIZE.)
Change-Id: I9e1b1d90971f91cc6e5d66d0aa93841445b2bc22
Reviewed-on: https://code.wireshark.org/review/15186
Reviewed-by: Guy Harris <guy@alum.mit.edu>
This is consistent with what the rest of the files do, and doesn't
require that the compiler explicitly be told to treat the current
directory as an include directory.
Change-Id: Iefaedd2acc936f45d5095546f8dea7167d2e88c8
Reviewed-on: https://code.wireshark.org/review/14797
Reviewed-by: Guy Harris <guy@alum.mit.edu>
git/epan/dissectors/packet-a21.c:478:25: error: 'item' was marked unused but was used
[-Werror,-Wused-but-marked-unused]
proto_item_append_text(item, "%s", val_to_str_const(event_id, a21_event_vals, "Unknown"));
^
Added manual change id because file-jpeg.c forced the use of commit -n
Change-Id: Iffff53d6253758c8454d9583f0a11f317c8390cb
Reviewed-on: https://code.wireshark.org/review/14666
Reviewed-by: Jörg Mayer <jmayer@loplof.de>
Clean up some things we ran across while making those changes.
Change-Id: Ic0d8943d36e6e120d7af0a6148fad98015d1e83e
Reviewed-on: https://code.wireshark.org/review/4581
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Add wtap_read_bytes(), which takes a FILE_T, a pointer, a byte count, an
error number pointer, and an error string pointer as arguments, and that
treats a short read of any sort, including a read that returns 0 bytes,
as a WTAP_ERR_SHORT_READ error, and that returns the error number and
string through its last two arguments.
Add wtap_read_bytes_or_eof(), which is similar, but that treats a read
that returns 0 bytes as an EOF, supplying an error number of 0 as an EOF
indication.
Use those in file readers; that simplifies the code and makes it less
likely that somebody will fail to supply the error number and error
string on a file read error.
Change-Id: Ia5dba2a6f81151e87b614461349d611cffc16210
Reviewed-on: https://code.wireshark.org/review/4512
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Pcap-ng files don't have a per-file time stamp resolution, they have a
per-interface time stamp resolution. Add new time stamp resolution
types of "unknown" and "per-packet", add the time stamp resolution to
struct wtap_pkthdr, have the libwiretap core initialize it to the
per-file time stamp resolution, and have pcap-ng do the same thing with
the resolution that it does with the packet encapsulation.
Get rid of the TS_PREC_AUTO_XXX values; just have TS_PREC_AUTO, which
means "use the packet's resolution to determine how many significant
digits to display". Rename all the WTAP_FILE_TSPREC_XXX values to
WTAP_TSPREC_XXX, as they're also used for per-packet values.
Change-Id: If9fd8f799b19836a5104aaa0870a951498886c69
Reviewed-on: https://code.wireshark.org/review/4349
Reviewed-by: Guy Harris <guy@alum.mit.edu>
In particular, epan/wslua/lrexlib.c has its own buffer_ routines,
causing some linker warnings on some platforms, as reported in bug
10332.
(Not to be backported to 1.12, as that would change the API and ABI of
libwsutil and libwiretap. We should also make the buffer_ routines in
epan/wslua/lrexlib.c static, which should also address this problem, but
the name change avoids other potential namespace collisions.)
Change-Id: I1d42c7d1778c7e4c019deb2608d476c52001ce28
Reviewed-on: https://code.wireshark.org/review/3351
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Otherwise, if you link with both libwiretap and libfiletap, it's
anybody's guess which one you get. That means you're wasting memory
with two copies of its routines if they're identical, and means
surprising behavior if they're not (which showed up when I was debugging
a double-free crash - fixing libwiretap's buffer_free() didn't fix the
problem, because Wireshark happened to be calling libfiletap' unfixed
buffer_free()).
There's nothing *tap-specific about Buffers, anyway, so it really
belongs in wsutil.
Change-Id: I91537e46917e91277981f8f3365a2c0873152870
Reviewed-on: https://code.wireshark.org/review/3066
Reviewed-by: Guy Harris <guy@alum.mit.edu>
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>
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>
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>
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>
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>
(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>
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
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
for read and seek-read.
Clarify a comment. (wtap_open_offline() only rewinds the file before
calling each open routine; once one of those routines has decided the
file belongs to it, the seek offset belongs to it, so it needs to do all
the seeking necessary - files with a file header *don't* want a rewind,
they want to leave the seek offset positioned *past* the file header so
it can read the records that follow the file header.)
svn path=/trunk/; revision=49347
Guy Harris