Howdy,
Along the lines of bug 2402, I'm adding verification code to prevent Lua script
duplicate field registration (bug 9709). The idea is to allow duplicate fields
if their ftypes are similar enough; otherwise reject it.
The question, though, is what ftypes are similar enough?
There's a
That patch almost (but not quite) matches what's listed in
README.dissector (lines 1018-1024). I believe the README is correct,
in which case the patch is simply out of date (I believe it's missing
FT_AX25 and FT_VINES, and possibly others I haven't done a thorough
check).
On Fri, Feb 21, 2014 at
On Feb 21, 2014, at 1:29 PM, Evan Huus eapa...@gmail.com wrote:
That patch almost (but not quite) matches what's listed in
README.dissector (lines 1018-1024). I believe the README is correct,
in which case the patch is simply out of date (I believe it's missing
FT_AX25 and FT_VINES, and
On Fri, Feb 21, 2014 at 1:43 PM, Hadriel Kaplan
hadriel.kap...@oracle.com wrote:
On Feb 21, 2014, at 1:29 PM, Evan Huus eapa...@gmail.com wrote:
That patch almost (but not quite) matches what's listed in
README.dissector (lines 1018-1024). I believe the README is correct,
in which case the
On Feb 21, 2014, at 10:43 AM, Hadriel Kaplan hadriel.kap...@oracle.com wrote:
So this then:
- FT_INT8, FT_INT16, FT_INT24 and FT_INT32
- FT_UINT8, FT_UINT16, FT_UINT24, FT_UINT32, FT_IPXNET and FT_FRAMENUM
I'd be tempted to consider FT_IPXNET and FT_FRAMENUM to be *sui generis*; they
might
I agree.
A different question though is why FT_UINT64 isn't in the same group as the
other FT_UINT* ones. (And of course FT_INT64 in FT_INT*)
Also, what about FT_NONE? Lots of current duplicate fields have one of the
duplicates as FT_NONE - why I don't know, but I don't think that breaks
Also, FT_IPv4 and FT_IPv6 are frequently in duplicate fields. Should they
be/not-be? Display filter input/verification might have issues with it, but it
seems logical to have generic foo.src/foo.dst/etc. fields of both types.
-hadriel
On Feb 21, 2014, at 2:43 PM, Hadriel Kaplan
On Feb 21, 2014, at 11:43 AM, Hadriel Kaplan hadriel.kap...@oracle.com wrote:
A different question though is why FT_UINT64 isn't in the same group as the
other FT_UINT* ones.
Because Wireshark was developed in an era where the majority of platforms on
which it ran were 32-bit, so we made
On Feb 21, 2014, at 12:08 PM, Hadriel Kaplan hadriel.kap...@oracle.com wrote:
Also, FT_IPv4 and FT_IPv6 are frequently in duplicate fields. Should they
be/not-be? Display filter input/verification might have issues with it, but
it seems logical to have generic foo.src/foo.dst/etc. fields
On Feb 21, 2014, at 6:36 PM, Guy Harris g...@alum.mit.edu wrote:
On Feb 21, 2014, at 12:08 PM, Hadriel Kaplan hadriel.kap...@oracle.com
wrote:
Also, FT_IPv4 and FT_IPv6 are frequently in duplicate fields. Should they
be/not-be? Display filter input/verification might have issues with
On Feb 21, 2014, at 6:27 PM, Guy Harris g...@alum.mit.edu wrote:
On Feb 21, 2014, at 11:43 AM, Hadriel Kaplan hadriel.kap...@oracle.com
wrote:
A different question though is why FT_UINT64 isn't in the same group as the
other FT_UINT* ones.
Because Wireshark was developed in an era
On Feb 21, 2014, at 7:22 PM, Evan Huus eapa...@gmail.com wrote:
On Fri, Feb 21, 2014 at 7:13 PM, Hadriel Kaplan
hadriel.kap...@oracle.com wrote:
The few such duplicates I checked basically used the FT_NONE field for a
tree item; while the real ftype field was used for actual data. (if I
12 matches
Mail list logo
