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