From 39883a90cf3ecabfc39e68e8b1d3265a4026d25c Mon Sep 17 00:00:00 2001 From: Andrew Tridgell Date: Sat, 30 Oct 2004 02:17:03 +0000 Subject: 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) --- source4/libcli/raw/rawsearch.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'source4/libcli/raw/rawsearch.c') 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); -- cgit