SMB and the Red Herring

SMB and the Red Herring

  • Comments 3
  • Likes

Sometimes when reviewing network captures, there are messages in the trace that seem to be indicative of the issue, but once you dig deeper, you realize that they are informational, not a sign of the problem. This article is being written so you can understand one SMB message better and not get concerned if you see it in a trace. The message we are going to discuss is the scary-sounding STATUS_BUFFER_TOO_SMALL.

Scenario

So imagine that you’re finding that when you are transferring data to a server, you have a slow-down or a disconnect. Your first troubleshooting steps should be to take a network capture. You start pouring through the capture when the words jump out at you – “STATUS_BUFFER_TOO_SMALL”. “Aha!” you think, but if you understand the significance of the message, you will soon realize that you need to look elsewhere for the root of the problem.

The Clues

In the trace, the frame will look something like this, which is an NT Transaction Response:

 

0.000208    192.168.1.11    192.168.1.10    SMB    SMB:R; Nt Transact, NT Query Security Description, FID = 0x4019 
- NT Status: System - Error, Code = (35) STATUS_BUFFER_TOO_SMALL

In a trace, you can find these with Network Monitor filter SMB.NTStatus.Code == 0x23. In the above frame, the message is being sent from the server to the client. You might think this means that the server’s buffer is getting too small, but that actually isn’t the case. The message is the server telling the client that the client’s buffer is too small. You will understand this better if we dig into the NT Transact sent to the server before the message appears:

 

0.000000    192.168.1.10    192.168.1.11    SMB    SMB:C; 
Nt Transact, NT Query Security Description, FID = 0x4019
Frame: Number = 1, Captured Frame Length = 142, MediaType = ETHERNET 
+ Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-17-94-4B-AC-43],SourceAddress:[00-21-70-77-95-BC]
+ Ipv4: Src = 192.168.1.10, Dest = 192.168.1.11, Next Protocol = TCP, Packet ID = 6396, Total IP Length = 128
+ Tcp: Flags=...AP..., SrcPort=L2TP(1701), DstPort=Microsoft-DS(445), PayloadLen=88, Seq=1366185756 - 1366185844, Ack=426719751, Win=64173
- Nbtss: SESSION MESSAGE, Length =84
    PacketType: SESSION MESSAGE, 0(0x00)
  + Flags: Add 0 to Length
    Length: 84(0x54)
- Smb: C; Nt Transact, NT Query Security Description, FID = 0x4019
    Protocol: SMB
    Command: Nt Transact 160(0xA0)
  + NTStatus: 0x0, Facility = FACILITY_SYSTEM, Severity = STATUS_SEVERITY_SUCCESS, Code = (0) STATUS_SUCCESS
  + SMBHeader: Command, TID: 0x5804, PID: 0x0AB0, UID: 0x9002, MID: 0x3A80
  - CNTTransaction: 
     WordCount: 19 (0x13)
     MaxSetupCount: 0 (0x0)
     Reserved: 0 (0x0)
     TotalParameterCount: 8 (0x8)
     TotalDataCount: 0 (0x0)
     MaxParameterCount: 4 (0x4)
     MaxDataCount: 0 (0x0)
     ParameterCount: 8 (0x8)
     ParameterOffset: 76 (0x4C)
     DataCount: 0 (0x0)
     DataOffset: 0 (0x0)
     SetupCount: 0 (0x0)
     Function: NT Query Security Description
     ByteCount: 11 (0xB)
     Pad1: Binary Large Object (3 Bytes)
   + NTQuerySecurityDescParameterBlock:

What you should notice is that within the NT Transact message, the MaxDataCount sent by the client to the server is “0.” This is the size of the buffer currently allocated by the client for the Security Descriptor data. If we then dig into the STATUS_BUFFER_TOO_SMALL message (the response from the server), we see this:

 

