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

CRC error anomaly - only small packets from one side

0

Greetings -

I'm seeing CRC errors from an Oracle server, but only for small packets. Capturing at my laptop - no CRC errors for any other IP - no CRC errors on packets bigger that 64 bytes for the Oracle box.

Any thoughts on possible causes? I know interference can be a cause on a segment, but only for 64byte packets? Seems rather mysterious.

alt text alt text

Thanks very much in advance for your thoughts.

Cheers,

John Gonder

asked 16 Jan '15, 13:00

packetlevel's gravatar image

packetlevel
1667
accept rate: 0%

edited 19 Jan '15, 10:36

Guy%20Harris's gravatar image

Guy Harris ♦♦
17.4k335196

Strange, I can't see a restriction for uploading files. Can you try to edit your post and add the picture, and if that doesn't work, send it to my email? I'll then edit the post for you.

(18 Jan '15, 08:40) Jasper ♦♦

Thanks, Jasper - I'll send you a pic - not the whole file.

(18 Jan '15, 08:55) packetlevel

Could we either see a capture file containing just one of the packets with the CRC present or a detailed dissection+hex data for one of those packets, as well as an indication of what version of Wireshark you're using?

This might be an issue with the code that attempts to determine whether an Ethernet packet includes the CRC or not.

(18 Jan '15, 18:01) Guy Harris ♦♦

File available at https://www.cloudshark.org/captures/05f9d55d4643 (John sent it to me so I put it up for him)

(19 Jan '15, 10:00) Jasper ♦♦

Do the packets that don't have CRC errors show a valid CRC in the "Ethernet" section of the packet details, or do they show no CRC there?

(19 Jan '15, 13:33) Guy Harris ♦♦

2 Answers:

1

At which layer do you see the CRC errors? Ethernet, IP, UDP, TCP? Do the packets get dropped by the receiving end or does the communication work, but wireshark just reports them as CRC errors?

One instance I have seen problems with small packets was when a cisco switch would not properly add padding when a packet was received on a tagged interface and forwarded on a non-tagged interface (stripping the vlan tag created a runt packet which was dropped by the next switch).

answered 18 Jan '15, 09:18

SYN-bit's gravatar image

SYN-bit ♦♦
17.1k957245
accept rate: 20%

Thanks very much for the responses - FCS is bad at Ethernet layer. Communication seems to work fine. Packets are not dropped. Yes, I've seen that Cisco problem too, but I don't think this is a runt - capture length is 64 bytes. captured with WS v 1.12.1

(19 Jan '15, 09:54) packetlevel

OK, the last 4 bytes of those packet are not part of the IP datagram, so they're either a trailer, an FCS, or random crap stuck there by some hardware or software in the capture data path.

What type of network adapter is this, and what OS are you using? Some older Macs, at least, would supply (valid) FCSes on incoming packets.

(19 Jan '15, 10:44) Guy Harris ♦♦

There are some small sized frames (len<64) in the picture with an IP src of 192.168.0.2 so I assume the capture was made on the system with IP address 192.168.0.2?

Then I see that this system has mac address Netgear_b5:85:dc (c4:04:15:b5:85:dc). Does your laptop (on which you say you captured) have a netgear nic? Oh wait, there are two parts in the picture corresponding to two different trace files. The NetGear is the router and the apple mac-address is from your laptop.

Are you seeing FCS for packets from other IP's? Or are the FCS's stripped for other packets from other IP's?

(19 Jan '15, 11:19) SYN-bit ♦♦

It looks to me like the Netgear device is unnecessarily adding extra padding bytes for packets whose lengths are below the minimum Ethernet packet length, and Wireshark is interpreting those bytes as the Ethernet FCS, which they aren't. I have seen similar captures where other devices seem to do this too.

(19 Jan '15, 13:02) cmaynard ♦♦

@cmaynard, the packet must have already been padded by the device sending the packet (the IP TTL is 48, so it must have traversed a couple of hops, assuming the server started with a TTL of 64,128 or 255). So when arriving at the NetGear, the packet was not undersized.

To me it looks like the NIC driver is passing on faulty FCS fields, but it beats me why it does this for one source IP only.

(19 Jan '15, 13:20) SYN-bit ♦♦

Maybe so, but the netgear could be adding an extra 4 bytes, even for minimum sized frames.

See also this related question and corresponding answers/comments. The ping tests I mentioned there, i.e., pinging the netgear device itself with various packet lengths, may help to prove if the netgear device is the culprit or not.

(19 Jan '15, 14:22) cmaynard ♦♦

OK, when I connect to 205.155.225.145 on port 443 from my own system, I do not get the extra padding, just the two 00 bytes that are needed for the minimum length frame.

@packetlevel, could you open the session to this server from behind a different router to see whether you still get the extra bytes?

If you do still see the extra bytes, then the problem might be on your apple laptop, so can you try it with a different laptop to see whether it shows the same behavior?

Also, could you answer @Guy Harris comment (Do the packets that don't have CRC errors show a valid CRC in the "Ethernet" section of the packet details, or do they show no CRC there?) to your question?

(19 Jan '15, 15:04) SYN-bit ♦♦
showing 5 of 7 show 2 more comments

0

Could be a (strange) firmware bug of your Netgear router/switch. Can you please try the following:

  • ping 205.155.225.144
  • ping 205.155.225.145
  • ping 205.155.225.147

Do you see FCS errors for:

  • A: none
  • B: one
  • C: some
  • D: all addresses

If A: Please also test

Do you now see FCS errors?

If B: Which one? If only 205.155.225.145 ==> firmware bug. Maybe the bit pattern of the address triggers the bug (sounds strange, but I have seen such weird things). Please check if a firmware upgrade (or downgrade) helps.

If C: which of those addresses?

If D: You could try to ping some random addresses and try to find a "pattern", or simply check if a firmware upgrade (or downgrade) helps.

Regards
Kurt

answered 19 Jan '15, 13:18

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%

Kurt, I like the tests, but I would focus on the NIC driver of the Apple device because if the NetGear was messing up, the packets would be dropped by the NIC due to FCS errors. But the TCP session does indeed get established and data is transferred, so the packets are accepted by 192.168.0.2.

Maybe another test can be done. If the NIC is not put into promiscuous mode, does the session still get established and data gets transferred? If not, than maybe it is indeed the NetGear.

(19 Jan '15, 13:26) SYN-bit ♦♦

The reason I believe it could be a Netgear firmware bug is the following paper I recalled: http://repo.hackerzvoice.net/depot_ouah/atstake_etherleak_report.pdf

On the other side, your argument that the Apple driver should have dropped the frames with the wrong FCS is very true, so it will be interesting to see what happens if the OP tries to access the site without putting the interface in promiscuous mode.

@packetlevel: Can you please comment on this?

(19 Jan '15, 13:37) Kurt Knochner ♦

The bytes being treated as CRC aren't normal Ethernet padding bytes - the payload of the frames are 46 bytes long (20 byte IP header, 20 byte TCP header, 6 byte TCP payload), and that, plus 14 bytes of Ethernet header and 4 bytes of CRC, makes 64 bytes, which is the Ethernet minimum (when including the CRC), so there shouldn't be any padding for a 6-byte TCP segment.

(19 Jan '15, 14:24) Guy Harris ♦♦