none
SMB2: CreditsGranted : Windows Server 2008 (as client) RESETs the TCP connection when less then requested Credits are Granted RRS feed

  • Question

  • Hi Team,

    Thanks for taking the question. I hope its straight forward reply.

    I have a scenario where

    a. Windows 2008 R2 as a client makes SMB2 connection requesting 31 credits.

    b. If the response comes with say 9 Credits (if I may, lets not go into why only 9 are being granted, say this is okay for the server to give only 9 back)

    c. The Client (Windows 2008 R2 server) Immediately resets the connection.

    Question:

    1. Is this expected behavior that Windows Server 2008 (as client) should RESET the TCP connection when less then requested Credits are Granted

    2. Is there a minimum requirement for Windows 2008 Server that if it does not get X credits or the number it requested it will kill the connection?

    ===========================

    Here's the communication from a trace

    ===========================

    ========================================================================================
    REQUEST FRAME: WINDOWS 2008 SERVER Requesting SMB2 SessionSetup with 31 Credits
    ========================================================================================

    Frame 23: 616 bytes on wire (4928 bits), 616 bytes captured (4928 bits)
        Arrival Time: Mar 20, 2013 07:09:55.883050000 EDT

        Frame Length: 616 bytes (4928 bits)
        Capture Length: 616 bytes (4928 bits)

    Transmission Control Protocol, Src Port: 62214 (62214), Dst Port: microsoft-ds (445), Seq: 10488, Ack: 505, Len: 562


    NetBIOS Session Service
        Message Type: Session message (0x00)
        Length: 10778
    SMB2 (Server Message Block Protocol version 2)
        SMB2 Header
            Server Component: SMB2
            Header Length: 64
            Credit Charge: 1
            NT Status: STATUS_SUCCESS (0x00000000)
            Command: SessionSetup (1)
            Credits requested: 31
            Flags: 0x00000000
                ...0 .... .... .... .... .... .... .... = DFS operation: This is a normal operation
                .... .... .... .... .... .... .... 0... = Signing: This pdu is NOT signed
                .... .... .... .... .... .... .... .0.. = Chained: This pdu is NOT a chained command
                .... .... .... .... .... .... .... ..0. = Async command: This is a SYNC command
                .... .... .... .... .... .... .... ...0 = Response: This is a REQUEST
            Chain Offset: 0x00000000
            Command Sequence Number: 2
            Process Id: 0000feff
            Tree Id: 0x00000000
            Session Id: 0x0000000000000000
            Signature: 00000000000000000000000000000000
        SessionSetup Request (0x01)
            Length: 24
            .... .... .... ...1 = Dynamic Part: True
            VC Num: 0
            Security mode: 0x02
                .... ..1. = Signing required: True
                .... ...0 = Signing enabled: False
            Capabilities: 0x00000001
                .... .... .... .... .... .... .... ...1 = DFS: This host supports DFS
                .... .... .... .... .... .... .... ..0. = LEASING: This host does NOT support LEASING
                .... .... .... .... .... .... .... .0.. = LARGE MTU: This host does NOT support LARGE_MTU
            Channel: 0
            Previous Session Id: 0x0000000000000000
            Security Blob: 608229be06062b0601050502a08229b2308229aea030302e...
                Offset: 0x00000058
                Length: 10690
                GSS-API Generic Security Service Application Program Interface
                    OID: 1.3.6.1.5.5.2 (SPNEGO - Simple Protected Negotiation)
                    Simple Protected Negotiation
                        negTokenInit
                            mechTypes: 4 items
                                MechType: 1.2.840.48018.1.2.2 (MS KRB5 - Microsoft Kerberos 5)
                                MechType: 1.2.840.113554.1.2.2 (KRB5 - Kerberos 5)
                                MechType: 1.3.6.1.4.1.311.2.2.30 (iso.3.6.1.4.1.311.2.2.30)
                                MechType: 1.3.6.1.4.1.311.2.2.10 (NTLMSSP - Microsoft NTLM Security Support Provider)
                            mechToken: 6082297006092a864886f71201020201006e82295f308229...
                            krb5_blob: 6082297006092a864886f71201020201006e82295f308229...
                                KRB5 OID: 1.2.840.113554.1.2.2 (KRB5 - Kerberos 5)
                                krb5_tok_id: KRB5_AP_REQ (0x0001)
                                Kerberos AP-REQ
                                    Pvno: 5
                                    MSG Type: AP-REQ (14)
                                    Padding: 0
                                    APOptions: 20000000 (Mutual required)
                                        0... .... .... .... .... .... .... .... = reserved: RESERVED bit off
                                        .0.. .... .... .... .... .... .... .... = Use Session Key: Do NOT use the session key to encrypt the ticket
                                        ..1. .... .... .... .... .... .... .... = Mutual required: MUTUAL authentication is REQUIRED
                                    Ticket
                                        Tkt-vno: 5
                                        Realm: DOMAIN.COM
                                        Server Name (Service and Instance): cifs/server.domain.com
                                            Name-type: Service and Instance (2)
                                            Name: cifs
                                            Name: server.domain.com
                                        enc-part rc4-hmac
                                            Encryption type: rc4-hmac (23)
                                            Kvno: 6
                                            enc-part: a5f5e1bc4c71e849631867c963ae2d8bb47019b9d6356465...
                                    Authenticator rc4-hmac
                                        Encryption type: rc4-hmac (23)
                                        Authenticator data: 58baab6ad896020f0da4f444f91278d6b49597cc33c05105...


    ========================================================================================
    RESPONSE FRAME: Response to WINDOWS 2008 SERVER's Request of 31 credits with 9 Credits
    ========================================================================================
                                        
    Frame 26: 312 bytes on wire (2496 bits), 312 bytes captured (2496 bits)
        Arrival Time: Mar 20, 2013 07:09:56.069858000 EDT
        Frame Length: 312 bytes (2496 bits)
        Capture Length: 312 bytes (2496 bits)

    Transmission Control Protocol, Src Port: microsoft-ds (445), Dst Port: 62214 (62214), Seq: 505, Ack: 11050, Len: 258

    NetBIOS Session Service
        Message Type: Session message (0x00)
        Length: 254
    SMB2 (Server Message Block Protocol version 2)
        SMB2 Header
            Server Component: SMB2
            Header Length: 64
            Credit Charge: 0
            NT Status: STATUS_SUCCESS (0x00000000)
            Command: SessionSetup (1)
            Credits granted: 9
            Flags: 0x00000009
                ...0 .... .... .... .... .... .... .... = DFS operation: This is a normal operation
                .... .... .... .... .... .... .... 1... = Signing: This pdu is SIGNED
                .... .... .... .... .... .... .... .0.. = Chained: This pdu is NOT a chained command
                .... .... .... .... .... .... .... ..0. = Async command: This is a SYNC command
                .... .... .... .... .... .... .... ...1 = Response: This is a RESPONSE
            Chain Offset: 0x00000000
            Command Sequence Number: 2
            Process Id: 0000feff
            Tree Id: 0x00000000
            Session Id: 0x000005c53000050d
            Signature: e8b7870cac11e37a9218d04c6f148abc
            [Response to: 23]
            [Time from request: 0.186808000 seconds]
        SessionSetup Response (0x01)
            Length: 8
            .... .... .... ...1 = Dynamic Part: True
            Session Flags: 0x0000
                .... .... .... ..0. = Null: False
                .... .... .... ...0 = Guest: False
            Security Blob: a181b33081b0a0030a0100a10b06092a864882f712010202...
                Offset: 0x00000048
                Length: 182
                GSS-API Generic Security Service Application Program Interface
                    Simple Protected Negotiation
                        negTokenTarg
                            negResult: accept-completed (0)
                            supportedMech: 1.2.840.48018.1.2.2 (MS KRB5 - Microsoft Kerberos 5)
                            responseToken: 60819506092a864886f71201020202006f8185308182a003...
                            krb5_blob: 60819506092a864886f71201020202006f8185308182a003...
                                KRB5 OID: 1.2.840.113554.1.2.2 (KRB5 - Kerberos 5)
                                krb5_tok_id: KRB5_AP_REP (0x0002)
                                Kerberos AP-REP
                                    Pvno: 5
                                    MSG Type: AP-REP (15)
                                    enc-part rc4-hmac
                                        Encryption type: rc4-hmac (23)
                                        enc-part: e7af023b0ee69cbad3b9f2908c7d73c7b52e8ca90eab71f4...

                                        
    ========================================================================================
    WINDOWS 2008 Server RESETS IMMEDIATELY
    ========================================================================================

    Frame 27: 60 bytes on wire (480 bits), 60 bytes captured (480 bits)
        Arrival Time: Mar 20, 2013 07:09:56.070871000 EDT

    Transmission Control Protocol, Src Port: 62214 (62214), Dst Port: microsoft-ds (445), Seq: 11050, Ack: 763, Len: 0
        Source port: 62214 (62214)
        Destination port: microsoft-ds (445)
        [Stream index: 0]
        Sequence number: 11050    (relative sequence number)
        Acknowledgement number: 763    (relative ack number)
        Header length: 20 bytes
        Flags: 0x14 (RST, ACK)
            000. .... .... = Reserved: Not set
            ...0 .... .... = Nonce: Not set
            .... 0... .... = Congestion Window Reduced (CWR): Not set
            .... .0.. .... = ECN-Echo: Not set
            .... ..0. .... = Urgent: Not set
            .... ...1 .... = Acknowledgement: Set
            .... .... 0... = Push: Not set
            .... .... .1.. = Reset: Set
                [Expert Info (Chat/Sequence): Connection reset (RST)]
            .... .... ..0. = Syn: Not set
            .... .... ...0 = Fin: Not set
    • Edited by 2cool2touch Thursday, March 21, 2013 6:23 PM
    Thursday, March 21, 2013 5:55 PM