Frame: Number = 2, Captured Frame Length = 134, MediaType = ETHERNET 
Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-21-70-77-95-BC],SourceAddress:[00-17-94-4B-AC-43]
Ipv4: Src = 192.168.1.11, Dest = 192.168.1.10, Next Protocol = TCP, Packet ID = 18417, Total IP Length = 120
Tcp: Flags=...AP..., SrcPort=Microsoft-DS(445), DstPort=L2TP(1701), PayloadLen=80, Seq=426719751 - 426719831, Ack=1366185844, Win=65535
Nbtss: SESSION MESSAGE, Length =76
  PacketType: SESSION MESSAGE, 0(0x00)
+ Flags: Add 0 to Length
  Length: 76(0x4C)
Smb: R; Nt Transact, NT Query Security Description, FID = 0x4019 - NT Status: System - Error, Code = (35) STATUS_BUFFER_TOO_SMALL
  Protocol: SMB
  Command: Nt Transact 160(0xA0)
+ NTStatus: 0xC0000023, Facility = FACILITY_SYSTEM, Severity = STATUS_SEVERITY_ERROR, Code = (35) STATUS_BUFFER_TOO_SMALL
+ SMBHeader: Response, TID: 0x5804, PID: 0x0AB0, UID: 0x9002, MID: 0x3A80
- RNTTransaction: 
   WordCount: 18 (0x12)
   Reserved: 0 (0x0)
   TotalParameterCount: 4 (0x4)
   TotalDataCount: 0 (0x0)
   ParameterCount: 4 (0x4)
   ParameterOffset: 72 (0x48)
   ParamDisplacement: 0 (0x0)
   DataCount: 0 (0x0)
   DataOffset: 76 (0x4C)
   DataDisplacement: 0 (0x0)
   SetupCount: 0 (0x0)
   ByteCount: 5 (0x5)
   Pad1: Binary Large Object (1 Bytes)
 - QuerySecDescParameterBlock: 
    SecurityDescriptorLength: 104 (0x68)

You should notice that in the server’s response, it’s telling the client that the Security Descriptor Length, which is the information the client requested, is 104 bytes in length. Obviously “0” isn’t big enough so the server is just informing the client what the size needs to be. The client then sends a new NT Query for the Security Descriptor:

 

Frame: Number = 3, Captured Frame Length = 142, MediaType = ETHERNET 
+ Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-17-94-4B-AC-43],SourceAddress:[00-21-70-77-95-BC]
+ Ipv4: Src = 192.168.1.10, Dest = 192.168.1.11, Next Protocol = TCP, Packet ID = 6397, Total IP Length = 128
+ Tcp: Flags=...AP..., SrcPort=L2TP(1701), DstPort=Microsoft-DS(445), PayloadLen=88, Seq=1366185844 - 1366185932, Ack=426719831, Win=64093
- Nbtss: SESSION MESSAGE, Length =84
    PacketType: SESSION MESSAGE, 0(0x00)
  + Flags: Add 0 to Length
    Length: 84(0x54)
- Smb: C; Nt Transact, NT Query Security Description, FID = 0x4019
    Protocol: SMB
    Command: Nt Transact 160(0xA0)
  + NTStatus: 0x0, Facility = FACILITY_SYSTEM, Severity = STATUS_SEVERITY_SUCCESS, Code = (0) STATUS_SUCCESS
  + SMBHeader: Command, TID: 0x5804, PID: 0x0AB0, UID: 0x9002, MID: 0x3AC0
  - CNTTransaction: 
     WordCount: 19 (0x13)
     MaxSetupCount: 0 (0x0)
     Reserved: 0 (0x0)
     TotalParameterCount: 8 (0x8)
     TotalDataCount: 0 (0x0)
     MaxParameterCount: 4 (0x4)
     MaxDataCount: 104 (0x68)
     ParameterCount: 8 (0x8)
     ParameterOffset: 76 (0x4C)
     DataCount: 0 (0x0)
     DataOffset: 0 (0x0)
     SetupCount: 0 (0x0)
     Function: NT Query Security Description
     ByteCount: 11 (0xB)
     Pad1: Binary Large Object (3 Bytes)
   + NTQuerySecurityDescParameterBlock:

Notice that the new client request has the MaxDataCount set to the value it received from the server – 104 bytes. With the buffer sized appropriately, the server then sends the data:

 

