Windows 7 SP1 PRO SMB2 Client Behaviour Quirk - Last SMB2 Query_Info request in compounded requests, contains 1 extra byte in the end after file_id

Question

Hi,
From the specification, SMB2 Query Info is defined as -Query_Info {
    uint16_t structure_size;
    uint8_t info_type;
    uint8_t file_info_class;
    uint32_t output_buf_len;
    uint16_t input_buffer_off;
    uint16_t res;
    uint32_t input_buf_len;
    uint32_t additional_information;
    uint32_t flags;
    uint8_t file_id[16];
I am looking at smb traffic between 2 Windows 7 Pro machines and I see that for SMB Query_Info Request records, for some compounded requests, the last Query_Info request has an extra byte after the 16 byte file_id.  This is only for SMB2 Query_Info
requests.
On checking Query_Info requests that are single(not compounded), I don't see this extra byte.
I have attached images below from wireshark for both with and without this extra byte, from the same flow.
Can we consider this a quirk of the windows client issuing Query_Info Compounded requests?
Image1 - http://postimg.org/image/th8fubvuz <- As you can see, this is a comounded series of requests and the last requset which is a query_info request *HAS* an extra byte after the file_id.
Image2 - http://postimg.org/image/kkp4adxe7/ <- As you can, this is a compounded series of requests and the last request which is a query_info request, DOES *NOT* HAVE an extra byte after the file_id unlike Image1
Image3- http://postimg.org/image/5w7061vrr/ <- As you can see, this is a single Query_Info request, and we don't have the extra byte here after the file_id.

Answer 1

We worked with cressnet and resolved these questions offline. Here is a summary of resolution.
Regarding the comments on compounded messages with QueryInfo,
this is not specific to QueryInfo.
The receiver’s transport layer delivers the message to the SMB2 layer (server/redirector). The SMB2 PDU starts with its header. The PDU is casted and interpreted based on the SMB2 command. What matters is the message’s structure
itself.
The transport’s (e.g. Nbtss or SMBoverTCP) indicates the length of its payload. Each SMB2 message has a structure which may include some variable length fields. Padding is one element that may complement the message for alignment
purpose. Any extra byte (s) that is not part of the SMB2 message fields would be irrelevant and ignored.
Regarding the comments on ErrorData,
the CHANGE_NOTIFY response packets look valid as documented in the [MS-SMB2] specification. In this particular case, even if the error is not a success code (i.e. STATUS_NOTIFY_ENUM_DIR), the response is an empty CHANGE_NOTIFY
Response, rather than a standard ERROR Response.
The exception cases that are not considered error messages are listed in [MS-SMB2] section 3.3.4.4. When in doubt, please consult the server processing of the specific SMB2 command.
[MS-SMB2] 3.3.4.4 Sending an Error Response
https://msdn.microsoft.com/en-us/library/cc246722.aspx
When the server is responding with a failure to any command sent by the client, the response message MUST be constructed as described here. An error code other than one of the following indicates a failure:
•         STATUS_MORE_PROCESSING_REQUIRED in an SMB2 SESSION_SETUP Response specified in section 2.2.6.
•         STATUS_BUFFER_OVERFLOW in an SMB2 QUERY_INFO Response specified in section 2.2.38.
•         STATUS_BUFFER_OVERFLOW in a FSCTL_PIPE_TRANSCEIVE, FSCTL_PIPE_PEEK or FSCTL_DFS_GET_REFERRALS Response specified in section 2.2.32.<190>
•         STATUS_BUFFER_OVERFLOW in an SMB2 READ Response on a named pipe specified in section 2.2.20.
•         STATUS_INVALID_PARAMETER in an FSCTL_SRV_COPYCHUNK or FSCTL_SRV_COPYCHUNK_WRITE response, when returning an SRV_COPYCHUNK_RESPONSE as described in section 3.3.5.15.6.2.
•         STATUS_NOTIFY_ENUM_DIR in an SMB2 CHANGE_NOTIFY Response specified in section 2.2.36.
[MS-SMB2] 3.3.5.19 Receiving an SMB2 CHANGE_NOTIFY Request
https://msdn.microsoft.com/en-us/library/cc246747.aspx
Change notification processing in the object store MUST be handled as specified in section 3.3.1.3. It is also outlined in [MS-CIFS] section 3.3.5.59.4.
If the server is unable to copy the results into the buffer of the SMB2 CHANGE_NOTIFY Response, then the server MUST construct the response as described below, with an OutputBufferLength of zero, and set the Status in the SMB2
header to STATUS_NOTIFY_ENUM_DIR.
Thanks,
Edgar