Blog

Networking Headaches I

I have an old computer that I use as a makeshift NAS, which I've done for years with old systems. Last week it became inaccessible to one particular computer, at random, but the rest of the network had no issues.

It was strange because nothing had changed on either side, at least that I could find. Even stranger was that although it'd fail the first time I tried to access it, if I waited about a minute it'd then be fine for the rest of the day.

After a few days of failures I figured that this wasn't one of those things and decided to sort out this irritance.

Wireshark is my first port of call when it comes to network issues. It was very revealing; contrary to the error message, not only was the computer "found", but it had a nice little chat before terminating the connection (the normal way, not a TCP RST). Misleading or what?

I wondered if there were any clues within the event logs. Older versions of Windows only log SMB server activities (no clues there, it was empty). Fortunately client events are logged on Windows 8 and up, and there was a relevant event within that one.

I suppose this was slightly more honest than the earlier error message, but only slightly - it didn't say why. At least it was consistent with the Wireshark capture, but it was no help.

I decided to compare captures with some other computers, and that's what gave me the breakthrough I needed.

Solution

Other computers would connect via port 445, whereas the bad computer would connect to port 139. Ye olde NetBIOS 139. SMB v1 has always been disabled, as nothing in the network needs it. Hmm.

Windows 10 is supposed to connect to 445 first, and then fall back onto 139 if it fails. My captures demonstrated the opposite behaviour - that is, it'd try 139, fail, and then use 445 a minute later.

Anyway instead of going further I simply disabled NetBIOS over TCP on the bad computer and now it's all good again.

The takeaway from this is: accurate error messages are important.

Return to Blog Index