Commit Graph

7 Commits

Author SHA1 Message Date
Guy Harris ed86f51e49 wiretap: rename wtap_register_file_type_subtypes().
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.
2021-02-23 20:39:16 -08:00
Guy Harris 842a7cccf9 wiretap: have file handlers advertise blocks and options supported.
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.
2021-02-21 23:18:35 +00:00
Guy Harris a7256d50b5 wiretap: more work on file type/subtypes.
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.
2021-02-17 21:54:28 +00:00
Guy Harris b8b3531883 wiretap: register most built-in file types from its module.
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.
2021-02-14 00:58:46 -08:00
Guy Harris 20800366dd HTTPS (almost) everywhere.
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>
2019-07-26 18:44:40 +00:00
Peter Wu 961f1388e4 wiretap: fix truncated reads while reading compressed file formats
A lot of file dissectors (pcapng, json, etc.) assumed that the packet
size is equal to the file size. This is not true if the file was
compressed and could result in silently truncating reads or failing to
open a file (if the compressed file is larger than the actual data).

Observe that a lot of file dissectors are simply copies of each other.
Move the fixed implementation to wtap.c and reuse the methods everywhere
else. While at it, avoid an unnecessary large allocation/read in
ruby_marshal.

Change-Id: I8e9cd0af9c4d1bd37789a3b509146ae2182a5379
Reviewed-on: https://code.wireshark.org/review/30570
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Reviewed-by: Dario Lombardo <lomato@gmail.com>
Tested-by: Dario Lombardo <lomato@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Michael Mann <mmann78@netscape.net>
2018-11-10 23:24:05 +00:00
Dario Lombardo 24713511eb wiretap: add support for ruby marshal object files.
Change-Id: Iefba3b15c907966bb0b8d5c0ff9b6bb7097d326e
Reviewed-on: https://code.wireshark.org/review/27763
Petri-Dish: Jaap Keuter <jaap.keuter@xs4all.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-06-07 04:54:49 +00:00