On Fri, Jul 14, 2017 at 2:01 PM, Sultan, Hassan via Wireshark-dev < wireshark-dev@wireshark.org> wrote:
> > > > -----Original Message----- > > From: Wireshark-dev [mailto:wireshark-dev-boun...@wireshark.org] On > Behalf > > Of Jeff Morriss > > Sent: Friday, July 14, 2017 10:49 AM > > To: Developer support list for Wireshark <wireshark-dev@wireshark.org> > > Subject: Re: [Wireshark-dev] Fields offsets & tree hierarchy questions > > > > > > > > On Fri, Jul 14, 2017 at 1:02 PM, Sultan, Hassan via Wireshark-dev > <wireshark- > > d...@wireshark.org <mailto:wireshark-dev@wireshark.org> > 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.
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
