I am hoping someone can provide some insight into approaching SMB troubleshooting via wireshark. I have two offices connected by a managed MPLS connection. Office A, Chicago, maintains a windows file server. Office B, Miami, has several Mac users who complain that file transfers are exceedingly slow, especially in directories with many (e.g. hundreds of files). A capture done from one of the Mac users workstations produces a lot of possible clues when I filter with smb.nt_status > 0 or smb2.nt_status > 0 I've been asked to determine the problem, or at least, show that it is NOT a network problem. It may also be helpful to know that there are no significant error count on any router or switch port involved, and MPLS circuit utilization is less than 10%. I am reasonably sure the relevant firewalls are not affecting traffic either, as PC users from Office B do not experience this problem when accessing the same files on the same file server. I am prevented by company policy from posting an actual capture, but here's a very typical screenshot.
Researching these status codes leads me down various rabbit holes related to either Mac OS' implementation of SMB and various similar sounding, but not exact, error codes on a Microsoft Dev FAQ. Any other information I could glean from these captures to help me understand what's happening here? asked 12 Aug '15, 09:58  stegad edited 12 Aug '15, 13:29 showing 5 of 7 show 2 more comments |
This is a static archive of our old Q&A Site.
Please post any new questions and answers at ask.wireshark.org.
What MacOS 10.x.y are they using?
OSX 10.10 I believe.
I know the conversation is happening over SMBv1 (right?) because the protocol column specifically identifies v2 when used. So I know that's part of the issue, perhaps the entire issue. But what of those error messages?
I am not sure, but could that be part of your problem? Here is a link where they talk about SMBv1 and SMBv2 problems between Windows and MacOS. http://cammodude.blogspot.com.au/2013/10/os-x-109-mavericks-workaround-for-smb.html
Thank you, but I don't think so. From my screenshot, you can see that the conversation is already happening over SMBv1... I think. And if so, that's probably part of the problem due to the application block size issue.
I don't know how to interpret the SMB errors being reported. I suspect some of them are probably normal, but I don't know for sure.
Then here is at least a hint to the Create AndX Request: https://ask.wireshark.org/questions/37818/smb-troubleshooting-status_lock_not_granted?page=1&focusedAnswerId=37846#37846
Here are some usefull inside the answer: https://ask.wireshark.org/questions/35541/smb2-successful-create-of-a-blank-file?page=1&focusedAnswerId=35595#35595
More I can´t read out of your half screenshot.
Is that a filtered capture? If so, try filtering, instead, with "smb.cmd == 0xa2", to find the NT Create andX requests and responses, and see what files it's trying to create/open with the failing requests.