This merge request adds:
* Decoding of ProtocolID and PPID in Component Status Protocol dissector.
* Moved SCTP PPID list from SCTP dissector into separate file sctpppids.c,
due to reuse in Component Status Protocol dissector.
* Export of sctpppid_val_ext containing the PPID list.
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.
This pull request includes:
* The "Follow DCCP stream" feature.
* Updated docbook documentation for the "Follow DCCP stream" feature.
* Test for the feature.
* Corresponding packet trace for the test.
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.)
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.
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.
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.
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?)
Pull the code to register plugin taps, and the loop to register built-in
taps, into a single register_all_tap_listeners() routine.
This leaves it up to libwireshark, not to the programs using it, to know
how to register them.
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.
If you load a capture file and open any statistics dialog, you'll see the
list of collected items. Each time you press the Apply button (without entering a
display filter) another list of items will be created as a top-level entry
of the statistics tree. Only the first list will have the correct values,
all subsequent lists will not be populated.
Each statistic module defines a stat_tap_table_ui structure that contains a
stat_tap_init_cb function. This init function is called by
SimpleStatisticsDialog::fillTree before the tap listener is registered. This
happens each time we collect the statistics.
However, it seems that all init functions create a new stat_tap_table each
time they are called, even if they already have an existing stat_tap_table
of the same name.
This patch adds a stat_tap_find_table function to find a table by name.
As a first step, we update the ANSI A-I/F BSMAP Statistics to check if its
table is already registered. If it is, the table will not be created again.
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)
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.
Pull the value-formatting code in proto_custom_set into
proto_item_fill_display_label. Use that in FieldInformation::toString
instead of fvalue_to_string_repr. Fixes#16911.
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.
Add support internally to using iconv (always present with glib) to convert
strings from various encodings to UTF-8 (using REPLACEMENT CHARACTER as
recommended), and use that to support GB 18030 and EUC-KR. Replace call
directly to iconv in ANSI 637 for EUC-KR to new API. Update comments
and documentation around character encodings. It is possible to replace
the calls to iconv with an internal decoder later. Tested on Linux and
on Windows (including with illegal characters). Closes#16630.
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.)
Implement the Unicode Standard "best practices" for replacing ill-formed
sequences with the Unicode REPLACEMENT CHARACTER. Add wmem_strbuf_append_len
for appending strings with embedded null characters. Clarify why
wmem_strbuf_grow() doesn't always ensure that there's enough room for
a new string, and short-circuit some tests there. Related to #14948
Add ui/urls.h to define some URLs on various of our websites. Use the
GitLab URL for the wiki. Add a macro to generate wiki URLs.
Update wiki URLs in comments etc.
Use the #defined URL for the docs page in
WelcomePage::on_helpLabel_clicked; that removes the last user of
topic_online_url(), so get rid of it and swallow it up into
topic_action_url().
Add an encoding for "unpacked" 3GPP TS 23.038 7-bit strings, in which
each code position is in a byte of its own, rather than with the code
positions packed into 7 bits. Rename the packed encoding to explicitly
indicate that it's packed.
Add an encoding for ETSI TS 102 221 Annex A strings.
Use the new encodings.
Change-Id: I2fad824ca417dcd089fabfdf06f28529c7ee9e87
Signed-off-by: Filipe Laíns <lains@archlinux.org>
Reviewed-on: https://code.wireshark.org/review/37949
Petri-Dish: Anders Broman <a.broman58@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
There cases where we may want to pre-allocate some memory before
appending all the fields.
Change-Id: Ic46e83733d4338dbda45b2ca3ff2d533c5b44026
Signed-off-by: Filipe Laíns <lains@archlinux.org>
Reviewed-on: https://code.wireshark.org/review/38122
Petri-Dish: Anders Broman <a.broman58@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
format_text(alloc, string, strlen(string)) is a common idiom; provide
format_text_string(), which does the strlen(string) for you. (Any
string used in a %s to set the text of a protocol tree item, if it was
directly extracted from the packet, should be run through a format_text
routine, to ensure that it's valid UTF-8 and that control characters are
handled correctly.)
Update comments while we're at it.
Change-Id: Ia8549efa1c96510ffce97178ed4ff7be4b02eb6e
Reviewed-on: https://code.wireshark.org/review/38202
Petri-Dish: Guy Harris <gharris@sonic.net>
Tested-by: Petri Dish Buildbot
Reviewed-by: Guy Harris <gharris@sonic.net>
'check_tfs.py --common' can look for tfs values that appear multiple times.
Current output prior to these dssector changes was:
('No Extension', 'Extension') appears 3 times in: ['epan/dissectors/packet-bssap.c', 'epan/dissectors/packet-camel.c', 'epan/dissectors/packet-gsm_map.c']
('Optimised for signalling traffic', 'Not optimised for signalling traffic') appears 3 times in: ['epan/dissectors/packet-gsm_a_gm.c', 'epan/dissectors/packet-gsm_map.c', 'epan/dissectors/packet-gtp.c']
('Data PDU', 'Control PDU') appears 3 times in: ['epan/dissectors/packet-pdcp-lte.c', 'epan/dissectors/packet-pdcp-nr.c', 'epan/dissectors/packet-rlc-nr.c']
('Message sent to originating side', 'Message sent from originating side') appears 3 times in: ['epan/dissectors/packet-q2931.c', 'epan/dissectors/packet-q931.c', 'epan/dissectors/packet-q933.c']
('User', 'Provider') appears 3 times in: ['epan/dissectors/packet-q2931.c', 'epan/dissectors/packet-q931.c', 'epan/dissectors/packet-q933.c']
The first and last ones were made common, the others seem a little too specialised.
Checking some of the existing items in tfs.c (using QtCreator's 'Find Usages'),
some of the common items are used a lot, but many of them are not referenced.
Change-Id: Ia4006d2c4fa7cafbc3b004dc7a367a986dbeb0c4
Reviewed-on: https://code.wireshark.org/review/38177
Petri-Dish: Martin Mathieson <martin.r.mathieson@googlemail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Export proto_item_set_bits_offset_len and fix
In file included from ../epan/dfilter/dfilter.h:18:
../epan/proto.h:1113:11: warning: parameter 'bits_offset' is already documented [-Wdocumentation]
* @param bits_offset The new length in bits.
^~~~~~~~~~~
../epan/proto.h:1112:5: note: previous documentation
* @param bits_offset The number of bits from the beginning of the field.
^ ~~~~~~~~~~~
Change-Id: Ib171ce38607b9656baea5eb7a3e6aee3b99ddbac
Reviewed-on: https://code.wireshark.org/review/38115
Reviewed-by: Gerald Combs <gerald@wireshark.org>
Petri-Dish: Gerald Combs <gerald@wireshark.org>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
It generates a fake IDB for files that don't have interface information
and that have a per-file encapsulation type, snapshot length, and time
stamp precision, and adds it to the file's list of IDBs.
Use it for libpcap.
We will use it later for other file formats, so that code such as the
mergecap code to merge into a pcapng file can handle input files that
don't have interface information.
(We should have a way to indicate whether the IDBs are real or fake, so
that capinfos and Statistics > Capture File Properties don't report
meaningless IDB information and make it look as if it's known that the
capture was done on one interface with the properties in question.)
Change-Id: Iec124bf3c7cbd4c69ec2ac7d0dd776e5287f8576
Reviewed-on: https://code.wireshark.org/review/37982
Petri-Dish: Guy Harris <gharris@sonic.net>
Tested-by: Petri Dish Buildbot
Reviewed-by: Guy Harris <gharris@sonic.net>
The decode_as_list is built at startup and contains all protocols
registered for "decode as". Do not clear this list on profile change,
only on exit.
Bug: 16635
Change-Id: I832a042327603ae0f01b10ab620fccc03d4fd3a3
Reviewed-on: https://code.wireshark.org/review/37579
Petri-Dish: Stig Bjørlykke <stig@bjorlykke.org>
Tested-by: Petri Dish Buildbot
Reviewed-by: Stig Bjørlykke <stig@bjorlykke.org>
The LUA API provides the "set_color_filter_slot" function, but without
a corresponding "get_" function, it's very hard for two LUA dissectors
to co-exist without one overwriting any color filters set by the other.
It also looks like the documentation comment for
"set_color_filter_slot" had an off-by-one error, which I've corrected
as I was adding almost identical documentation for the new API.
Change-Id: Ic54d23be555ec12e1830bbe6f84a1b04d04fd4f0
Reviewed-on: https://code.wireshark.org/review/37511
Petri-Dish: Anders Broman <a.broman58@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Thomas Dreibholz