Wireshark-dev: [Wireshark-dev] Re: Changes in the latest dev code (since 4.4.7) which heavily i
From: John Thacker <johnthacker@xxxxxxxxx>
Date: Thu, 26 Jun 2025 00:51:53 -0400
It's a little difficult to see, because the field that triggers everything is hidden unless the PER preference "Display the internal PER fields in the tree" is enabled. That's disabled by default, so by default the field with the large offset is hidden.
John
On Thu, Jun 26, 2025 at 12:48 AM John Thacker <johnthacker@xxxxxxxxx> wrote:
The root problem is that the "start_idle_count" logic doesn't take into account multiple data sources.NR-RRC uses unaligned PER. The packet has a very large (26201 octet) OCTET STRING which is not octet-aligned to the packet. So a new octet-aligned data source gets created for that. As the note under X.691 17.8 says, fragmentation procedures for an OCTET STRING may apply after 16K, 32K, 48K, or 64K octets. In this case they apply after 16K (really KiB, 16384.). So 16409 octets into the original frame (there's some things before the OCTET STRING) there's the PER length indicator for the rest of the string (9817). The code above remembers for the tree that the "max_start" offset was 16409.However, that's in the original, unaligned frame. The 26201 octet OCTET STRING contains many, many fields. Most of them have offsets (relative to the aligned string) which are less than 16409 (and there's a lot of tiny less than one octet bitfields and internal PER encoding information; even some that are later in the OCTET STRING are unaligned relative to that and end up creating new additional aligned data sources with earlier start offsets relative to their new data sources.) From the logic there, all of those fields have a start "earlier" than the 16409 offset, and so they cause the idle counter to continue to increment, as it waits for the start offset to increase.Probably the start_idle_count should reset if fi->ds_tvb has changed from the last time new_field_info() was called; I guess the most recent value could be stored in the tree_data.As a side note, it wouldn't be a problem for this one case if the NR-RRC unaligned PER had been encoded to allow the OCTET STRING to be larger before fragmenting, picking one of the other options.JohnOn Wed, Jun 25, 2025 at 11:30 PM Tamás Regős <regost@xxxxxxxxx> wrote:I just checked the source code of 4.4.7 and it does not have this merge included so that is why it works.packet-nr-rrc is quite long and complex (and generated from asn1) and it may conflict with this new 50,000 limit._______________________________________________On Thu, 26 Jun 2025 at 08:55, Gilbert Ramirez via Wireshark-dev <wireshark-dev@xxxxxxxxxxxxx> wrote:The way the packet-nr-rrc.c dissector is adding many fields for the same bytes in the packet isn't playing well with the "start_idle_count" logic that was added to new_field_info() in proto.cWhen I add a debugging printf like this:diff --git a/epan/proto.c b/epan/proto.cindex 12758f9d00..c91fc441c5 100644--- a/epan/proto.c+++ b/epan/proto.c@@ -6833,6 +6833,8 @@ new_field_info(proto_tree *tree, header_field_info *hfinfo, tvbuff_t *tvb,fi->hfinfo = hfinfo;fi->start = start;fi->start += (tvb)?tvb_raw_offset(tvb):0;+ printf("%s start=%d max_start=%d idle=%d\n", fi->hfinfo->abbrev, fi->start, PTREE_DATA(tree)->max_start,+ PTREE_DATA(tree)->start_idle_count);// If our start offset hasn't advanced after adding many items it probably// means we're in a large or infinite loop.if (fi->start > 0) {Even though the "start" field *is* changing over time, the "start_idle_count" keeps increasing:per.optional_field_bit start=0 max_start=16409 idle=0per.optional_field_bit start=1 max_start=16409 idle=0per.optional_field_bit start=1 max_start=16409 idle=1per.optional_field_bit start=1 max_start=16409 idle=2per.extension_present_bit start=1 max_start=16409 idle=3per.enum_index start=1 max_start=16409 idle=4nr-rrc.accessStratumRelease start=1 max_start=16409 idle=5nr-rrc.pdcp_Parameters_element start=1 max_start=16409 idle=6per.extension_bit start=1 max_start=16409 idle=7per.optional_field_bit start=2 max_start=16409 idle=8per.optional_field_bit start=2 max_start=16409 idle=9per.optional_field_bit start=2 max_start=16409 idle=10per.optional_field_bit start=2 max_start=16409 idle=11per.optional_field_bit start=2 max_start=16409 idle=12per.optional_field_bit start=2 max_start=16409 idle=13nr-rrc.supportedROHC_Profiles_element start=2 max_start=16409 idle=14nr-rrc.profile0x0000 start=2 max_start=16409 idle=15nr-rrc.profile0x0001 start=2 max_start=16409 idle=16nr-rrc.profile0x0002 start=3 max_start=16409 idle=17nr-rrc.profile0x0003 start=3 max_start=16409 idle=18and it keeps growing:er.enum_index start=3593 max_start=16409 idle=16405nr-rrc.ca_BandwidthClassDL_NR start=3593 max_start=16409 idle=16406text start=3594 max_start=16409 idle=16407per.choice_index start=3594 max_start=16409 idle=16408nr-rrc.BandParameters start=3594 max_start=16409 idle=16409nr-rrc.nr_element start=3594 max_start=16409 idle=16410per.optional_field_bit start=3594 max_start=16409 idle=16411per.optional_field_bit start=3594 max_start=16409 idle=16412nr-rrc.bandNR start=3594 max_start=16409 idle=16413per.extension_present_bit start=3595 max_start=16409 idle=16414and growingr-rrc.FeatureSetDownlinkPerCC_Id start=15678 max_start=16409 idle=90026per.enum_index start=15679 max_start=16409 idle=90027nr-rrc.scellWithoutSSB start=15679 max_start=16409 idle=90028per.enum_index start=15679 max_start=16409 idle=90029I don't know the "start_idle_count" logic, and couldn't quite figure it out through a brief reading. It feels like it's counting wrong here, though.Gerald wrote that code, in https://gitlab.com/gilramir1/wireshark/-/commit/f0c6b3b366e0062205dde0f9384cbd11da5cd2fcMaybe he'll be able to figure out if it's doing the wrong thing in this case, *or* if the packet-nr-rrc.c dissector needs to be adjusted.Gilbert_______________________________________________On Wed, Jun 25, 2025 at 4:14 AM Tamás Regős <regost@xxxxxxxxx> wrote:Hi Developers,_______________________________________________The attached ~30KB large pcap file has 1 NR RRC packet and the current latest official WS version 4.4.7 can decode it properly. This is good.However, when I try to open and decode it with the latest development version, it fails (Version 4.5.0 (6f13ac41b7df)).(I just refetched the whole source code and recompiled again from scratch).CLI:** (wireshark:16076) 14:01:27.439488 [Epan WARNING] -- Dissector bug, protocol NR RRC, in packet 1: ...\wireshark\epan\proto.c:6841: failed assertion "((tree)->tree_data)->start_idle_count < 50000" (nr-rrc.BandParameters_v1540_element)GUI:[Dissector bug, protocol NR RRC: ...\wireshark\epan\proto.c:6841: failed assertion "((tree)->tree_data)->start_idle_count < 50000" (nr-rrc.BandParameters_v1540_element)]
[Expert Info (Error/Dissector bug): ...\wireshark\epan\proto.c:6841: failed assertion "((tree)->tree_data)->start_idle_count < 50000" (nr-rrc.BandParameters_v1540_element)]
[...\wireshark\epan\proto.c:6841: failed assertion "((tree)->tree_data)->start_idle_count < 50000" (nr-rrc.BandParameters_v1540_element)]
[Severity level: Error]
[Group: Dissector bug]It seems whatever changes could have been done in packet-nr-rrc.c (or somewhere else?) it did heavily impact the start_idle_count (or when it's reset) and the "PROTO_TREE_MAX_IDLE 50000" in proto.c is not enough anymore.I was testing with higher values and ended up with "PROTO_TREE_MAX_IDLE 93100" to make it work and be able to decode the packet (93000 still failed).That is a significant issue, I believe.Could anyone please have a look at what could be the underlying issue?Thank you.Regards,Tamas
Wireshark-dev mailing list -- wireshark-dev@xxxxxxxxxxxxx
To unsubscribe send an email to wireshark-dev-leave@xxxxxxxxxxxxx
Wireshark-dev mailing list -- wireshark-dev@xxxxxxxxxxxxx
To unsubscribe send an email to wireshark-dev-leave@xxxxxxxxxxxxx
Wireshark-dev mailing list -- wireshark-dev@xxxxxxxxxxxxx
To unsubscribe send an email to wireshark-dev-leave@xxxxxxxxxxxxx
- Follow-Ups:
- References:
- [Wireshark-dev] Changes in the latest dev code (since 4.4.7) which heavily impacted PROTO_TREE_MAX_IDLE
- From: Tamás Regős
- [Wireshark-dev] Re: Changes in the latest dev code (since 4.4.7) which heavily impacted PROTO_TREE_MAX_IDLE
- From: Gilbert Ramirez
- [Wireshark-dev] Re: Changes in the latest dev code (since 4.4.7) which heavily impacted PROTO_TREE_MAX_IDLE
- From: Tamás Regős
- [Wireshark-dev] Re: Changes in the latest dev code (since 4.4.7) which heavily impacted PROTO_TREE_MAX_IDLE
- From: John Thacker
- [Wireshark-dev] Changes in the latest dev code (since 4.4.7) which heavily impacted PROTO_TREE_MAX_IDLE
- Prev by Date: [Wireshark-dev] Re: Changes in the latest dev code (since 4.4.7) which heavily impacted PROTO_TREE_MAX_IDLE
- Next by Date: [Wireshark-dev] Call for Election: Wireshark Technical Steering Committee (WTSC)
- Previous by thread: [Wireshark-dev] Re: Changes in the latest dev code (since 4.4.7) which heavily impacted PROTO_TREE_MAX_IDLE
- Next by thread: [Wireshark-dev] Re: Changes in the latest dev code (since 4.4.7) which heavily impacted PROTO_TREE_MAX_IDLE
- Index(es):