This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

What is the meaning of corrupted packets with bytes filled with 0x55?

0

I started seeing corrupted packets that I've never seen before and wanted to know what the root cause is.

I suspect an overloaded network, but a bug or a defective sender might also be the possible (or something completely different).

This is a sample of a corrupted packet:

0000   68 58 c5 55 55 55 55 55 55 55 55 55 55 55 55 55
0010   55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
0020   55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
0030   55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
0040   55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
0050   55 55 55

They don't occur too often, but often enough to be visible.

Is my assumption correct that these are caused by collisions or network overload?

I'm using Wireshark 2.2.3 and the development network these packets are from has a lot of broadcasts.

asked 28 Jun '17, 05:53

Blutkoete's gravatar image

Blutkoete
6●1●1●3
accept rate: 0%

edited 28 Jun '17, 05:54

The answer largely depends on what hardware you use to capture the packets and what type of network you use. A normal Ethernet card would silently drop any incoming packet with a wrong CRC, so either it doesn't because it is a hardware specially designed to capture everything including corrupt packets, or the source sends them with correct CRC. And yes, there is also a theoretical possibility that the CRC of the packet above is 55 55 55 55, but somehow I don't believe it :-)

I'm afraid you'll need to identify the source by splitting the network into halves and capturing just one direction between them, and then splitting the guilty half into halves again, etc., until you get to the last switch where you'll need to check port by port.

(28 Jun '17, 06:44) sindy

Thank you very much!

I feared there's no simple answer to my problem.

(28 Jun '17, 07:13) Blutkoete

Having TDM / VoIP equipment in the 'development network'?

(28 Jun '17, 07:36) Jaap ♦

I would maybe start by using a network card based on a different chipset (and, preferably, even chipset vendor) for capturing, in order to exclude the receiving side from the search. This should be relatively simple as world is full of USB network cards.

(28 Jun '17, 07:37) sindy

I'll try to record a trace with a USB network card and check every part of the network step by step. It was just I hoped that there was a simple answer like 'Ah! 0x55! That's a clear indicator of X!', but that is obviously not the case :).

The development network is connecting reference systems for position and distance measurements, if there is a sender in there issuing VoIP packets than something has gone really wrong in the lab.

(28 Jun '17, 07:49) Blutkoete

What @Jaap was thinking of was that 0x55 is PCMA (type of voice codec) zero, so a chain of 0x55 is PCMA silence. But there should be much more other bytes in front of it even if you would capture at raw IP level (no Ethernet layer in the captured frame).

(28 Jun '17, 07:54) sindy
showing 5 of 6 show 1 more comments

One Answer:

0

0x55 is the bit pattern "01010101", which is used as the preamble and can sometimes be seen when a collision on a half duplex network occurs. In your case it crashed into the beginning of a new frame from the MAC starting with 68:58:c5 before "disaster" strikes (meaning, another node starting to send it's preamble to the wire).

So yes, these are caused by collisions.

answered 28 Jun '17, 08:22

Jasper's gravatar image

Jasper ♦♦
23.8k●5●51●284
accept rate: 18%