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/rawtrans.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) (limited to 'source4/libcli/raw/rawtrans.c') diff --git a/source4/libcli/raw/rawtrans.c b/source4/libcli/raw/rawtrans.c index e6c928e3ed..21e20d00e0 100644 --- a/source4/libcli/raw/rawtrans.c +++ b/source4/libcli/raw/rawtrans.c @@ -531,3 +531,15 @@ NTSTATUS smb_raw_nttrans(struct smbcli_tree *tree, return smb_raw_nttrans_recv(req, mem_ctx, parms); } + +/* + work out the maximum data size for a trans request while avoiding + multi-part replies + + TODO: we only need to avoid multi-part replies because the + multi-part trans receive code is broken. +*/ +size_t smb_raw_max_trans_data(struct smbcli_tree *tree, size_t param_size) +{ + return tree->session->transport->options.max_xmit - (70 + param_size); +} -- cgit