[Samba] Windows clients connecting to SMB share differently over IP than DNS
Gavin Greenwalt
im.thatoneguy at gmail.com
Thu Apr 1 17:25:51 UTC 2021
Yes the first Session Setup Request contains a krb5_blob (KRB5 OID:
1.2.840.113554.1.2.2 (KRB5 - Kerberos 5)). And if I filter down to just
those requests and responses there does appear to be 1s of latency per
request/response which would nearly perfectly match the performance
degradation I'm observing as a user.
8.87 2.2.2.2 1.1.1.1 SMB2 1940 Session Setup Request
9.67 1.1.1.1 2.2.2.2 SMB2 315 Session Setup Response
(~.8s)
19.47 2.2.2.2 1.1.1.1 SMB2 1940 Session Setup Request
20.37 1.1.1.1 2.2.2.2 SMB2 315 Session Setup Response
(.9s)
20.39 2.2.2.2 1.1.1.1 SMB2 1940 Session Setup Request
21.40 1.1.1.1 2.2.2.2 SMB2 315 Session Setup Response
(~1s)
21.43 2.2.2.2 1.1.1.1 SMB2 1940 Session Setup Request
22.40 1.1.1.1 2.2.2.2 SMB2 315 Session Setup Response
(~1s)
22.43 2.2.2.2 1.1.1.1 SMB2 1940 Session Setup Request
23.33 1.1.1.1 2.2.2.2 SMB2 315 Session Setup Response
(.9s)
Am I reading the flow correctly then:
client requests a krb5 authentication.
0.8s delay...
server responds with new krb5 session.
client attempts to use the krb5 session to "Tree Request" (reasons unknown,
it shouldn't need to)
Error: STATUS_ACCESS_DENIED
Client ends session
[File transfer then proceeds successfully in 0.1 seconds as normal
(although with far more transactions than the ?NTLMv2? flow)]
All of that seems completely superfluous which is extra strange. Because
jumping through the wireshark. Every file transfer used the Session
Id 0x00000000ed832df6 which must have been negotiated very early on before
I even started capturing. So it's presumably already authenticated? I
wonder why it's performing and failing (maybe from a slow krb5 timeout?)
the whole side show with the tree requests.
Thank you! That gives me something concrete to investigate further. Do you
think the Tree Connect flow is a red herring?
Gavin
(apologies for the double message Jeremy, didn't hit reply-all)
On Thu, Apr 1, 2021 at 9:50 AM Jeremy Allison <jra at samba.org> wrote:
> On Thu, Apr 01, 2021 at 09:44:40AM -0700, Gavin Greenwalt via samba wrote:
> >I have a CIFS share on a samba server ((Version 4.4.16)) joined as a
> member
> >to a Windows 2012 R2 AD domain. If I on a windows 10 machine mount the
> >share over IP address it takes about 14.5 minutes for 21,000 files to
> copy.
> >(which is in of itself slow but I believe due to a lack of official SMB3
> >multichannel support in Samba.) If I mount the share with the DNS name it
> >takes *205* minutes to copy the 21,000 files to copy. More than 10x
> >slower.
> >
> >Connecting to the IP address (e.g. \\1.1.1.1\share) the SMB transaction
> >goes as expected.
> >
> >5153 19.122016 2.2.2.2 1.1.1.1 Create Request File:
> >temp\Folder\1 - Copy (83).txt
> >
> >5154 19.122612 1.1.1.1 2.2.2.2 Create Response File:
> >temp\Folder\1 - Copy (83).txt
> >
> >5155 19.122716 2.2.2.2 1.1.1.1 SetInfo Request
> >FILE_INFO/SMB2_FILE_ENDOFFILE_INFO File: temp\Folder\1 - Copy (83).txt
> >
> >5156 19.122886 1.1.1.1 2.2.2.2 SetInfo Response
> >
> >5157 19.122951 2.2.2.2 1.1.1.1 Write Request Len:8888
> >Off:0 File: temp\Folder\1 - Copy (83).txt
> >
> >5159 19.123135 1.1.1.1 2.2.2.2 Write Response
> >
> >5160 19.123165 2.2.2.2 1.1.1.1 SetInfo Request
> >FILE_INFO/SMB2_FILE_BASIC_INFO File: temp\Folder\1 - Copy (83).txt
> >
> >5161 19.123308 1.1.1.1 2.2.2.2 SetInfo Response
> >
> >5162 19.123338 2.2.2.2 1.1.1.1 GetInfo Request
> >FILE_INFO/SMB2_FILE_NETWORK_OPEN_INFO File: temp\Folder\1 - Copy (83).txt
> >
> >5163 19.123420 1.1.1.1 2.2.2.2 GetInfo Response
> >
> >5164 19.123541 2.2.2.2 1.1.1.1 GetInfo Request
> >FILE_INFO/SMB2_FILE_NETWORK_OPEN_INFO File: temp\Folder\1 - Copy (83).txt
> >
> >5165 19.123616 1.1.1.1 2.2.2.2 GetInfo Response
> >
> >5166 19.123666 2.2.2.2 1.1.1.1 GetInfo Request
> >SEC_INFO/SMB2_SEC_INFO_00 File: temp\Folder\1 - Copy (83).txt
> >
> >5167 19.127104 1.1.1.1 2.2.2.2 GetInfo Response,
> >Error: STATUS_BUFFER_TOO_SMALL
> >
> >5168 19.127171 2.2.2.2 1.1.1.1 GetInfo Request
> >SEC_INFO/SMB2_SEC_INFO_00 File: temp\Folder\1 - Copy (83).txt
> >
> >5169 19.130321 1.1.1.1 2.2.2.2 GetInfo Response
> >
> >5170 19.130584 2.2.2.2 1.1.1.1 Close Request File:
> >temp\Folder\1 - Copy (83).txt
> >
> >5171 19.130800 1.1.1.1 2.2.2.2 Close Response
> >
> >
> >
> >Over DNS (e.g. \\server\share) things screech to a halt and follow a
> >completely different transaction loop involving a tree connect request
> over
> >every single file. This slows things down to about 1 file/second.
> >
> >
> >
> >4365 9.064473 2.2.2.2 1.1.1.1 Session Setup Request
> >
> >4367 9.067749 2.2.2.2 1.1.1.1 Create Request File:
> >temp\Folder\1 - Copy (83).txt
> >
> >4749 10.061721 2.2.2.2 1.1.1.1 Create Request File:
> >temp\Folder
> >
> >4755 10.068555 1.1.1.1 2.2.2.2 Session Setup Response
> >
> >4756 10.068922 2.2.2.2 1.1.1.1 Tree Connect Request
> >Tree: \\Synology\Share
> >
> >4757 10.069262 1.1.1.1 2.2.2.2 Create Response File:
> >temp\Folder\1 - Copy (83).txt
> >
> >4758 10.069483 2.2.2.2 1.1.1.1 SetInfo Request
> >FILE_INFO/SMB2_FILE_ENDOFFILE_INFO File: temp\Folder\1 - Copy (83).txt
> >
> >4759 10.069613 1.1.1.1 2.2.2.2 Create Response File:
> >temp\Folder
> >
> >4760 10.069729 2.2.2.2 1.1.1.1 Find Request File:
> >temp\Folder SMB2_FIND_ID_BOTH_DIRECTORY_INFO Pattern: *;Find Request File:
> >temp\Folder SMB2_FIND_ID_BOTH_DIRECTORY_INFO Pattern: *
> >
> >4762 10.074482 1.1.1.1 2.2.2.2 Tree Connect Response,
> >Error: STATUS_ACCESS_DENIED
> >
> >4763 10.074550 2.2.2.2 1.1.1.1 Session Logoff Request
> >
> >4764 10.074688 1.1.1.1 2.2.2.2 SetInfo Response
> >
> >4765 10.074810 2.2.2.2 1.1.1.1 Write Request Len:8888
> >Off:0 File: temp\Folder\1 - Copy (83).txt
> >
> >4767 10.077222 1.1.1.1 2.2.2.2 Response;Find
> Response,
> >Error: STATUS_NO_MORE_FILES
> >
> >4769 10.077405 1.1.1.1 2.2.2.2 Session Logoff
> Response
> >
> >4770 10.077448 2.2.2.2 1.1.1.1 Close Request File:
> >temp\Folder
> >
> >4771 10.077535 1.1.1.1 2.2.2.2 Write Response
> >
> >4772 10.077630 1.1.1.1 2.2.2.2 Close Response
> >
> >4774 10.077712 2.2.2.2 1.1.1.1 SetInfo Request
> >FILE_INFO/SMB2_FILE_BASIC_INFO File: temp\Folder\1 - Copy (83).txt
> >
> >4775 10.077872 2.2.2.2 1.1.1.1 Create Request File:
> >temp\Folder
> >
> >4776 10.078096 1.1.1.1 2.2.2.2 SetInfo Response
> >
> >4777 10.078166 2.2.2.2 1.1.1.1 GetInfo Request
> >FILE_INFO/SMB2_FILE_NETWORK_OPEN_INFO File: temp\Folder\1 - Copy (83).txt
> >
> >4778 10.078337 1.1.1.1 2.2.2.2 Create Response File:
> >temp\Folder
> >
> >4779 10.078378 1.1.1.1 2.2.2.2 GetInfo Response
> >
> >4781 10.078430 2.2.2.2 1.1.1.1 Close Request File:
> >temp\Folder
> >
> >4782 10.078550 1.1.1.1 2.2.2.2 Close Response
> >
> >4783 10.078648 2.2.2.2 1.1.1.1 GetInfo Request
> >FILE_INFO/SMB2_FILE_NETWORK_OPEN_INFO File: temp\Folder\1 - Copy (83).txt
> >
> >4784 10.078670 2.2.2.2 1.1.1.1 Create Request File:
> >temp
> >
> >4785 10.078748 1.1.1.1 2.2.2.2 GetInfo Response
> >
> >4786 10.078821 2.2.2.2 1.1.1.1 GetInfo Request
> >SEC_INFO/SMB2_SEC_INFO_00 File: temp\Folder\1 - Copy (83).txt
> >
> >4787 10.078897 1.1.1.1 2.2.2.2 Create Response File:
> >temp
> >
> >4788 10.078998 2.2.2.2 1.1.1.1 Close Request File:
> temp
> >
> >4789 10.083060 1.1.1.1 2.2.2.2 GetInfo Response,
> >Error: STATUS_BUFFER_TOO_SMALL
> >
> >4790 10.083148 1.1.1.1 2.2.2.2 Close Response
> >
> >4791 10.083155 2.2.2.2 1.1.1.1 GetInfo Request
> >SEC_INFO/SMB2_SEC_INFO_00 File: temp\Folder\1 - Copy (83).txt
> >
> >4792 10.083252 2.2.2.2 1.1.1.1 Create Request File:
> >
> >4793 10.087615 1.1.1.1 2.2.2.2 GetInfo Response
> >
> >4794 10.087860 1.1.1.1 2.2.2.2 Create Response File:
> >
> >4796 10.087948 2.2.2.2 1.1.1.1 Find Request File:
> >SMB2_FIND_ID_BOTH_DIRECTORY_INFO Pattern: *;Find Request File:
> >SMB2_FIND_ID_BOTH_DIRECTORY_INFO Pattern: *
> >
> >4797 10.088101 2.2.2.2 1.1.1.1 Close Request File:
> >temp\Folder\1 - Copy (83).txt
> >
> >4798 10.089075 1.1.1.1 2.2.2.2 Find Response;Find
> >Response, Error: STATUS_NO_MORE_FILES
> >
> >4800 10.089169 2.2.2.2 1.1.1.1 Close Request File:
> >
> >4801 10.089291 1.1.1.1 2.2.2.2 Close Response
> >
> >4802 10.089375 1.1.1.1 2.2.2.2 Close Response
> >
> >
> >
> >The initial delay seems to be somewhat random. E.g. but consistenly around
> >1second per file for the negotiation.
> >
> >11686 28.24ms 2.2.2.2 1.1.1.1 Session Setup Request
> >
> >11688 28.24ms 2.2.2.2 1.1.1.1 Create Request File:
> >temp\Folder\1 - Copy (114).txt
> >
> >11997 28.74ms 2.2.2.2 1.1.1.1 Create Request File:
> >temp\Folder\Files
> >
> >12079 28.99ms 1.1.1.1 2.2.2.2 Session Setup Response
> >
> >12080 28.99ms 2.2.2.2 1.1.1.1 Tree Connect Request
> >Tree: \\Synology\Share
> >
> >Do windows clients connect to \\path\shares differently from
> >\\ip.ad.d.ress\paths? I’m kind of stuck trying to think of what else to
> >test to make progress on why the server is so much slower on Windows 10
> >clients when mapped over DNS name. Windows reports the smb connection as
> >a 3.1.1 dialect for both \\ip and \\dns.
> >
> >The only intriguing thing I can note is that Windows connects to the \\ip
> >address as domain\user for credentials. However no matter what I do it
> >connects as domain*.com*\user for named server connections (both Windows
> >and Linux\samba). For comparison a Windows 2012R2 file server and a
> >Windows 10 desktop client follow the correct (fast\streamlined) SMB
> >transaction with both DNS and IP Address. So it seems to be limited to
> the
> >Samba share.
>
> That's... really bizarre. The only difference between IP address
> and dns name should be in the auth used. For IP it's going to
> be NTLMv2, for DNS it could be krb5.
>
More information about the samba
mailing list