Re: [Wireshark-dev] Some apparent type bugs

On Fri, Jul 31, 2020 at 8:13 AM Jaap Keuter wrote: > Hi, > > Don’t know, just noticed the UINT part and thought about returning 'a > value' should be possible. > Will have to look into this more closely to see if and what makes sense. > > I created change 38006

Re: [Wireshark-dev] Some apparent type bugs

Hi, Okay, I’ve pushed a change (38004 ) for the first ones. Thanks, Jaap > On 31 Jul 2020, at 11:28, Martin Mathieson via Wireshark-dev > wrote: > > I won't have time to look into these properly for a few days - if anyone else > does please feel

Re: [Wireshark-dev] Some apparent type bugs

Hi, Don’t know, just noticed the UINT part and thought about returning 'a value' should be possible. Will have to look into this more closely to see if and what makes sense. Thanks, Jaap > On 31 Jul 2020, at 14:05, John Thacker wrote: > > > On Fri, Jul 31, 2020 at 7:51 AM Jaap Keuter

Re: [Wireshark-dev] Some apparent type bugs

Oops. On Fri, Jul 31, 2020 at 1:05 PM Jaap Keuter wrote: > Hi, > > This one you probably have to look into yourself, because that’s not from > the published code base, AFAIKT. > > Thanks, > Jaap > > On 31 Jul 2020, at 11:28, Martin Mathieson via Wireshark-dev < > wireshark-dev@wireshark.org>

Re: [Wireshark-dev] Some apparent type bugs

Oh yeah. Need to make that RE even more unreadable :) It is likely that there are 'allowed' entries wrong or missing. The script defines this collection of checks, then runs them all over each dissector file. I was surprised not to find more issues than I did. # These are all of the APIs in

Re: [Wireshark-dev] Some apparent type bugs

On Fri, Jul 31, 2020 at 7:51 AM Jaap Keuter wrote: > Hi, > > Shouldn’t these be supported? After all, they have a UINT. > > On 31 Jul 2020, at 11:28, Martin Mathieson via Wireshark-dev < > wireshark-dev@wireshark.org> wrote: > > Error: proto_tree_add_item_ret_uint (.., hf_lcp_opt_id , ...)

Re: [Wireshark-dev] Some apparent type bugs

Hi, This one you probably have to look into yourself, because that’s not from the published code base, AFAIKT. Thanks, Jaap > On 31 Jul 2020, at 11:28, Martin Mathieson via Wireshark-dev > wrote: > > I won't have time to look into these properly for a few days - if anyone else > does

Re: [Wireshark-dev] Some apparent type bugs

I don't know how that type works, but in my script I used the current types tested in the switch or if statements in proto.c So proto_tree_add_item_ret_uint() has: switch (hfinfo->type) { case FT_CHAR: case FT_UINT8: case FT_UINT16: case FT_UINT24: case FT_UINT32:

Re: [Wireshark-dev] Some apparent type bugs

Hi, This is the script tripped up by inserted comments I’m afraid. Thanks, Jaap > On 31 Jul 2020, at 11:28, Martin Mathieson via Wireshark-dev > wrote: > > Error: proto_tree_add_item_ret_uint64 (.., hf_epl_od_uint , ...) called at > ./tools/../epan/dissectors/packet-epl.c 2744 with type >

Re: [Wireshark-dev] Some apparent type bugs

Hi, Shouldn’t these be supported? After all, they have a UINT. > On 31 Jul 2020, at 11:28, Martin Mathieson via Wireshark-dev > wrote: > > Error: proto_tree_add_item_ret_uint (.., hf_lcp_opt_id , ...) called at > ./tools/../epan/dissectors/packet-ppp.c 2377 with type FT_UINT_BYTES >

Re: [Wireshark-dev] Some apparent type bugs

Hi Anders, This code in packet-pfcp.c, line 7482 looks wrong to me /* Octet 5 to 20 NF Instance ID */ proto_tree_add_item_ret_uint(tree, hf_pfcp_nf_instance_id, tvb, offset, 1, ENC_BIG_ENDIAN, _length); Isn’t this supposed to be /* Octet 5 to 20 NF Instance ID */

[Wireshark-dev] Some apparent type bugs

Hi, I wrote a script to try to check the types of hf items passed to proto.h APIs where there is a subset of types that are allowed. i.e. Trying to stop errors such as: ** (process:8243): WARNING **: Dissector bug, protocol IDN, in packet 126: epan/proto.c:11693: field idn.gts_wavelength_prefix