Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA
Path: utzoo!watmath!clyde!cbosgd!ihnp4!ucbvax!MIT-BITSY.MIT.EDU!jis
From: jis@MIT-BITSY.MIT.EDU (Jeffrey I. Schiller)
Newsgroups: fa.tcp-ip
Subject: problems getting to CISL-SERVICE-MULTICS
Message-ID: <8509300400.AA02010@MIT-BITSY.MIT.EDU>
Date: Mon, 30-Sep-85 00:00:25 EDT
Article-I.D.: MIT-BITS.8509300400.AA02010
Posted: Mon Sep 30 00:00:25 1985
Date-Received: Tue, 1-Oct-85 03:26:17 EDT
Sender: daemon@ucbvax.ARPA
Reply-To: tcp-ip@ucb-vax.arpa
Organization: The ARPA Internet
Lines: 16

Actually the situation with CISL-SERVICE-MULTICS is more complicated
then that. CISL is running an IP/TCP which doesn't understand about
any other network but net 10 (The ArpaNet). There is a kludge installed
in its IP that sends any non-net-10 packet to MIT-MULTICS who then
routes it apropriately.

Now MIT-MULTICS is constrainted to not send packets greater then 200
bytes (because if it does, the IMP it is plugged into crashes... a problem
(unresolved now for over two years) with message mode HDH support in
the IMP). So chances are now that CISL is sending you 572 byte packets
which are being fragmented by MIT-MULTICS. It is quite possible that
either your reassembly code is bad or MIT-MULTICS's fragmentation code
is bad (MIT-MULTICS's TCP arranges never to send segments that would
be fragmented by the IP layer). Some IP tracing would probably help.

			-Jeff