Initial delay when browsing SMB share from Windows

Question

We have a NAS (Synology, running DSM 6) which is connected to our Active Directory on a Windows 2016 server. The NAS has 7 shared folders which are shared using SMB2.
When browsing to the NAS using Windows Explorer (tested on both Windows 7 and Windows server 2016) there is a delay for about 10 seconds before the shared folders are shown. It doesn't matter whether we use the name of the NAS (\\my-nas) or its IP-address (\\10.x.x.x).
While continously navigating the folders there is no delay.

Any ideas on why this is happening and how to fix it?

Update
I ran Wireshark and then started Windows Explorer. This is what the output looks like (I have filtered to just show my IP and the NAS's IP):

As you can see by the red rectangle there is about 8 seconds with total inactivity. This is after "Session Setup Request" is sent from the client (10.0.107.100) to the NAS (10.0.107.99), and before an answer, "Session Setup Response", is received.

Update 2
Did a new Wireshark session, in response to Michal Sokolowski's comment, and this time also included the traffic for our domain server (10.0.0.98). Now some UDP traffic on port 53 (shown as "DSN" protocol) and on port 137 (shown as "NBNS" protocol) is visible:

Update 3
I installed Wireshark on the domain server (10.0.0.98) to see the entire communication with the NAS:
(The image shows just an excerpt: Full Wireshark log for 'Update 3')
The line selected in the image, number 402, is just before a 3 second delay. This happens once more later on with the exact same messages.
Is it possible to say something more given this information?

Solution 1

By using tcpdump on the NAS I found out that the domain server returned two IP-addresses to the NAS when it did a DNS query. The domain server only has one physical network interface, which is the "correct" one. The other one is a virtual interface that VirtualBox has created. I followed this guide at MSDN and unchecked "Register this connections Address in DNS". That took the connection time from about 10 seconds to 3 seconds.

Looking at the tcpdump now there is one place where there seems to be no activity, between no. 14 and 15: But I guess that the NAS is working with something internally?

Ideally it would be nice if it could go even faster.

Thanks for all comments.

Update
I received a confirmation from Synology support that a 3 second delay is to expect from a low-end NAS (DS214se).

Solution 2

It looks like a delay when you try to expand the name. I have two options, both can be checked using wireshark or similar tool:

1. NAS does not accept the connection to the 445-th port, and before the opening of the connection to the 139-th Windows trying to expand the host name through WINS, which not present.
2. In NAS configured log file naming with name of connected host. In Samba there is possible only through the acceptance of connections on the 139th port and with running WINS.

WINS queries you can hear with the help of wireshark or similar tool.

UPD. As i see you have name rezolution troubles on NAS:

1. Client request session setup (packet #45 in your capture)
2. Server try resolv client name: I think, the server first tries to use DNS and hosts file and we do not see.
3. Then, the server attempts to find a WINS server (Typically, this configuration in an attempt to last) and we see broadcast packet #75
4. After the failure of the server still opens session (packet #78)

It is typical problem.

Comments

[Michal Sokolowski]

Trace is almost useless, please include ports 53,137-139/UDP.

[Björn]

@MichalSokolowski I changed the filter to include our domain server in Wireshark and uploaded a new screenshot.

[joeqwerty]

It looks like the NAS is issuing several LDAP search queries to the DC (authenticating the user that's trying to connect to the share on the NAS) and the DC is responding pretty quickly, but then the NAS just sits there for 3 or so seconds. So maybe there's something amiss in the configuration of the NAS? How do you have Domain/LDAP configured in the NAS? Is the NAS using your DC for DNS?

[Michal Sokolowski]

@joeqwerty, Samba does that, it can query LDAP server multiple times, before waiting for an answer for 1st query. Björn: Is initial directory has many elements? Can you post Samba configuration from NAS? (running testparm on it would be ideal)

[Björn]

Thanks for your suggestion. I ran Wireshark and have updated the question with the result. From what I understand port 445 is OK. (We donät have a WINS server in our domain.) Does this make any sense to you?

[Slipeer]

@Björn Sorry, I do not see the image attachments - imgur blocked.

[Björn]

I uploaded the image to snag.gy: snag.gy/Eir1Ly.jpg Does that work?

[joeqwerty]

1. You can clearly see the DNS query and positive response. 2. You can clealry see the TCP sessions established immediately after the DNS query/response. 3. You can clearly see the client and the NAS are communicating via SMB-Direct (port 445). 4. The NetBIOS name query occurs after the successful TCP session establishment. Additionally, without seeing what name the NetBIOS name query is for it's impossible to know if it's related BUT it isn't likely related because we've already seen the successful DNS query/response and the successful TCP session establishment.

[joeqwerty]

5. All that being said, this problem has nothing to do with DNS, WINS or NetBIOS. The client is successfully resolving the name of the NAS via DNS and it is successfully establishing a TCP session via port 445. The problem is that the SMB session setup response from the NAS to the client is delayed. That delay is most likely occurring on the NAS itself. To reiterate: We see a successful DNS query/response. We see successful TCP session establishment. We see successful SMB dialect negotiation. We see a delay in the actual SMB session setup.

[Slipeer]

@joeqwerty re-read my answer: the server has name rezolution problem and therefore delays the establishment of the session. Packets #33 and #34 - its server's name resolution by client.

[joeqwerty]

Packets 33 and 34 show successful DNS name resolution in less than a millisecond. How is that the problem? Additionally, you can see the delay is in the SMB session setup at packets 45 and 75. The DNS name resolution has occurred successfully (packets 33 and 34) and the TCP session has been established (packets 37, 38 and 39). The SMB dialect has been successfully negotiated (packets 40 and 43). The part that is being delayed is the actual SMB session setup/creation. That's where the problem lies.

[Slipeer]

@joeqwerty DNS query in packet #33 sent by the client. I'm talking about the name problems at server side. At SMB session setup server try to resolve client name too.

[joeqwerty]

OK, I see what you're referring to, but that gives me 2 questions: 1. Why would the NAS need to resolve the name of the client? That makes no sense and is not how network communications work. A file server doesn't need to resolve my client name for me to make a connection to it. My client needs to resolve the file server name and then establishes a connection. We see that happening here successfully. 2. Why would this be happening AFTER the successful TCP establishment and SMB dialect negotiation?

[joeqwerty]

Also, without knowing the actual name that the NAS is trying to resolve it's impossible to know if it's related. There's no reason that the NAS would need to resolve the name of the client.

[marctxk]

From the client perspective the problem is with the NAS as joeqwerty says. Therefore either the NAS gets a slow or no response from a service that it depends on (whether or not it really needs that service), or it's slow internally. A capture of NAS traffic will tell you which of those is true so you need to capture all traffic at the NAS.

[Björn]

@joeqwerty, Slipeer and marctxk: I installed Wireshark at the domain server and captured the traffic between the server and the NAS (the domain server is also the client running Windows Explorer) to get some more information. All ideas are appreciated.

[marctxk]

@Björn, capture at the NAS, otherwise you can never be sure who it might be trying to talk to. You need to be sure that it's not waiting for something else. If it is then you may be able to configure it out.

[marctxk]

that trace shows the AD responding quickly to all queries at least 4 out of the 4.2 secs shown is accounted for by the NAS sitting around picking its nose.

[Slipeer]

@Björn, What's a domain with NetBIOS name "CC"? Why are NAS trying to find it? This domain exists? This NetBIOS domain is present in the NetBIOS queries and LDAP Ping...

[Björn]

@Slipeer "CC" is the (correct) NetBIOS name of our domain.

[joeqwerty]

Again, the delay seems to be with the LDAP queries from the NAS to the DC. It may be that there's nothing you can do about it, but I would double check the Domain/LDAP configuration and the DNS configuration on the NAS.