[Gerald Combs <gerald@xxxxxxxxxxxxx>]

This should be fixed in MR 20353, although the idle count gets up to 26599 (and 37971 when internal PER fields are enabled) for the supplied capture file. We can always increase PROTO_TREE_MAX_IDLE, but we need to figure out where "normal dissection behavior" ends and "infinite loop" begins.

I also noticed that it doesn't seem to be possible to navigate to or select data source tabs that are outside the widget boundary, at least on macOS.

On 6/25/25 9:51 PM, John Thacker wrote:

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.

John

On 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.c

When I add a debugging printf like this:

diff --git a/epan/proto.c b/epan/proto.c

index 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=0

per.optional_field_bit start=1 max_start=16409 idle=0

per.optional_field_bit start=1 max_start=16409 idle=1

per.optional_field_bit start=1 max_start=16409 idle=2

per.extension_present_bit start=1 max_start=16409 idle=3

per.enum_index start=1 max_start=16409 idle=4

nr-rrc.accessStratumRelease start=1 max_start=16409 idle=5

nr-rrc.pdcp_Parameters_element start=1 max_start=16409 idle=6

per.extension_bit start=1 max_start=16409 idle=7

per.optional_field_bit start=2 max_start=16409 idle=8

per.optional_field_bit start=2 max_start=16409 idle=9

per.optional_field_bit start=2 max_start=16409 idle=10

per.optional_field_bit start=2 max_start=16409 idle=11

per.optional_field_bit start=2 max_start=16409 idle=12

per.optional_field_bit start=2 max_start=16409 idle=13

nr-rrc.supportedROHC_Profiles_element start=2 max_start=16409 idle=14

nr-rrc.profile0x0000 start=2 max_start=16409 idle=15

nr-rrc.profile0x0001 start=2 max_start=16409 idle=16

nr-rrc.profile0x0002 start=3 max_start=16409 idle=17

nr-rrc.profile0x0003 start=3 max_start=16409 idle=18

and it keeps growing:

er.enum_index start=3593 max_start=16409 idle=16405

nr-rrc.ca_BandwidthClassDL_NR start=3593 max_start=16409 idle=16406

text start=3594 max_start=16409 idle=16407

per.choice_index start=3594 max_start=16409 idle=16408

nr-rrc.BandParameters start=3594 max_start=16409 idle=16409

nr-rrc.nr_element start=3594 max_start=16409 idle=16410

per.optional_field_bit start=3594 max_start=16409 idle=16411

per.optional_field_bit start=3594 max_start=16409 idle=16412

nr-rrc.bandNR start=3594 max_start=16409 idle=16413

per.extension_present_bit start=3595 max_start=16409 idle=16414

and growing

r-rrc.FeatureSetDownlinkPerCC_Id start=15678 max_start=16409 idle=90026

per.enum_index start=15679 max_start=16409 idle=90027

nr-rrc.scellWithoutSSB start=15679 max_start=16409 idle=90028

per.enum_index start=15679 max_start=16409 idle=90029

I 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/f0c6b3b366e0062205dde0f9384cbd11da5cd2fc

Maybe 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

_______________________________________________
Wireshark-dev mailing list -- wireshark-dev@xxxxxxxxxxxxx
To unsubscribe send an email to wireshark-dev-leave@xxxxxxxxxxxxx