diff options
Diffstat (limited to 'source3/modules')
| -rw-r--r-- | source3/modules/vfs_smb_traffic_analyzer.c | 62 |
1 files changed, 62 insertions, 0 deletions
diff --git a/source3/modules/vfs_smb_traffic_analyzer.c b/source3/modules/vfs_smb_traffic_analyzer.c index f2735ec9fe..226611ca64 100644 --- a/source3/modules/vfs_smb_traffic_analyzer.c +++ b/source3/modules/vfs_smb_traffic_analyzer.c @@ -27,6 +27,68 @@ 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 Usually, this byte contains the character '0'. If the + * VFS module is configured for anonymization, this is + * set to 'A'. This information can be useful for the + * receiver. + * 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 { |