> -----Original Message-----
> From: Wireshark-dev [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf
> Of Jeff Morriss
> Sent: Friday, July 14, 2017 10:49 AM
> To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
> Subject: Re: [Wireshark-dev] Fields offsets & tree hierarchy questions
>
>
>
> On Fri, Jul 14, 2017 at 1:02 PM, Sultan, Hassan via Wireshark-dev <wireshark-
> dev@xxxxxxxxxxxxx <mailto:wireshark-dev@xxxxxxxxxxxxx> > wrote:
>
>
[...]
>
> 2) When looking at http.file_data(65), the field's offset is 0, relative to
> that field's tvb which contains the decompressed data, is there any way to get
> the position relative to the 'main' tvb representing the whole packet ? I couldn't
> find one but maybe I'm missing something. http.file_data(65) represents
> decompressed data so technically not present in the main tvb, but I was
> wondering if there was a way to link it to the compressed data field it represents
> (the "text(83)" field)
>
>
>
> I don't think so. Only the HTTP dissector (and a human) know that the dissector
> created a new TVB out of data from the text(83) field. There's no linkage (that I
> recall) between those 2 TVBs (unlike, say, subset TVBs).
I see. I'm trying to figure out how automation could make the difference so it can ignore fields like this one that represent the same data as another field.
One way would be to look for fields that contain an ft_value , though this would mean some segments of the packet_data would be missing (http.response.code being an example, there's no field without an ft_value representing those bytes of the packet), or maybe ignore any field that has offset 0 without being the top-level field ? It seems a bit hackish though.
Thanks,
Hassan
