libcli/smb: make TSTREAM_SMBXCLI_NP_MAX_BUF_SIZE public

This should be used to negotiate the may fragment size
of DCERPC connections.

Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>

diff --git a/libcli/smb/tstream_smbXcli_np.c b/libcli/smb/tstream_smbXcli_np.c
index f6bd2f616cfad77eb13218489348d43d87a78868..cbe7f6f83d34543cc3f15eb94338148374c59b7d 100644 (file)
--- a/libcli/smb/tstream_smbXcli_np.c
+++ b/libcli/smb/tstream_smbXcli_np.c
@@ -29,26 +29,6 @@
 
 static const struct tstream_context_ops tstream_smbXcli_np_ops;
 
-/*
- * Windows uses 4280 (the max xmit/recv size negotiated on DCERPC).
- * This is fits into the max_xmit negotiated at the SMB layer.
- *
- * On the sending side they may use SMBtranss if the request does not
- * fit into a single SMBtrans call.
- *
- * Windows uses 1024 as max data size of a SMBtrans request and then
- * possibly reads the rest of the DCERPC fragment (up to 3256 bytes)
- * via a SMBreadX.
- *
- * For now we just ask for the full 4280 bytes (max data size) in the SMBtrans
- * request to get the whole fragment at once (like samba 3.5.x and below did.
- *
- * It is important that we use do SMBwriteX with the size of a full fragment,
- * otherwise we may get NT_STATUS_PIPE_BUSY on the SMBtrans request
- * from NT4 servers. (See bug #8195)
- */
-#define TSTREAM_SMBXCLI_NP_MAX_BUF_SIZE 4280
-
 #define TSTREAM_SMBXCLI_NP_DESIRED_ACCESS ( \
        SEC_STD_READ_CONTROL | \
        SEC_FILE_READ_DATA | \

diff --git a/libcli/smb/tstream_smbXcli_np.h b/libcli/smb/tstream_smbXcli_np.h
index c4af532717315c2ca90af0a9eeafffcb8b411957..e8c5c39297a8df891bc6b4aa3cc7bd360639af52 100644 (file)
--- a/libcli/smb/tstream_smbXcli_np.h
+++ b/libcli/smb/tstream_smbXcli_np.h
@@ -49,4 +49,24 @@ NTSTATUS tstream_smbXcli_np_use_trans(struct tstream_context *stream);
 unsigned int tstream_smbXcli_np_set_timeout(struct tstream_context *stream,
                                            unsigned int timeout);
 
+/*
+ * Windows uses 4280 (the max xmit/recv size negotiated on DCERPC).
+ * This is fits into the max_xmit negotiated at the SMB layer.
+ *
+ * On the sending side they may use SMBtranss if the request does not
+ * fit into a single SMBtrans call.
+ *
+ * Windows uses 1024 as max data size of a SMBtrans request and then
+ * possibly reads the rest of the DCERPC fragment (up to 3256 bytes)
+ * via a SMBreadX.
+ *
+ * For now we just ask for the full 4280 bytes (max data size) in the SMBtrans
+ * request to get the whole fragment at once (like samba 3.5.x and below did.
+ *
+ * It is important that we use do SMBwriteX with the size of a full fragment,
+ * otherwise we may get NT_STATUS_PIPE_BUSY on the SMBtrans request
+ * from NT4 servers. (See bug #8195)
+ */
+#define TSTREAM_SMBXCLI_NP_MAX_BUF_SIZE 4280
+
 #endif /*  _CLI_NP_TSTREAM_H_ */