Register the data dissector to all dissector tables that support
Decode As. This provides a way to disable decoding for table
entries that have a default dissector registered to a value.
It is particularly useful when a dissector is registered by default
to several values (e.g. HTTP), to be able to disable decoding
for one port without disabling the dissector in general.
It is also useful to prevent payloads from being handed off
to heuristic dissectors, and is thus distinguished from the
fallback to data when no dissector is set. N.B.: that this has no
effect on dissectors that have a "Try heuristic sub-dissectors first"
preference set to TRUE.
It does not solve a second issue for table entries with a default
dissector - setting the dissector to "none" in order to force
payloads to be sent to heuristic dissectors without setting a
preference as above. (Note that in some cases one will wish to
send dissection on some ports to heuristics without enabling
heuristics first for _all_ ports.)
Fix#17518. Fix#15717. Related to #12098, which also needs the
last issue mentioned above addressed.
Non-blocking reads were used to workaround Windows pipe handle leaks.
Now that the underlying issue is fixed (i.e. Wireshark no longer leaks
child process stdin/stdout/stderr handles), we can use blocking reads.
Using blocking reads is the main performance improvement. Reading more
than one byte at a time gives additional 15% performance improvement (on
top of enormous speedup due to blocking reads).
Avoid stdin and stdout file descriptor race conditions by closing the
descriptors only after the respective threads exit.
dfvm.c:206:1: warning: no previous prototype for function 'dfvm_value_tostr'
dfvm.c:550:1: warning: no previous prototype for function 'filter_finfo_fvalues'
dfvm.c:645:1: warning: no previous prototype for function 'filter_refs_fvalues'
lpcre2.c:506:13: warning: no previous prototype for function 'luaopen_rex_pcre2'
lpcre2_f.c:207:5: warning: no previous prototype for function 'Lpcre2_config'
lpcre2_f.c:234:5: warning: no previous prototype for function 'Lpcre2_get_flags'
ftype-double.c:89:1: warning: no previous prototype for function 'val_unary_minus'
ftype-double.c:96:1: warning: no previous prototype for function 'val_add'
ftype-double.c:103:1: warning: no previous prototype for function 'val_subtract'
ftype-double.c:110:1: warning: no previous prototype for function 'val_multiply'
ftype-double.c:117:1: warning: no previous prototype for function 'val_divide'
ftype-integer.c:670:1: warning: no previous prototype for function 'uint_bitwise_and'
ftype-integer.c:677:1: warning: no previous prototype for function 'uint_is_zero'
ftype-integer.c:683:1: warning: no previous prototype for function 'uint_is_negative'
ftype-integer.c:689:1: warning: no previous prototype for function 'uint_unary_minus'
ftype-integer.c:704:1: warning: no previous prototype for function 'uint64_bitwise_and'
ftype-integer.c:711:1: warning: no previous prototype for function 'uint64_is_zero'
ftype-integer.c:717:1: warning: no previous prototype for function 'uint64_is_negative'
ftype-integer.c:723:1: warning: no previous prototype for function 'uint64_unary_minus'
ftype-integer.c:738:1: warning: no previous prototype for function 'sint_bitwise_and'
ftype-integer.c:745:1: warning: no previous prototype for function 'sint_is_zero'
ftype-integer.c:751:1: warning: no previous prototype for function 'sint_is_negative'
ftype-integer.c:757:1: warning: no previous prototype for function 'sint_unary_minus
ftype-integer.c:764:1: warning: no previous prototype for function 'sint64_bitwise_and'
ftype-integer.c:771:1: warning: no previous prototype for function 'sint64_is_zero'
ftype-integer.c:777:1: warning: no previous prototype for function 'sint64_is_negative'
ftype-integer.c:783:1: warning: no previous prototype for function 'sint64_unary_minus'
packet-bpv6.c:2182:1: warning: no previous prototype for function 'proto_register_bpv6'
packet-bpv6.c:2766:1: warning: no previous prototype for function 'proto_reg_handoff_bpv6'
packet-bpv7.c:1978:6: warning: no previous prototype for function 'proto_register_bpv7'
packet-bpv7.c:2037:6: warning: no previous prototype for function 'proto_reg_handoff_bpv7'
packet-realtek.c:349:1: warning: no previous prototype for function 'proto_register_realtek'
packet-realtek.c:436:1: warning: no previous prototype for function 'proto_reg_handoff_realtek'
packet-tcpcl.c:2147:1: warning: no previous prototype for function 'proto_register_tcpclv3'
packet-tcpcl.c:2211:1: warning: no previous prototype for function 'proto_reg_handoff_tcpclv3'
A "proto_tree_add..._ret_..." routine *must* return the value through
the pointer, even if no protocol tree is being built, as there's no
guarantee that a protocol tree will be built under all circumstances
(for example, if the dissection is only being done to generate the
column values, no column is a custom column, there are no coloring
rules, etc., so that none of the named field values are of interest, and
the protocol tree isn't going to be displayed, no protocol tree will be
built).
Fixes#18203.
packet-thrift.h:118:15: warning: parameter 'thrift_opt' not found in the function declaration
packet-thrift.h:119:15: warning: parameter 'is_field' not found in the function declaration
packet-thrift.h:121:15: warning: parameter 'field_id' not found in the function declaration
packet-thrift.h:122:15: warning: parameter 'hf_id' not found in the function declaration
packet-thrift.h:124:15: warning: parameter 'encoding' not found in the function declaration
packet-thrift.h:167:15: warning: parameter 'elt' not found in the function declaration
packet-thrift.h:169:15: warning: parameter 'seq' not found in the function declaration
Field 'File ID' (gsm_sim.file_id) has a conflicting entry in its value_string: 24380 is at indices 72 (DF.MExE) and 78 (DF.MexE)
Field 'File ID' (gsm_sim.file_id) has a conflicting entry in its value_string: 24384 is at indices 73 (DF.EIA/TIA-533) and 80 (DF.WLAN)
Field 'File ID' (gsm_sim.file_id) has a conflicting entry in its value_string: 20233 is at indices 194 (EF.EFSUPI_NAI) and 198 (EF.PBC)
Field 'File ID' (gsm_sim.file_id) has a conflicting entry in its value_string: 20234 is at indices 195 (EF.Routing_Indicator) and 199 (EF.PBC1)
All/any equal have their own symbols for operators so cannot
be handled in the same switch case.
Other comparisons don't have different symbols for any/all.
New vendor ID's up to june 22, 2022 have been added.
Decoding of the optional description field in BACnet SC BVLC's has been fixed.
Decoding of the exteded event parameters has been fixed.
It's possible for a dissector to claim a frame without adding to
the tree or being added to frame.protocols (see !6669)
Log a debug message showing the pinfo layers and the dissector that
claimed the tvb (frame/packet).
Add a function to get the column text of the nth column, taking
into account whether the column is resolved or unresolved. Use
this function in the GUI, as well as in tshark, when writing
PSML, exporting dissection to PSML, etc., instead of accessing
col_data directly.
This removes the direct accesses of col_data from outside
column.c and column-utils.c
Fix#18168.
Currently Wireshark does not close the vlans file on profile change.
This leads to major problems, when vlan resolution is turned on:
- Deleting a profile (not even selected) is not possible without exiting
Wireshark.
- Switching from one profile with vlans to another with vlans, does
not switch the resolution but stays on the names of the old profile!
This patch improves the uat config checking for SOME/IP:
- detecting simple endless loops
- better error output on faulty configs
- using uat resets to fix crash on faulty configs
When writing a custom column, some field types can't have a resolved
value, and just copy the label from the expression to the value.
Only copy information from the most recent field when doing so,
so that with multifield custom columns the entire unresolved value
doesn't get overwritten with the resolved value (if some fields
have resolved values and some don't.) This also reduces copying
from O(N^2) to O(N).
Fixes the display "unresolved" value for multifield custom columns
that are a mix of field types.
Custom column expressions do not need to be limited to COL_MAX_LEN.
The size of the expression does not have any necessary relationship
to the size of the column contents, especially in the common case of
many semantically equivalent different fields from different protocols,
only one of which appears in any given frame.
The only place that actually does limit the length of custom
custom expressions is in reading the preferences. Use a GString
instead of allocating a buffer to COL_MAX_LEN when constructing
the string. In normal cases, this should decrease temporary
memory usage. Fix#16905
For the top-level item for an extension, initially create it with a
length of "to the end of the packet" and, when we finish dissecting it,
set the length appropriately. That way, if the length is too large, we
don't throw an immediate exception, making it a little clearer what's
happending.
When dissecting an authentication extension, construct the text of the
top-level item as we dissect it, and initially create it with a length
of "to the end of the packet" and, when we're finished dissecting it,
set the length appropriately. That way, we don't throw an exception
before doing any dissection if the data for the item isn't all there, we
only throw an exception when we run out of data, and we also don't try
to add the data unless there is at least one byte of data.
The latter of those fixes#18181.
Switch to the name "Logray" for the log analyzer. Rays are biological
cousins of sharks and more people like the name "Logray" in a completely
unscientific survey here. Apologies for any inconvenience this might
cause.
proto_strlcpy in normal situations returns the number of bytes
copied (because the return value of g_strlcpy is strlen of the
source buffer). It can copy no more than dest_size - 1, because
dest_size is the size of the buffer, including the null terminator.
(https://docs.gtk.org/glib/func.strlcpy.html)
Returning dest_size can cause offsets to get off by one and reach
the end of the buffer, and can cause subsequent calls to have
buffer overflows. (See #16905 for an example in the comments.)
Several of the constant length string built in address types don't
check to see if the buf_len passed in is long enough to write
the string.
This can cause buffer overflows, e.g. with a custom column with
many FT_ETHER fields.
Gerald Combs