Wireshark-dev: Re: [Wireshark-dev] What ftypes are "compatible" enough for duplicate fields?

From: Hadriel Kaplan <hadriel.kaplan@xxxxxxxxxx>
Date: Fri, 21 Feb 2014 15:08:54 -0500
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 <hadriel.kaplan@xxxxxxxxxx> wrote:

> 
> 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 filtering input. (though I'm not positive about that)
> 
> -hadriel
> 
> 
> On Feb 21, 2014, at 2:15 PM, Guy Harris <guy@xxxxxxxxxxxx> wrote:
> 
>> 
>> On Feb 21, 2014, at 10:43 AM, Hadriel Kaplan <hadriel.kaplan@xxxxxxxxxx> 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 be displayed as unsigned integers, but, unlike FT_UINTn, where they're just unsigned integers of different sizes, FT_IPXNET is an IPX network number and FT_FRAMENUM is a frame number, so I'm not sure it makes sense to have, for example, a field that's sometimes an integer from the packet and sometimes a frame number.
>> 
>>> - FT_UINT64 and FT_EUI64
>> 
>> Same there - an EUI-64 is a specific type of value.
>> 
>>> - FT_BYTES, FT_UINT_BYTES, FT_AX25, FT_ETHER, FT_VINES, FT_OID and FT_REL_OID
>> 
>> And same here - I'd go for
>> 
>> 	- FT_BYTES and FT_UINT_BYTES
>> 	- FT_AX25 (this is an AX.25 address, and is unlikely to be anything else)
>> 	- FT_ETHER (MAC-48, and unlikely to be anything else)
>> 	- FT_VINES (Vines address)
>> 	- FT_OID and FT_REL_OID (I'm guessing that a given OID could be represented either way; if not, maybe they should be separate)
>> 
>>> - FT_ABSOLUTE_TIME and FT_RELATIVE_TIME
>> 
>> Absolute times are time stamps; relative times are "n seconds from now"-type values.  I'd split them as well.
>> 
>> ___________________________________________________________________________
>> Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
>> Archives:    http://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>>            mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
> 
> ___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe