none
Non-standard Netbios Session Service carrying SMB, using the flags field to hold length RRS feed

  • Question

  • Hi all,

    From what I know and have seen of NBSS, 17 bits(1 bit from the flags field - 0x01) and 2 bytes(3rd and 4th byte of the 4 bytes) from the NBSS header is used to calculate the length of the NBSS message.

    I have a pcap, where it is using the whole of the flags field to specify the length.  The NBSS is having a length of 1048656.  I obtained this from a Windows 7 machine.

    I have mailed the pcap for your reference.  Please let me know if you need any more details.

    Monday, September 28, 2015 9:09 AM

Answers

  • Hello Cressnet,

    Thank you for checking.  We do have follow-up to provide after going through this and conferring with team.

    For the capture and communication, this is SMB over Direct TCP transport.  The StreamProtocolLength is 3 bytes, see [MS-SMB2] 2.1 Transport.   For SMB1, the length is caped to 0x1FFFF, see MS-SMB 2.1 Transport.

    The trace shows a large SMB2 Read of 0x100000, which is segmented in several TCP packets, and this is perfectly fine, because SMB2 large MTU capability is being leveraged.

    ProtocolId is FE 53 4D 42 i.e SMB2

    We used Microsoft Network Monitor 3.4

    https://www.microsoft.com/en-us/download/details.aspx?id=4865

    with using the latest parsers:

    https://connect.microsoft.com/site216/Network%20Monitor%20Parsers

    From the parsers, we see the following:

    2              05:40:32.9477270             0.0017270                            192.168.2.67       192.168.2.55       SMB2    SMB2:R   READ (0x8), 0x100000 bytes read,     {SMBOverTCP:3, TCP:2, IPv4:1}

    SMBOverTCP: Length = 1048656

    SMBOverTCPPacket: Length = 1048656

    SMBOverTCPPacket: Continuation Data

    SMB2: R   READ (0x8), 0x100000 bytes read

    Best regards,
    Nathan Manis
    Microsoft Open Specifications

     

    Wednesday, October 7, 2015 7:28 PM
    Moderator

All replies

  • I have mailed the pcap to dochelp@microsoft.com for your reference.  Thank you.

    Monday, September 28, 2015 9:16 AM
  • Hi Cressnet,

    Thank you for the question and pcap file.  One of the members of the Open Specifications team will respond shortly to begin working with you on this issue.

    Best regards,
    Nathan Manis
    Microsoft Open Specifications

    Monday, September 28, 2015 5:09 PM
    Moderator
  • Hi Cressnet,

    Thank you for the question and file.  We have reviewed the short trace collected.   In review, we see the length of buffer is 1444.

    However, we do see the Message Analyzer parse of the trace to show the DataLength to be 1048576  (or 0x100000).

    In the data in raw format, the data for the length shows 00 00 10 00 which Message Analyzer parses into 0x00100000.   Now, the question we are reviewing is this correct for the scenario with NBSS.

    We are looking at this further for NBSS and will be in touch soon.

    Best regards,
    Nathan Manis
    Microsoft Open Specifications

    Wednesday, September 30, 2015 8:56 PM
    Moderator
  • Hello,

    Thanks for the response.

    In review, for what buffer did you arrive at 1444 as length?  The ReadResponse body length?  If so, I still seem to see it as 0x100000, from the raw payload.

    I was focusing more on the length specified by NBSS Header, which shows it as 1048656(0x100050), which makes sense - 64 bytes of SMB Header + 16 bytes of ReadResponse Header + 1048576(0x100000) of ReadResponse length.

    Thursday, October 1, 2015 12:37 AM
  • Hi Cressnet,

    Thank you for the feedback.  Sorry for the 1444 number, I misread it yesterday in looking at parsing error on frame 820.  

    Back to the trace, the Response buffer size is indeed 1048576 and does have a bunch of data in the buffer.

    We are not sure on the question for this one now.  

    From the trace,  is the team expecting the size to be much smaller?   Or something else?

    Thanks,

    Nathan 

    Thursday, October 1, 2015 6:13 PM
    Moderator
  • Hi Nathan,

    According the RFC 1002 in a NBSS header,

    -----

        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      TYPE     |     FLAGS     |            LENGTH             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       /               TRAILER (Packet Type Dependent)                 /
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    
       The TYPE, FLAGS, and LENGTH fields are present in every session
       packet.
    

    The LENGTH field is the number of bytes following the LENGTH field. In other words, LENGTH is the combined size of the TRAILER field(s). For example, the POSITIVE SESSION RESPONSE packet always has a LENGTH field value of zero (0000) while the RETARGET SESSION RESPONSE always has a LENGTH field value of six (0006). One of the bits of the FLAGS field acts as an additional, high- order bit for the LENGTH field. Thus the cumulative size of the trailer field(s) may range from 0 to 128K bytes.

    -----

    So according to the above specs, it can only use the first bit(lowest bit) of the flags byte, and the next 2 bytes, to specify the length of the NBSS body, bringing the total upto to 17 bits(1 + 16 bits).

    But if you look at the NBSS header, you will see the length reported as 1048656(0x100050), which has exceeded 17 bits, which breaks above RFC specs for NBSS.  Is this standard for NBSS to use more than 17 bits to specify the length? This is the first time I am seeing captures where NBSS used more bits from the flags field to specify length!

    Friday, October 2, 2015 1:53 AM
  • Hi,

    Anything on this?

    Wednesday, October 7, 2015 12:56 PM
  • Hello Cressnet,

    Thank you for checking.  We do have follow-up to provide after going through this and conferring with team.

    For the capture and communication, this is SMB over Direct TCP transport.  The StreamProtocolLength is 3 bytes, see [MS-SMB2] 2.1 Transport.   For SMB1, the length is caped to 0x1FFFF, see MS-SMB 2.1 Transport.

    The trace shows a large SMB2 Read of 0x100000, which is segmented in several TCP packets, and this is perfectly fine, because SMB2 large MTU capability is being leveraged.

    ProtocolId is FE 53 4D 42 i.e SMB2

    We used Microsoft Network Monitor 3.4

    https://www.microsoft.com/en-us/download/details.aspx?id=4865

    with using the latest parsers:

    https://connect.microsoft.com/site216/Network%20Monitor%20Parsers

    From the parsers, we see the following:

    2              05:40:32.9477270             0.0017270                            192.168.2.67       192.168.2.55       SMB2    SMB2:R   READ (0x8), 0x100000 bytes read,     {SMBOverTCP:3, TCP:2, IPv4:1}

    SMBOverTCP: Length = 1048656

    SMBOverTCPPacket: Length = 1048656

    SMBOverTCPPacket: Continuation Data

    SMB2: R   READ (0x8), 0x100000 bytes read

    Best regards,
    Nathan Manis
    Microsoft Open Specifications

     

    Wednesday, October 7, 2015 7:28 PM
    Moderator
  • Thank you for the information.

    Thursday, October 8, 2015 2:47 AM