2

I am in the process of debugging an Ethernet communication issue. Basically using Wireshark to monitor the source data the stream was intermittent when the cable was removed and subsequently reconnected.

I'm expecting the manufacturer to say their hardware doesn't stop transmission in these circumstances.

It occurred to me that due to the state of the system under test its possible that large amounts of the >1400 payload could be 0x00. Could this cause problems to the receiving hardware making the transmission appear intermittent?

At the time all I was looking at was that the header information and first few bytes of known fixed data were correct.

Improve this question

2 Answers 2

Reset to default
4

No, a large number of zero bits in your test data will not cause problems on ethernet. You don't specify which ethernet variant you are using, but the different encoding schemes used on the ethernet variants deal with the consecutive zero problem.

You can do a search for "ethernet encoding schemes" to learn more about the specific encoding scheme used in your ethernet variant.

Edit:

I recommend you hire an experienced cable installer with the proper test equipment to test your cabling. You should always start at layer-1 when troubleshooting, especially with intermittent problems.

One source of problems when you disconnect/reconnect a cable during a data stream is that the interface is disabled, then it must reinitialize, possibly needing to auto-negotiate, and needing to run ARP to discover the destination MAC address.

Improve this answer
5

Data that is sent down Ethernet links is always encoded in some way. The problems caused by long sequences of the same logic level in data communications and storage systems are well known. The solution is some form of encoding, and in this case it is known as line coding. 10 Mbps ethernet, for example, uses Manchester encoding, which encodes data bits as transitions. For example, 00000000 would get sent as 1010101010101010. Faster versions of Ethernet use more efficient encodings, including 4/5b, 8b/10b, and 64b/66b.

Properly designed line codes prevent this issue by ensuring there are enough transitions for the receiver at the other end to keep track of the bits. Modern line codes are very good, but there have been issues in the past from poorly-designed line codes causing problems. A famous example of this is a standard called SONET. The line code used in SONET used a 7 bit LFSR to scramble the data. This proved to be much too short and therefore predictable as a malicious user could craft a small number of IP packets that cycled through all possible states of the scrambler and as a result produced a long enough string of ones or zeros to cause the receiver to lose lock and disrupt the link, causing a significant amount of packet loss. Modern line codes are either fully deterministic (so it is impossible to generate a long string of 0s or 1s, no matter the input) or they use much longer scrambler sequences (64b/66b uses a 58 bit LFSR) which are infeasible to break in the same way.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.