CVS update: samba/source/lib

[Luke Leighton]

Date:	Sunday January 2, 19100 @ 15:26
Author:	lkcl

Update of /data/cvs/samba/source/lib
In directory samba:/tmp/cvs-serv25743/lib

Modified Files:
      Tag: SAMBA_TNG
	msrpc-client.c 
Log Message:
ok, it's not so easy to remove smbd dependence on dce/rpc.

you need to do a "partial" decode of the dce/rpc header, in order
to know if the "last pdu" flag is set, so that you can skip
a receive from the dce/rpc socket.

otherwise, you end up waiting on a read from the dce/rpc socket for
a response pdu, and the daemon on the other side is waiting on a
read expecting the next _request_ pdu (except, of course, if it
just received the last request pdu, _then_ it processes data and
writes response pdus).

also added multi-request-pdu processing to smbd and dce/rpc daemons.
hooray!  at long last!

it's been added to SMBwriteX, it HASN'T been added to SMBwrite.
i don't know which word in the SMBwrite SMB header is "mode",
it's smb_vwv7 in SMBwriteX.

using SMBwriteX is a pain, to transfer DCE/RPC pdus.  smb_vwv7 is
set to 0x000c on the first part of a pdu, and the first two bytes
of the SMBwriteX data are set to the length of the pdu [what the
hell for? i hear you ask.  because the little red dwarf.  don't
ask such a damn silly question, this is MICROSOFT design we're
talking.  btw, if you are reading this, and implementing your
own DCE/RPC SMB client, for xxxx's sake get these two bytes right
on NT5-no-hotfix and NT4sp6 and below].  then, you send the
pdu.  if you need to use multiple SMBwriteXs to transfer a pdu,
the next SMBwriteX has smb_vwv7 set to 0x0004, and does NOT have
the two length-field bytes at the start of the data.

btw, you don't use message-mode 0x000c on RPC_BINDCONT (3-way
bind/bind-resp/bind-cont stuff for NTLMSSP neg/chal/resp), you
can get away with a straight SMBwriteX, there, smb_vwv7 = 0x0.