Shorted Wires On Cat5e Ethernet Cable?

Hello everyone,

A client of mine had a short circuit in his Ethernet cable running between the broadband modem and his router. Inexplicably, he was able to surf the internet without problems, but when trying to remotely accessing a LAN server ... it failed miserably. Once the shorted cable was replaced, remote access was successful. In your opinion, why was surfing the net possible and not remote access due to the short circuit in the Ethernet cable??
Best regards,
-Ronald

I would guess that it would have to do with the nature of the protocol differences in each application, and that only one of the pairs (TX or RX) were shorted. So it might not have been a hard short, just partial and with web surfing he was barely transmitting any data (just page requests), whereas with remote accessing a LAN server he was sending acknowledgements for each packet he was receiving from the remote server. The RX pair was probably fine, but the TX was probably a partial short and allowing some data through, but very limited?

Sean's guess mirrors mine. The pinout grid below illustrates the point:

(The chart assumes 568B, but your standard may be different.) Note that Pins 1&2, 3, and 6 are extremely relevant to RX/TX traffic. In the case Undisclosed describes, I'd wager that the short was on one of these strands, and probably on 1 or 2.

as Brain said, it is the possibility of short circuit happended in other pairs....1,2,3 & 6 will be used for TX/RX. Your question reminds me that few years before I have used one single cat5e cable for connecting two different devices through LAN (2pairs/device)... for any LAN connection 2pairs is more than sufficient but other pairs required for remote access, POE etc....

Thank you Sean, Brian and Velayuthan for sharing your knowledge with me. Very useful information.

Velayuthan, Do you have any references (webpage links) to support your theory? That remote accessing a LAN PC (as full desktop control) via WAN would make use of TRD wires within the Ethernet cable between the modem and the router?

"for any LAN connection 2pairs is more than sufficient but other pairs required for remote access, POE etc...."

Not exactly...

Ethernet uses 2 pairs, as described elsewhere above. ALL connections work exactly the same, packets are packets on the LAN. From your PC's perspective every packet is "local", it's ALWAYS going to another device on the LAN. Sometimes, that other device is a router, which then sends the packet on to a remote site/the Internet. But every single packet is going across the network the same way, on the same wires.

PoE can go over the other pairs (most common) OR it can also go over the same data pairs. The PoE power method is dictated by the powering device, and in order to be compliant any PoE powered device needs to be able to accept power via either method. This is one of many reasons why ALL Cat5+ drops should be wired to the 568A or 568B spec, with all 4 pairs punched down and not split across multiple jacks.

The original problem described above sounds like a very odd case, and technically a short should affected either scenario the same way. I could see it being more probable to occur in the manner decribed if one data stream was UDP and the other TCP, but these both sound like TCP streams. This reminds me a little bit about the famous "500 mile email" problem and I wonder if there wasn't more to it than just a bad cable.

As soon as the cable was replaced, the remote access (similar to PCanywhere) worked. The manufacturer of the software tells me it uses UDP as data stream.

I've had a similar problem in the past. I had a PC in a crane which couldn't get his data from the server.

When I ran ping's over the line I noticed that all the pings (standard size) worked. However, once I replaced the cabling I was able to connect to the server again.
There's a good chance that once you start pushing pings with large sizes (ping <ip> -t -l 15000) you see the connection dropping. I recon it hasn't got to do with a particular protocol you're sending, but more the bandwidth you're using.

So far I couldn't figure what might be causing the problems. My only guess is that due to a malfunction with the cable you have more interference from the other wires, thus when using more bandwidth you get so much package loss your connection stops working. Basicly the reason why for CAT7 you have such strong demands on how the cable is connected to the sockets, to prevent interference

I had a site once where I couldn't get more than a 10Mbps connection between a DVR and its switch, although both cameras that were connected to the switch were at 100Mbps. The cameras ran acceptably (if slow) on the DVR, but their admin web pages would only start to come up and then fail.

I finally inspected the cables and found the patch cable between the DVR and switch (custom made by the original installer) had a wiring fault: wired 568B, the orange pair was fine, but the the white/blue and green wires were reversed on one end, so basically no RX- connection. It was enough that it showed a link and could partially communicate with the cameras, but not enough to work properly.

I also had to troubleshoot a setup where there was a link showing, but only VERY spotty connectivity... turned out the guy who terminated the cable (normally an audio tech) had just crimped it down in RJ45 plugs in straight pairs - white/color, white/color, white/color, white/color. So while the link had electrical connectivity, the RX set was split across two pairs, resulting in some strange behaviour.

Thanks Rogier and Matt for your testimonies. Nice to know I'm not alone with strange behaviors stemming from a bad cable.

Be advised that all 8 conductors are used for 1000BASE-T.

I knew I got that RCDD for something!

In one of our IPVMU classes, a student said RCDD = Really Cool Data Dude. If the shoe fits, I guess.

Yes Jesse, all 4 pairs will be used for Gigabit Ethernet.. For 10BASE-T/100BASE-T, it requires 2 pairs only....

To Undisclosed Integrator

here is the link, which gives some details about it...

http://en.wikipedia.org/wiki/Ethernet_over_twisted_pair

@ Brian Karas, I somewhat agree with "I wonder if there wasn't more to it than just a bad cable."

Newbie (to IPVM) here. Now retired with many years installing and maintaning ethernet. All good valid responding information. Unfortunately it seems to be based on a simple explain of a suspected physical condition. With no defines. Ergo. Problem, solution (assumed?), replace cable, fixed. So now speculation and therum.

A short? How do it know? Short to what? Across a pair, to one side of another pair, to ground (sheilded ethernet?). What type of connetions? Jack ended, punch down? Did the cable run near any intrferance and the new run not? And was it really in the cable? Meaning the connections are equally suspect and maybe even more so as that has the most exposure to potential trouble.

I guess I don't see the 'short' was proven to be 'in' the cable. My experience suggests that may be a rare occurance as opposed to all the lngering (read potential) troubles caused during installaiion and onging activity.

I prefer to know that the 'problem' WAS (or wasn't) and documented for future maintainers of a system.

OK. I feel better now. :-) Thanks for listening.

@Cal - your post made me think of a couple of things I've seen more than once over the years...a slightly corroded connection point, an RJ-45 end where the spring tab was loose or broken (resulting in a poor connection), and patch cords that had gotten run over by office chairs and the like (so, not shorted, but the integrity of the twists were destroyed).

Knowing a bit how Ethernet signalling works, a "shorted" cable seems highly unlikely. But a damaged cable or poor outlet/plug could certainly cause interesting operation.

Opps. Sorry for the typos. Don't know why FireFox wasn't underlining those.

Now where to ask for a 'review' button afore posting?

@Brian, Ezzzactly, Well said. Bringing tidbits to a medium like this informs (educates?) everyone. Heck I've seen coils of ethernet thrown under a raised floor (rather that cut it to the prescribed slack) that shouldn't have affected anything, be the cause of a few problems.

Thanks J.A. for the insight. The 90 or so foot patch cable (no it wasn't an ethernet cable with jacks) started in one color (blue) and ended in another color (grey). Back then, the client accepted that I change the cable as a paid service, but later refused to admit the change was needed even though remote access was finally possible the minute I changed the cable with a real ethernet cable with modular jacks at each end.

Later on, he accused me of breaking his original cable even though I hadn't gone to the basement until I passed my own cable. Once accused, I asked for permission to go to the crawl space in the basement and get the old patch cable for inspection to find out exactly what the problem with it was, but he refused. Go figure!

Some people who are wrong do not want it proven even if it was not their fault.

I replaced an overhead garage door sensor because it quit working. I found the wire was cut due to a piece of angle iron that had dropped on it. The concrete below the cut wire was chipped and the angle iron had concrete residue on it. Happily I reported what I has discovered in an attempt to show the customer why it needed replaced and what had happened so they could avoid the same occurrence in the future. I was angrily told to leave and not come back. ????????????????????

@Scott, Interesting obfuscated story.

Re: "Some people who are wrong do not want it proven even if it was not their fault".

From your explain. I read the 'cut wire' was the problem and to me, reconnecting it should have been the fix. Thus no need to replace the sensor.

So who was at fault (wrong)?

Please clarify. Thanks.

Cal, The angle iron cut the wire in the armored cable about 3 inches from the sensor. Since there was no way to permanently fix it where it would be protected by the armor continuously to the metal receptacle box I replaced the sensor contact. The customer didn't know and didn't care he just wanted the alarm to arm without problems. Apparently he thought I was accusing him of cutting the contact's wire.

One of the aspects of Ethernet cabling is that there can be more to a cable problem than conductors being cut (open) or shorted. Brian Karas mentioned the integrity of the twists, which is critical to what frequencies the cable can handle well.

Most Ethernet switches auto negotiate the speed at which they connect. If a cable is stretched or kinked or the twists are untwisted too far back from the connector, the cable can't handle the frequencies of the higher data rates.

Thus, for example, in a 1 Gbps LAN a cable might have its connection negotiated down to 100 Mbps or even 10 Mbps and still pass low levels of traffic. In such a situation a small video stream may be displayed in a browser window or client application with no problem, but trying to display 8 cameras at once fails.

I have seen this kind of thing much more often than I have seen cuts or shorts in network cable. If the switch is out of sight, such as when you connect to a wall socket or you are out at the camera end, you won't see the switch's LED light that indicates the low speed connection.

I wrote a column about this not too long ago: Don’t Get Kinky, which among other things talks about cable testing.

I have also seen cables run over fluorescent lighting, near motors, and even strapped to AC power cables. Strong electrical interference can cause some data packets to be corrupted even if there is nothing wrong with the cable. When packets get corrupted after leaving the switch, the TCP protocol calls for retransmitting the packets that failed to arrive intact. A high level of retransmission can reduce the overall capacity of the connection, with the result that a low level of small data packets will get through, but in a high volume of large data packets some packets won't make it.

Good training in network cable installation, whether formal or on-the-job, is important.

I have seen jobs where poorly performing cable went undetected until the "second round" of cameras got installed, and then problems were seen.