s3:libsmb/cli_np_tstream: use larger buffers to avoid a bug NT4 servers (bug #8195)

NT4 servers return NT_STATUS_PIPE_BUSY if we try a SMBtrans
and the SMBwriteX before hasn't transmited the whole DCERPC fragment.

W2K and above is happy with that.

As a result we try to match the behavior of Windows and older Samba clients,
they use write and read buffers of 4280 bytes instead of 1024 bytes.
On Windows only the SMBtrans based read uses 1024 (while we also use 4280
there).

metze

Autobuild-User: Stefan Metzmacher <metze@samba.org>
Autobuild-Date: Tue Jun  7 20:25:32 CEST 2011 on sn-devel-104

1 files changed, 17 insertions, 2 deletions

diff --git a/source3/libsmb/cli_np_tstream.c b/source3/libsmb/cli_np_tstream.c
index ba37ea5d2c..5e11a92d06 100644
--- a/source3/libsmb/cli_np_tstream.c
+++ b/source3/libsmb/cli_np_tstream.c
@@ -28,9 +28,24 @@
 static const struct tstream_context_ops tstream_cli_np_ops;
 
 /*
- * Window uses 1024 hardcoded for read size and trans max data
+ * Windows uses 4280 (the max xmit/recv size negotiated on DCERPC).
+ * This is fits into the max_xmit negotiated at the SMB layer.
+ *
+ * On the sending side they may use SMBtranss if the request does not
+ * fit into a single SMBtrans call.
+ *
+ * Windows uses 1024 as max data size of a SMBtrans request and then
+ * possibly reads the rest of the DCERPC fragment (up to 3256 bytes)
+ * via a SMBreadX.
+ *
+ * For now we just ask for the full 4280 bytes (max data size) in the SMBtrans
+ * request to get the whole fragment at once (like samba 3.5.x and below did.
+ *
+ * It is important that we use do SMBwriteX with the size of a full fragment,
+ * otherwise we may get NT_STATUS_PIPE_BUSY on the SMBtrans request
+ * from NT4 servers. (See bug #8195)
  */
-#define TSTREAM_CLI_NP_BUF_SIZE 1024
+#define TSTREAM_CLI_NP_BUF_SIZE 4280
 
 struct tstream_cli_np {
 	struct cli_state *cli;