Wireshark mailing list archives

Re: Wondering about TCP checksum errors in AFP-over-TCP


From: Martin Visser <martinvisser99 () gmail com>
Date: Tue, 29 Mar 2011 10:15:54 +1100

There really is a small risk in deselecting "Validate TCP checksums if
possible". If your TCP headers were really corrupted then most likely
this would be because of physical layer errors. However, as with most
media there is built-in physical layer error detection (or
correction), corrupted packets are going to either be discarded or
corrected before Wireshark gets to see it. The only time you really
need to validate TCP checksums would be if you are  developing your
own TCP stack or developing devices that try to manipulate the TCP
headers in interesting ways - not something most network engineers or
sysadmins are doing.


Regards, Martin

MartinVisser99 () gmail com



On 29 March 2011 04:17, Kok-Yong Tan <ktan () realityartisans com> wrote:
Got it.  Thanks.  I found the preference for "Validate TCP checksums if
possible" and deselected it.  I guess this leaves me kind of "flying blind"
if there are legitimate TCP checksum errors as I was hoping the "if
possible" in the above preference would somehow take into account TCP
offloading but I suppose it can't.  Oh well...
On Sun, Mar 27, 2011, at 12:52, Anders Broman wrote:

Kok-Yong Tan skrev 2011-03-27 16:51:

It says that "Wireshark 1.2 and above disable IP, TCP and UDP checksum by
default."  Does this mean that it disables checksum [validation] by default?
 If so, note that I'm running Wireshark 1.4.3 with default settings on a
MacOS X 10.5.8 system and I'm still seeing the TCP checksum errors.

If you upgraded from an earlier version your (old)preferences will be
retained...
/Anders

On Sun, Mar 27, 2011, at 01:19, Martin Visser wrote:

In pretty much all case where you are seeing TCP checksum errors on a
server, it will because of the various TCP offload features of the NIC /
driver. If can capture on the wire (that is using port-mirroring on a
switch) this will confirm this, or alternatively turn off those features on
your server temporarily while testing.
See http://wiki.wireshark.org/CaptureSetup/Offloading for details
Regards, Martin

MartinVisser99 () gmail com


On 27 March 2011 10:07, Kok-Yong Tan <ktan () realityartisans com> wrote:

On Sat, Mar 26, 2011, at 18:53, Kok-Yong Tan wrote:

Just for kicks, I decided to do a wireshark trace of AFP-over-TCP
conversations between my Apple MacOS X 10.4.11 Tiger server and my Apple
MacOS X 10.5.8 Leopard (PPC) client.  Surprisingly, I'm seeing lots of TCP
checksum errors (no ssh going on here in the connection since it's all
protected on my internal LAN) on packets going in both directions.  Now, if
the TCP stack were damaged either on the client or the server or both, I
would expect connection issues and all packets going through to exhibit the
checksum errors.  But I don't and not all packets are exhibiting checksum
errors between the two machines.  Only some.  Of course, this is manifesting
itself in slower than expected throughput between the server and client
since I assume that TCP checksum errors result in retransmits.  The server
is connected to a ZyXEL GS2024 switch via LACP 802.3ad with 1 IP address in
use in the two-NIC bonded pipe.  Could this be causing the TCP checksum
errors?

More info on this:  I'm beginning to think that the LACP/IEEE802.3ad
bonding of the server with the switch has nothing to do with it as I'm
seeing the same checksum errors between the client (which only has one NIC
and doesn't use LACP/IEEE802.3ad) and public servers hosted at akamai.net,
doubleclick.com, etc., and even my externally hosted mail server.


--
Reality Artisans, Inc.             #   Network Wrangling and Delousing
P.O. Box 565, Gracie Station       #   Apple Certified Consultant
New York, NY 10028-0019            #   Apple Consultants Network member
<http://www.realityartisans.com>   #   Apple Developer Connection member
(212) 369-4876 (Voice)             #   My PGP public key can be found
at <https://keyserver.pgp.com>




___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
            mailto:wireshark-users-request () wireshark org?subject=unsubscribe

___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request () wireshark org?subject=unsubscribe

Current thread: