[Jeff Morriss <jeff.morriss.ws@xxxxxxxxx>]

On Fri, Jul 14, 2017 at 1:02 PM, Sultan, Hassan via Wireshark-dev <wireshark-dev@xxxxxxxxxxxxx> wrote:

Hi everyone,

Sorry to bother you with might be beginner questions but... well... I'm a beginner :)

In my quest to understand how Wireshark's parsing engine works I've written a small wrapper that iterates through all parsed fields and displays them in the following format :

[offset] [abbrev]([length]) : [value, which might be either my interpretation of the bytes on the wire according to type/encoding info for the types I currently support, or the ft_value of the field if it is present]

And for some packets I am getting :

 

[...]
 

Which brings the following questions :

1) Am I right to assume there are absolutely no guarantee about the order of fields reported by proto_tree_children_foreach in regard to offset within the same tvb ? I'm looking at the json fields and the offsets of sub-fields are not ordered. I guess the order is the order in which the fields were added to the tree ?

Yes, that would be my expectation.  Fields are reported (in the UI and other places) in the order that they were added to the tree.

 

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).