ROKI@D.ISI.EDU (08/08/86)
Folks,
Following is a short description of a problem which seems to be a bug in
the TCP-IP code at D.ISI.EDU [10.0.0.27] (Tops20) concerning the computation
of a wrong TCP checksum when an IP Source Route Option is specified.
While the fact that a problem exists has been evident (after exchanging a
number of correct (!) packets) in each TCP connection from DFVLR2 [128.7.0.2]
via DFVLR4-X25 [14.0.0.16] (specified as IP Source Route Option) to
D.ISI.EDU [10.0.0.27], it was much more difficult to discover the bug.
Since this problem might occur on other TOPS20 machines as well, I am
sending this message not only to the host administrator of D.ISI.EDU, but
to the TCP-IP and INENG-TF list as well.
INTERNET Configuration:
----------------------
To route packets from the (SATNET isolated) DFVLR-net [128.7.x.x] to
D.ISI.EDU [10.0.0.27] through the PDN [14.x.x.x] and to get packets back
on the same path via the BBN-VAN-GW [14.0.0.10] and DFVLR4-X25 [14.0.0.16],
in the current (poor) routing situation, the local VAN-GW (DFVLR4-X25),
has to be specified as an IP Source Route Option by an user on the DFVLR-net.
DFVLR2 DFVLR4-X25 BBN-VAN-GW D.ISI.EDU
[128.7.0.2] [128.7.0.4,14.0.0.16] [14.0.0.10,10.3.0.40] [10.0.0.27]
DFVLR-net ! PDN ! ARPANET
^
Monitoring
Fortunately D.ISI.EDU uses the specified IP Source Route Option [14.0.0.16]
even in its reply packets and therefore after opening an TCP connection to
D.ISI.EDU packets were routed back on the same path via DFVLR4-X25 to DFVLR2
and received there correctly.
However after receiving a number of packets with a correct TCP checksum at
DFVLR2, only packets (retransmissions) with a bad TCP checksum were
received and therefore discarded, so the connection was blocked (no more
data exchange).
After implementing some monitor tools behind the X.25 interface at
DFVLR4-X25 (monitoring the packets as transmitted over X.25 PDN), I found
that those packets look fine (no corruption), but already contain a wrong
TCP checksum.
TCP-checksum:
------------
As you know the TCP checksum also covers a 96 bit pseudo header which contains
the Source Address, Destination Address, Protocol and TCP length.
When recomputing the TCP checksum (TCP header + data + pseudo header) using
a pseudo header of
10 0 0 27
128 7 0 2
0 6 length
I got another TCP checksum as contained in the packet. Since the TCP header
and the data looked fine, I played around with some possible computations of
modified TCP pseudo headers and finally (surprise !) I got the same (wrong)
TCP checksum as transmitted in the packet, when using a Destination Address
of 14.0.0.16, which is the Destination Address in the IP Header before the
packet reaches DFVLR4-X25 [14.0.0.16] (IP Source Route Option), but must
never be specified as the Destination Address in the TCP Pseudo Header.
Thus with the following TCP pseudo header:
10 0 0 27
14 0 0 16 (instead of 128 7 0 2)
0 6 length
I computed the TCP checksum contained in the packet.
Assuming that no intermediate host or gateway between D.ISI.EDU and
DFVLR4-X25 recomputes the TCP checksum, I guess that the wrong TCP checksum
is already computed at the source (D.ISI.EDU).
NOTE: Before receiving packets with this bad TCP checksum (14.0.0.16 as
Destination Address in TCP pseudo header), I am receiving packets
with correct TCP checksum (128.7.0.2). I have no idea what causes this
switch, however I have found packets (in which 14.0.0.16 is used to
compute the TCP checksum) only in packets with an ODD (!) number of data
bytes.
Monitoring Dump:
---------------
Herewith I enclose a dump of two packets (both might be retransmissions),
which were received immediately one after the other over an virtual circuit
through PDN (X.25) from the BBN-VAN-GW at DFVLR4-X25 (dumped immediately
after the X.25 interface).
While the first packet (IP Source Route specified, ACK only, 52 bytes, 0 data
bytes) contains a correct TCP checksum (assuming 128.7.0.2 as destination
in the TCP pseudo header), the TCP checksum computation of the second packet
(IP Source Route, 53 bytes, 1 data byte (@)) seems to use 14.0.0.16 as the
destination address in the TCP pseudo header. A bad TCP checksum was
therefore computed at the destination DFVLR2 [128.7.0.2] and the packet
was discarded.
Good packet (IP Source Route specified, ACK only, 52 bytes, 0 data bytes):
-------------------------------------------------------------------------
72 0 0 52 83 135 0 0 58 6 98 125 10 0 0 27 14 0 0 16
VIHL TOS Length Ident. Fl/Frag TTL Pro HChksum Source Destination
131 11 8 10 0 0 27 128 7 0 2 0 0 23 16 0 52 151 0 203
SRR len poi route (source) (destination) pad !SPort DPort Sequence Numb.
4 165 127 231 80 16 3 190 87 237 0 0
Acknowl. number Offs ACK Window Chksum Urg.Poi
TCP OK
TCP Pseudo Header:
10 0 0 27 128 7 0 2 0 6 0 20
Source Address Destin. Address Zer PTCL length
Bad packet (IP Source Route specified, ACK only, 52 bytes, 0 data bytes):
-------------------------------------------------------------------------
72 0 0 53 79 175 0 0 54 6 106 84 10 0 0 27 14 0 0 16
VIHL TOS Length Ident. Fl/Frag TTL Pro HChksum Source Destination
131 11 8 10 0 0 27 128 7 0 2 0 0 23 16 0 52 151 0 202
SRR len poi route (source) (destination) pad !SPort DPort Sequence Numb.
4 165 127 231 80 24 3 190 137 222 0 0 64 (0)
Acknowl. number Offs ACK Window Chksum Urg.Poi !Data
PSH TCP BAD,
should be
23 229
Assumed TCP Pseudo Header:
10 0 0 27 14 0 0 16 0 6 0 21
Source Address Destin. Address Zer PTCL length
should be
128 7 0 2
Debugging:
---------
For a debugging session similar packets should be reproduceable. Does anybody
has seen similar problems ? (Perhaps somebody could try !?)
Thanks for any comments and fixing the problem.
Best regards,
Carl-H. Rokitansky (Roki)
--------------------------
PS.: Currently I'm routing my packets by means of a cludge (assignment of
[14.0.0.16] to DFVLR2 !!)
-------