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

False FCS Error for frame packet size more than 64 bytes

1

I am sorry if this is a repeated question regarding FCS Error. We are getting the FCS error for the frame packet size more than 64 bytes. Frame check sequence: 0x4a495453 [incorrect, should be 0xd7636502]

In our ethernet driver there is an option to Make sure the driver does not transmit packet less than minimum(i.e 64 bytes) as per the Ethernet standards. But, we are getting the FCS errors if we set the packet size as 64 bytes and there won't be FCS errors if we set the minimum packet size as 60 bytes.

As the communication itself doesn't have any problem we believe this may be a
false alarm by the Wireshark. Is there any way to avoid such false errors on the Wireshark.

This question is marked "community wiki".

asked 10 Sep '13, 07:42

paddu's gravatar image

paddu
1112
accept rate: 0%

edited 10 Sep '13, 07:45

grahamb's gravatar image

grahamb ♦
19.8k330206

What preferences are set for the Ethernet dissector in your profile?

(10 Sep '13, 07:47) grahamb ♦

Does this happen with all protocols running on top of Ethernet, including, for example, IPv4 and IPv6, or does it just happen with some protocols?

In your driver, does the minimum packet size refer to the size of the packet including the FCS (in which case 64 is the correct minimum), or not including the FCS (in which case 60 is the correct minimum)?

(And, yes, grahamb's question is also relevant here.)

(10 Sep '13, 12:59) Guy Harris ♦♦

Thank you.. Yes we are using NDK(IPv4) ethernet drivers provided from TI. According to the documents of this driver the driver includes the FCS, but I am not able to confirm where it is added inside the driver.

Actually there is an function named EmacSend() in the driver, which sets the valid length of the packet as shown below.

/ Make sure the driver does not transmit packet less than min. as per the * Ethernet standards. / if( PBM_getValidLen(hPkt) < 60 ) PBM_setValidLen (hPkt, 64 );

If we change the setValidLen to 60, there won't be any FCS error but FCS error occurs if we leave it as 64.

As I am new to this field I don't know much about the Ethernet dissector I shall come back about this later.

(11 Sep '13, 06:23) paddu

can you please post two capture files that show the effect (google drive, dropbox, cloudshark). One with good FCS and one with bad FCS.

(11 Sep '13, 09:12) Kurt Knochner ♦

2 Answers:

0

Please read the following thread and search for EMAC_DSC_FLAG_PASSCRC.

http://e2e.ti.com/support/embedded/bios/f/355/p/274592/969028.aspx

Did you set or clear that flag?

If you set it, did you calculate the CRC value yourself (correctly) and added it to the frame?
If you set the flag, please try to clear it and let the EMAC create the CRC.

Regards
Kurt

answered 11 Sep '13, 10:02

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%

edited 11 Sep '13, 10:09

Thank you.. Regarding the "PASSCRC" flag we haven't changed anything from the default driver, so the flag seems to be "clear" i.e the EMAC generates CRC.

We are little bit confused about the if loop in the TI NDK Driver. "if( PBM_getValidLen(hPkt) < 60 ) PBM_setValidLen (hPkt, 64 );"

They are checking if the packets are less than "60" , and if it is less than "60" set the packet valid leght to "64"

But as pet the ethernet standard the minimum packet lenght is "64" so, why is this driver checking for packets <60 in the if condition and why not directly check if the packet is<64?

I have asked the same question to TI but yet to get a reply.

Please let know if are any comments on this part also.

Regarding the capture files, I need the permission from the company to upload the data, I shall come back to you as soon as possible.

(12 Sep '13, 04:40) paddu

I have asked the same question to TI but yet to get a reply.
Please let know if are any comments on this part also.

O.K. if TI has no answer to that question, how could I? ;-))

Regarding the capture files, I need the permission from the company to upload the data,

O.K.

(12 Sep '13, 12:50) Kurt Knochner ♦

I am sorry for the delay. I have uploaded the capture file of the bad FCS into the below cloudshark site. http://www.cloudshark.org/captures/c5f307132b33

If the frame length is 64 bytes, it appears that Wireshark will take the last 4 bytes of the packet greater than 60 bytes and use those 4 bytes as the FCS.

(24 Sep '13, 08:39) paddu

I received a capture file just yesterday exhibiting this same behavior. It caused a few folks to waste some time chasing this red herring until I set them straight.

An independent capture file is posted on cloudshark at http://cloudshark.org/captures/943b17cd1baa. It contains 2 ICMP echo request/reply exchanges. In the first case, the packet is less than 60 bytes so padding is required, and in the second case the pakcet is more than 60 bytes so no padding is required. You can see the extra 4 bytes of padding in the ICMP echo reply in frame 2 and also notice the ETHERNET FRAME CHECK SEQUENCE INCORRECT indication from Wireshark. (The manufacturer has been contacted about their extra 4 bytes of padding, but no reply has been received from them yet.)

The file was anonymized using TraceWrangler.

(24 Sep '13, 12:59) cmaynard ♦♦

Thank you so much, can I assume that this behavior is not from the wireshark but from the Ethernet driver(from the manufacture)?

Please let me know if there is any possible solution to overcome this sort of errors.

(24 Sep '13, 19:49) paddu

Well, it seems that some manufacturers are adding more padding than is necessary. As a result, Wireshark gets confused and can incorrectly report FCS errors when there aren't any. The "solution", at least for now, is to turn off the Ethernet dissector's "Validate the Ethernet checksum if possible" preference if you don't like seeing these indications in Wireshark.

(24 Sep '13, 19:54) cmaynard ♦♦

Hi cmaynard,

I was studying the capture you posted to cloudshark above in trying to understand why this padding and FCS are present.

From what I can tell, it seems that the padding is added to bring the data size up to 60 bytes, with the FCS being an additional 4 bytes (after the padding), which results in a total size of 64 bytes. But I'm not sure why this padding and FRC are not always added.

Looking at the capture, let host A = 192.168.1.1 and host B = 192.168.1.2

In frame 1 and frame 2, I see that they both contain 43 bytes of "valid data," yet the value shown in the length column shows 43 bytes for frame 1, but 64 bytes for frame 2.

The key difference that I noticed between these two frames is that in frame 2, sent by host B, there is a 17 byte padding, plus 4 byte frame check (CRC) appended to the end of the frame. This results in a frame that meets the minimum size of 64 bytes. Frame 1, sent by host A, does not add such padding: alt text

The question I have is, why doesn't host A apply this same padding and FCS (in frame 1)?

It seems like the Ethernet driver at host A was not implemented to add padding/FCS to the end of the Ethernet frame, but host B's driver was. (or the maybe the h/w itself does this?).

Furthermore, neither host adds a frame check to frames 3 and 4. So it seems that a frame check should only exist if the total length of the frame is 64 bytes, and in such case the last 4 bytes are to be read as the frame check sequence ... ?

Your thoughts are appreciated!

(25 Sep '13, 12:10) stevenconnell

First, the capture was taken at the host 192.168.1.1, so Wireshark gets the packet before the transmitter adds the padding, thus the reason it's only 43 bytes. Whenever you see packets less than the minimum frame size, this is a tell-tale sign of the capture point. When that 43-byte packet hits the wire, it will be padded by 17 bytes to meet the minimum 60 byte (data) size ... plus the 4 byte FCS of course.

When 192.168.1.2 receives the packet, it replies and also needs to add padding. However, it adds not 17 bytes but 21 bytes of padding, 4 bytes more than is necessary. I do not have capture hardware that will actually capture the Ethernet FCS, so by the time Wireshark gets the packet, the FCS has already been discarded by the NIC. In fact, if the FCS truly was bad, Wireshark would never even see the packet. Those last 4 bytes are part of the padding, being misinterpreted by Wireshark as an FCS due to the sending device adding an extra, completely unnecessary 4 bytes of padding.

Regarding frames 3 and 4, they're both larger than the minimum frame size, so no padding is needed nor added. You don't see the FCS for those either because, as I mentioned above, we never actually receive the FCS for any frame, regardless of size.

Does that make sense?

You can even run some simple tests yourself using ping to verify this. Try some payload sizes such as follows to see the effect:

*nix:

ping -c 1 -s 1 <host>
ping -c 1 -s 14 <host>
ping -c 1 -s 18 <host>
ping -c 1 -s 22 <host>
ping -c 1 -s 58 <host>

Windows:

ping -n 1 -l 1 <host>
ping -n 1 -l 14 <host>
ping -n 1 -l 18 <host>
ping -n 1 -l 22 <host>
ping -n 1 -l 58 <host>
(25 Sep '13, 12:43) cmaynard ♦♦

Your response actually cleared things up a lot, thanks!

(27 Sep '13, 13:41) stevenconnell
showing 5 of 9 show 4 more comments

0

Try this:

  1. Open the config page as follows: Edit/Preferences/Protocols/Ethernet
  2. Uncheck the "Validate the Ethernet checksum if possible".

Wireshark of Version 1.11.3 (v1.11.3-0-g1dd5d3a from master) is tested OK.

Good Luck!

answered 22 Oct '14, 23:05

liang_xinhui's gravatar image

liang_xinhui
111
accept rate: 0%

edited 23 Oct '14, 00:21

Guy%20Harris's gravatar image

Guy Harris ♦♦
17.4k335196