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
We have wtap_block_set_string_option_value(),
wtap_block_set_string_option_value_format(), and
wtap_block_set_nth_string_option_value(); complete the collection and
win valuable prizes.
It corresponds to LINKTYPE_ETW in pcap and pcapng files; the structures
in the record format come from the Event Tracing for Windows (ETW) API
rather than directly from Event Trace Log files.
While we're at it, explain what extcap/etl does.
Make some packet size variables unsigned.
Leave some others signed, because they're read with sscanf(), and
sscanf() handles string-to-unsigned conversions in the same crazy way
strtouX() routines do, wherein a leading sign is *not* an error.
Instead, cast them to unsigned after we make sure they're not negative.
This adds a function to parse a string date-time in ISO 8601 format into
a `nstime_t` structure. It's based on code from epan/tvbuff.c and
wiretap/nettrace_3gpp_32_423.c and meant to eventually replace both.
(Currently only replaces the latter.)
Since most of Wireshark expects ISO 8601 date-times to fit a fairly
strict pattern, iso8601_to_nstime() currently rejects date-times without
separators between the components, even though ISO 8601 actually permits
this. This could be revisited later.
Also uses iso8601_to_nstime in editcap to parse the -A/-B options,
thus allowing the user to specify a time zone if desired. (See #17110)
Old behaviour is to read the entire file into memory at once; provide
the XML tree as the first packet; and then individual `<msg>` elements
as subsequent packets. It did this by writing to a temporary pcapng
file.
This change causes the XML file to only be read a chunk at a time (and
be read directly, not through an intermediate pcapng). This means much
larger files can be loaded, at the cost of no longer showing the raw XML
as the first packet. This is not a loss because the file can be loaded
in MIME Files Format (or a text editor) to see the XML.
Much of the logic from the old functions `create_temp_pcapng_file()` and
`write_packet_data()` has been relocated into the new function
`nettrace_msg_to_packet()`, and is used to directly generate packet data
for wiretap instead of writing it to a temporary file.
Also includes some initial "code smell" fixes:
- Removed some duplicate `#define`s from epan/exported_pdu.h
- Replaces some magic numbers with macros from epan/exported_pdu.h
- Replaces other magic numbers with the CLEN() macro to make it easier
to see (and debug) where sizes/offsets come from
- Use `g_strstr_len()` instead of `strstr()` to remove the need to
insert string terminators
- Uses direct pointer math instead of indexing into a byte array
This compiles and runs, and seems to produce the same results as the old
reader (except for the XML packet). Consider it a proof of concept; it
needs further revision before being review-ready.
Adds a pre-commit hook for detecting and replacing
occurrences of `g_malloc()` and `wmem_alloc()` with
`g_new()` and `wmem_new()`, to improve the
readability of Wireshark's code, and
occurrences of
`g_malloc(sizeof(struct myobj) * foo)`
with
`g_new(struct myobj, foo)`
to prevent integer overflows
Also fixes all existing occurrences across
the codebase.
There are traffic dumps that only include the PDU payload
without lower layer information. This commit allows any
dissector to be embedded in the DCT2000 as a protocol name.
tshark/wireshark will decode it despite having no lower
layer information.
The change allows a DCT2000 protocol field to look for a
dissector.
The change can be enabled or disabled with the preference
dct2000.use_protocol_name_as_dissector_name and it defaults
to FALSE.
Example:
Session Transcript (format 3.1)
December 6, 2020 16:45:20.5185
LTE-RRC.1/lte_rrc.dl_dcch/1/// r tm 22.5695 l $2c02
S1AP.1/s1ap/1/// s tm 23.3926 l
$001700130000020063000608023d7c00830002400202a0
It's possible for memcpy's source and destination
to be the same address, and so therefore
'overlap'. Use memmove instead, which
is safe for overlapping regions.
This fixes Coverity 1450802.
New link type DLT_ETW is added for write and read Event Trace on Windows.
This change updates MBIM dissector to decode a MBIM message from
a DLT_ETW packet.
Convert wiretap/ascend.y.in from Bison/YACC to Lemon and rename it to
wiretap/ascend_parser.lemon. Tighten up some of our scanning and
parsing. Make the indentation in it and related files consistent. Aside
from the recent IPv4 fragment offset changes, this produces identical
output to the 3.4 branch for the Ascend trace files I have here.
Remove the comment about supporting other commands. Another timeline
might have an Ascend that successfully pivoted to DSL or 15625B+1D
gigabit ISDN, but this one has neither.
This was our last/only Bison/YACC file, so remove Bison/YACC as a
development and packaging dependency and remove references to it from
the documentation.
It's easy to create systemd blocks with a missing or invalid
__REALTIME_TIMESTAMP= field when fuzz testing. If that's the case, leave
WTAP_HAS_TS unset instead of returning an error. Fixes#16965.
A nettrace 3gpp capture contains the 'beginTime' in ISO 8601 format.
This patch corrects the conversion for the following steps:
- the UTC offset must be subtracted from the given time,
- given time must be converted to UTC time when an offset is provided (localtime otherwise)
- sub-seconds conversion fixed (i.e. .0012 was converted to .12).
Closes#16888
Systemd journal entries aren't file-type-specific; they're found in both
systemd journal entry blocks in pcapng files and in systemd journal
export files. Give it a record type, for use with both file types.
This fixes#16955.
It also means that you can open a systemd journal export file and save
it as a pcapng file.
Instead of grabbing the set of IDBs found at open time, have a loop
using wtap_get_next_interface_description() to read all unread IDBs run
after opening the input file, after reading a packet from the input
file, and after getting an EOF on the input file.
Add a routine wtap_uses_interface_ids() to check whether the file type
and subtype for a dump file uses interface IDs and requires IDBs. If
so, in the aforementioned loop, add the IDBs to the dump stream.
Add a routine wtap_dump_add_idb() to add IDBs to a dump stream. Have it
call a file-format-specific routine to add the IDBs; the only file type
that supports it is pcapng, and it 1) writes out the IDB and 2) adds it
to the set of IDBs for the stream.
Add a wtap_dump_params_init_no_idbs() routine that prevents the IDBs
from the input file from being used to initialize the output file; use
it in cases where we're using the aforementioned loop to copy over IDBs.
Don't require any IDBs to be present when opening a pcapng file for
writing; 1) the simplest pcapng file has just an SHB in it, 2) that
requirement causes dumps that don't provide IDBs at open time to fail,
and 3) the real issue is that we don't want packets with an interface ID
not corresponding to a known IDB, and we already have a check for that.
(There are some hacks here; eventually, when everything processes the
IDBs in such a loop, we may be able to get rid of the "two favors of
dump parameter initialization" hack.)
Fixes#15844.
Addresses the same issue in #15502, but there are other issues there
that also need to be addressed.
In addition, the merge code also needs to be changed to handle this.
It currently wraps wtap_block_create() and wtap_block_copy(); if there
are no remaining use cases for wtap_block_copy() at some point, it can
just *replace* wtap_block_copy().
In a wtap, keep track of the first interface description not yet fetched
with wtap_get_next_interface_description() and, when
wtap_get_next_interface_description() is called, have it return that
description, as a wtap_block_t for its IDB. If there are no
as-yet-unfetched interface descriptions, return NULL; there may, in the
future, be more interface descriptions for the file, so this should be
called:
* after the file is opened;
* after wtap_read() returns TRUE, indicating that it's returned a
record (and *before* you process the record that wtap_read()
returns, as it might be the interface description for the
interface on which the packet in that record arrived);
* after wtap_read() returns FALSE, indicating an EOF or an error
return (as there might have been interfaces at the end of the
file or before the error point).
At each of those points, the caller should loop until
wtap_get_next_interface_description() returns NULL.
Not used yet (but tested with capinfos, which found a reason why you
have to wait until the end of the file before processing the interface
information - there's now a comment in the code giving that reason).
This will probably be used in the future.
Currently, the only file types that use them are pcapng and IBM's
iptrace; we don't support writing the latter, so this is mainly of
interest for pcapng.
This makes it a bit more obvious what some "is this pcapng?" tests are
really trying to determine, and allows them to automatically support any
new file types that use them.
(With regard to interface descriptions, tere are three types of file:
1) files that contain no interface information;
2) files that contain "just FYI" interface information but that don't
tie packets or other records to particular interfaces;
3) files that contain interface information and tie all packets (and
possibly other records) to an interface.
This tests for files of type 3.)
Gerald Combs