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, 2 insertions, 2 deletions

diff --git a/source4/libcli/raw/rawfileinfo.c b/source4/libcli/raw/rawfileinfo.c
index cbb666b7ce..a0ee7891bf 100644
--- a/source4/libcli/raw/rawfileinfo.c
+++ b/source4/libcli/raw/rawfileinfo.c
@@ -291,7 +291,7 @@ static struct smbcli_request *smb_raw_fileinfo_blob_send(struct smbcli_tree *tre
 	tp.in.setup_count = 1;
 	tp.in.data = data_blob(NULL, 0);
 	tp.in.max_param = 2;
-	tp.in.max_data = 0xFFFF;
+	tp.in.max_data = smb_raw_max_trans_data(tree, 2);
 	tp.in.setup = &setup;
 	
 	tp.in.params = data_blob_talloc(mem_ctx, NULL, 4);
@@ -344,7 +344,7 @@ static struct smbcli_request *smb_raw_pathinfo_blob_send(struct smbcli_tree *tre
 	tp.in.setup_count = 1;
 	tp.in.data = data_blob(NULL, 0);
 	tp.in.max_param = 2;
-	tp.in.max_data = 0xFFFF;
+	tp.in.max_data = smb_raw_max_trans_data(tree, 2);
 	tp.in.setup = &setup;
 	
 	tp.in.params = data_blob_talloc(mem_ctx, NULL, 6);