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 <[EMAIL PROTECTED]>: > 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, [EMAIL PROTECTED], [EMAIL PROTECTED], > [EMAIL PROTECTED] > > _______________________________________________ > Ethereal-dev mailing list > [EMAIL PROTECTED] > http://www.ethereal.com/mailman/listinfo/ethereal-dev > Devin Heitmueller Senior Software Engineer Netilla Networks Inc
