Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] Hierarchy of fields & offsets again, more potential offender

From: "Sultan, Hassan" <sultah@xxxxxxxxxx>
Date: Fri, 4 Aug 2017 00:01:04 +0000

> -----Original Message-----
> From: Pascal Quantin [mailto:pascal.quantin@xxxxxxxxx]
> Sent: Wednesday, August 02, 2017 12:41 PM
> To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
> Cc: Sultan, Hassan <sultah@xxxxxxxxxx>
> Subject: Re: [Wireshark-dev] Hierarchy of fields & offsets again, more potential
> offenders
> 
> 
> 
> 2017-08-02 21:24 GMT+02:00 Pascal Quantin <pascal.quantin@xxxxxxxxx
> <mailto:pascal.quantin@xxxxxxxxx> >:
> 
> 
> 	Hi Hassan,
> 
[...]

> 		                                 FT_STRING 378 ntlmssp.auth.domain(8) :
> SUSE
> 		                                         FT_UINT16 186 ntlmssp.string.length(2) :
> 8
> 		VIOLATION 1 : Child ntlmssp.string.length has an offset lower
> than its parent
> 		                                         FT_UINT16 188 ntlmssp.string.maxlen(2)
> : 8
> 		VIOLATION 1 : Child ntlmssp.string.maxlen has an offset lower
> than its parent
> 		                                         FT_UINT32 190 ntlmssp.string.offset(4) :
> 220
> 		VIOLATION 1 : Child ntlmssp.string.offset has an offset lower
> than its parent
> 
> 
> 
> 	It looks like some fields describing the string position (and present
> before the string) were put in a subtree of the string. Whether this is to improve
> readability is left to someone knowing NTLM Server Challenge protocol (so not
> me).

I just submitted https://code.wireshark.org/review/#/c/22937/ to turn the parent field of NTLMSSP strings to FT_NONE, while still providing visually the same information in the same way and having the FT_NONE cover the length/maxlen/offset only. Let me know what you guys think.

Thanks,

Hassan