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.
Some DVB-CI messages contain a file that can be dissected by the mime-encap
dissector. mime-encap adds itself to the protocol column. We already set a
fence, but things still look messy:
DVB-CIMIME_FILE
This patch adds ", " before the fence and "Data" afterwards. If mime-encap
is enabled, it'll overwrite the Data with its protocol name
DVB-CI, MIME_FILE
If mime-encap is disabled, the embedded file will be handled by the data
dissector, who doesn't touch the protocol column. So we keep
DVB-CI, Data
Note that we use EditorConfig in the WSDG and README.developer, and that
you should make sure your editor uses it. Recommend 4 space indentation
more strongly. Ping #17253.
Reorder and reword the coding style sections of each document while
we're here.
from the earlier version C37.237-2011. The previous version of this
standard, IEEE Std C37.238-2011, separated grandmaster time inaccuracy
and what was then called NetworkTimeInaccuracy into two fields. The
first, grandmasterTimeInaccuracy, was located immediately before
totalTimeInaccuracy in this version (now a reserved field). The second,
networkTimeInaccuracy, was located where totalTimeInaccuracy is now
found.
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.
In Git protocol, a pkt-line consists of a 4-hexdigit pkt-length,
followed by several bytes of pkt-data. The pkt-length represents the
length of the entire pkt-line including the length field, so for an
ordinary pkt-line the length is always >= 4. This allows the protocol
to use values less than 4 as special values --- for example, 0000 is a
so-called flush-pkt, representing the end of a command.
There's one particular pkt-length value that should never appear: 0003
is not >= 4 and is not a flush-pkt, delim-pkt, or response-end-pkt, so
it is not permitted in Git protocol. Currently the dissector handles
this case by returning length 0 so it doesn't show up in wireshark as
Git protocol. Better to treat it as Git protocol and add expert-info
describing what is wrong in case it shows up in a corrupt capture.
Part of #17093. Based on a hint from Pascal Quantin at [1].
[1] https://gitlab.com/wireshark/wireshark/-/merge_requests/1946#note_515567051
Regression introduced by b287e7165e.
To avoid an infinite loop with malformed packets, that commit stops
parsing the tags list after finding an unknown tag.
When this "unknown" tag is perfectly valid but not supported by
Wireshark, we don't decode any subsequent (valid) tags anymore.
GQUIC is going to die soon and it is quite unlikely it will change in
the next future. Therefore the best/quick solution is simply decoding
any valid tag.
Close#17250
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.
The second argument is the file type/subtype, and the third argument is
the file descriptor, according to the function declaration and all the
calls to it. Make it so in the function definition.
Fixes Coverity CIDs 1473314 and 1473312.
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.
dissect_pkt_line takes an `offset` parameter (passed by reference) to
allow parsing multiple pkt-lines from a single tvbuff. Currently the
only caller passes an offset of 0, so reading from `0` happens to do
the right thing, but that is about to change when [1] adds support for
dissecting multiple pkt-lines in a buffered HTTP request or response.
Part of #17093. Noticed by Joey Salazar and explained by Pascal
Quantin.
[1] https://gitlab.com/wireshark/wireshark/-/merge_requests/1946
These will be backported, for the benefit of Lua scripts that want those
specific file types/subtypes (typically in order to write files of those
types); that allows those types to be fetched without having to know the
right string to hand to wslua_wtap_name_to_file_type_subtype().
"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.
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.
When we're walking the list of fragments to free, if we encounter
FD_VISITED_FREE, we can conclude traversal of this fragment list immediately
(and go to the next hash bucket), since everything subsequent to this point in
the list has already been processed by free_all_reassembled_fragments. This
trims an O(n^2) hash table iteration down to O(n).
Before this change, a very ugly 1.1 GByte TFTP capture (with lots of
out-of-order and retransmitted blocks) takes 4 hours to process with
tftp.defragment=TRUE -- output completes after 1.25 hours, and then about
2.75 hours of time is spent doing repeated list traversals within
free_all_reassembled_fragments...(!) With this change, the same test completes
in 1.25 hours, with the cleanup taking just 71 msec.
Tested also with reassemble_test under Valgrind; No issues/leaks were reported.
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.
Use guint64 instead of u_int64_t. GLib might make it easier to use
standard types at some point[1] but they haven't yet. Make our offsets
unsigned.
[1]https://gitlab.gnome.org/GNOME/glib/-/issues/1484
João Valverde