Re: -mm merge plans for 2.6.20

In-Reply-To: <457CDC38.2090907@xxxxxxxxxx>

On Sun, 10 Dec 2006 22:19:04 -0600, Steve French wrote:

> I don't remember any problems reported with plain text password
> support on current cifs and I have certainly seen it negotiated with no 
> problem,
> but I will double check with your reported flag combination.

I played around with it some more.

With SecurityFlags = 0x7 (default) the server asks for a plaintext
password and the client refuses.  That's fine.

With 0x37 the client agrees to send a plaintext password (or at least
fails to reject the server's request for one,) but actually sends:

<         ANSI Password Length: 24
<         Unicode Password Length: 24

<         ANSI Password: 3577D3557009178AFF455A0F7A99C6585CAEF99C515F2F2C
<         Unicode Password: 3577D3557009178AFF455A0F7A99C6585CAEF99C515F2F2C

(my password was aaaaaaaa).  This fails with error -13 (invalid password.)

With 0x30 the client sends:

>         Password Length: 24

>         Password: 61616161616161610000000000000000681C1DCF00002200

and everything works.

> > Also, the client doesn't automatically pick up the domain name from
> > smb.conf like smbfs does.
> >
> >   
> That is true, and is intentional.   cifs sends a domain of null (ie use 
> the server's
> default domain) - but it can be overridden on mount

That's OK then.  I just happened to notice it when I was comparing
traces of smbfs mounts to the ones from cifs.  Maybe the manpage should
mention this difference for those who are converting, though.

-- 
MBTI: IXTP