SMB: Name vs IP speed difference copying files Windows???

[Phone Guy]

I am no network engineer, so I dont know if this is normal or not, but this is absolutely repeatable for me give or take a few mbs/sec...
I am getting different speeds copying files over the network on my Windows machines to my Nas. If I use \\IP\folder its a faster transfer by about double! vs \\syno\folder

Scenario 1:
In windows, open network, open icon for SYNONAS, open temp shared folder, now drag and drop 1.1gb file.. I get a maximum transfer of 60mb/sec (\\synonas\temp)

Scenario 2:
Change location in windows explorer to direct ip (\\192.168.1.100\temp) I get 110mb/sec.

So if the window shows a direct ip in the location, the speed is nearly doubled. If it show synonas its about half speed...? any clue? This is a repeatable experiment. I get similar results from different pcs on the lan, different files, and the results almost always the same, give or take a few mbs/sec. Obvious synonas and 192.168.1.100 are the same device, the ports are not in a bond, its all running through a 24 port gigabit switch, and I can immediately see a speed difference by using the device name vs its ip.

 

[EAZ1964]

I can imagine an issue in the windows DNS area.
there are some tools to clean it, you can easily google these.

 

[John82]

The second is using NetBIOS. You will find a lot of articles of how can be disabled. Google it.

You may also try the FQDN: synonas.your domain, it must be equal to the IP address.

 

[Phone Guy]

Sorry, I dont understand, which is why I posted the question... Clean my DNS area? Try FQDN?
I did try adding the local ip to host file and flushed dns, no change.
I attached some pics, where you can see if the "name" is in the address bar the speed is around 60mb, but if I change it to the ip/temp the speed is over 100mb

 

[John82]

Try to disable NetBIOS in WINS settings and tell us how it goes: Disable NetBIOS in Windows networks

FQDN is fully qualified domain name, e.g. DS3622.myhome.net.

\\DS362S is using the ancient NetBIOS protocol and \\IP or \\FQDN the SMB. With netstat you will see that they are using different ports… ( 138 & 139 for NetBIOS, 445 for SMB. )

 

[Phone Guy]

Try to disable NetBIOS in WINS settings and tell us how it goes: Disable NetBIOS in Windows networks

FQDN is fully qualified domain name, e.g. DS3622.myhome.net.

\\DS362S is using the ancient NetBIOS protocol and \\IP or \\FQDN the SMB. With netstat you will see that they are using different ports… ( 138 & 139 for NetBIOS, 445 for SMB. )

I tried to disable netbios by selecting network properties, ipv4, advanced and disable. then restart. Max out 60mb sec, and even with directip same results now. \\10.10.10.10\temp same 60mb sec as \\ds3622\temp

 

[John82]

Ok, try the opposite now, enable it.

 

[Phone Guy]

It was enabled, so the results are the same either way.

 

[EAZ1964]

Flushing will probably not enough try:
ipconfig /flushdns
ipconfig /registerdns
ipconfig /release
ipconfig /renew
netsh winsock reset catalog
netsh int ipv4 reset reset.log
netsh int ipv6 reset reset.log

 

[John82]

The default is to get the configuration from DHCP.

I had solved it 15 years ago (around Windows Server 2012 era), but can’t remember if I had applied any Group Policy settings for SMB. Surely we had DHCP configured…

It’s a very common issue with some luck and a lot of patience you will nail it:

smb performance when using ip address and netbios name - Google Search

 

[Robbie]

I'm not sure if my contribution will help as my network is almost exclusively macOS and until the most recent DSM7 update everything worked flawlessly as my SMB configurations were carefully tuned and honed to perfection. I have also helped many other macOS / Synology users to fully realise the capability within DSM and macOS.

But I have been shaken from my nirvana by inexplicable NetBIOS issues, even though my tuned macOS SMB config and DSM settings should preclude anything to do with SMB 1 or NetBIOS in any way.

My symptoms included an unexpected amount of network traffic, including over wifi APs, to clients that have no shares mounted, on an almost continuous basis. Not good at all for wired network performance and a kicking for wifi. Unhelpfully, macOS lists this inbound traffic under kernel_task, so no clues to its actual purpose or source.

The Wireshark screenshot below show the magnitude of the issue. My primary NAS (Rivendell) is continually broadcasting NetBIOS Session Service packets at clients (MacBook Pro over wifi in this example). They are full-fat NetBIOS packets (1514 bytes) at a machine-gun rate:

My NAS is configured for SMB 2&3 only and is not set as local master:

I have macOS configured with a nsmb.conf file and it specifically prohibits SMB1 and NetBIOS:

