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/torture/basic/scanner.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'source4/torture/basic/scanner.c') diff --git a/source4/torture/basic/scanner.c b/source4/torture/basic/scanner.c index cd53cb3979..0e79e94f82 100644 --- a/source4/torture/basic/scanner.c +++ b/source4/torture/basic/scanner.c @@ -58,8 +58,8 @@ static NTSTATUS try_trans2(struct smbcli_state *cli, mem_ctx = talloc_init("try_trans2"); - t2.in.max_param = 1024; - t2.in.max_data = 0x8000; + t2.in.max_param = 64; + t2.in.max_data = smb_raw_max_trans_data(cli->tree, 64); t2.in.max_setup = 10; t2.in.flags = 0; t2.in.timeout = 0; @@ -339,8 +339,8 @@ static NTSTATUS try_nttrans(struct smbcli_state *cli, ntdata_blob.length = data_len; ntdata_blob.data = data; - parms.in.max_param = 1024; - parms.in.max_data = 1024; + parms.in.max_param = 64; + parms.in.max_data = smb_raw_max_trans_data(cli->tree, 64); parms.in.max_setup = 0; parms.in.setup_count = 0; parms.in.function = op; -- cgit