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