r3383: avoid multi-part SMBtrans and SMBtrans2 replies until our client library can handle

them properly (they are difficult to do in an async fashion).

By choosing trans.in.max_data to fix in the negotiated buffer size a
server won't send us multi-part replies.

I notice that windows seems to avoid them too :)
(This used to be commit e23edf762cace35f937959c9ffbef718431a79b9)

1 files changed, 4 insertions, 4 deletions

diff --git a/source4/libcli/raw/rawsearch.c b/source4/libcli/raw/rawsearch.c
index dd8904dfd1..120a42f0d6 100644
--- a/source4/libcli/raw/rawsearch.c
+++ b/source4/libcli/raw/rawsearch.c
@@ -206,8 +206,8 @@ static NTSTATUS smb_raw_search_first_blob(struct smbcli_tree *tree,
 	tp.in.timeout = 0;
 	tp.in.setup_count = 1;
 	tp.in.data = data_blob(NULL, 0);
-	tp.in.max_param = 1024;
-	tp.in.max_data = 8192;
+	tp.in.max_param = 10;
+	tp.in.max_data = smb_raw_max_trans_data(tree, 10);
 	tp.in.setup = &setup;
 	
 	tp.in.params = data_blob_talloc(mem_ctx, NULL, 12);
@@ -258,8 +258,8 @@ static NTSTATUS smb_raw_search_next_blob(struct smbcli_tree *tree,
 	tp.in.timeout = 0;
 	tp.in.setup_count = 1;
 	tp.in.data = data_blob(NULL, 0);
-	tp.in.max_param = 1024;
-	tp.in.max_data = 8192;
+	tp.in.max_param = 10;
+	tp.in.max_data = smb_raw_max_trans_data(tree, 10);
 	tp.in.setup = &setup;
 	
 	tp.in.params = data_blob_talloc(mem_ctx, NULL, 12);