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)

1 files changed, 12 insertions, 0 deletions

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);
+}