From Alan at AI.AI.MIT.EDU  Fri Feb 26 18:26:00 1988
From: Alan at AI.AI.MIT.EDU (Alan Bawden)
Date: Feb 26 88 12:26 EST
Subject: What the heck is this?
Message-ID: <880226122631.0.ALAN@PIGPEN.AI.MIT.EDU>

These connections to ELBERETH.RUTGERS.EDU have been in this state since
sometime yesterday.  I'm going to take a crash dump into
AI:CRASH;TCP ELBERE and reload the system so that we can free up some
network channels.


AI ITS 1615  Peek 629   2/26/88 11:14:28  Up time = 19:21:17:00
IMP is up.   TCP/IP is available.
Ix Usr Uname  Jname  State   RWnd Ibf SWnd ReTxQ Lclprt Fgnprt Fgnhst
 5   6 15TLNT TELSER OPEN    5170  0 10000 0   0     27   2012 MONK.PROTEON.COM
 4  20 406T20 TCP    OPEN   11324  0 10000 0   0  10263     31 ATHENA.MIT.EDU
 0  24 406T24 TCP    SYNSNT  5170  0     0 1   0  12264     31 WALKER-EMH.ARPA
23                   TIMWT   5170  0 20000 0   0     31   6150 ELBERETH.RUTGERS.EDU
22                   TIMWT   5170  0 20000 0   0     31   3302 ELBERETH.RUTGERS.EDU
21                   TIMWT   5170  0 20000 0   0     31   5746 ELBERETH.RUTGERS.EDU
20                   TIMWT   5170  0 20000 0   0     31   3305 ELBERETH.RUTGERS.EDU
17                   TIMWT   5170  0 20000 0   0     31  10021 TOPAZ.RUTGERS.EDU
16                   TIMWT   5170  0 20000 0   0     31   6717 ELBERETH.RUTGERS.EDU
15                   TIMWT   5170  0 20000 0   0     31   5712 ELBERETH.RUTGERS.EDU
14                   TIMWT   5170  0 20000 0   0     31  11164 ELBERETH.RUTGERS.EDU
13                   TIMWT   5170  0 20000 0   0     31  11602 ELBERETH.RUTGERS.EDU
12                   TIMWT   5170  0 20000 0   0     31  10312 ELBERETH.RUTGERS.EDU
11                   TIMWT   5170  0 20000 0   0     31  11407 ELBERETH.RUTGERS.EDU
10                   TIMWT   5170  0 20000 0   0     31   5727 ELBERETH.RUTGERS.EDU
 7                   TIMWT   5170  0 20000 0   0     31  10614 ELBERETH.RUTGERS.EDU
 6                   TIMWT   5170  0 20000 0   0     31  11226 ELBERETH.RUTGERS.EDU
 3                   TIMWT   5170  0 20000 0   0     31   5235 ELBERETH.RUTGERS.EDU
 2                   TIMWT   5170  0 20000 0   0     31  10015 ELBERETH.RUTGERS.EDU
 1                   TIMWT   5170  0 20000 0   0     31  10340 ELBERETH.RUTGERS.EDU
8 buffers (7 free)

STY Map
    Idx    STY owner   Idx    STY user    Host
T15   6 15TLNT TELSER   12 JNC    CHTN    MONK.PROTEON.COM (TCP)
T16  13 16TLNT TELSER   23 ALAN   P       PIGPEN.AI.MIT.EDU (Chaos)


From DEVON at AI.AI.MIT.EDU  Thu Feb 25 21:27:46 1988
From: DEVON at AI.AI.MIT.EDU (Devon Sean McCullough)
Date: Feb 25 88 15:27:46 EST
Subject: No subject
Message-ID: <331879.880225.DEVON@AI.AI.MIT.EDU>

Suddenly AI is refusing telnet connections and reporting
TCP: SYN queue full
on the console, fairly often.  I have never noticed this before.

From Alan at AI.AI.MIT.EDU  Wed Feb 24 22:39:00 1988
From: Alan at AI.AI.MIT.EDU (Alan Bawden)
Date: Feb 24 88 16:39 EST
Subject: weird MC TCP lossage
In-Reply-To: <331156.880224.GUMBY@AI.AI.MIT.EDU>
Message-ID: <880224163949.6.ALAN@PIGPEN.AI.MIT.EDU>

    Date: Wed, 24 Feb 88 06:25:47 EST
    From: David Vinayak Wallace <GUMBY at AI.AI.MIT.EDU>
    ...  The stats file was very interesting.  COMSAT would wake up,
    connect to some host, deliver all the mail for that host, and then
    choke when it got to the next host for which it had mail.  The way in
    which it choked was interesting:  After the HELO it would read the
    terminating command from the previous connection.

This is the usual situation when some TCP resource runs out.  Opening a new
pair of TCP channels fails, probably with some kind of device full error,
which COMSAT apparently fumbles to produce this behavior.  At least, that's
my theory.  SRA claims that the code in COMSAT couldn't possibly have this
bug, and it must be ITS's fault, but I find this hard to believe given that
no other program that uses TCP shows any kind of analogous behavior.

Unfortunately, it is hard to reproduce this situation so that we can see
what COMSAT is -really- doing.

    ...  I called someone on the ninth floor to ask him to take a crash
    dump, but mc appears not to have come back up....

It looks like it did come back up, but whoever you talked to was typing
total jokes on the console.  Like giving nonexistent commands, and typing
DDT commands to the 8080 front-end, etc.


From GUMBY at AI.AI.MIT.EDU  Wed Feb 24 12:25:47 1988
From: GUMBY at AI.AI.MIT.EDU (David Vinayak Wallace)
Date: Feb 24 88 06:25:47 EST
Subject: weird MC TCP lossage
Message-ID: <331156.880224.GUMBY@AI.AI.MIT.EDU>

I was unable to get any sort of tcp connection to MC this morning.
Chaosnet worked fine.  I logged in; the machine was idle!  Early
morning is often a busy time for ol'MC.

I spied on COMSAT, which was idle most of the time.  The stats file
was very interesting.  COMSAT would wake up, connect to some host,
deliver all the mail for that host, and then choke when it got to the
next host for which it had mail.  The way in which it choked was
interesting:  After the HELO it would read the terminating command
from the previous connection.

For example COMSAT connected to DECWRL.DEC.COM and apparently
delivered lots of mail successfully (one wonders what it was actually
sending, but the remote host seemed happy).  Anyway, when done with
decwrl.dec.com, it tried to talk to some other host, say, bbn.com.
The stats file would say something like "ICP BBN.COM: Bad reply 221
decwrl.dec.com signing off."

Well, this was certainly weird.  I called someone on the ninth floor
to ask him to take a crash dump, but mc appears not to have come back
up.  I don't know what the story is, but it seemed to be happy running
in this weird state.  Perhaps our local TCP frobber can shed some
light on this.