Re: Hierarchy of fields & offsets

[Guy Harris <guy () alum mit edu>]

On Jul 25, 2017, at 3:26 PM, Sultan, Hassan via Wireshark-dev <wireshark-dev () wireshark org> wrote:
 
>                                 FT_BYTES 198 smb2.security_blob(120) : 
> 60:76:06:06:2b:06:01:05:05:02:a0:6c:30:6a:a0:3c:30:3a:06:0a:2b:06:01:04:01:82:37:02:02:1e:06:09:2a:86:48:82:f7:12:01:02:02:06:09:2a:86:48:86:f7:1
> 2:01:02:02:06:0a:2a:86:48:86:f7:12:01:02:02:03:06:0a:2b:06:01:04:01:82:37:02:02:0a:a3:2a:30:28:a0:26:1b:24:6e:6f:74:5f:64:65:66:69:6e:65:64:5f:69:6e:5f:52:46:43:34:31:37:38:40:70:6c:65:61:73:65:5f:69:6
> 7:6e:6f:72:65
>                                                 FT_UINT32 190 smb2.olb.offset(2) : 0x00000080
>                                                 FT_UINT32 192 smb2.olb.length(2) : 120
>                                                 FT_PROTOCOL 198 gss-api(120) :
>  
> Notice how smb2.olb.offset & smb2.olb.length are under smb2.security_blob, but their offset starts at 190/192 while 
> smb2.security_blob starts at 198

Now we're not just dealing with data structures, we're dealing with pointers....

If the pointer and length are considered part of the "security blob", then the "security blob" needs to have three 
subfields - offset, length, and content - and therefore must be an FT_NONE and must not be a contiguous blob.  That 
would require that Wireshark support fields with more than one offset/length pair; if you clicked on them, they'd 
highlight more than one region of the hex pane.

If the pointer and length are *not* considered part of the security blob, then they shouldn't be under 
smb2.security_blob.
___________________________________________________________________________
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-request () wireshark org?subject=unsubscribe