> -----Original Message-----
> From: Wireshark-dev [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf
> Of Jeff Morriss
> Sent: Friday, July 14, 2017 11:32 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 2:01 PM, Sultan, Hassan via Wireshark-dev <wireshark-
> dev@xxxxxxxxxxxxx <mailto:wireshark-dev@xxxxxxxxxxxxx> > wrote:
>
>
>
>
> > -----Original Message-----
> > From: Wireshark-dev [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx
> <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 <mailto: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:dev@xxxxxxxxxxxxx> <mailto: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.
>
>
>
> Maybe there's a way by comparing proto_node->field_info->ds_tvb? For such
> packets there will be 2 (or more) TVBs.
Great idea ! I'll give it a try and see what I get.
Thanks !
Hassan
