Put all the protocol stuff into a separate header file.

All the structures and the vfs function identifier list is required
by the receiver. It's therefore very handy to have this in an extra
header file.

2 files changed, 152 insertions, 114 deletions

diff --git a/source3/modules/vfs_smb_traffic_analyzer.c b/source3/modules/vfs_smb_traffic_analyzer.c
index 4465425927..7d7332e1b9 100644
--- a/source3/modules/vfs_smb_traffic_analyzer.c
+++ b/source3/modules/vfs_smb_traffic_analyzer.c
@@ -21,123 +21,13 @@
 
 #include "includes.h"
 #include "../lib/crypto/crypto.h"
+#include "vfs_smb_traffic_analyzer.h"
 
 /* abstraction for the send_over_network function */
 enum sock_type {INTERNET_SOCKET = 0, UNIX_DOMAIN_SOCKET};
 
 #define LOCAL_PATHNAME "/var/tmp/stadsocket"
 
-
-/**
- * Protocol version 2.0 description
- *
- * The following table shows the exact assembly of the 2.0 protocol.
- *
- * -->Header<--
- * The protocol header is always send first, and contains various
- * information about the data block to come.
- * The header is always of fixed length, and will be send unencrypted.
- *
- * Byte Number/Bytes	Description
- * 00-02		Contains always the string "V2."
- * 03			This byte contains a possible subrelease number of the
- *			protocol. This enables the receiver to make a version
- * 			check to ensure the compatibility and allows us to
- *			release 2.x versions of the protocol with bugfixes or
- *			enhancements.
- * 04			This byte is reserved for possible future extensions.
- * 05			Usually, this byte contains the character '0'. If the
- *			VFS module is configured for encryption of the data,
- *			this byte is set to 'E'.
- * 06-09		These bytes contain the character '0' by default, and
- *			are reserved for possible future extensions. They have
- *			no function in 2.0.
- * 10-27		17 bytes containing a string representation of the
- *			number of bytes to come in the following data block.
- *			It is right aligned and filled from the left with '0'.
- * 
- * -->Data Block<--
- * The data block is send immediately after the header was send. It's length
- * is exactly what was given in bytes 11-28 from in the header.
- *
- * The data block may be send encrypted.
- * 
- * To make the data block easy for the receiver to read, it is divided into
- * several sub-blocks, each with it's own header of four byte length. In each
- * of the sub-headers, a string representation of the length of this block is
- * to be found.
- *
- * Thus the formal structure is very simple:
- *
- * [HEADER]data[HEADER]data[HEADER]data[END]
- *
- * whereas [END] is exactly at the position given in bytes 11-28 of the
- * header.
- *
- * Some data the VFS module is capturing is of use for any VFS operation.
- * Therefore, there is a "common set" of data, that will be send with any
- * data block. The following provides a list of this data.
- * - the VFS function identifier (see VFS function ifentifier table below).
- * - a timestamp to the millisecond.
- * - the username (as text) who runs the VFS operation.
- * - the SID of the user who run the VFS operation.
- * - the domain under which the VFS operation has happened.
- *
- */
-
- 
-/** 
- * VFS Functions identifier table. In protocol version 2, every vfs
- * function is given a unique id.
- */
-enum vfs_id {
-	/*
-	 * care for the order here, required for compatibility
-	 * with protocol version 1.
-	 */
-        vfs_id_read,
-        vfs_id_pread,
-        vfs_id_write,
-        vfs_id_pwrite,
-	/* end of protocol version 1 identifiers. */
-	vfs_id_mkdir,
-	vfs_id_rmdir,
-	vfs_id_rename,
-	vfs_id_chdir
-};
-
-/*
- * Specific data sets for the VFS functions.
- * A compatible receiver has to have the exact same dataset.
- */
-struct mkdir_data {
-	const char *path;
-	mode_t mode;
-	int result;
-};
-
-struct rmdir_data {
-	const char *path;
-	int result;
-};
-
-struct rename_data {
-	const char *src;
-	const char *dst;
-	int result;
-};
-
-struct chdir_data {
-	const char *path;
-	int result;
-};
-	
-/* rw_data used for read/write/pread/pwrite */
-struct rw_data {
-	char *filename;
-	size_t len;
-};
-
 static int vfs_smb_traffic_analyzer_debug_level = DBGC_VFS;
 
 static enum sock_type smb_traffic_analyzer_connMode(vfs_handle_struct *handle)
