MR 20354 gets the idle count down to a max of 50 (without internal PER
fields enabled.) The data source tvb wasn't getting set to the field info
until after the check, so the check wasn't effective until the third data
source.
Most of that 50 is I think cases with bit fields that have the same byte
offset but different bit offsets, and the check doesn't look at bit offsets.
On Thu, Jun 26, 2025 at 9:14 PM Gerald Combs via Wireshark-dev <
wireshark-dev@wireshark.org> wrote:
> 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 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
