Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site ut-ngp.UTEXAS Path: utzoo!linus!decvax!ucbvax!ucdavis!lll-crg!gymble!umcp-cs!seismo!ut-sally!ut-ngp!clyde From: clyde@ut-ngp.UTEXAS (Clyde W. Hoover) Newsgroups: net.bugs.4bsd,net.unix-wizards Subject: Loss of RFNM (w/fix) Message-ID: <2476@ut-ngp.UTEXAS> Date: Thu, 10-Oct-85 18:30:47 EDT Article-I.D.: ut-ngp.2476 Posted: Thu Oct 10 18:30:47 1985 Date-Received: Sat, 12-Oct-85 07:42:38 EDT Distribution: net Organization: UTexas Computation Center, Austin, Texas Lines: 63 Xref: linus net.bugs.4bsd:1497 net.unix-wizards:12353 Subject: Loss of RFNMs on ARPAnet hosts Index: /sys/netimp/if_imp.h 4.2BSD NOTE: This is **not applicable** unless the modifications from Chris Kent (cak@purdue.ARPA, posted 21 March 1984) have been made to /sys/netinet/tcp_output.c. These modifications advertise a maximum TCP segment size that is tuned per network interface. Description: Connections to certain hosts on the ARPAnet will start failing with "out of buffer space" messages. Doing a 'netstat -h' shows that the host (or the gateway to it) has a RFNM count of 8. The RFNM count never drops below 8 and so the network path is unusable until the system is rebooted. The problem lies in the LH/DH-11 IMP interface. Sometimes, most likely always, it will not set the flag in the control & status register if the input buffer is filled at the same time that from the IMP comes up. This causes the LH/DH driver to append the next incoming message from the IMP to the the previous message. This process (appending of messages) will continue until a message SHORTER then the input buffer size is sent -- a RFNM response does nicely. This results in the LOSS of the succeeding messages (e.g. RFNMs) since the 1822 protocol handling code expects to get only message from the LH/DH at a time. This problem happens when the IMP MTU is advertised as the TCP maximum segment size (as is done by the TCP changes from cak@purdue). This allows an incoming message to be 1006 + 12 bytes long, which equals the size of the 1018 byte input buffer in the IMP (I believe) and so exercises the bug in the LH/DH. Fix: /sys/netimp/if_imp.h: /* * When IMPMTU based on 8159 is advertised as the TCP maximum * segment size, it exercises a bug in the LH/DH-11 that causes small * messages (e.g. RFNMs) to be dropped. So we just arbitrarily * shrink this number until it falls below the bug threshold. * #define IMPMTU ((8159 / NBBY) & ~01) * ^^^^ */ #define IMPMTU ((8000 / NBBY) & ~01) As long as all incoming messages are less than or equal to 576 + 12 bytes long. Since 576 + 12 bytes is less then 1018 bytes, the size of the input driver buffer, the end of message flag in the control&status register is always set correctly. -- Shouter-To-Dead-Parrots @ Univ. of Texas Computation Center; Austin, Texas "All life is a blur of Republicans and meat." -Zippy the Pinhead clyde@ngp.UTEXAS.EDU, clyde@sally.UTEXAS.EDU ...!ihnp4!ut-ngp!clyde, ...!allegra!ut-ngp!clyde