@@ -277,13 +167,21 @@ static char *smb_traffic_analyzer_create_string( struct tm *tm, \
 	char *usersid = NULL;
 	const char *total_anonymization = NULL;
 	const char *anon_prefix = NULL;
+	/*
+	 * first create the data that is transfered with any VFS op
+	 * These are, in the following order:
+	 * number of data to come [6 in v2.0]
+	 * 1.vfs_operation identifier
+	 * 2.username
+	 * 3.user-SID
+	 * 4.affected file + full path
+	 * 5.domain
+	 * 6.timestamp
+	 */
 
-	/* first create the data that is transfered with any VFS op */
 	opstr = talloc_asprintf(talloc_tos(), "%i", vfs_operation);
 	len = strlen(opstr);
 	buf = talloc_asprintf(talloc_tos(), "%04u%s", len, opstr);
-	len = strlen( username );
-	buf = talloc_asprintf_append(buf, "%04u%s", len, username);
 
 	/*
 	 * Handle anonymization. In protocol v2, we have to anonymize
diff --git a/source3/modules/vfs_smb_traffic_analyzer.h b/source3/modules/vfs_smb_traffic_analyzer.h
new file mode 100644
index 0000000000..7a3c358a0e
--- /dev/null
+++ b/source3/modules/vfs_smb_traffic_analyzer.h
@@ -0,0 +1,140 @@
+/*
+ * traffic-analyzer VFS module. Measure the smb traffic users create
+ * on the net.
+ *
+ * Copyright (C) Holger Hetterich, 2008
+ * Copyright (C) Jeremy Allison, 2008
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 3 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see <http://www.gnu.org/licenses/>.
+ */
+
+
+/*
+ * Protocol V2.0 definition
+ *
+/
+
+/**
+ * Protocol version 2.0 description
+ *
+ * The following table shows the exact assembly of the 2.0 protocol.
+ *
+ * -->Header<--
+ * The protocol header is always send first, and contains various
+ * information about the data block to come.
+ * The header is always of fixed length, and will be send unencrypted.
+ *
+ * Byte Number/Bytes    Description
+ * 00-02                Contains always the string "V2."
+ * 03                   This byte contains a possible subrelease number of the
+ *                      protocol. This enables the receiver to make a version
+ *                      check to ensure the compatibility and allows us to
+ *                      release 2.x versions of the protocol with bugfixes or
+ *                      enhancements.
+ * 04                   This byte is reserved for possible future extensions.
+ * 05                   Usually, this byte contains the character '0'. If the
+ *                      VFS module is configured for encryption of the data,
+ *                      this byte is set to 'E'.
+ * 06-09                These bytes contain the character '0' by default, and
+ *                      are reserved for possible future extensions. They have
+ *                      no function in 2.0.
+ * 10-27                17 bytes containing a string representation of the
+ *                      number of bytes to come in the following data block.
+ *                      It is right aligned and filled from the left with '0'.
+ *
+ * -->Data Block<--
+ * The data block is send immediately after the header was send. It's length
+ * is exactly what was given in bytes 11-28 from in the header.
+ *
+ * The data block may be send encrypted.
+ *
+ * To make the data block easy for the receiver to read, it is divided into
+ * several sub-blocks, each with it's own header of four byte length. In each
+ * of the sub-headers, a string representation of the length of this block is
+ * to be found.
+ *
+ * Thus the formal structure is very simple:
+ *
+ * [HEADER]data[HEADER]data[HEADER]data[END]
+ *
+ * whereas [END] is exactly at the position given in bytes 11-28 of the
+ * header.
+ *
+ * Some data the VFS module is capturing is of use for any VFS operation.
+ * Therefore, there is a "common set" of data, that will be send with any
+ * data block. The following provides a list of this data.
+ * - the VFS function identifier (see VFS function ifentifier table below).
+ * - a timestamp to the millisecond.
+ * - the username (as text) who runs the VFS operation.
+ * - the SID of the user who run the VFS operation.
+ * - the domain under which the VFS operation has happened.
+ *
+ */
+
+
+/*
+ * VFS Functions identifier table. In protocol version 2, every vfs
+ * function is given a unique id.
+ */
+enum vfs_id {
+        /*
+         * care for the order here, required for compatibility
+         * with protocol version 1.
+         */
+        vfs_id_read,
+        vfs_id_pread,
+        vfs_id_write,
+        vfs_id_pwrite,
+        /* end of protocol version 1 identifiers. */
+        vfs_id_mkdir,
+        vfs_id_rmdir,
+        vfs_id_rename,
+        vfs_id_chdir
+};
+
+
+
+/*
+ * Specific data sets for the VFS functions.
+ * A compatible receiver has to have the exact same dataset.
+ */
+struct mkdir_data {
+        const char *path;
+        mode_t mode;
+        int result;
+};
+
+struct rmdir_data {
+        const char *path;
+        int result;
+};
+
+struct rename_data {
+        const char *src;
+        const char *dst;
+        int result;
+};
+
+struct chdir_data {
+        const char *path;
+        int result;
+};
+
+/* rw_data used for read/write/pread/pwrite */
+struct rw_data {
+        char *filename;
+        size_t len;
+};
+
+