From JNC at LCS.MIT.EDU  Tue Jan 31 00:00:00 1989
From: JNC at LCS.MIT.EDU (J. Noel Chiappa)
Date: Tue 31 Jan 89, 00:00
Subject: No subject
In-Reply-To: <19890131201142.2.ALAN@PIGPEN.AI.MIT.EDU>
Message-ID: <12467048716.14.JNC@LCS.MIT.EDU>

    That is, he believed that there was something we could do, -if- we
    knew the machine was about to crash, that would normalize relations
    with the IMP so that the NOC's software not to bitch.

	This sounds sort of bogus to me. The p4200 ARPANet code
doesn't give any warning when *it's* going to crash, but the NOC
people don't seem to be turning p4200 ports off. Maybe it's just the
frequency of the crashes, which proably generate little 'Host X on IMP
Y went down' messages on te NOC console. I could also believe that the MC
IMP code is doing something that causes a message to come out, hence
the turnoff, but I'm not sure how likely this is.

	However, I think the whole issue is moot. According to what I
hear, they are going to turn off the ARPANet in the near future, and
*ALL* the MIT IMP's are going away. If you want any ITS (including MC,
which has out main mail forwarder) to have Internet access after that
date, someone better get busy and write some local net driver for the
machine (and then we can have them all on the Internet, not just MC
and AI).
	You can have Pronet-10 interfaces for all the machines; Mike
Patton has a ton of them, and they're pretty easy to program. I don't
know how many Interlan Unibus Ethernet cards there are, but now that
the 750's are mostly gone there may be a bunch of them too. They are
somewhat harder to program, and you'd also have to write ARP.


	Noel
-------

From Alan at AI.AI.MIT.EDU  Tue Jan 31 21:11:00 1989
From: Alan at AI.AI.MIT.EDU (Alan Bawden)
Date: Jan 31 89 15:11 EST
Subject: No subject
In-Reply-To: <CMM.0.88.602132868.sra@bigboote.LCS.MIT.EDU>
Message-ID: <19890131201142.2.ALAN@PIGPEN.AI.MIT.EDU>

    Date: Sun, 29 Jan 1989 22:07:48 EST
    From: Rob Austein <SRA at lcs.mit.edu>

    Do we actually understand the syndrome well enough to say who all the
    culprits are?

I think so.  According to our spy at SAIL:

	Date: Sun, 29 Jan 89 20:45:30 EST
	From: David Chapman <ZVONA at AI.AI.MIT.EDU>
	...  Joe [Weening] says that SAIL has the same problem with them we
        do, and that it actualy comes not from a change in the TIP software
        but from the NOC monitoring software, which now displays a message
        on the operator's console every time a host does something weird.
	Whatever MC does constitutes something weird, adn tehy get sick of
	seeing it, and so they manually turn off the host interface....

The only thing I would add to this is that according to a drone at the NOC
I tried to get some information out of one day, the "something weird" that
MC does is crash at the wrong time.  That is, he believed that there was
something we could do, -if- we knew the machine was about to crash, that
would normalize relations with the IMP so that the NOC's software not to
bitch.  Needless to say, this isn't very useful if your machine gets errors
that cause it to drop dead without warning (as MC has been doing).

    I know that the NOC does this random shutoff thing, and I think I
    remember hearing that there was a hardware bug on our side;

There is no hardware bug on our side, unless you count the fact that the
processor has a tendency to spontaneously drop dead.  There is nothing
wrong with the LH/DH-11.

    is there also, for example, a software problem in the IMP that causes
    this?

I have been accusing the vaguely defined "IMP software".  It sounds like
software in question doesn't actually run in an IMP, but in some machine at
the NOC.  

	   The reason I ask is that we (well, MIT, or DARPA, or somebody)
    pay lots of money for the IMP ports, and if the NOC is shutting off
    our service because their software can't cope, I think we can
    legitimately give them some grief in the formal sense.  If it's just a
    stupid reaction on their part to a bug (hardware/software,
    our/DEC's/ACC's fault, I don't care), I guess we have to live with it.

It sounds to me like it is a stupid reaction on their part to a software
bug in -their- software.  I don't think it is reasonable that we should
have to live with it.

    If this is BBN's fault beyond the NOC lossage, I think we should kick
    them, hard.  Hell, maybe we should call our congresscritters and
    complain about government waste due to incompetant contractors.

I have never understood the dividing line you draw between uneasonable
behavior that we have to live with and uneasonable behavior that we should
bitch about.  It seems quite clear to me that if you are running a network
like the Arpanet, and your software causes your operators to shut off
service to your users just because they crashed at the wrong moment, then
your customers have legitimate cause to bitch.

From SRA at lcs.mit.edu  Mon Jan 30 04:07:48 1989
From: SRA at lcs.mit.edu (Rob Austein)
Date: Jan 29 1989 22:07:48 EST
Subject: No subject
In-Reply-To: Your message of Sun, 29 Jan 89 18:04:44 EST 
Message-ID: <CMM.0.88.602132868.sra@bigboote.LCS.MIT.EDU>

Do we actually understand the syndrome well enough to say who all the
culprits are?  I know that the NOC does this random shutoff thing, and
I think I remember hearing that there was a hardware bug on our side;
is there also, for example, a software problem in the IMP that causes
this?  The reason I ask is that we (well, MIT, or DARPA, or somebody)
pay lots of money for the IMP ports, and if the NOC is shutting off
our service because their software can't cope, I think we can
legitimately give them some grief in the formal sense.  If it's just a
stupid reaction on their part to a bug (hardware/software,
our/DEC's/ACC's fault, I don't care), I guess we have to live with it.

If this is BBN's fault beyond the NOC lossage, I think we should kick
them, hard.  Hell, maybe we should call our congresscritters and
complain about government waste due to incompetant contractors.

From ZVONA at AI.AI.MIT.EDU  Mon Jan 30 00:04:44 1989
From: ZVONA at AI.AI.MIT.EDU (David Chapman)
Date: Jan 29 89 18:04:44 EST
Subject: No subject
Message-ID: <528214.890129.ZVONA@AI.AI.MIT.EDU>

Oh.  Giving the NOC a hard time is a fine reason; I just didn't know that
there was one.

From Alan at AI.AI.MIT.EDU  Sun Jan 29 23:57:00 1989
From: Alan at AI.AI.MIT.EDU (Alan Bawden)
Date: Jan 29 89 17:57 EST
Subject: No subject
In-Reply-To: <528036.890128.ZVONA@AI.AI.MIT.EDU>
Message-ID: <19890129225728.2.ALAN@PIGPEN.AI.MIT.EDU>

    Date: Sat, 28 Jan 89 22:47:32 EST
    From: David Chapman <ZVONA at AI.AI.MIT.EDU>
    I've deleted ai:sys;net mail a couple times, because I don't think
    people need to be told again the gory details of how the NOC is losing
    and like that.  Somone restored it each time.  Is there a good reason
    for this?

The reason is that I'm pissed at the NOC for making it even less likely
that anyone besides me will bring MC up when it crashes.  It makes me feel
better to publicize their foolishness this way.  I think you have to put up
with it because I do backups, and if I get pushed too hard I may stop doing
that.

From ZVONA at AI.AI.MIT.EDU  Sun Jan 29 04:47:32 1989
From: ZVONA at AI.AI.MIT.EDU (David Chapman)
Date: Jan 28 89 22:47:32 EST
Subject: No subject
Message-ID: <528036.890128.ZVONA@AI.AI.MIT.EDU>

I've deleted ai:sys;net mail a couple times, because I don't think
people need to be told again the gory details of how the NOC is losing
and like that.  Somone restored it each time.  Is there a good reason
for this? 

From ZVONA at AI.AI.MIT.EDU  Wed Jan 18 00:19:51 1989
From: ZVONA at AI.AI.MIT.EDU (David Chapman)
Date: Jan 17 89 18:19:51 EST
Subject: No subject
Message-ID: <521426.890117.ZVONA@AI.AI.MIT.EDU>

AI wasn't talking to the net at all, in or out; Finger for instance
complained that all sockets were in use.  I reset it with lock.

From Alan at AI.AI.MIT.EDU  Mon Jan 16 21:50:00 1989
From: Alan at AI.AI.MIT.EDU (Alan Bawden)
Date: Jan 16 89 15:50 EST
Subject: Unibus Chaosnet board...
In-Reply-To: <12462000174.22.411.4820@KICKI.STACKEN.KTH.SE>
Message-ID: <19890116205029.5.ALAN@PIGPEN.AI.MIT.EDU>

    Date: 12-Jan-89 18:11:30 +0100
    From: Peter Lothberg <ROLL at KICKI.STACKEN.KTH.SE>


    There are tre banks of DIP-switches, what do they do? 
       --------

Presumably two of them are network and host address.  These two should be
right next to eachother, if I recall correctly.  The third must be the
interrupt address.

Take a look at SYSTEM;KSNET >.  Since you can read the network address back
from the board, you should be able to figure out what switches do what by
plugging it in to some machine and playing with it.

From ALAN at AI.AI.MIT.EDU  Sat Jan 14 04:19:19 1989
From: ALAN at AI.AI.MIT.EDU (Alan Bawden)
Date: Jan 13 89 22:19:19 EST
Subject: Don't try this at home!
Message-ID: <519854.890113.ALAN@AI.AI.MIT.EDU>

If you tell ITS that your terminal has 8 columns or less, then when a
**MORE** break happens ITS will try to continue the "**MORE**" onto
the next line by doing "!<cr><lf>".  But (you guessed it) the <lf>
causes a **MORE** break!  The result is a PDL overflow in Exec mode, and
a crashed ITS.  See AI:CRASH;CRASH MORE for an example of this.

From CBF at AI.AI.MIT.EDU  Fri Jan 13 09:00:11 1989
From: CBF at AI.AI.MIT.EDU (Charles Frankston)
Date: Jan 13 89 03:00:11 EST
Subject: Chaosnet through Internet.
Message-ID: <519167.890113.CBF@AI.AI.MIT.EDU>

We did run chaos packets through the Internet from Livermore to MIT.  I
think a total of about 10 packets were exchanged since we found that the
fixed Chaos timeouts were ill-suited to the cross country delays and the
accumulated retransmisson packets tickled bugs that caused XX's front end
to crash.  EAK was doing the Livermore end and I think JTW hacked XX's
front end.

From ROLL at KICKI.STACKEN.KTH.SE  Thu Jan 12 18:11:30 1989
From: ROLL at KICKI.STACKEN.KTH.SE (Peter Lothberg)
Date: 12-Jan-89 18:11:30 +0100
Subject: Unibus Chaosnet board...
Message-ID: <12462000174.22.411.4820@KICKI.STACKEN.KTH.SE>


There are tre banks of DIP-switches, what do they do? 
   --------


From JNC at XX.LCS.MIT.EDU  Tue Jan 10 00:00:00 1989
From: JNC at XX.LCS.MIT.EDU (J. Noel Chiappa)
Date: Tue 10 Jan 89, 00:00
Subject: Chaosnet through Internet.
In-Reply-To: <12461385557.1.2.79320@KICKI.STACKEN.KTH.SE>
Message-ID: <12461508265.16.JNC@XX.LCS.MIT.EDU>

	Ahhh, you don't want to know about this. At one point there was a
discussion on using the IP packet protocol to carry around CHAOS streams.
There was never a final, definite scheme on how to do this, although I think
some kludges were in use.
	The rationale was that people would be able to get to a larger number
of machines if you starting using IP packets, and it wouldn't be a major
change. However, the interactions between 'pure' CHAOS machines and machines
using CHAOS wrapped in IP can become tricky. (E.g. how does a 'pure' machine
address a machine with a different high order IP address; 16 bit addresses
don't map into 32 bits.) If you *really* care about this, some old stuff is
online on ML:JNC;CHAOS IN and CHAOS2 *.

	If you want to string a line between your CHAOS net and MIT's, fine,
you might want to allocate subnet numbers from the MIT space. If you're going
through the Internet, use TCP/IP - it almost works.

	Noel
-------

From JMR at KICKI.STACKEN.KTH.SE  Tue Jan 10 09:55:18 1989
From: JMR at KICKI.STACKEN.KTH.SE (Jan Michael Rynning)
Date: 10-Jan-89  9:55:18 +0100
Subject: Chaosnet through Internet.
Message-ID: <12461385557.1.2.79320@KICKI.STACKEN.KTH.SE>


> Date: Sun, 8 Jan 89 15:17 EST
> From: David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
>
> No.  Chaosnet does not bridge through Internet.

So, what's this?  (From RFC 1010 (assigned numbers)):

PROTOCOL NUMBERS

   In the Internet Protocol (IP) [36,80] there is a field, called
   Protocol, to identify the the next level protocol.  This is an 8 bit
   field.

   Assigned Internet Protocol Numbers

      Decimal    Keyword     Protocol                         References
      -------    -------     --------                         ----------
...
          16     CHAOS       Chaos                                 [NC3]
   --------


From ROLL at KICKI.STACKEN.KTH.SE  Mon Jan  9 14:23:39 1989
From: ROLL at KICKI.STACKEN.KTH.SE (Peter Lothberg)
Date: 9-Jan-89 14:23:39 +0100
Subject: Chaos-net adresses
In-Reply-To: <19890108201751.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
References: Message from bug-its@AI.AI.MIT.EDU of  9-Jan-89 14:16:23
Message-ID: <12461172265.28.2.91760@KICKI.STACKEN.KTH.SE>

foo
roll at kicki.stacken.kth.se

Date: Jan 8 89 15:17 EST
Cc: David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
To: Peter Lothberg <ROLL at kicki.stacken.kth.se>
From: bug-its at AI.AI.MIT.EDU
Subject: Chaos-net adresses
Message-Id: <19890108201751.6.MOON at EUPHRATES.SCRC.Symbolics.COM>

>    Date:  8-Jan-89 15:38:08 +0100
>    From: Peter Lothberg <ROLL at KICKI.STACKEN.KTH.SE>
>
>    1,)  How do i set up the chaos net (unibus) board adress, i has no HW doc.
>
>Use the pair of DIP switches.  I don't think there ever was any documentation
>other than the print set.  Did you not get a print set?

No, i did not get the print set for the Unibus board, i did get a drawing for
the the Cardr board.

>    2,)  Do we need to coordinate the chaos-host numbers with the other chaos
>     based hosts @ mit, when (if) we get our KS-ITS to talk to Internet?
>
>No.  Chaosnet does not bridge through Internet.
>
>     If we have to cordinate, if i got this right, i need a subnet here?
>     (we have, 2 KS, MX-Eleven, 2 Cadrs, and a T20 system, total 6)

My thought, was, if it hapens in the future, that we get a bridge somehow,
to the MIT-Chaos, it might be clever to chose a subnet not in use. 

A lesson i learned from the work with the Nordical-Internet implementation
was, 'do it right the first time if possible'.

-peter

   --------


From Moon at STONY-BROOK.SCRC.Symbolics.COM  Sun Jan  8 21:17:00 1989
From: Moon at STONY-BROOK.SCRC.Symbolics.COM (David A. Moon)
Date: Jan 8 89 15:17 EST
Subject: Chaos-net adresses
In-Reply-To: <12460923678.29.411.15980@KICKI.STACKEN.KTH.SE>
Message-ID: <19890108201751.6.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date:  8-Jan-89 15:38:08 +0100
    From: Peter Lothberg <ROLL at KICKI.STACKEN.KTH.SE>

    1,)  How do i set up the chaos net (unibus) board adress, i has no HW doc.

