The photo above is of a pair of Ethernet jacks, the kind we see on the backs of desktop computers and don’t really think about unless they mysteriously stop working properly, something they rarely do. That’s not to say that network connections never malfunction; it’s just that when they do, it’s rarely the fault of the network jack in the computer. Today’s tale is about a pair of problems that a client asked me to fix. One was that his network was down, and the other was a computer that wouldn’t boot normally, and those problems turned out to be related in a very unexpected way.
The more pressing issue that the client had was that none of his computers could connect to his network, even though all the cables appeared to be in the right places and all the expected network indicator lights were on or flashing, whichever was appropriate. His ISP had sent a field technician out to look at it, and the technician had concluded that the problem wasn’t with their equipment. This client is fairly tech-savvy, and had spent some time troubleshooting his LAN equipment – which consisted of the ISP’s gateway, a simple, unmanaged network switch and half a dozen CAT8 cables, one connecting the gateway to the switch, and the rest connecting computers to the switch.
No, CAT8 was not a typo. This client is using Category 8 Ethernet cables, which are intended for high-speed, short-range use in data centers and usually not deployed in office settings. This client obviously didn’t read up on IEEE, CCITT and ISO network cabling standards before buying these. But while I conducted some of my tests using a more appropriate CAT6 cable, that was mainly to rule out the idea that unorthodox use of CAT8 might be causing his problems. I was not, in fact, there to troubleshoot the network cables, as they had been in use for quite some time and the problem had only appeared a week or so before my visit.
Naturally, I concentrated my attention on the network switch, which is an unmanaged, 8-port PoE model (although the client doesn’t have any PoE devices). You might ask why I didn’t start with the gateway, which is one of those all-in-one cable modem/router/wifi devices that incorporates a 4-port switch. After all, many cable Internet companies deploy these to their customers, and they’ve been known to cause problems, mainly with VoIP phone service. But this client doesn’t have any VoIP phones, and the one computer that was communicating properly over the network was plugged directly into the gateway, So, the mystery was why the computer plugged directly into the router was working fine, but any computer plugged into the switch either failed to obtain an IP address, or, if it did manage to get a valid TCP/IP setup from the DHCP server (in the gateway), it still could not communicate on the network afterward. So, the logical place to start seemed to be the switch.
The client had a couple of spare network switches, so I tried swapping switches — no change. I checked and re-checked all the connections; again, everything appeared to be hooked up correctly. It made no difference if I connected up using my CAT6 cable or the client’s CAT8 one. If I connected my laptop to the gateway, my laptop got a working connection, but if I plugged into the switch, it didn’t. It seemed unlikely that all three switches were bad, especially since one of which was just a few weeks old.
So, I then turned my attention to the ISP’s gateway. I had never seen that particular model gateway before, so maybe there was some obscure setting in it that had could affect a connected switch and had accidentally been changed. But no matter where I looked in the gateway’s administration GUI, I couldn’t find any settings that might be responsible for causing issues with the switch.
So much for the places where I most often find this sort of trouble. I now had to start looking at the rest of the network. In a typical home or small business network, plugging certain kinds of rogue devices into the switch can bring down the network. Fortunately, this was a small network, and it was pretty much down anyway, so I unplugged all the client’s network cables from the switch, except for the one that connected it to the gateway, and then plugged just my laptop into the switch. Aha, now I was getting somewhere! My laptop was instantly assigned a valid IP configuration and went online.
Next, I began plugging the client’s network cables back in one by one, testing with my laptop after each. Since we’re only talking about four cables, it didn’t take long to find the problematic one. What surprised me, though, is that the cable that brought the network back down turned out to be plugged into the second problem I was asked to fix: the computer that didn’t work.
It’s instructive to note that a modern computer’s Ethernet jack works even if the computer is turned off, as long as a) it’s plugged into a working electrical outlet, b) the power supply is at least working well enough to energize the system board, and c) the Wake-On-LAN setting in the system board’s BIOS hasn’t been turned off. Apparently, this computer’s Ethernet jack was not only energized, but was also transmitting a constant stream of garbage data out over the network cable. That stream was causing the network outage.
The computer turned out to have some strange things about it. First of all, it has two network jacks instead of the usual one. (Two network jacks is quite common when the computer in question is a network server, but this one was a custom-built, but otherwise fairly ordinary, desktop PC, albeit one equipped with high-end components.) One of the jacks was, in fact, connected to the cable from the network switch. The other one was incorrectly connected to a network printer via a standard Ethernet patch cable. I had to explain to the client that such a connection doesn’t work, particularly not without a special crossover cable, and not without at least setting a static IP address on the printer. But even with a crossover cable, such a configuration was unlikely to make the printer work, so I removed the Ethernet cable that had connected the PC directly to the printer.
But could that unworkable connection have caused the network to go down? That seemed unlikely, because, as mentioned earlier, that computer wasn’t working. OK, to be more precise, it wasn’t running an operating system, because, as I would find out later, its power supply was failing. The system board was getting enough power in its off state to energize its Ethernet jacks, but unless there is something very strange about the way those Ethernet jacks were connected to the system board, having a printer improperly plugged into one of them shouldn’t have caused the other one to create problems on the network.
A failing power supply can, theoretically, cause a component like an onboard Ethernet module to fail, but this, too, seemed unlikely under the circumstances. The power supply in the computer was good enough to get the computer through its power-on self-test. It only failed shortly before or after Windows 10 displayed the logon screen, at which point it would shut down.
So, it seemed more likely that the Ethernet jack connected to the (correct) network cable had gone bad. Or maybe the Ethernet adapter circuitry to which that jack is soldered went bad. Either way, moving the network connection to the other Ethernet jack seems to have solved the network problem. Now the client is waiting on a new power supply for that computer.
The moral of the story is that after you’ve eliminated all the common causes for a common problem, be sure to investigate the uncommon causes before giving up.