Last login: Tue Aug  9 23:48:59 on ttys000
rob@MBP-Rob ~ % cat /etc/nsmb.conf                          
[default]
# Disable signing, this became default in later macOS versions
signing_required=no
# Lock negotiation to SMB2/3 only
# 7 == 0111  SMB 1/2/3 should be enabled
# 6 == 0110  SMB 2/3 should be enabled
# 4 == 0100  SMB 3 should be enabled
protocol_vers_map=6
# No SMB1 = no NetBIOS (WINS) and it should be disabled
port445=no_netbios
# Prefer wired networks over Wi-Fi networks that may advertise faster speeds than appropriate
mc_prefer_wired=yes
# Remember, after editing and saving with VI, to log out of macOS account and log back in again for the new settings to load
rob@MBP-Rob ~ %

Only SMB2 and SMB3 enabled on macOS shares:

rob@MBP-Rob ~ % smbutil statshares -a

==================================================================================================
SHARE                         ATTRIBUTE TYPE                VALUE
==================================================================================================

--------------------------------------------------------------------------------------------------
Time Machine Storage        
                              SERVER_NAME                   Rivendell._smb._tcp.local
                              USER_ID                       501
                              SMB_NEGOTIATE                 SMBV_NEG_SMB2_ENABLED
                              SMB_NEGOTIATE                 SMBV_NEG_SMB3_ENABLED
                              SMB_VERSION                   SMB_3.1.1
                              SMB_ENCRYPT_ALGORITHMS        AES_128_CCM_ENABLED
                              SMB_ENCRYPT_ALGORITHMS        AES_128_GCM_ENABLED
                              SMB_ENCRYPT_ALGORITHMS        AES_256_CCM_ENABLED
                              SMB_ENCRYPT_ALGORITHMS        AES_256_GCM_ENABLED
                              SMB_CURR_ENCRYPT_ALGORITHM    OFF
                              SMB_SHARE_TYPE                DISK
                              SIGNING_SUPPORTED             TRUE
                              EXTENDED_SECURITY_SUPPORTED   TRUE
                              UNIX_SUPPORT                  TRUE
                              LARGE_FILE_SUPPORTED          TRUE
                              OS_X_SERVER                   TRUE
                              FILE_IDS_SUPPORTED            TRUE
                              DFS_SUPPORTED                 TRUE
                              FILE_LEASING_SUPPORTED        TRUE
                              MULTI_CREDIT_SUPPORTED        TRUE

--------------------------------------------------------------------------------------------------
Documents                    
                              SERVER_NAME                   Rivendell._smb._tcp.local
                              USER_ID                       501
                              SMB_NEGOTIATE                 SMBV_NEG_SMB2_ENABLED
                              SMB_NEGOTIATE                 SMBV_NEG_SMB3_ENABLED
                              SMB_VERSION                   SMB_3.1.1
                              SMB_ENCRYPT_ALGORITHMS        AES_128_CCM_ENABLED
                              SMB_ENCRYPT_ALGORITHMS        AES_128_GCM_ENABLED
                              SMB_ENCRYPT_ALGORITHMS        AES_256_CCM_ENABLED
                              SMB_ENCRYPT_ALGORITHMS        AES_256_GCM_ENABLED
                              SMB_CURR_ENCRYPT_ALGORITHM    OFF
                              SMB_SHARE_TYPE                DISK
                              SIGNING_SUPPORTED             TRUE
                              EXTENDED_SECURITY_SUPPORTED   TRUE
                              UNIX_SUPPORT                  TRUE
                              LARGE_FILE_SUPPORTED          TRUE
                              OS_X_SERVER                   TRUE
                              FILE_IDS_SUPPORTED            TRUE
                              DFS_SUPPORTED                 TRUE
                              FILE_LEASING_SUPPORTED        TRUE
                              MULTI_CREDIT_SUPPORTED        TRUE

--------------------------------------------------------------------------------------------------

Something has changed in the DSM7 network stack and it isn't pretty.

I am currently experimenting with killing DSM services (synosamba) and have gained control of almost all the recent DSM NetBIOS madness but with some impact to macOS smbutil. NetBIOS is old and rubbish so I have no idea why DSM wants to play this way but this recent errata may help explain your issues.

Thoughts from the knowledgable?

️

 

[Phone Guy]

@Robbie wow, that's a ton of information, and a little above my level of networking knowledge.

@John82 I had no idea this was such an issue. Wow.

Well, I expected this to be something easily fixed, looks like I am not alone in this phenomenon, but the fix doesn't seem to be a "click this" kind of solution.

 

[John82]

I’m afraid it never was just a click thing. As you can see there are many settings hidden in config files or registry. 99,9% the defaults are fine in general with some exceptions of course…

I did a very quick check on a Windows 10 21H2 machine. Both ways used 445/tcp port. I may try a Windows 7 later…

A more thorough testing is needed (WireShark, methodology, performance). An update or combination of things is enough to change the behavior of a system so we must be as specific as possible.

In case of macOS even the CPU type seems to play a role here…

 

[Phone Guy]

All my testing was done on a fresh install of Windows 10 Pro 21H2, if I didn't mention that.