Differences between revisions 3 and 4
Revision 3 as of 2004-11-19 23:30:37
Size: 1659
Comment: add link to tcp reassembly
Revision 4 as of 2004-11-20 21:44:43
Size: 1742
Editor: GuyHarris
Comment: Tweak the discussion of checksum offloading.
Deletions are marked like this. Additions are marked like this.
Line 10: Line 10:

It should be VERY VERY rare with corrupted packets in todays networks unless you have a router or a switch with a bad RAM module with a sticky bit. Still it should be VERY rare to see this for packets that actually are corrupted.
It should be VERY VERY rare with corrupted packets in todays networks unless you have a router or a switch with a bad RAM module with a sticky bit. Still, it should be VERY rare to see this for packets that actually are corrupted.
Line 14: Line 13:
If you capture on a ["Gigabit Ethernet"] ["NIC"] you might see many such "errors" however. This is due to TCP Checksum offloading often being implemented on those ["NIC"]s and thus, the checksum will not be calculated until the packet is sent out by the ["NIC"], long long after your capture tool intercepted the packet from the network stack. If you capture on a ["Gigabit Ethernet"] ["NIC"], or on some slower Ethernet ["NIC"]s, you might see many such "errors" however. This is due to TCP Checksum offloading often being implemented on those ["NIC"]s and thus, for packets being transmitted by the machine, the checksum will not be calculated until the packet is sent out by the ["NIC"], long long after your capture tool intercepted the packet from the network stack.

TCP Checksum Verification

By default and whenever possible Ethereal will verify whether the TCP checksum of a packet will be correct or not. TCP packets that have invalid checksums will be marked as such with a warning in the information column in the summary pane and also, most important, if the checksum is BAD that tells ethereal that the packet is corrupted and it will NOT be included in any ["TCP Reassembly"]. I.e. these packets will be ignored by the ["TCP Reassembly"] engine and reassembly will not work.

The TCP checksum will only be tested for packets that have been fully captured, and thus for short packets, the checksum will never be verified. But then again, short packets will be ignored by the desegmentation engine anyway.

It should be VERY VERY rare with corrupted packets in todays networks unless you have a router or a switch with a bad RAM module with a sticky bit. Still, it should be VERY rare to see this for packets that actually are corrupted.

However, there are other causes where you might see it. If you capture on a ["Gigabit Ethernet"] ["NIC"], or on some slower Ethernet ["NIC"]s, you might see many such "errors" however. This is due to TCP Checksum offloading often being implemented on those ["NIC"]s and thus, for packets being transmitted by the machine, the checksum will not be calculated until the packet is sent out by the ["NIC"], long long after your capture tool intercepted the packet from the network stack.

To disable checking of the TCP checksum validity, go to the TCP preferences and untick the box for checksum verification attachment:tcpchecksumchecking.jpg

Preference String

Check the validity of the TCP checksum when possible.

TCP_Checksum_Verification (last edited 2008-04-12 17:51:24 by localhost)