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