This is where I plead incompetence. I wrote the NTLMSSP dissector the way it was because I didn't understand the NDR dissector routines, didn't have real experience with Microsoft protocols, Ethereal, or DCE/RPC. The immediate goal was just to get the dissector working. This the same reason it doesn't have any state management, nor does it properly dissect a couple of traces Guy sent in early August.
I'm not making excuses; I'll be the first to admit that the way it was written is not the way it should have been. I just haven't had the time to make any changes that would improve the dissector (nor do I suspect to in the next month). I'm sorry.
-Devin
Quoting Richard Sharpe <rsharpe@xxxxxxxxxx>:
> Hi,
>
> I was looking at the NTLMSSP dissector and running it over some data now
>
> that SPNEGO is working OK, and I noticed two things:
>
> 1. We know that the NTLMSSP blob is NDR encoded, so rather than breaking
>
> it out by hand, it would be a lot more useful if the support in
> packet-dcerpc.c et al was used.
>
> 2. The challenge field has a top level ref pointer to a string. That is
> what those unknown1 and unknown2 uint32s are. The first one contains the
>
> actual and max len for the string and the second is a buffer ref.
>
> I migt get some time next week to rework it if someone else doesn't
> first.
>
> Regards
> -----
> Richard Sharpe, rsharpe@xxxxxxxxxx, rsharpe@xxxxxxxxx,
> sharpe@xxxxxxxxxxxx
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
>
Devin Heitmueller
Senior Software Engineer
Netilla Networks Inc
