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/rap/rap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'source4/torture/rap/rap.c') diff --git a/source4/torture/rap/rap.c b/source4/torture/rap/rap.c index a74acdb331..1ae92a6034 100644 --- a/source4/torture/rap/rap.c +++ b/source4/torture/rap/rap.c @@ -172,7 +172,7 @@ static NTSTATUS rap_cli_do_call(struct smbcli_state *cli, TALLOC_CTX *mem_ctx, params->flags = RAPNDR_FLAGS; trans.in.max_param = call->rcv_paramlen; - trans.in.max_data = call->rcv_datalen; + trans.in.max_data = smb_raw_max_trans_data(cli->tree, call->rcv_paramlen); trans.in.max_setup = 0; trans.in.flags = 0; trans.in.timeout = 0; -- cgit