Use the pair of DIP switches.  I don't think there ever was any documentation
other than the print set.  Did you not get a print set?

    2,)  Do we need to coordinate the chaos-host numbers with the other chaos
	 based hosts @ mit, when (if) we get our KS-ITS to talk to Internet?

No.  Chaosnet does not bridge through Internet.

	 If we have to cordinate, if i got this right, i need a subnet here?
	 (we have, 2 KS, MX-Eleven, 2 Cadrs, and a T20 system, total 6)

You need a subnet number for each chaos cable you have.  People whose cables
aren't connected by bridges don't have to coordinate their subnet numbers.
I'd guess that you have one cable and no bridges, so you need one subnet
number.  May as well use 1.

You may have to purge MIT chaosnet addresses out of your host tables, if
you got your host tables by copying the MIT ones.  Otherwise SI might think
it can talk to AI via Chaosnet instead of Internet.

From ROLL at KICKI.STACKEN.KTH.SE  Sun Jan  8 15:38:08 1989
From: ROLL at KICKI.STACKEN.KTH.SE (Peter Lothberg)
Date: 8-Jan-89 15:38:08 +0100
Subject: Chaos-net adresses
Message-ID: <12460923678.29.411.15980@KICKI.STACKEN.KTH.SE>


1,)  How do i set up the chaos net (unibus) board adress, i has no HW doc.
2,)  Do we need to coordinate the chaos-host numbers with the other chaos
     based hosts @ mit, when (if) we get our KS-ITS to talk to Internet?

     If we have to cordinate, if i got this right, i need a subnet here?
     (we have, 2 KS, MX-Eleven, 2 Cadrs, and a T20 system, total 6)

-peter
   --------