SMB traffic analysis in Wireshark can feel like trying to read a conversation in a language you only half-understand, especially when you’re debugging file share issues.

The most surprising thing about Wireshark SMB analysis is how much of the "magic" of file sharing is actually just a very verbose, stateful negotiation between client and server.

Let’s watch a file open request and its response.

Frame 10: SMB2 Negotiate Protocol Request
    ...
    Security Mode: 0x03 (SMB2_NEGOTIATE_SIGNING_ENABLED|SMB2_NEGOTIATE_SIGNING_REQUIRED)
    ...

Frame 11: SMB2 Negotiate Protocol Response
    ...
    Dialect: 2.1 (0x0202)
    ...

Frame 12: SMB2 Session Setup Request
    ...
    Flags: 0x01 (SMB2_SESSION_FLAG_IS_GUEST)
    ...

Frame 13: SMB2 Session Setup Response
    ...
    Status: Success (0x00000000)
    ...

Frame 14: SMB2 Tree Connect Request
    Path: \\MYSERVER\SHARE
    ...

Frame 15: SMB2 Tree Connect Response
    Tree ID: 0x0001
    Status: Success (0x00000000)
    ...

Frame 16: SMB2 Create Request
    File: README.txt
    ...
    Create Flags: 0x00 (None)
    Desired Access: Read, Write, Execute, Delete, Read Control, Write DAC, Write Owner (0x12019f)
    ...

Frame 17: SMB2 Create Response
    File ID: 0x0001
    Status: Success (0x00000000)
    ...

Frame 18: SMB2 Read Request
    File ID: 0x0001
    Offset: 0
    Length: 65536
    ...

Frame 19: SMB2 Read Response
    ...
    Data: (65536 bytes)
    ...

This is the core loop: negotiate, set up a session, connect to a share, create/open a file, and then read/write to it. Each step is a distinct SMB2 request and response.

The problem SMB solves is providing a consistent, reliable way for different operating systems to access files over a network, abstracting away the underlying network transport. It’s a complex protocol with many layers and states.

Internally, SMB uses a "dialect" negotiation to determine the highest common version of the protocol supported by both client and server. SMB1 is old and insecure; SMB2 (versions 2.0, 2.1, 3.0, 3.02, 3.1.1) is the modern standard. Session setup establishes authenticated context, and tree connect mounts a specific share. File operations like Create, Read, Write, and Close are then performed on a file handle obtained during the Create request.

The commands you’ll see most often are:

  • Negotiate Protocol: Client and server agree on SMB version and capabilities.
  • Session Setup: Authentication.
  • Tree Connect: Accessing a specific share (e.g., \\server\share).
  • Create: Opening or creating a file.
  • Read/Write: Transferring data.
  • Close: Releasing file handles.
  • Query Directory: Listing files in a folder.
  • Delete: Removing a file.

When debugging, you’re looking for non-zero status codes in the response packets. A STATUS_OBJECT_NAME_NOT_FOUND (0xC0000023) means the file or path doesn’t exist. STATUS_ACCESS_DENIED (0xC000006D) indicates permission issues. STATUS_CONNECTION_REFUSED or STATUS_NETWORK_UNREACHABLE point to network connectivity problems before SMB even gets a chance.

To filter for SMB traffic in Wireshark, use smb2. If you’re seeing authentication issues, filter for smb2.ntstatus == 0xc000006d. For missing files, smb2.ntstatus == 0xc0000023.

The most common cause of slow file transfers isn’t network bandwidth, but rather the chatty nature of SMB and TCP acknowledgments. Each read or write request needs to be acknowledged, and if there’s any latency, these acknowledgments can cause significant delays, especially with many small I/O operations. This is why SMB has features like multichannel and large MTU support in SMB 3.x to reduce this overhead.

If you’re troubleshooting a file share that suddenly becomes inaccessible, and you see STATUS_CONNECTION_REFUSED in the SMB2 Session Setup Response (or even earlier in the TCP handshake), the first thing to check is the firewall on the server side. Specifically, ensure that TCP port 445 is open for inbound traffic. Many security policies inadvertently block this essential port, preventing clients from establishing SMB connections. The fix is to add a firewall rule allowing inbound TCP traffic on port 445 from your client IP addresses or subnet. This works because SMB relies on TCP port 445 for its primary communication channel. Without it, the server simply refuses the connection attempt before any SMB negotiation can begin.

The next error you’ll encounter after fixing connectivity is likely related to authentication or permissions.

Want structured learning?

Take the full Wireshark course →