This IE has been recently renamed in GSUP protocol spec [1] and main
implementation (libosmocore) [2] from "PDP Type" to "PDP Address",
update it here too.
While at it, properly dissect the type_org, type_nr and address buffers.
[1] 602fabc6d5
[2] 74ee02420a
Similar to the UMTS MM Context, when the Extended Access
Restriction Data length is greater than 1, handle the length
but indicate that we don't dissect it yet.
Also fix two of the UMTS MM Context expert infos being added to
the wrong tree.
Fix#19630
The Endace ERF format has extended the 'Interface Id' from 2 bits (interface 0-3) to 3 bits (interface 0-7).
The Interface Id high order bit is not adjacent in the flags field.
Extend wtap handling for ERF records.
Extend epan dissection and display of ERF format.
The existing erf.flags.cap field is retained and extended to 0-7.
A new erf.flags.if_raw field is added for the unformatted value.
Note proto_tree_add_split_bits_item_ret_val() cannot be used here because it only supports input from the tvb and not from a non-tvb value.
PI_RECEIVE is for indications from the process of receiving packets,
such as CRC errors, short/long frame indications, etc..
PI_INTERFACE is for indications from an interface (other than receive
indications), such as out-of-buffrs indications, hardware errors,
changes in link speed, etc..
See !14177 for some discussion of this.
In the first pass of two-pass wireshark, where we can do
asynchronous DNS lookups, make sure to actually take the
requests off the queue and process them, instead of waiting
until the end of the first pass.
Use a mutex to protect taking requests off the queue, just in
case.
Related to #19629.
Some of the functions in proto.c when handling a FT_BOOLEAN field
allow it to be part of a 64 bit unsigned integer with a 64 bit
bitmask. Other functions do not. Some of the functions start out
allowing a 64 bit bitmask and then switch to casting the value to
a 32 bit unsigned integer (but others don't.) Consistently allow
a boolean to be extracted using a 64 bit bitmask by changing the
various proto_tree_add_boolean functions to allow a 64 bit unsigned
integer value parameter.
There was only one function adding a boolean that already took
a 64 bit value, proto_tree_add_boolean_bits_format_value64, a
counterpart of proto_tree_add_boolean_bits_format_value. It was
never used anywhere and not WS_DLL_PUBLIC, so it is safe to remove
in favor of having the latter take a uint64_t.
Note that _proto_tree_add_bits_format_value, as a comment says:
"does not receive an actual value but a dimensionless pointer to that value.
For this reason, the type of the header field is examined in order to determine
what kind of value we should read from this address.
The caller of this function must make sure that for the specific header field
type the address of a compatible value is provided."
Both proto_tree_add_boolean_bits_format_value and
proto_tree_add_boolean_bits_format_value64 called that function, one
passing a pointer to a guint32 as a void*, the other passing a
pointer to a guint64. In both cases it was cast to a guint32*, which
was less than ideal in the value64 case. Fix that.
This is related to #19552, as it is necessary in order to add support
for passing a UInt64 value to a boolean field (as oppposed to extracting
it directly from the tvb.)
When switching to synchronous external host name lookups (e.g., upon
starting the second pass of a two-pass tshark command), if there are
any in-flight requests, wait for them to return.
This avoids a problem where on the second pass, synchronous lookups
aren't performed but instead immediately report failure (because
according to our cache the request has already been made; in the GUI,
the answer would be updated later.)
It makes tshark two-pass performance faster than one-pass, so long as
the host name lookups are queued in the first pass (e.g., by offering
a display filter like "-Y ip.addr".)
A nice enhancement later would be to ensure that any external host name
lookups that will be needed in the second pass are done asynchronously
in the first pass. Even the overkill of doing the dissection with a visible
tree is likely better performance than waiting for many synchronous
lookups.
Fix#19629.
Define VCS_NUM_COMMITS and VCS_COMMIT_ID in vcs_version.h. Use them to
return the Logray version in get_lr_vcs_version_info and use that where
appropriate. Rename VCSVERSION to VCS_VERSION.
Vendor Data for the Status Message CM and the Status Message Interface
are not required to have a multiple of 2 as length.
Also ASAM CMP UDP encapsulation was missing.
Closes: #19626
The RTP dissector already calculates an extended timestamp
that takes into account wrapping and passes it to the taps.
Just use that in the analysis stats instead of redoing the
extended timestamp calculation.
(The calculation currently in the analysis has some slight
issues about when to use a absolute difference versus a
signed difference, and what to cast the 32 bit timestamps to.)
Fix#19622. Tested and works with the various edges cases
in !4853 and #16330 and others.
Fix the distributed examples to use the "new" style configuration,
as shown in the WSUG and Wiki. Fix the FTP example in the WSUG,
as it's missing the Match keyword
Related to #12118.
Fix#16940
Use the ws_log system instead of a special #define for RTMPT.
If Wireshark isn't compiled for the Debug target, the compiler
will optimize away all these calls.
Ping #19519
We remove layers when a dissector rejects a packet and returns 0.
When a dissector handles desegmentation, it can accept a packet
(return a non zero length) but actually consume zero bytes by
setting desegment_len to a different value and desegment_offset to 0.
That indicates that no bytes were actually consumed because a
future segment is needed.
In such a case, nothing should be added to the tree anyway. On the
next pass the dissector shouldn't be called again (or should have
the same behavior again). The layer needs to be removed on the first
pass in case there are additional PDUs still to be processed in the
frame, so that those PDUs get the same layer number on the first
pass that they'll get in subsequent passes, which affects reassembly
and other various file scoped structures that use the layer number.
Fix#19609
If the last hex character in a line of a packet is 0x5c (ASCII '\'),
we have to make sure that doesn't end the line, because a backslash-newline
gets treated as a spliced line in C (and that happens in syntax
translation in a very early phase, before comment removal).
We can't just add whitespace (even though §5.1.2.2 of the C standard
says we could), because gcc (and clang) helpfully assume that a
backslash with only whitespace before a newline is probably programmer
error and treats it as a continuation while warning about it:
https://gcc.gnu.org/onlinedocs/gcc/Escaped-Newlines.html#Escaped-Newlines
Surround the text with `|` because that's what hexdump(1) does, though
really most anything that isn't whitespace would do.
Fix#19615
In addition to the start and end offset locations, store a pointer to
the data source tvb in each mate_range. The start and end offsets
are only relevant within a data source.
If a field has a data source different from one of the protocol,
transport protocol, or payload ranges, search in the tree for the
ancestor nodes of the field, and see if an ancestor is located within
one of the ranges.
In order to workaround #17877 (non-visible items can't change length
after being added to the tree, which affects most protocols), set
the tree as visible similar to done with a number of Lua postdissectors
that need all fields. Unfortunately this is overkill that hurts
performance.
Fix#19619
If a field_info is visible, we don't fake the representation and
allow the representation and length to be set after construction.
Therefore, when trying to add a child item to a tree item that has
a visible field_info, we can't fake the child node and return the
current tree node.
If we do, we can't distinguish between an attempt to set the length
or representation of the current tree item, and an attempt to set
the length or representation of the faked child (or its descendent)
because they'd both have the same node.
Since we need the lengths of protocol items for the proto hierarchy
stats (and many protocols are added with length "to the end of the
frame" and then fixed later), if we're not faking protocols, don't
set a protocol field info to hidden even if the tree is not visible.
There are probably still some issues related to the use of
proto_item_get_parent[_nth]. We might have to avoid faking nodes for
any lineal descendent of an item whose representation we need.
Related to #19619 (fixes some handling of MATE ranges),
related to #19573 (fixes getting the representation of certain items that
are also subtrees and have children that set their representation), and
fixes the Protocol Hierarchy stats issue in #17877.
Martin Mathieson
Pau Espin