|
I am using Wireshark to debug an obscure problem, but on the way I have started seeing an unrelated issue: every packet sent to the monitoring PC is being flagged as having an incorrect frame check sequence (reported as being 0). This has started happening from the time I reinstalled Wiresharc, before which no such problems were being reported. I am assuming that the reinstallation gave me a newer version of Wireshark; I am currently running Version 1.10.0 (SVN Rev 49790 from /trunk-1.10). As Windows XP is happily processing all these packets and giving the correct results, it seems that XP is seeing correct checksums in the packets. Is there a problem with Wireshark or are the packets really wrong and XP is ignoring the frame check? |
|
You can disable the checksum validation in the ethernet protocol preferences. In most cases it's because the frame has some residual data appended to the real packet that was flowing over the ethernet. So it is not really something to be worried about. if the FCS was indeed incorrect you wouldn't have seen it in your trace. |
|
You can upload your capture file somewhere else, like www.cloudshark.org, and then include a link to it in your question. Usually incorrect Frame Check Sequences are not a problem. Almost all modern network cards do checksum offloading; that is, the FCS is calculated and applied by the NIC instead of by the OS. If you're capturing on one of the endpoints, Wireshark will see frames transmitted by that system before the FCS is calculated and added by the NIC. Some signs that incorrect Frame Check Sequences are just due to checksum offloading, and are not really an error:
Its usually better to capture from the wire instead of from either of the endpoints involved in the communication. There are other reasons, besides checksum offloading, why the packets that are transmitted on the wire will be different from packets captured on an endpoint. |
|
You can upload your capture file somewhere else, like www.cloudshark.org, and then include a link to it in your question. Usually incorrect Frame Check Sequences are not a problem. Almost all modern network cards do checksum offloading; that is, the FCS is calculated and applied by the NIC instead of by the OS. If you're capturing on one of the endpoints, Wireshark will see frames transmitted by that system before the FCS is calculated and added by the NIC. Some signs that incorrect Frame Check Sequences are just due to checksum offloading, and are not really an error:
Its usually better to capture from the wire instead of from either of the endpoints involved in the communication. There are other reasons, besides checksum offloading, why the packets that are transmitted on the wire will be different from packets captured on an endpoint. |
扫一扫
526
到【灌水乐园】发言
Wireshark uses a hack^Wheuristic to determine whether the packet capture includes the checksum - some adapters/drivers/OS capture mechanisms supply checksums, some don't. Perhaps the code that implemented the heuristic changed between the previous version of Wireshark and the one you're now running, and it's now thinking the zero bytes at the end are an FCS.
What type of packets are they? Does the Ethernet header have a type or length field? If it's a length field, does it equal {the length as reported in the "Frame" section, minus 14}? If it's a type field, what protocol type are they? If some are IPv4 packets, does the "total length" in those packets equal {the length as reported in the "Frame" section, minus 14}? If some are IPv6 packets, does the "payload length" of those packets equal {the length as reported in the "Frame" section, minus 54}?