I don't have any docs, but I came to this conclusion by looking into the 
ethereal parsed packet. Ethereal rounded up the value 301 to 302.
However if it works this way, it should be committed, as this patch 
couldn't harm.

Simone Gotti wrote:
> On Saturday 11 June 2005 16:40, Szombathelyi György wrote:
> 
> 
>>Can you try the attached patch (untested by me)?
> 
> 
> I tried it but then the auth failed to the NTLMSSP_NEGOTIATE phase and didn't 
> reached the third phase. I don't know why as your code looked right to me.
> 
> Then I changed this line:
> 
> secbuf.offset = (buf.size() + 1) && 0xfffffffe;
> 
> into this one: 
> 
> secbuf.offset = ( buf.size() % 2 ) ? buf.size() + 1 : buf.size();
> 
> and then it finally worked :D. 
> 
> I don't know if this is right and I cannot test it with other servers.
> I'll test if NTLMv1 works again with this server (disabling NTLMv2 in the 
> code).
> 
> 
>>It seems that NTLM buffers should be padded to 2 byte boundaries. 
> 
> Just curious, do you have some docs where this assumption is reported?
> 
> What I can understand is that the buf should always be composed by an even 
> number of bytes. Can this be right? An idea can be to analyze how the 
> ethereal NTLMv2 parser works. What do you think?
> 
> Bye!
> 
> 
> 
> ------------------------------------------------------------------------
> 
>  
> 
>>>Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<