TCP Checksum Interoperability
Chris Trobridge <CTrobridge@baltimore.com> Fri, 05 April 2002 10:55 UTC
Received: from loki.ietf.org (loki [10.27.2.29]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01507; Fri, 5 Apr 2002 05:55:39 -0500 (EST)
Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id FAA24987 for ietf-outbound.10@loki.ietf.org; Fri, 5 Apr 2002 05:54:01 -0500 (EST)
Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id FAA24962 for <ietf-mainout@loki.ietf.org>; Fri, 5 Apr 2002 05:52:17 -0500 (EST)
Received: by ietf.org (8.9.1a/8.9.1a) id FAA01483 for ietf-mainout; Fri, 5 Apr 2002 05:52:12 -0500 (EST)
X-Authentication-Warning: ietf.org: majordom set sender to owner-ietf@ietf.org using -f
Received: from stonewall.baltimore.com (mailhost.baltimore.com [193.41.18.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA01478 for <ietf@ietf.org>; Fri, 5 Apr 2002 05:52:04 -0500 (EST)
Message-ID: <F86F34FDF1F9D411B7A40008C74C27B853776C@baltimore.com>
From: Chris Trobridge <CTrobridge@baltimore.com>
To: ietf@ietf.org
Subject: TCP Checksum Interoperability
Date: Fri, 05 Apr 2002 11:52:33 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DC8F.FD979B90"
Sender: owner-ietf@ietf.org
Precedence: bulk
X-Loop: ietf@ietf.org
I writing to this list because the TCP workgroup was shutdown a while ago. We have a compatibility problem between two third party implementations of the TCP checksum. The problem concerns the representation of zero, which has two 1-s complement representations (0000 and ffff). We don't have source to either stack but I managed to deduce the problem from looking at a packet trace. The receiver drops all datagrams containing a TCP with a TCP checksum of ffff. The receiver appears to be following the checksum procedure in the RFC literally - ie zero checksum, recalculate and check that the result is the complement of what the sender sent. The problem is that the sender and receiver don't agree about zero and hence the datagram is dropped silently. My view is that the receiver is in error; it should be checking the special case of 0. All the receiver code I have seen doesn't work this way. The normal approach is to calculate the1-s complement sum with checksum in place and check that this is zero. The methods I konw always return just one representation for zero, hence there is no special case. Any thoughts? Thanks, Chris ----------------------------------------------------------------------------------------------------------------- The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Baltimore Technologies plc will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on. In addition, certain Marketing collateral may be added from time to time to promote Baltimore Technologies products, services, Global e-Security or appearance at trade shows and conferences. This footnote confirms that this email message has been swept by Baltimore MIMEsweeper for Content Security threats, including computer viruses.
- TCP Checksum Interoperability Chris Trobridge
- Re: TCP Checksum Interoperability Lloyd Wood
- Re: TCP Checksum Interoperability Rob Austein
- Re: TCP Checksum Interoperability Joe Touch
- Re: TCP Checksum Interoperability Joe Touch
- RE: TCP Checksum Interoperability Michael Smith
- RE: TCP Checksum Interoperability Lloyd Wood
- Re: TCP Checksum Interoperability Rob Austein
- Re: TCP Checksum Interoperability J. Noel Chiappa
- Re: TCP Checksum Interoperability Lloyd Wood
- Re: TCP Checksum Interoperability Bob Braden
- Re: TCP Checksum Interoperability Rob Austein
- Re: TCP Checksum Interoperability Matt Crawford
- Re: TCP Checksum Interoperability Lloyd Wood
- Re: TCP Checksum Interoperability Daniel Senie
- Re: TCP Checksum Interoperability Fred Baker
- Re: TCP Checksum Interoperability Rob Austein
- RE: TCP Checksum Interoperability Chris Trobridge
- SLA concept in Intserv/RSVP Nguyen Thi Mai Trang
- Re: SLA concept in Intserv/RSVP Alex Audu