Add macros to round to multiples of 2, 4, 8, 16, and 32.
Use them instead of independently defined macros.
(We don't define a general "round to a power of 2" macro to avoid the
risk of somebody passing something other than a power of 2 to it.)
Experience has shown that:
1. The current logging methods are not very reliable or practical.
A logging bitmask makes little sense as the user-facing interface (who
would want debug but not crtical messages for example?); it's
computer-friendly and user-unfriendly. More importantly the console
log level preference is initialized too late in the startup process
to be used for the logging subsystem and that fact raises a number
of annoying and hard-to-fix usability issues.
2. Coding around G_MESSAGES_DEBUG to comply with our log level mask
and not clobber the user's settings or not create unexpected log misses
is unworkable and generally follows the principle of most surprise.
The fact that G_MESSAGES_DEBUG="all" can leak to other programs using
GLib is also annoying.
3. The non-structured GLib logging API is very opinionated and lacks
configurability beyond replacing the log handler.
4. Windows GUI has some special code to attach to a console,
but it would be nice to abstract away the rest under a single
interface.
5. Using this logger seems to be noticeably faster.
Deprecate the console log level preference and extend our API to
implement a log handler in wsutil/wslog.h to provide easy-to-use,
flexible and dependable logging during all execution phases.
Log levels have a hierarchy, from most verbose to least verbose
(debug to error). When a given level is set everything above that
is also enabled.
The log level can be set with an environment variable or a command
line option (parsed as soon as possible but still later than the
environment). The default log level is "message".
Dissector logging is not included because it is not clear what log
domain they should use. An explosion to thousands of domains is
not desirable and putting everything in a single domain is probably
too coarse and noisy. For now I think it makes sense to let them do
their own thing using g_log_default_handler() and continue using the
G_MESSAGES_DEBUG mechanism with specific domains for each individual
dissector.
In the future a mechanism may be added to selectively enable these
domains at runtime while trying to avoid the problems introduced
by G_MESSAGES_DEBUG.
REC_TYPE_PACKET is 0, so if it's been initialized to 0, and never gets
overwritten, this fixes code withotu fixing a visible bug, but it should
be done anyway.
Make the variable into which we put the return value of
wtap_block_get_nth_string_option_value() a wtap_opttype_return_val, as
that's the type of the return value - it's not a boolean, it's a status
code with multiple values.
Explicitly check that value against WTAP_OPTTYPE_SUCCESS. Yes,
WTAP_OPTTYPE_SUCCESS is 0, so
if (xxx)
is equivalent to
if (xxx != WTAP_OPTTYPE_SUCCESS)
but it's better to make it explict, so it's clear that it's checking for
failure.
If the two putative number-of-records values don't match (meaning one of
them is presumably the number of records and the other one isn't - we
don't know which is the case), free up the private data structure we
allocated before returning an error.
Replace most instances of ws_debug_printf() except in
epan/dissectors and dissector plugins.
Some replacements use printf(), some use ws_debug(), and
some were removed because they were dead or judged to be
temporary.
Most of the time, the return value tells us nothing useful, as we've
already decided that we're perfectly willing to live with string
truncation. Hopefully this keeps Coverity from whining that those
routines could return an error code (NARRATOR: They don't) and thus that
we're ignoring the possibility of failure (as indicated, we've already
decided that we can live with string truncation, so truncation is *NOT*
a failure).
The secs field is a time_t, which is not necessarily 32 bits. If it's
not, casting away the upper bits, by casting to guint32, introduces a
Y2.038K bug.
Either cast to time_t or, if you're assigning a time_t to it, don't
bother with the cast.
Calling cmake with -DENABLE_VLD=ON when building with Visual Studio,
results in debug configuration being linked to Visual Leak Detector.
By default, Visual Leak Detector outputs the leak summary to Visual
Studio debug window. When ENABLE_VLD is active, VLD is linked to all
wireshark libraries and executables.
Drop in the comment from libpcap about version 1.2 (I wrote that
comment, and generously double-license it under the BSD license and the
GPL :-)).
Redo the version test as
if (!({version is one we handle}))
to match the way it's done in libpcap.
- parse the number of system call arguments in a way that works for both V1 and V2 event blocks
- returned the correct error string when unable to read the nparams entry from a sysdig event block V2
Update the pcap-ng reader and sysdig event dissector to support the second version of the sysdig event block, which was introduced after Wireshark's original implementation
All the NetMon reading code does is initialize the pseudo-header; the
bulk of the work is done in the dissector. Give the dissector its own
pseudo-header structure, and do the initialization there.
That's the way other packet formats in which the 802.11 radio metadata
is a header at the beginning of the packet data, such as radiotap, work.
The '/codecs' dir was removed in g63af1da7e7.
Avoid using include_directories(), prefer target_include_directories().
Remove some unnecessary CMAKE_CURRENT_*_DIR includes and some other
small cleanups while at it.
If a header declares a function, or anything else requiring the extern
"C" decoration, have it wrap the declaration itself; don't rely on the
header itself being included inside extern "C".
Add comments in various switch statements warning people *not* to add
standardized block types or option codes that aren't in the pcapng spec.
If you want a standardized block or option type, go through the
standards process.
Only a tiny amount of code outside libwiretap needs to know about
pcap/pcapng LINKTYPE_ values, and all that code needs to know is, for a
given LINKTYPE_ value, what the corresponding WTAP_ENCAP_ value is.
Nothing should need to know, for a given WTAP_ENCAP_ value, what its
LINKTYPE_ value is.
Make it the case that nothing *does* need to know, for a given
WTAP_ENCAP_ value, what its LINKTYPE_ value is. Export
wtap_dump_can_write_encap() and use *that*, in the "import hex dump"
code, what formats can be written to a pcap file.
Add missing entries, regularize the descriptions, etc..
Note that pcap and pcapng are the native formats.
Fix various issues.
Update the editcap -F output to match urrent reality.
While we're at it, sort the libwiretap modules, putting observer.c in
the right place.
Name the source to the code to read Observer files after the file
format, not the company that created it, got bought by JDSU, and then
ended up in Viavi when JDSU split.
Refer to the file format as "Viavi Observer" to reflect that.
Let individual file type/subtype modules register their
backwards-compatibility names, rather than having a centralized table
that would need to be updated along with the module.
We don't need to initialize first_section before calling
pcapng_read_section_header_block(); it doesn't depend on it being
initialized, and sets byte_swapped, version_major, and version_minor if
what it reads is a valid SHB, so we don't need to set those in
pcap_open().
We don't need to set shb_off until we've deemed this to be a pcapng
file, so do so at the same point that we initialize
We also don't need to initialize wblock until we call
pcapng_read_section_header_block(), so do so all in one place.
Instead of pcapng_open() calling pcap_block_read() to do all the work of
reading the initial SHB, have it do the read of the initial SHB itself,
by calling the same routines that pcap_block_read() calls.
That way, pcap_block_read() doesn't have to be prepared to be called to
read that block, so it can treat all issues with an SHB that it reads as
errors, rather than possibly reporting them as "not a pcapng file", and
it doesn't have to support being called without a pointer to the
pcapng_t for the file being read, as it no longer ever is. It can now
just return a gboolean success/failure indication.
That makes pcapng_open() a little more complicated but it makes
pcap_block_read() less complicated.
Fix some use of : as ' in comments while we're at it.
Pass a null pointer to pcapng_read_block(), instead. In
pcapng_read_block(), treat that as the indication that we're trying to
read the purported first SHB, rather than treating a null section_info
pointer as that indication.
This addreses one, but not all, of the problems reported in issue #17281.
Use the data rate and channel to determine 11b vs. 11g vs. 11a for:
* Aruba Networks encapsulated remote mirroring;
* Prism headers;
* *Peek remote protocol;
* Network Instruments^W^WViavi Observer;
* *Peek classic format;
* Shomiti Surveyor.
Note why we *don't* need to do that for NetMon captures.
Do more fixups of the "phy" based on the data rate, so that it reflects
the modulation used for the packet.
Note, in comments, why we're doing this, and that there's no reiable
way, in radiotap, to determine the type of channel on which capturing is
being done, as some packet providers use the channel field to indicate
the channel type and others use it to indicate the modulation.
Only provide the "short preamble" for "11b", as that's now being used to
mean "DSSS modulation" - packets on an 11g channel will be marked as
"11g" if they're OFDM or "11b" if they're DSSS.
Make some other cleanups while we're at it.
Put all the TLV stuff together. *If* some TLVs are only in the file
header and others are only in packets, thot should be the split; it
appears that the TLVS with a type with the 0x01 bit clear are for the
file header, so perhaps they can be split based on that.
Don't include the TLV header in the structure for the time_info TLV;
that matches other TLV structures. Write the time_info TLV in two
parts, as we do with the comment TLV.
Consistently use _TO_LE macros in our _TO_LE_IN_PLACE macros.
Add _FROM_LE_IN_PLACE and _TO_LE_IN_PLACE macros for the network_load
TLV.
Use %z, now that we require C99-or-later.
Check the length of TLVs.
Note some things found in files while reverse engineering.
FOr 11b and 11g, also set the metadata to provide the "short preamble"
indication.
Add some macros to wsutil/802_11-utils.h to help there, as I threatened
to do in the previous commit. :-)
When building with GCC 10.2.0 and optimization level 3 some new
warnings turn up. Fix them.
./epan/crypt/dot11decrypt_util.c: In function ‘dot11decrypt_derive_pmk_r0’:
../epan/crypt/dot11decrypt_util.c:308:5: error: ‘sha256_res’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
308 | memcpy(pmk_r0_name, sha256_res, 16);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../epan/crypt/dot11decrypt_util.c: In function ‘dot11decrypt_derive_pmk_r1’:
../epan/crypt/dot11decrypt_util.c:357:5: error: ‘sha256_res’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
357 | memcpy(pmk_r1_name, sha256_res, 16);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../wiretap/wtap_opttypes.c: In function ‘wtap_block_add_if_filter_option’:
../wiretap/wtap_opttypes.c:782:12: error: ‘*((void *)&filter_dest+8)’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
782 | return filter_dest;
| ^~~~~~~~~~~
../wiretap/wtap_opttypes.c: In function ‘wtap_block_set_if_filter_option_value’:
../wiretap/wtap_opttypes.c:782:12: error: ‘*((void *)&filter_dest+8)’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
782 | return filter_dest;
| ^~~~~~~~~~~
In the top-level .editorconfig, note that we don't use CMake's standard
indentation.
Remove ascendtext.[ch] from wiretap/.editorconfig since it's no longer
needed.
I believe this was the original intention, to use these API restricitons
with dissectors only (not that I necessarily agree with that policy either),
and through copy-paste and lack of clear guidelines it spread to other
parts of the build.
Rename the checkAPI groups to make it very clear that this is dissector-only.
This doesn't mean, of course, that good programming practices shouldn't be
followed everywhere. In particular assertions need to be used properly.
Don't use them to catch runtime errors or validate input data.
This commit will be followed by another removing the various ugly hacks
people have been using to get around the checkAPI hammer.
Those are used by more than one file type, so we should provide a block
type for them. (We don't *currently* use that block type, or the packet
block type, but this makes them available for future use.)
Check to make sure the value is non-negative and less than the number of
file type/subtypes.
Make it clearer than one check is unnecessary:
* pull wtap_dump_open_check() into wtap_dump_init_dumper(), so it's
clear that wtap_dump_init_dumper() ensures the validity of the file
type/subtype value early on (wtap_dump_can_open() fails if it's not
valid);
* pull wtap_dump_alloc_wdh() into wtap_dump_init_dumper(), so that the
allocation and all the initialiation is done there - that makes it clear
that it sets the file_type_subtype member of the wtap_dumper structure
before wtap_dump_init_dumper() returns;
* have wtap_dump_open_finish() use that value rather than being passed
the type/subtype value explicitly, so it's clear that it's dealing with
a validated value.
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.
Register the pcap and pcapng file types/subtypes rather than hardwiring
them into the table.
Call the registration routines for them directly, rather than through a
generated table; they're always supposed to be there, as some code in
Wireshark either writes only one of those formats or defaults to writing
one of those formats. Don't run their source code through the
registration-routine-finder script.
Have the file type/subtype codes for them be directly exported to the
libwiretap core, and provide routines to return each of them, to be used
by the aforementioned code.
When reporting errors with cfile_write_failure_message(), use
wtap_dump_file_type_subtype() to get the file type/subtype value for the
wtap_dumper to which we're writing, rather than hardcoding it.
Have the "export PDU" code capable of supporting arbitrary file
types/subtypes, although we currently only use pcapng.
Get rid of declarations of now-static can_write_encap and
dump_open routines in various headers.
"i" and "j" are too similar, so it's easy to use the wrong one if you're
using both as array indices and not easy enough to notice the mistake.
Use somewhat more meaningful names when we fix the index.
Fixes#17252.
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.
Save a copy of the pathname used to open a file in the wtap structure.
This allows the BER file reader to put a pointer to it in the
pseudo-header; it also would allow file readers to attempt to read
"associated" files that have the same name as the file, but with a
different extension.
Instead of having cf_open() special-case BER files, and calling a
routine in the BER dissector to specify the file name to the dissector,
have separate dissectors for "dissect packet payload as BER" and
"dissect a file as BER", and have the latter get the pathname of the
file from the pseudo-header and determine the ASN.1 syntax from that.
(Side-effect - this means that you can now dissect a BER file, and have
the syntax be determined by the file extension, in TShark as well; the
above cf_open() special-casing was *not* done in TShark, so it didn't
work before. Now the application code doesn't need to do any of that,
so it works in TShark as well as Wireshark.)
Eliminate WTAP_FILE_TYPE_SUBTYPE_ERF and
WTAP_FILE_TYPE_SUBTYPE_SYSTEMD_JOURNAL - instead, fetch the values by
name, using wtap_name_to_file_type_subtype().
This requires that wtap_init() be called before epan_init(); that's
currently the case, but put in comments to indicate why it must continue
to be the case.
It was returning the length of the array *after* we added the new entry,
which is the index that would be used for the *next* entry added.
Return, instead, the length of the array *before* we add the new entry.
We need to update the count of builtin types after copying over the
entries from the fixed table; otherwise, slot 0, for
WTAP_FILE_TYPE_SUBTYPE_UNKNOWN, will get assigned to the first
non-fixed-table builtin module.
Fix a comment (is a "builtin plugin" like a "square circle"?).
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.
The "short name" is really just the name, used to look it up. The
"name" is really a description intended solely for human consumption.
Rename the fields, and the functions that access them, to match.
The "description" maintained by Lua for file type handlers is used
*only* for one debugging message; we should probably just eliminate it.
Call it an "internal description" for now.
For most file types, blocks for which we don't have a wtap_block_type_t
aren't "custom", they're just "file-type specific". Add
WTAP_BLOCK_FT_SPECIFIC_REPORT and WTAP_BLOCK_FT_SPECIFIC_EVENT block
types; the "mandatory" part of those blocks includes a
file-type-specific block type value, with specific values assigned to
specific block types (either as part of the file type's definition, or
by us if necessary).
For pcapng files, blocks for which we don't have a wtap_block_type_t are
either "local" (block type has the high-order bit set), are defined in
the current spec but aren't supported yet (which we should fix), or are
*not* defined in the current spec and are *not* "local" (in which case
whoever's using the block number should submit a pull request to the
spec to register the block type *and* give it a specification, so we can
add support). For "local" block types and for not-yet-supported
non-"local" block types, they should be handled as file-type-specific
blocks with the file-type-specific block value being the pcapng block
type code, with plugin support in the pcapng code to read *and* write
those blocks.
Move the structures for the "mandatory" parts of blocks to
wiretap/wtap_opttypes.h, right after the definition of
wtap_block_type_t.
When registering a custom block type, set the block type field of the
wtap_blocktype_t structure. (We may do custom blocks differently, so
this is just for now.)
When registering a standard block type, don't pass in the block type, as
we can just use the type in the wtap_blocktype_t structure.
Remove NG from the names - it adds nothing.
Don't use the abbreviations for pcapng block names, spell out what the
block does (e.g. "WTAP_BLOCK_DECRYPTION_SECRETS" rather than
"WTAP_BLOCK_DSB"), to make it more obvious what the block does.
Spell out some other abbreviations.
Add WTAP_BLOCK_PACKET for future use for packet blocks; there's no need
to distinguish between the Enhanced Packet Block, the Simple Packet
Block, and the deprecated Packet Block here.
In answer to the question "How do we support multiple backends?", this
is the answer - what they mean is "how do we support multiple
encapsulation types for the *same* file format", and the answer is "you
have one dump open routine that writes the appropriate encapsulation
type in the header, depending on the encapulation type, and you have one
dump write routine that generates the appropriate packet header and
writes out the packet, depending on the encapsulation type".
Fix the generation of the packet header when writing H1 and H4 packets,
and *don't* strip off the first octet of the packet data when writing H1
packets - that octet isn't generated when reading H1 packets, it's read
from the file.
Tested by running several H1 and H4 captures through "editcap -F
btsnoop" and making sure that the files are identical.
Currently, only pcapng has one, and it does nothing, but this mechanism
will be used more in the future.
Update comments in epan/dissectors/CMakeLists.txt and ui/taps.h while
we're at it.
Instead *_register_plugin() is turned into a noop (with a warning).
The test suit is failing with ENABLE_PLUGINS=Off (it was already failing
before and this patch didn't affect that).
Closes#17202.
Option types aren't guaranteed to be small integers, so store option
types for a block type in a hash table, so we don't need to have a big
array to handle the custom option types (the type values of which aren't
small integers) and with local-use option types (the type values of
which also aren't small integers).
Make all the option type structures const while we're at it.
The options get unmarshalled (deserialized) when you read them; they
need to get marshalled (serialized) when you write them. This requires
an option handler to have more than one function.
While we're at it, in the declarations for function types for *block*
reader and writer plugins, add names to the prototype function
arguments, to make it a bit clearer what those arguments are.
Found by Coverity; fixes Coverity CID 1472770.
(At least *this* Coverity report doesn't use that tainted word
"tainted", which, most of the time, means "ZOMG UR PROGRAM READS
EXTERNAL FILEZ!!!!111ONE!!!")
Change the data structure for that option to have a type field,
indicating that it's either a pcap filter string or a BPF program,
followed by a union with a string-pointer member for pcap filter strings
and an instruction-count-and-pointer-to-instructions structure for BPF
programs.
Have routines to add, set, and fetch that option that handle that
structure; discard the "generic structured option" routines. That means
there's more type checking possible at compile time.
Add more code to handle BPF programs.
When writing pcapng files, check, both for that option and for string
options, whether the option length is too big for the data to fit in a
pcapng option, and don't write it if it is. (XXX - truncate the data?
Report an error?)
S1G adapters should be shipping soon since Silex America has a dev-kit
available, so it is about time to add support for this.
Change-Id: I0225d87f78efbcbe88476921d4fce3d56a3ce0cd
Guy Harris