Background
In our environment we have a login script that runs to connect users to the network shares. This worked flawlessly until some of the Macs were upgraded to macOS Sierra, when we were suddenly unable to connect to one of the SMB shares using the server's IP address.
There are three Windows servers that the Macs need to connect to on login – one with IP address 192.168.65.3, one with IP address 192.168.65.30, and the final one with IP address 192.168.65.25 (this one connects using Acronis Access Connect and AFP).
The first SMB share from 192.168.65.3 connects successfully with no issues, then when attempting to connect to the second SMB share – 192.168.65.30 – the Mac fails to connect. Finally the Macs completes the login script by connecting successfully to the AFP share – 192.168.65.25.
What I've Done
I have discovered that there is no issue when attempting to connect to the hostname of the second SMB server – server2. Using the connection string smb://server2/share_name works perfectly where smb://192.168.65.30/share_name doesn't work at all.
Next I attempted to capture the packets using Wireshark – I set the filter to ip.src == 192.168.65.30 or ip.dst == 192.168.65.30 but when I attempted to connect to the share there were no packets that were sent from/to that IP address.
So I removed the filter and tried to connect again – I could see that there were packets being sent to the network address 192.168.65.255 to resolve the IP address 192.168.65.30 to a hostname using the NetBIOS Name Service (NBNS) instead of treating it as an IP address. When it failed to resolve the IP to another IP, the process of connecting failed.
TLDR
Sierra thinks an IP address is actually a hostname during SMB connection and is attempting to resolve it to an IP address, which is obviously unsuccessful. It doesn't treat all IP addresses this way as another IP on the same subnet connects successfully.
This occurs on all Macs that are upgraded to Sierra.
So…
Why is macOS treating this IP address as a hostname? Is there a way I can force it to treat it as a normal IP address?
Update
I've noticed that after a while (maybe 10 minutes?) of the machines being on and logged in, it will actually connect successfully to the IP address that has been causing issues.
Update 2
So – I have noticed that I am able to connect to the second IP address – 192.168.65.30 – if I am currently not connected to the first IP address – 192.168.65.3 – and vice-versa.
On the second connection it attempts to connect to the share name on the first server that was connected to. For example, if I connect to smb://192.168.65.3/share_1 first then attempt to connect to smb://192.168.65.30/share_2, the packets say that it actually attempts to connect to smb://192.168.65.3/share_2, which doesn't exist, and hence the connection fails to be established.
In fact, I've found that any second SMB connection attempt fails! This is reproducible by upgrading to Sierra and then just attempting to connect to two different SMB shares.
Update 3
The name resolution was a red herring – I now know this issue to be related to opening a connection to a second SMB server. Sierra will attempt to use the same IP address it used for the first connection, and the share name specified in the second connection. A workaround would be to use the hostname, however there are issues associated with this for us when connecting from outside the office using VPN.
Best Answer
This may be a reverse lookup - an attempt to resolve host name by IP. Please check the opcode... Mac may need this to display host name rather than its IP. Not sure about Sierra, but Win clients, as well as some other clients (like NQ, for example) do this. If server does not answer Mac may postpone or even fail the connect.