[Gilbert Ramirez <gram@xxxxxxxxxxxxxxx>]

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