OemDomainName in Negotiate Protocol Repsonse

Sat Jul 20 12:04:02 GMT 2002

Probably it does not cause a problem for regular clients who may not use
the
information in that field and get the same by other means.  I mean, we
know
that Windows clients work with Samba Servers and vice-versa - SmbClient
works with Windows Servers NT or 2K.

It affects the development of non-standard clients - e.g.
A client that tries to get the Domain Name field with as few
interactions with 
the Server as possible will find this to be the first such occurence of
the Domain 
Name and cannot reliably conclude from the same.

Regards,
Raghu

-----Original Message----- 
From: Richard Sharpe 
Sent: Sat 7/20/2002 10:59 PM 
To: Raghu Iyer 
Cc: samba-technical at samba.org; Michael B. Allen 
Subject: RE: OemDomainName in Negotiate Protocol Repsonse

	On Sat, 20 Jul 2002, Raghu Iyer wrote:

	> Richard,
	>
	> Michael is correct - in that Samba does not respond
	> the same as Windows NT/2K. It responds correctly as
	> per spec.
	>
	> And there-in lies the issue. I have attached a Samba
	> trace (packet #19, source m/c ip = 192.168.60.232, Linux)
	> - and going by the flags2 bit - it is correctly
	> sending ASCII. And Windows sends UNICODE even if flags2
	> bit says no-UNICODE. Not knowing whether the Server is
	> Samba or Windows, the client can misinterpret the
	> OemDomainName.

	So, does it cause a problem for the client?

	> Regards,
	> Raghu
	>
	> -----Original Message-----
	> From: Michael B. Allen [mailto:miallen at eskimo.com]
	> Sent: Saturday, July 20, 2002 1:04 AM
	> To: Richard Sharpe
	> Cc: Raghu Iyer; samba-technical at samba.org
	> Subject: Re: OemDomainName in Negotiate Protocol Repsonse
	>
	>
	> On Sat, 20 Jul 2002 04:12:06 +0930 (CST)
	> Richard Sharpe <rsharpe at ns.aus.com> wrote:
	>
	> > On Fri, 19 Jul 2002, Raghu Iyer wrote:
	> >
	> > > I have attached a packet trace between two NT4.0 machines
	> > > that shows a NegProt Response (packet #7) where the flags2
bit
	> > > does not say Unicode, yet the oemdomainname field is in
UNICODE.
	> > > Additional packets are included to show the machine
identity.
	> >
	> > Can you elaborate on what you think the problem is? In my
traces,
	> Samba
	> > responds in UNICODE.
	> >
	> > So if Samba does the same as Windows NT/2K, where's the
problem?
	>
	> But it doesn't. Samba does the "right" thing and returns
OemDomainName
	> in ASCII when a client asks for it in ASCII. NT returns it in
Unicode
	> regardless of what you ask for. See attached pcap of client
asking NT
	> for ASCII and getting only OemDomainName in Unicode.
	>
	> Jul 19 15:06:00.290 - smb received
	>
SmbComNegotiateResponse[command=SMB_COM_NEGOTIATE,received=true,errorCod
	>
e=0x00000000,flags=0x0098,flags2=0x0001,tid=0,pid=26455,uid=0,mid=1,word
	>
Count=17,byteCount=22,wordCount=17,dialectIndex=0,securityMode=0x3,secur
	>
ity=user,encryptedPasswords=true,maxMpxCount=50,maxNumberVcs=1,maxBuffer
	>
Size=4356,maxRawSize=65536,sessionKey=0x00000000,capabilities=0x000043FD
	> ,serverTime=Fri Jul 19 15:12:15 EDT
	>
2002,serverTimeZone=240,encryptionKeyLength=8,byteCount=22,encryptionKey
	> =0x2F62F45892789E70,oemDomainName=F]
	>
	> Jul 19 15:06:00.294 - smb received
	> 00000: FF 53 4D 42 72 00 00 00 00 98 01 00 00 00 00 00
	> |ÿSMBr...........|
	> 00010: 00 00 00 00 00 00 00 00 00 00 57 67 00 00 01 00
	> |..........Wg....|
	> 00020: 11 00 00 03 32 00 01 00 04 11 00 00 00 00 01 00
	> |....2...........|
	> 00030: 00 00 00 00 FD 43 00 00 F0 17 6A 31 58 2F C2 01
	> |....ýC..ð.j1X/Â.|
	> 00040: F0 00 08 16 00 2F 62 F4 58 92 78 9E 70 46 00 4F
	> |ð..../bôX.x.pF.O|
	> 00050: 00 4F 00 4E 00 45 00 54 00 00 00
|.O.N.E.T...
	> |
	>
	> Here's another similar issue:
	>
	>
http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A1=ind0104e&L=cifs
	>
	> Samba and Win98 return ASCII ShortNames in
	> SMB_FIND_FILE_BOTH_DIRECTORY_INFO when NT and "The Spec"
(4.3.4.6 on
	> SMB_FIND_FILE_BOTH_DIRECTORY_INFO) says these are always
Unicode. Here
	> are two TRANS2_FIND_FIRST2/NEXT2 responses with
	> Unicode off:
	>
	> NT:
	>
	> Jul 19 15:25:55.325 - ShortName[3]
	> 00000: 53 00 50 00 52 00 49 00 4E 00 47 00 7E 00 31 00
	> |S.P.R.I.N.G.~.1.|
	> 00010: 2E 00 45 00 58 00 45 00
|..E.X.E.
	> |
	>
	> Jul 19 15:25:55.325 - Trans2FindFirst2/Next2Response debugging
	>
bufferIndex=322,lastNameBufferIndex=674,nextEntryOffet=450,shortName=SPR
	> ING~1.EXE,shortNameLength=24
	> Jul 19 15:25:55.325 - ShortName[4]
	> 00000: 50 00 41 00 4C 00 4D 00 44 00 53 00 7E 00 31 00
	> |P.A.L.M.D.S.~.1.|
	> 00010: 2E 00 5A 00 49 00 50 00
|..Z.I.P.
	> |
	>
	> Jul 19 15:25:55.325 - Trans2FindFirst2/Next2Response debugging
	>
bufferIndex=450,lastNameBufferIndex=674,nextEntryOffet=570,shortName=PAL
	> MDS~1.ZIP,shortNameLength=24
	> Jul 19 15:25:55.326 - Trans2FindFirst2/Next2Response debugging
	>
bufferIndex=570,lastNameBufferIndex=674,nextEntryOffet=674,shortName=,sh
	> ortNameLength=0
	> Jul 19 15:25:55.326 - ShortName[6]
	> 00000: 42 00 41 00 53 00 41 00 4C 00 54 00 7E 00 31 00
	> |B.A.S.A.L.T.~.1.|
	> 00010: 2E 00 43 00                                      |..C.
	> |
	>
	> Samba:
	>
	> Jul 19 15:26:53.991 - ShortName[0]
	> 00000: 4E 4F 54 49 43 7E 4B 25 2E 50 44 46
|NOTIC~K%.PDF
	> |
	>
	> Jul 19 15:26:53.992 - Trans2FindFirst2/Next2Response debugging
	>
bufferIndex=10,lastNameBufferIndex=482,nextEntryOffet=134,shortName=NOTI
	> C~K%.PDF,shortNameLength=12
	> Jul 19 15:26:53.993 - ShortName[1]
	> 00000: 54 4D 50 4D 53 7E 33 5A 2E 30 38 31
|TMPMS~3Z.081
	> |
	>
	> Jul 19 15:26:53.993 - Trans2FindFirst2/Next2Response debugging
	>
bufferIndex=134,lastNameBufferIndex=482,nextEntryOffet=246,shortName=TMP
	> MS~3Z.081,shortNameLength=12
	> Jul 19 15:26:53.993 - ShortName[2]
	> 00000: 4F 45 4D 44 4F 7E 47 48 2E 50 43 41
|OEMDO~GH.PCA
	> |
	>
	>

	--
	Regards
	-----
	Richard Sharpe, rsharpe at ns.aus.com, rsharpe at samba.org,
	sharpe at ethereal.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 10578 bytes
Desc: not available
Url : http://lists.samba.org/archive/samba-technical/attachments/20020720/7015114e/attachment.bin