re: Problem with CIFS

["Steve French (IBM LTC)" <smfltc@us.ibm.com>]

> I was trying to use CIFS, but it failed to mount my samba shares
> whereas mounting a share of a Win2K PC worked.   <snip>
> In fs/cifs/cifssmb.c around line 238 the cifs modul expects a 16 Byte
> GUID, where samba only send 14 bytes consisting of some random
> numbers followed by my workgroupname: WG.
> So I to set my workgroupname to something longer with enabled me to
> mount my share.

This is caused by an interesting bug in Samba, but one I should be able to
workaround.  Basically Samba is setting a flag in the negotiate response saying
    "I support extended security"
which indicates that this frame should be decoded as if it contained an SPNEGO blob
(ala RFC 2478) and a conflicting capability in the same frame which indicates
    "I am not capable of extended security"
The Samba server sets this SMB_FLAGS2_EXTENDED_SECURITY in the response even though
the client said - no extended security (Windows gets this right).   Presumably all
other smb/cifs clients either 1) negotiate extended security (this is turned off by
default in the cifs vfs ie /proc/fs/cifs/ExtendedSecurity is zero)  or 2) don't
check or don't care what is in the bcc area of the negprot response (which is the
case for earlier clients)

> but I think it should be possible to mount shares in workgroups which
> names are shorter the 4 Bytes.
Yes you are correct - there is no minimum domain length, although there is a minimal
bcc length for true NTLMSSP and SPNEGO negotiate responses which I will now be
forced to detect differently on the client.   As you noticed it worked for longer
domain names, because the bcc was larger and spnego decoding was harmless for longer
domain names.

I will fix this today, probably by adding a check in fs/cifs/cifssmb.c (in
CIFSSMBNegotiate) in parsing the negotiate response from something like from:

 if (pSMBr->hdr.Flags2 & SMBFLG2_EXT_SEC)

to

if ((pSMBr->hdr.Flags2 & SMBFLG2_EXT_SEC) &&
   (server->capabilities & CAP_EXTENDED_SECURITY))

The Samba fix is pretty easy as well (it only hits source/smbd/negprot.c -
reply_negprot function), I will bounce the fix off jra before updating the Samba 3
source.