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 <reg...@gmail.com> 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@wireshark.org
> To unsubscribe send an email to wireshark-dev-le...@wireshark.org
>
_______________________________________________
Wireshark-dev mailing list -- wireshark-dev@wireshark.org
To unsubscribe send an email to wireshark-dev-le...@wireshark.org
