none
[MS-CIFS] SMB_COM_TRANSACTION2 request sent by Windows XP SP3 RRS feed

  • Question

  • Hi,

    I have issues with Windows XP SP3 clients sending SMB_COM_TRANSACTION2 request that is somewhat different than the documented format.

    According to MS-CIFS, if Unicode support has been negotiated, then the Name field MUST consist of two terminating null characters.

    However, Windows XP SP3 will send only one null character (when Unicode support HAS been negotiated),

    and Windows Server 2003 will accept this format.

    I'm sending a packet capture session to "dochelp (at) Microsoft (dot) com".

    Thanks,

    Tal Aloni

    Tuesday, April 29, 2014 12:01 PM

Answers

  • As for Issue #2:

    “Please note that at packet number 67, the 'ShortName' field in the SMB_FIND_FILE_BOTH_DIRECTORY_INFO structures contain 24 null bytes. however, the specs mandates that "This field MUST contain the 8.3 name of the file in Unicode format".”

    In addition to the trace you sent, I wrote a test application that recreated this issue on Windows 8.1 (when in SMB2 was disabled, thus forcing SMB1/CIFS).  ShortNameLength is zero and ShortName contains 24 zero bytes (12 NULL WCHARs) followed by a two-byte NULL pad.  I filed an issue against [MS-CIFS]


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team

    Thursday, May 8, 2014 10:10 PM
    Moderator

All replies

  • Hello Tal Aloni,
                         Thank you for your inquiry about file sharing protocols. One of the Open specifications team member will contact you shortly.

     
    Regards,
    Sreekanth Nadendla
    Microsoft Windows Open specifications

    Tuesday, April 29, 2014 2:52 PM
    Moderator
  • Hi, Tal,

    I'll research this for you.  Thanks.


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team

    Tuesday, April 29, 2014 5:16 PM
    Moderator
  • Thanks Bryan,

    Issue #2:

    Please note that at packet number 67, the 'ShortName' field in the SMB_FIND_FILE_BOTH_DIRECTORY_INFO structures contain 24 null bytes. however, the specs mandates that "This field MUST contain the 8.3 name of the file in Unicode format".

    Thursday, May 1, 2014 3:09 PM
  • Hi Tal,

    I am researching #2 for you.


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team

    Friday, May 2, 2014 10:45 PM
    Moderator
  • As for Issue #2:

    “Please note that at packet number 67, the 'ShortName' field in the SMB_FIND_FILE_BOTH_DIRECTORY_INFO structures contain 24 null bytes. however, the specs mandates that "This field MUST contain the 8.3 name of the file in Unicode format".”

    In addition to the trace you sent, I wrote a test application that recreated this issue on Windows 8.1 (when in SMB2 was disabled, thus forcing SMB1/CIFS).  ShortNameLength is zero and ShortName contains 24 zero bytes (12 NULL WCHARs) followed by a two-byte NULL pad.  I filed an issue against [MS-CIFS]


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team

    Thursday, May 8, 2014 10:10 PM
    Moderator
  • Hi Tal,

    Returning to your initial issue (top of thread).  I reviewed this a bit more.  While frame 110 (in the trace you sent me) is a SMB_COM_TRANSACTION2 request, which often contains a SMB_Data that contains a SMB_STRING Name field, this frame has a Sub-Command of 0x0003 that corresponds to [MS-CIFS] 2.2.6.4.1 “TRANS2_QUERY_FS_INFORMATION (0x0003) Request” that specifies:

    The TRANS2_QUERY_FS_INFORMATION request and response formats are special cases of SMB_COM_TRANSACTION2 (section 2.2.4.46) SMB. Only the TRANS2_QUERY_FS_INFORMATION specifics are described here.

    SMB_Parameters:

    WordCount (1 byte): This field MUST be 0x0F.

    Words (30 bytes):

    TotalDataCount (2 bytes): This field MUST be zero (0x0000).

    SetupCount (1 byte): This field MUST be 0x01.

    Setup(2 bytes): This field MUST be TRANS2_QUERY_FS_INFORMATION (0x0003).

    Trans2_Parameters:

    Trans2_Parameters

      {

      USHORT InformationLevel;

      }

    InformationLevel (2 bytes): This field contains an information level code, which determines the information contained in the response. The list of valid information level codes is specified in section 2.2.2.3.2

    Trans2_Data: No data is sent by this message.

    Accordingly, I believe that the specification does correctly describe this frame ultimately when the sections under 2.2.6  “Transaction2 Subcommands” are taken into account as each indicates that Setup in each special case means Subcommand and then describes the payload for each.


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team

    Friday, May 9, 2014 8:58 PM
    Moderator
  • Bryan,

    If I understand correctly, the SMB_Data structure of SMB_COM_TRANSACTION2 does not change, it's simply the values of Trans2_Parameters and Trans2_Data (inside SMB_Data) that changes according to the individual SMB_COM_TRANSACTION2 subcommands.

    So accordingly, the other fields inside SMB_Data (Name, Pad1 and Pad2) must be present in each SMB_COM_TRANSACTION2 request.

    And since Name is an SMB_STRING, I'm expecting it to be null terminated (2 bytes for unicode), which is clearly not the case.

    Tal



    • Edited by Tal Aloni Saturday, May 10, 2014 11:24 AM
    Saturday, May 10, 2014 11:19 AM
  • Still waiting for an answer,

    Thanks.

    Thursday, July 24, 2014 11:48 AM
  • Hi Tal,

    I totally missed your follow-up post re Issue #1 (post date: 10 May), as I was under the impression that both issues were resolved, in addition to the other issues you posted at http://social.msdn.microsoft.com/Forums/en-US/713b6ce7-183b-489c-8b97-dbcda8ce7a46/mscifs-possible-documentaion-mistakes?forum=os_specifications#51dd135e-de01-4960-ab43-fd77fa4cc448.

    We’re happy to respond to questions in any way that is convenient to you, but it would be helpful to start a new form post (thread) for each.

    I am researching this (below, from your post) for you now:

    “If I understand correctly, the SMB_Data structure of SMB_COM_TRANSACTION2 does not change, it's simply the values of Trans2_Parameters and Trans2_Data (inside SMB_Data) that changes according to the individual SMB_COM_TRANSACTION2 subcommands.  So accordingly, the other fields inside SMB_Data (Name, Pad1 and Pad2) must be present in each SMB_COM_TRANSACTION2 request.  And since Name is an SMB_STRING, I'm expecting it to be null terminated (2 bytes for unicode), which is clearly not the case”

    Thank you for asking.


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team

    Thursday, July 24, 2014 9:44 PM
    Moderator
  • Hi Tal,

    I reproed and verified the behavior you described using two Windows 7 SP1 machines (with SMB2 disabled: server-side HKLM\System\CCS\Services\LanmanServer\Parameters\Smb2 (WORD) 0) and a console app that emits a [MS-CIFS] 2.2.4.46 SMB_COM_TRANSACTION2/2.2.6.4   TRANS2_QUERY_FS_INFORMATION frame (by calling GetVolumeInformationByHandleW).

    Following Setup[0], which contains the SubCommand 0x0003 indicating [MS-CIFS] 2.2.6.4 TRANS2_QUERY_FS_INFORMATION, is a ByteCount that is NOT followed by Name.

    I have reported this issue to the owners of [MS-CIFS]

    Thank you for reporting this.


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team

    Friday, July 25, 2014 10:17 PM
    Moderator