[comp.protocols.tcp-ip] TCP/SMTP ULTRIX <-> MULTICS PROBLEM

scottr@csc-lons.csv001.tv.ARPA (Scott W. Rogers) (12/31/87)

 I'm having a problem receiving some (SMTP) mail from a MULTICS host on
 my ULTRIX 1.2 and 2.0 (binary, sigh) VAX 8600 and 8650 systems.

 I can send mail to MULTICS without any problem, and most mail is
 received.  The problem is as follows:

    After the SMTP initialization, MULTICS sends a 51 character 'MAIL
    From: <username.mailbox.qualification.etc>' string which is never
    acknowledged by ULTRIX.  The MULTICS engineer says that his system
    is not receiving the TCP ACK even after several retrys and changing
    his timeout from 1 to 2 minutes.

    ULTRIX nevers sees the connection drop, and sendmail hangs.

    The next time MULTICS mail is received (every 15 minutes), a new
    sendmail process is spawned, and the same problem occurs.  This
    quickly stuffs the process table full of sendmail processes.

    The problem is completely reproducable through MAIL.  Using TELNET,
    the Multics engineer was able to produce it only sometimes.

    Notes:  The same problem occurs with ULTRIX 2.0 over DDN thru 2
    PSN's and ULTRIX 1.2 when MULTICS is on the same PSN.  I don't know
    if this provides any great insight to anyone.

    Also, TELNET connections to MULTICS work, but tend to hang/drop
    after some period of time.  I'm not sure of the relation, but if
    the problem lies in the TCP/IP code ...   DEC, are you listening !

 If anyone has had similar problems, or has a solution, or even any
 idea's, please let me know.

				Thanks.

				    Scott W. Rogers
				    scottr@csc-lons.arpa
----

DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer) (12/31/87)

    Date: Wed, 30 Dec 87 12:24:00 est
    From: scottr@csc-lons.csv001.tv.ARPA (Scott W. Rogers)

     If anyone has had similar problems, or has a solution, or even any
     idea's, please let me know.

Look for TCP checksum errors on both ends.  If you don't have a counter
for such things, you should.

Ata@RADC-MULTICS.ARPA ("John G. Ata") (01/01/88)

    Delivery-Date:  30 December 1987 12:36 est
    Delivery-By:  Network_Server.Daemon (tcp-ip-RELAY@SRI-NIC.ARPA)
    Date:  Wednesday, 30 December 1987 12:24 est
    From:  scottr at CSC-LONS.CSV001.TV (Scott W. Rogers)
    Subject:  TCP/SMTP ULTRIX <-> MULTICS PROBLEM
    To:  tcp-ip at SRI-NIC
    cc:  cscmaint at RADC-LONS
    
     I'm having a problem receiving some (SMTP) mail from a MULTICS host on
     my ULTRIX 1.2 and 2.0 (binary, sigh) VAX 8600 and 8650 systems.
    
     I can send mail to MULTICS without any problem, and most mail is
     received.  The problem is as follows:
    
        After the SMTP initialization, MULTICS sends a 51 character 'MAIL
        From: <username.mailbox.qualification.etc>' string which is never
        acknowledged by ULTRIX.  The MULTICS engineer says that his system
        is not receiving the TCP ACK even after several retrys and changing
        his timeout from 1 to 2 minutes.

The connection seems to go comotose.  We send the 51 character packet
out, and retransmit a number of times, but the ACK never arrives.  Our
logs show no checksum errors or any other kind of error.  We have tried
it with different size packets, but strangly enough 51 seems to be the
magic number causing this problem.
    
          .
          .
          .
    
        The problem is completely reproducable through MAIL.  Using TELNET,
        the Multics engineer was able to produce it only sometimes.

This problem is also completely reproducable by opening a TELNET
connection to CSC-LONS mail server and simulating a message.

This problem appears to affect certain ULTRIX sites, but not all of
them.  We chose some ULTRIX sites at random and they seemed to work ok.
Suspect that they are running a different version of TCP/SMTP.

                    John G. Ata
          Site Technical Specialist at RADC-MULTICS

mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett) (01/02/88)

This may sound somewhat ridiculous but try padding the message so that the data
length is either modulo 2 or modulo 4 bytes (octets) in length.  Not all DEC
interfaces are necessarily byte oriented.

Merton Campbell Crockett
EATON Information Management Systems