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/librpc/rpc/dcerpc_smb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'source4/librpc/rpc/dcerpc_smb.c') diff --git a/source4/librpc/rpc/dcerpc_smb.c b/source4/librpc/rpc/dcerpc_smb.c index a6307a9413..ead479230d 100644 --- a/source4/librpc/rpc/dcerpc_smb.c +++ b/source4/librpc/rpc/dcerpc_smb.c @@ -236,7 +236,7 @@ static NTSTATUS smb_send_trans_request(struct dcerpc_pipe *p, DATA_BLOB *blob) setup[1] = smb->fnum; trans->in.max_param = 0; - trans->in.max_data = 0x8000; + trans->in.max_data = smb_raw_max_trans_data(smb->tree, 0); trans->in.max_setup = 0; trans->in.setup_count = 2; trans->in.flags = 0; -- cgit