Solved Cannot connect to Samba share from Windows 10.

I have been battling with a very strange issue all day (and evening) today.

A month back, I set up a server (13.2-RELEASE) the main function of which is to serve files to Windows clients (samba416-4.16.11). There are about 6 PCs on the site and all have been connecting to the server without a hitch.

Today they called to tell me that they had brought two new PCs with Windows 10 freshly installed (and fully updated), and no matter what they had done, they had not been able to get them to connect to the NAS.

So I went there with my laptop (which also happened have Windows 10 freshly installed and fully updated) and spent hours trying to connect it to the NAS. It did not work. I connected the NAS (192.168.1.2) to VPN and installed Tight VNC Server on one of the problematic machines (192.168.1.131) and opened a port to it, so I could deal with the problem from the comfort of my home.

I spent hours scouring the Internet trying to find a solution to the problem, tried everything, to no avail. As a last resort, I ran tcpdump(1), and found out that the NAS is sending TCP packets with incorrect checksums, which the PC probably does not acknowledge. Then this begets the question: Why do the other PCs connect then?

I have attached the output file. Can anyone explain what is going on?
 

Attachments

  • tcpdump.txt
    14.9 KB · Views: 55
If six PCs work and three newer ones don’t that might mean something different on the six working machines - something in their configuration that allows them to connect but on the newer machines the defaults are different (on the Windows side) so connections fail.
 
Samba has log files. Start looking into them; it is there you will find the answers.
Created a VM on the laptop and installed 14.0-RELEASE on it; it connects. I could not find anything of use in the the Samba logs, by the way.

If six PCs work and three newer ones don’t that might mean something different on the six working machines - something in their configuration that allows them to connect but on the newer machines the defaults are different (on the Windows side) so connections fail.
That was my first guess, and it makes sense. But going through the tcpdump(1) output, something caught my attention; for some reason the NAS constantly sends TCP segments with incorrect checksums.

I might have to upgrade the NAS to the latest version in the end, but I would also like to know why this happens.
 
I think I got to the bottom of the problem.

It is neither a FreeBSD, nor a Samba, nor a Windows 10 issue.

I assigned a manual IP to the laptop and connected it directly to the NAS using a patch cable, and voila!

I asked them what had changed recently, and they said it was the ISP-provided modem. (Can't tell you what make, but it is one of those cheap PoS routers.)The old one had died and had to be replaced. I don't know why or how but I suspect Samba server somehow queries DNS when a client tries to connect. If a valid DNS server cannot be accessed, the query and therefore the connection attempt fail. (Or at least that was what I deduced from such an experience in the past with Samba. I'd love to learn if someone could tell me how it actually works.) And to avoid such a problem, I always assign the router IP as the primary name server. (If an external DNS server is used, like 8.8.8.8, and the machine is not connected to the Internet, Samba might not function as expected; it has happened before.) I don't know why but the ISP-provided router somehow gets in the way. And the reason why the old machines can connect is that both they and the NAS have each other's hostnames in their caches. (I had once stopped Window's DNS Client service for some reason and had not been able to connect to a similar NAS.)

I will install a proper pfSense router tomorrow morning and I believe it will work.

At least that is my theory. Of course, I'd still love to know the opinion of the good FreeBSD people.
 
That is kind of basic really: the internet (as today's people know it) is built on DNS. No DNS, no service. So that should be one checkpoint in a list when something doesn't work.
(oh yes, there are services which technically work without dns. Still a moot point, nobody remembers ip addresses anymore)
 
Back
Top