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

Hi,

im getting some errors while running wireshark. im getting all these errors from my network printer what could be the reason for that?

[Expert Info (Error/Checksum): Bad checksum [should be 0x1c224e67]

asked 25 May '17, 09:08

vasim's gravatar image

vasim
6112
accept rate: 0%

In what context is the checksum? From the size it would seem to be an application protocol?

(25 May '17, 09:11) grahamb ♦

getting this error at broadcast ARP Frame check sequence: 0x00000000 [incorrect, should be 0xa5a56305] im getting this for my 2 network printers.

(26 May '17, 23:29) vasim

getting this error at broadcast ARP Frame check sequence: 0x00000000 [incorrect, should be 0xa5a56305] im getting this for my 2 network printers.

It probably means that Wireshark thinks the packet, as captured, has a CRC at the end when, in fact, it doesn't. (All Ethernet packets have a CRC at the end - but not all capture devices and mechanisms include the CRC in the packet data.)

We'd have to see one of the packets (preferably in the form of a capture file, rather than a screenshot) to see whether this is a problem in Wireshark or just some case where there's not enough information for Wireshark to determine whether there's a CRC or not.

permanent link

answered 27 May '17, 12:59

Guy%20Harris's gravatar image

Guy Harris ♦♦
17.4k335196
accept rate: 19%

Frame 36594: 64 bytes on wire (512 bits), 64 bytes captured (512 bits) on interface 0 Interface id: 0 (\Device\NPF_{0A822D34-D117-4A97-9600-B75053AE0252}) Encapsulation type: Ethernet (1) Arrival Time: May 25, 2017 20:12:20.225033000 Arabian Standard Time [Time shift for this packet: 0.000000000 seconds] Epoch Time: 1495728740.225033000 seconds [Time delta from previous captured frame: 0.005614000 seconds] [Time delta from previous displayed frame: 0.005614000 seconds] [Time since reference or first frame: 2067.779529000 seconds] Frame Number: 36594 Frame Length: 64 bytes (512 bits) Capture Length: 64 bytes (512 bits) [Frame is marked: False] [Frame is ignored: False] [Protocols in frame: eth:ethertype:arp] [Coloring Rule Name: ARP] [Coloring Rule String: arp] Ethernet II, Src: Sharp_51:df:3b (34:f6:2d:51:df:3b), Dst: Broadcast (ff:ff:ff:ff:ff:ff) Destination: Broadcast (ff:ff:ff:ff:ff:ff) Address: Broadcast (ff:ff:ff:ff:ff:ff) .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default) .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast) Source: Sharp_51:df:3b (34:f6:2d:51:df:3b) Address: Sharp_51:df:3b (34:f6:2d:51:df:3b) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Type: ARP (0x0806) Padding: 000000000000000000000000000000000000 Frame check sequence: 0x00000000 [incorrect, should be 0x1c224e67] [Expert Info (Error/Checksum): Bad checksum [should be 0x1c224e67]] [Bad checksum [should be 0x1c224e67]] [Severity level: Error] [Group: Checksum] [FCS Status: Bad] Address Resolution Protocol (request) Hardware type: Ethernet (1) Protocol type: IPv4 (0x0800) Hardware size: 6 Protocol size: 4 Opcode: request (1) Sender MAC address: Sharp_51:df:3b (34:f6:2d:51:df:3b) Sender IP address: 192.168.0.225 Target MAC address: 00:00:00_00:00:00 (00:00:00:00:00:00) Target IP address: 192.168.0.205

(28 May '17, 04:05) vasim

OK, this is on Windows (on UN*X, interfaces don't have names like \Device\NPF_{0A822D34-D117-4A97-9600-B75053AE0252}), and the frame is claimed to be 64 bytes long, but it's an ARP packet, which means that it's short enough that the payload is less than 64-(14+4) = 46 bytes long.

That means that, if the host that transmitted it padded the payload sufficiently to make it a minimum-length Ethernet frame, if it were 64 bytes long the last 4 bytes would be the FCS.

So, given that the last 4 bytes are zero, either 1) the machine that sent it added an extra 4 bytes of padding - which is legal, although wasteful - or 2) those 4 bytes of zero were added by something else.

Perhaps Wireshark's heuristic to guess whether there's an FCS or not should assume that if the last 4 bytes of the frame are zero, it's not an FCS. For now, just ignore those errors if the FCS is reported as zero.

(28 May '17, 09:24) Guy Harris ♦♦
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×36
×9

question asked: 25 May '17, 09:08

question was seen: 11,101 times

last updated: 28 May '17, 09:24

p​o​w​e​r​e​d by O​S​Q​A