Extract Method for multiple message parsing for tpdus to simplify things for future bug fixes and to make the code logic clearer.
Encapsulate the following functions:
dissect_gtp_tpdu_by_handle
dissect_gtp_tpdu_as_pdcp_lte_info
dissect_gtp_tpsu_as_pdcp_nr_info
Note: The original code function is not changed.
Updating the message checking for 3GPP TS 29.060 V16.0.0,
adding 7.5A MBMS Messages and 7.5B MS Info Change Reporting Messages.
This adds all the messages from TS 29.060. Some of them could be
updates to use the GSN specific fields in some cases. Also the
ETSI message checking needs to be updated to handle GTP' correctly.
The GGSN addresses for control plane and user traffic are both
included or both not included in the Update PDP Context Response
message (included if the Cause is Request Accepted), so we know
which one is the control plane and which one is the user plane.
Also fix the coment about the IEs for the alternative address, and
that they are Conditional, not Optional.
The Release Identifer field is only one nibble in GTP'. So in
Release 15 of 3GPP TS 32.295, an extra octet, Release Identifier
Extension, was added to support CDRs encoded with Release 16 and
higher of TS 32.298. Fix#17903.
From 3GPP TS 29.06 V 17.1.0 7.7.51:
The routing area code consists of 2 octets and is found in octet 10
and octet 11. Only the first octet (10) contains the RAC and the
second octet (11) is coded as "11111111".
Don't include the spare octet 11 in the RAC field. The RAC is only
one octet.
Add some undecoded IEs from 3GPP TS 29.060 V17.1.0:
Hop Counter (163), Signaling Priority Indication (203), Signaling
Priority Indication with NSAPI (204), ULI Timestamp (214),
and LHN-ID with NSAPI (215). Related to #17839.
Repeated words were found with:
egrep "(\b[a-zA-Z]+) +\1\b" . -Ir
and then manually reviewed.
Non-displayed strings (e.g., in comments)
were also corrected, to ease future review.
These display bases work to replace unprintable characters so the
name is a misnomer. In addition they are the same option and this
display behaviour is not something that is configurable.
This does not affect encodings because all our internal text strings
need to be valid UTF-8 and the source encoding is specified using
ENC_*.
Remove the assertion for valid UTF-8 in proto.c because
tvb_get_*_string() must return a valid UTF-8 string, always, and we
don't need to assert that, it is expensive.
All fields with GSN address were decodes as common hf_gsn_addr. But if
ETSI order is used, it's possible to specify alternative decoder
depending on message type and field position.
Alternative decoder for GSN address was added for mandatary fields and
optional/conditional field in the case there is single GSN address in
message.
Added new function as common dissector for all addr types.
Reuse the DIAMETER dissector for 3GPP-ULI for RADIUS as well.
The DIAMETER dissector for 3GPP-ULI IE is more complete than the RADIUS
version. The format of the IE is the same in RADIUS and DIAMETER.
As of now GTP dissector provides option to decode T-PDU data ether, async, and with some heuristics.
But there is no option present to decode a new protocol with a plugin.
This change adds an option to decode T-PDU data with a plugin, to help develop and test new protocols that are
encapsulated as GTP T-PDU data.
Fix issues found by running ./tools/check_typed_item_calls.py
epan/dissectors/packet-gtp.c:4414 proto_tree_add_item called for hf_gtp_sel_mode - item type is FT_UINT8 but call has len 2
epan/dissectors/packet-gtp.c:6807 proto_tree_add_item called for hf_gtp_rai_rac - item type is FT_UINT8 but call has len 2
epan/dissectors/packet-gtp.c:7600 proto_tree_add_item called for hf_gtp_bssgp_cause - item type is FT_UINT8 but call has len 2
epan/dissectors/packet-gtpv2.c:3607 proto_tree_add_item called for hf_gtpv2_trace_id - item type is FT_UINT16 but call has len 3
epan/dissectors/packet-gtpv2.c:5049 proto_tree_add_item called for hf_gtpv2_trace_id - item type is FT_UINT16 but call has len 3
It is called as a protocol by GTP as before, but making it separate
and findable by name protocol allows for that layer to be logged and
dissected separately.
These were detected by running check_typed_item_calls.py
with --consecutive, which flags items that have different
labels but the same filter string. Usually this is because
of copy/paste.
Quite a few similar bugs still exist, will address in a future commit.
Roland Knall