Frame: Number = 4, Captured Frame Length = 238, MediaType = ETHERNET 
Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-21-70-77-95-BC],SourceAddress:[00-17-94-4B-AC-43]
Ipv4: Src = 10.33.10.22, Dest = 10.33.31.167, Next Protocol = TCP, Packet ID = 18420, Total IP Length = 224
Tcp: Flags=...AP..., SrcPort=Microsoft-DS(445), DstPort=L2TP(1701), PayloadLen=184, Seq=426719831 - 426720015, Ack=1366185932, Win=65447
Nbtss: SESSION MESSAGE, Length =180
Smb: R; Nt Transact, NT Query Security Description, FID = 0x4019
  Protocol: SMB
  Command: Nt Transact 160(0xA0)
+ NTStatus: 0x0, Facility = FACILITY_SYSTEM, Severity = STATUS_SEVERITY_SUCCESS, Code = (0) STATUS_SUCCESS
+ SMBHeader: Response, TID: 0x5804, PID: 0x0AB0, UID: 0x9002, MID: 0x3AC0
- RNTTransaction: 
   WordCount: 18 (0x12)
   Reserved: 0 (0x0)
   TotalParameterCount: 4 (0x4)
   TotalDataCount: 104 (0x68)
   ParameterCount: 4 (0x4)
   ParameterOffset: 72 (0x48)
   ParamDisplacement: 0 (0x0)
   DataCount: 104 (0x68)
   DataOffset: 76 (0x4C)
   DataDisplacement: 0 (0x0)
   SetupCount: 0 (0x0)
   ByteCount: 109 (0x6D)
   Pad1: Binary Large Object (1 Bytes)
 - QuerySecDescParameterBlock: 
    SecurityDescriptorLength: 104 (0x68)
 - SecurityDescriptor: OwnerSID: S-1-5-21-1697806599-1153585985-1472874943-33115 Unknown SID GroupSID: S-1-5-21-1697806599-1153585985-1472874943-513 Domain Users -- A global group that, by default, includes all user accounts in a domain. When you create a user a
    Revision: 1 (0x1)
    Sbz1: 0 (0x0)
  + SecurityDescriptorControl: 0x8004
    OffsetToOwnerSID: 20 (0x14) Offset: 0x9A
    OffsetToGroupSID: 48 (0x30) Offset: 0xB6
    OffsetToSacl: 0 (0x0) 
    OffsetToDacl: 76 (0x4C) Offset: 0xD2
  + OwnerSid: S-1-5-21-1697806599-1153585985-1472874943-33115 Unknown SID
  + GroupSid: S-1-5-21-1697806599-1153585985-1472874943-513 Domain Users -- A global group that, by default, includes all user accounts in a domain. When you create a user account in a domain, it is added to this group by default
  + Dacl: ACE Entries: 1

If you look at the time offset in a trace, you should see that the time from the initial request to the successful response takes almost no time at all and does not result in any problems. In fact, because this is happening at the SMB layer, TCP is not aware of the above transaction (study that OSI model again for additional information).

Conclusion

While Network Monitor can provide a wealth of information, sometimes the data you get may take you down the wrong path. Once you understand how SMB works, you can see how the information flows between the client and the server.

A list of SMB message codes can be found at http://msdn.microsoft.com/en-us/library/cc212457(PROT.10).aspx.

The latest version of Network Monitor is 3.2 and can be found at http://www.microsoft.com/downloads/details.aspx?FamilyID=f4db40af-1e08-4a21-a26b-ec2f4dc4190d&DisplayLang=en.

Thanks and happy hunting!

- Michael Rendino

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • 203 Microsoft Team blogs searched, 88 blogs have new articles in the past 7 days. 199 new articles found

  • hi michael,

    i have a question, what happens when there is a pipe communication from your example ?

    AFAIK, maxdatacount is the number of byte client reads from the pipe , in this case how does client determine the data to be read ?

  • Most SMB packet traces are riddled with this and other informational messages.  I think the better question here is "why design the protocol to add this needless back-and-forth in the first place?"  

    SMB is notorious for its intolerance for latency because of poor programming decisions like this.  At least make an attempt to set a maxdatacount that might work the first time.