Answers

  • After reviewing the private data, we have concluded that the issue was related to the packets being modified in route and the signature not being recalculated.

    SEBASTIAN CANEVARI - MSFT Escalation Engineer Protocol Documentation Team

    Tuesday, April 23, 2013 3:57 PM

All replies

  • Hi 2cool2touch,

    Thanks for your question.

    Someone from our team will get in touch with you shortly.

    Thanks and regards,


    SEBASTIAN CANEVARI - MSFT Escalation Engineer Protocol Documentation Team

    Friday, March 22, 2013 1:14 AM
  • Hi 2cool2touch,

    I'll be the one helping you with this request.

    As soon as I have news or questions I'll get back to you.

    Thanks!


    SEBASTIAN CANEVARI - MSFT Escalation Engineer Protocol Documentation Team

    Friday, March 22, 2013 4:15 PM
  • Thanks Sebastian. I will wait for your reply.

    One nugget that may help further is that if this behavior is different when the server is initiating the connection with the intent to connect to IPC$ share?

    As we can see in the traces I provided that the RST from the client (2k8 server) comes even before SMB2 TreeConnect happens, hence from the trace it is not known what share it was intending to connect to, however, internally, it of course knows why is it trying to open the connection (i.e. for IPC$ share).

    Friday, March 22, 2013 6:19 PM
  • Is there any update Sebastian. Been waiting. Thanks!
    Tuesday, March 26, 2013 2:10 PM
  • Hi 2cool2touch,

    I am still working on your response. I'll let you know as soon as I have an answer or some follow up questions.

    Thanks and regards,


    SEBASTIAN CANEVARI - MSFT Escalation Engineer Protocol Documentation Team

    Tuesday, March 26, 2013 2:51 PM
  • Hi Sebastian,

    Any updates?

    I was reading the MS-SMB2 Open Specifications Documentation and it mentioned:

    The client MUST NOT decrease its credits to zero, and SHOULD request a sufficient number of credits to support implementation-defined local requirements.

    Do you have a list of minimum credits needed to support Microsoft's implementation-defined local requirements. For ex, the connections going to IPC$ share must be granted X Credits or for doing AD related activities, Y credits must be granted, or else the connection should fail?

    Wednesday, April 3, 2013 12:08 PM
  • Hi 2cool2touch,

    I am still working on getting you the answer to this request.

    BTW, could you please send me a full trace to dochelp@microsoft.com ?

    Thanks and regards,

    Sebastian


    SEBASTIAN CANEVARI - MSFT Escalation Engineer Protocol Documentation Team

    Wednesday, April 3, 2013 4:40 PM
  • Hi 2cool2touch,

    I have not seen the network capture coming in through dochelp@microsoft.com. I would like to know if you will be able to send it to me. Even though I've tried to find a possible cause for the reset from the pieces of information that you have provided, it wasn't possible. Hence, the request.

     

    As per your question regarding the number of credits, I suggest you review the latest version of [MS-SMB2] at: http://msdn.microsoft.com/en-us/library/cc246805.aspx

    Specifically, sections:

    3.2.4.1.2 Requesting Credits from the Server

    3.2.4.1.5 Sending Multi-Credit Requests

    3.2.4.1.6 Algorithm for Handling Available Message Sequence Numbers by the Client

    3.2.5.1.4 Granting Message Credits

    3.3.1.1 Algorithm for Handling Available Message Sequence Numbers by the Server

    3.3.1.2 Algorithm for the Granting of Credits

    3.3.4.1.2 Granting Credits to the Client

    3.3.4.1.3 Sending Compounded Responses

    And all the pertaining Product Behavior notes from Section 6 - Appendix A.

    Section 4 will provide you with a couple examples that you may want to peek into.

    Oversimplifying the explanation, almost every message requires 1 credit except for cancels that require 0 and multicredit requests that are variable.

    Please let me know if you will be able to send me the capture.

    BTW, please do not apply any filters to it. Not capture nor display filters.

    Thanks and regards,


    SEBASTIAN CANEVARI - MSFT Escalation Engineer Protocol Documentation Team

    Thursday, April 4, 2013 10:24 PM
  • Thanks Sebo. Will be sending the trace shortly. Will look into the doc again. Have gone thru it before but may be i missed
    Friday, April 5, 2013 12:28 AM
  • Hi 2cool2touch,

    When you are able to send the network trace my way, I would like you to follow a specific procedure for which I need to send you a cmd file.

    Would you please send an email to dochelp@microsoft.com so I can reply to you with the file and the instructions?

    Thanks!

    Sebastian


    SEBASTIAN CANEVARI - MSFT Escalation Engineer Protocol Documentation Team


    Friday, April 5, 2013 9:05 PM
  • After reviewing the private data, we have concluded that the issue was related to the packets being modified in route and the signature not being recalculated.

    SEBASTIAN CANEVARI - MSFT Escalation Engineer Protocol Documentation Team

    Tuesday, April 23, 2013 3:57 PM