rms@ACC-SB-UNIX.ARPA (Ron Stoughton) (06/17/86)
There have been some inquiries lately regarding the inter-operability of X.25 with 1822 using PSN 6.0 in Standard mode. I believe a subsequent reply stated that PSN 6.0 supports such inter-operability. Recent testing we have done at customer sites has confirmed this, but some problems appear to exist in the PSN 6.0 software. A couple of these are described below in an effort to assist users attempting to connect to MILNET using Standard mode X.25. We would appreciate hearing from anyone experiencing similar problems since debugging of such can be very time consuming. Battle #1: This configuration consisted of our IBM MVS host in Columbia connected to the same IMP as our VAX running 4.2 BSD Unix. The VAX system was connected via an ACC IF-11/HDH interface running HDH (1822-J) packet mode at 19.2K bps. The IBM system was connected via an ACC IF-370/DDN interface running X.25 Standard at 57.6K bps. The problem occurred when attempting to log onto the IBM system from a VAX terminal using Telnet and manifested itself has a permanent hang condition during the logon sequence. The hang occurred when the IBM system sent a long message prompting for input. This message was sent across the X.25 interface as a 2-packet sequence (128-byte packet size) and was sent across the HDH interface as a 3-packet sequence (leader packet plus two data packets). However, the middle packet was 134 bytes in length which is a violation of the HDH protocol which specifies a middle packet length in the range of 2 to 126 bytes. This oversize packet was dutifully discarded by the HDH interface, thus causing a subsequent retransmission by TCP which repeated the error. Battle #2: This configuration consisted of an IBM VM host located at the Navy Yard (NARDAC) connected to a PSN 6.0 IMP via an ACC IF-370/DDN interface running X.25 Standard at 9.6K bps. It was discovered that FTPing the host table from the NIC took an extraordinarily long time (it actually appeared to be hung) and caused X.25 packet-level errors at our interface. However, transferring the same file from our IBM host in Columbia completed as expected and without error. In this case our IBM host in Columbia was connected via an ACC IF-370/1822 interface running distant host 1822 across a 9.6K bps ECU connection to the PSN 5.0 IMP at NIH. The NIC is connected to its local MILNET PSN 5.0 IMP via a BBN 1822 interface running in local or distant mode. Being a local IMP connection, the NIC interface will run at the asynchronous speed of the C/30's 1822 interface. We investigated this further with a Chameleon X.25 Data Analyzer and found the PSN 6.0 IMP was transmitting several IP datagrams concatenated together into a single X.25 packet sequence (i.e., the M-bit was set for several [how about 14?] successive X.25 packets). Each full-size (576-byte) IP datagram was also truncated to two 128-byte X.25 packets. In other words, the sequence of packets was: Packet Content 1 TCP/IP Header [Datagram n, Len=576], Data, M=1 2 Data, M=1 3 TCP/IP Header [Datagram n+1, Len=576], Data, M=1 4 Data, M=1 5 TCP/IP Header [Datagram n+2, Len=576], Data, M=1 6 Data, M=1 7 TCP/IP Header [Datagram n+3, Len=576], Data, M=1 8 Data, M=1 9 TCP/IP Header [Datagram n+4, Len=576], Data, M=1 10 Data, M=1 . . . . . . The proper sequence should have been: Packet Content 1 TCP/IP Header [Datagram n, Len=576], Data, M=1 2 Data, M=1 3 Data, M=1 4 Data, M=1 5 Data, M=0 6 TCP/IP Header [Datagram n+1, Len=576], Data, M=1 7 Data, M=1 8 Data, M=1 9 Data, M=1 10 Data, M=0 . . . . . . The above two problems are similar in that they both occur at the packet level and the data source is much faster than the data sink. However, since one occurs in HDH and the other in X.25, I don't expect they are related. Battle #3 We are still investigating this problem, but some preliminary info may be of interest to the community. We have multiple sites connected with identical IF-370/DDN interfaces to PSN 6.0 IMPs. All but one are running without problems except as noted above. The exception is 1ISG which is unable to run at all due to the IMP rejecting our call request packets. The indication from the IMP is that our precedence facility code is being administratively disallowed. Both ACC and BBN have compared the configuration parameters of the various IMPs and found them to be the same. In order to eliminate our hardware as the culprit, we canned some X.25 sequences on the Chameleon and fired them at the IMP to see what it would do. As expected, it accepted call requests as long as they didn't contain the precedence facility. One would conclude that there is an obvious difference in the configuration of the IMP port to which we are attached, but so far it has eluded BBN. Anyone with similar X.25 battle stories is encouraged to share them with the tcp/ip community so that we don't debug the same problem multiple times. Ron Stoughton RMS@ACC-SB-UNIX.ARPA