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 reason for Bad checksum [should be 0x55718ef8]

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]

checksum bad

asked 25 May '17, 09:08

vasim
6●1●1●2
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

One Answer:

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.

answered 27 May '17, 12:59

Guy Harris ♦♦
17.4k●3●35●196
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 ♦♦