[TUHS] 2.10

[TUHS] 2.10

[Jacob Ritorto]

Hi all,
  Wanting to set up an 11/34 or 11/23 with a unix that's at least
contemporary enough to run telnet and ftp.  From what I can gather on line,
I guess 2.10 is the best shot, but it's apparently a little less popular
and I can't fin enough docs about it to determine if it'll run with the
hardware I have.  Am I on the right track here, or should I be considering
backporting the programs to 2.9?  Pointers to 2.10 Setup manual would be
most welcome as well as suggestions on where to find other resources to
meet this goal..

thx
jake
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20141120/81febd5b/attachment.html>

[TUHS] 2.10

[Nick Downing]

Is there any special reason why you want to use 2.09 or 2.10 rather than
the latest, 2.11? Is it because of your hardware requirements, I think
possibly 2.11 requires split I/D right? Anyway the best way to answer your
question is to try it out in SIMH. I do know that 2.11 has a modern TCP/IP
stack, which is backported from 4.3 or thereabouts (it does not suppprt
some advanced features such as syn cookies, so it was not backported from
the latest, but it's pretty modern still). I would be interested to know if
2.09 or 2.10 have the same TCP/IP stack as 2.11, my feeling is they don't.
cheers, Nick
On 21/11/2014 12:34 PM, "Jacob Ritorto" <jacob.ritorto at gmail.com> wrote:

> Hi all,
>   Wanting to set up an 11/34 or 11/23 with a unix that's at least
> contemporary enough to run telnet and ftp.  From what I can gather on line,
> I guess 2.10 is the best shot, but it's apparently a little less popular
> and I can't fin enough docs about it to determine if it'll run with the
> hardware I have.  Am I on the right track here, or should I be considering
> backporting the programs to 2.9?  Pointers to 2.10 Setup manual would be
> most welcome as well as suggestions on where to find other resources to
> meet this goal..
>
> thx
> jake
>
>
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20141121/251bc9ad/attachment.html>

[TUHS] 2.10

[Jacob Ritorto]

Jim / Nick,  That's kinda my problem: can't find enough documentation on
2.10 to ascertain if I can / should run it. I know 2.9 is OK for the 11/34,
but 2.9 doesn't have telnet or ftp and I want this machine to be easily
reachable on the net.

  From what I've read, 2.11 is right out except for the little glimmer of
hope in the docs that it "would probably only require a moderate amount of
squeezing to fit on machines with less memory, but it would also be very
unhappy about the prospect," which I think roughly translates to, "don't
try it on a puny thing like an 11/34."

  I wonder if porting telnet and ftp to 2.9 on the 11/34 would be my best
hope?  But with a much more antique tcp stack, it sounds daunting.


On Thu, Nov 20, 2014 at 9:05 PM, Jim Carpenter <jim at deitygraveyard.com>
wrote:
>
>
> 2.10 and 2.11 require split I/D, right? I'm positive 2.9 was the
> latest I could run on my 11/34.
>
> Jim
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20141120/7e451367/attachment.html>

[TUHS] 2.10

[Cory Smelosky]

On Thu, 20 Nov 2014, Jacob Ritorto wrote:

> Jim / Nick,  That's kinda my problem: can't find enough documentation on
> 2.10 to ascertain if I can / should run it. I know 2.9 is OK for the 11/34,
> but 2.9 doesn't have telnet or ftp and I want this machine to be easily
> reachable on the net.
>

Was it branched from the CSRG tree or was it implemented third-party?  I 
can search my copy of the SCCS tree and see what it would've included if 
the former is the case.

>  From what I've read, 2.11 is right out except for the little glimmer of
> hope in the docs that it "would probably only require a moderate amount of
> squeezing to fit on machines with less memory, but it would also be very
> unhappy about the prospect," which I think roughly translates to, "don't
> try it on a puny thing like an 11/34."
>
>  I wonder if porting telnet and ftp to 2.9 on the 11/34 would be my best
> hope?  But with a much more antique tcp stack, it sounds daunting.
>

Wonder if ULTRIX-11 would work on an 11/34 or if the usermode stack would 
run under MINIX-UNIX

>

-- 
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects

[TUHS] 2.10

[Cory Smelosky]

On Thu, 20 Nov 2014, Cory Smelosky wrote:

> On Thu, 20 Nov 2014, Jacob Ritorto wrote:
>
>> Jim / Nick,  That's kinda my problem: can't find enough documentation on
>> 2.10 to ascertain if I can / should run it. I know 2.9 is OK for the 11/34,
>> but 2.9 doesn't have telnet or ftp and I want this machine to be easily
>> reachable on the net.
>> 
>
> Was it branched from the CSRG tree or was it implemented third-party?  I can 
> search my copy of the SCCS tree and see what it would've included if the 
> former is the case.
>

Oh, nevermind.  Looks like I have an archive containing 2.10 source and 
(maybe) some binaries.

# Machine type
# 2.10 runs on:
#	11/24/34/44/53/60/70/73/83/84
#	11/23/35/40/45/50/55 with 18 or 22 bit addressing
# 2.10 WILL NOT run on:
#	T11, 11/03/04/05/10/15/20/21
#	11/23/35/40/45/50/55 with 16 bit addressing
# 2.10 networking will run on:
#	11/44/53/70/73/83/84
#	11/45/50/55 with 18 bit addressing

#ifndef lint
static char sccsid[] = "@(#)telnetd.c   5.19 (Berkeley) 7/27/87";
#endif not lint


-- 
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects

[TUHS] 2.10

[Clem Cole]

I don't think the BSD networking code in 2.10 worked on systems with only
256K bytes of memory.  The kernel is too big even without networking and a
lot of work was done to push things out of the kernel. [The 17th bit (split
I/D) really only mattered for user space, the kernel mapped things around -
but with only 18 bits of address map there is not much space]. Adding
networking and in particular the space for the mbuf's becomes a real issue.


Here are some thoughts..

1.) Easiest/Cheapest solution might be to front end the system with an RPi,
Intel Edison or the like and run the IP stack on it and then use one or
more serial ports from the micro to 11.

2.) See if you can dig up an old copy of the 3 COM's first product - UNET -
which was the original TCP/IP for V7.  It's old and not very sexy, but the
kernel requirements are minimal and if all you want it telnet & FTP that
will work.

3.) If you have real hardware, see if you can find an old Able "Enable"
board which will allow you to put 4Megs of memory in an 40 class processor
(you get a cache plus a new memory MAP with 22 bits of address like the 45
class processors).   I had 2.X working on that years ago (and wrote a
USENIX paper on it).  The Enable board support was in the BSD 2*
distributions (I put there) but I doubt its been tried in many years.

4.) Ultrix-11 should boot on a 40 class system, but I do not remember if on
the 18 bit machines you could configure networking.   Armando might
remember if Fred ever made that work.  If any one could have or would have,
it would have been Fred.  As I said, there just is not a lot of space and
frankly there is not going to be a lot of space left for user programs.

Clem

PS I remember running V6 on 11/34 with 48K bytes of memory for a few months
as our memory for that system was back ordered.  It was slow, but it worked
and we were happy.  It was our machine!!

On Thu, Nov 20, 2014 at 7:32 PM, Jacob Ritorto <jacob.ritorto at gmail.com>
wrote:

> Hi all,
>   Wanting to set up an 11/34 or 11/23 with a unix that's at least
> contemporary enough to run telnet and ftp.  From what I can gather on line,
> I guess 2.10 is the best shot, but it's apparently a little less popular
> and I can't fin enough docs about it to determine if it'll run with the
> hardware I have.  Am I on the right track here, or should I be considering
> backporting the programs to 2.9?  Pointers to 2.10 Setup manual would be
> most welcome as well as suggestions on where to find other resources to
> meet this goal..
>
> thx
> jake
>
>
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20141120/cebdf591/attachment.html>

[TUHS] 2.10

[Cory Smelosky]

On Thu, 20 Nov 2014, Clem Cole wrote:

> I don't think the BSD networking code in 2.10 worked on systems with only
> 256K bytes of memory.  The kernel is too big even without networking and a
> lot of work was done to push things out of the kernel. [The 17th bit (split
> I/D) really only mattered for user space, the kernel mapped things around -
> but with only 18 bits of address map there is not much space]. Adding
> networking and in particular the space for the mbuf's becomes a real issue.
>

It's unsupported; see my email where I pasted the "HCL" from 2.10's 
GENERIC config.

>
> Here are some thoughts..
>
> 1.) Easiest/Cheapest solution might be to front end the system with an RPi,
> Intel Edison or the like and run the IP stack on it and then use one or
> more serial ports from the micro to 11.
>

Well, 2.10 has SLIP, but it'd certainly be easier to implement a simple 
userland tool to talk to a frontend!

> 2.) See if you can dig up an old copy of the 3 COM's first product - UNET -
> which was the original TCP/IP for V7.  It's old and not very sexy, but the
> kernel requirements are minimal and if all you want it telnet & FTP that
> will work.
>

That I am pretty sure I DO NOT have source for.

> 3.) If you have real hardware, see if you can find an old Able "Enable"
> board which will allow you to put 4Megs of memory in an 40 class processor
> (you get a cache plus a new memory MAP with 22 bits of address like the 45
> class processors).   I had 2.X working on that years ago (and wrote a
> USENIX paper on it).  The Enable board support was in the BSD 2*
> distributions (I put there) but I doubt its been tried in many years.
>

That sounds like a neat board.  Betting it's a bit hard to find, though. 
;)

> 4.) Ultrix-11 should boot on a 40 class system, but I do not remember if on
> the 18 bit machines you could configure networking.   Armando might
> remember if Fred ever made that work.  If any one could have or would have,
> it would have been Fred.  As I said, there just is not a lot of space and
> frankly there is not going to be a lot of space left for user programs.
>

I'd check but I'm pretty sure I don't have Ultrix-11 sources. :(

> Clem
>
> PS I remember running V6 on 11/34 with 48K bytes of memory for a few months
> as our memory for that system was back ordered.  It was slow, but it worked
> and we were happy.  It was our machine!!
>

What were you using for paging/swapping on that?

-- 
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects

[TUHS] 2.10

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1551 bytes --]

On Thu, Nov 20, 2014 at 10:55 PM, Cory Smelosky <b4 at gewt.net> wrote:

> Well, 2.10 has SLIP,

​SLIP means you still need the IP stack
​ (serial-line-ip)​
.  It ​
​just replaces an ethernet driver with a serial port.




> but it'd certainly be easier to implement a simple userland tool to talk
> to a frontend!


​Actually there was tool that was almost all in userland to support
multiple sessions over single serial line between a Macs a UNIX system.  My
memory is that it used Chesson's multiplexer (mpx) which is part of stock
V7 (his is pre-select system call).​  I wish I could remember the name of
that program.  But I bet it or something like it could be repurposed pretty
quickly to talk to a frontend micro.

Biggest issue is interrupt overhead on serial ports on the 11.   If this is
real HW, see you can find a real DEC DH or better yet - an Able DH/DM.  DH
style interfaces will be a huge difference over DL's or DZs.  DZs were pigs
on Vaxen and on an 11 a line at 19.2K continuous could kill it.

BTW:  I thought of another option.  It's not telnet or ftp, but if your
desire is move files back and forth without having to use a common physical
media and sneaker-net, BSD 2x should have the BerkNET code in it.   That
will run on an serial line - although my previous comment about the type of
interface can matter from a performance standpoint.

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20141120/ab5a1bb6/attachment.html>

[TUHS] 2.10

[Cory Smelosky]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 758 bytes --]

On Thu, 20 Nov 2014, Clem Cole wrote:

> On Thu, Nov 20, 2014 at 10:55 PM, Cory Smelosky <b4 at gewt.net> wrote:
>
> ​just replaces an ethernet driver with a serial port.
>

Mmmm, right.  I figured.

>
>
>
> BTW:  I thought of another option.  It's not telnet or ftp, but if your
> desire is move files back and forth without having to use a common physical
> media and sneaker-net, BSD 2x should have the BerkNET code in it.   That
> will run on an serial line - although my previous comment about the type of
> interface can matter from a performance standpoint.
>

I take it you actually understand BERKNET's addressing then?  I could 
never figure it out!

> Clem
>

-- 
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects

[TUHS] 2.10

[Jacob Ritorto]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3199 bytes --]

Hilariously, I actually do have an enable-34 board in my stash.. Just saw
it in the last week or so & will dig it out in next few days.  So does that
single board contain the memory and everything, or is this a backplane
mod/special memory kind of setup?

I'd be eager to run Ultrix jut for the extra flavor (I've only done the
bsds on my pdp11s thus far), but one of my real desires here is to have the
machine behave itself as a pretty normal net citizen, connecting through
some sort of ethernet and running legit telnetd and ftpd.  That said, I
won't be too sad if that's impossible and kludges are required, but it is
my initial hope.  I guess I need to first ascertain exactly which 11/34 I
have, how much ram I can scrounge up, which addressing scheme, etc. then
move on to what I can actually do, software-wise, with the kit.

With the enable34 board, do I have some hope of getting 2.11bsd on this
one?  Sounds like that'd avoid a lot of the more sporty software
modifications and let me have something that works like a "normal"
modern-ish system.  But then, I do have an 11/73 I'm working on that could
run that build much more easily and appropriately..  I guess I'm up for
whatever is most historically appropriate, a good match for the hardware
and at least able to be present on a contemporary network without
intermediary kludge hardware.

thx
jake



On Fri, Nov 21, 2014 at 12:46 AM, Clem Cole <clemc at ccc.com> wrote:

>
> On Thu, Nov 20, 2014 at 10:55 PM, Cory Smelosky <b4 at gewt.net> wrote:
>
>> Well, 2.10 has SLIP,
>
> ​SLIP means you still need the IP stack
> ​ (serial-line-ip)​
> .  It ​
> ​just replaces an ethernet driver with a serial port.
>
>
>
>
>> but it'd certainly be easier to implement a simple userland tool to talk
>> to a frontend!
>
>
> ​Actually there was tool that was almost all in userland to support
> multiple sessions over single serial line between a Macs a UNIX system.  My
> memory is that it used Chesson's multiplexer (mpx) which is part of stock
> V7 (his is pre-select system call).​  I wish I could remember the name of
> that program.  But I bet it or something like it could be repurposed pretty
> quickly to talk to a frontend micro.
>
> Biggest issue is interrupt overhead on serial ports on the 11.   If this
> is real HW, see you can find a real DEC DH or better yet - an Able DH/DM.
> DH style interfaces will be a huge difference over DL's or DZs.  DZs were
> pigs on Vaxen and on an 11 a line at 19.2K continuous could kill it.
>
> BTW:  I thought of another option.  It's not telnet or ftp, but if your
> desire is move files back and forth without having to use a common physical
> media and sneaker-net, BSD 2x should have the BerkNET code in it.   That
> will run on an serial line - although my previous comment about the type of
> interface can matter from a performance standpoint.
>
> Clem
>
>
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20141121/7fbbc1d9/attachment.html>

[TUHS] 2.10

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4277 bytes --]

Re: enable-34 - There are no backplane mods.  As I recall it used normal
memory, just enabled the top bits in the address map which were not driven
by the 40 class processors.   I'll see if I can dig up some doc for it,
which I might still have.   I'm traveling, so this will have to wait for a
few days.

As for running 2.11bsd - I can't say as I never tried it.  What the enable
board will do it give you 4Megs of memory. By using thunks and the memory
map, the enable will allow the kernel to have I/O buffers, mbufs, and a
kernel I space that can grow beyond the 64k address limit - plus still have
room for  a few user processes in memory at the same time.

RE: ultrix vs BSD 2* -- Once it's running, I don't think you are going to
find a lot differences mostly in what was packaged in the defaults system -
just shades of grey.  Much less than the flavors of Linux these days IMO.

Clem

On Fri, Nov 21, 2014 at 12:13 AM, Jacob Ritorto <jacob.ritorto at gmail.com>
wrote:

> Hilariously, I actually do have an enable-34 board in my stash.. Just saw
> it in the last week or so & will dig it out in next few days.  So does that
> single board contain the memory and everything, or is this a backplane
> mod/special memory kind of setup?
>
> I'd be eager to run Ultrix jut for the extra flavor (I've only done the
> bsds on my pdp11s thus far), but one of my real desires here is to have the
> machine behave itself as a pretty normal net citizen, connecting through
> some sort of ethernet and running legit telnetd and ftpd.  That said, I
> won't be too sad if that's impossible and kludges are required, but it is
> my initial hope.  I guess I need to first ascertain exactly which 11/34 I
> have, how much ram I can scrounge up, which addressing scheme, etc. then
> move on to what I can actually do, software-wise, with the kit.
>
> With the enable34 board, do I have some hope of getting 2.11bsd on this
> one?  Sounds like that'd avoid a lot of the more sporty software
> modifications and let me have something that works like a "normal"
> modern-ish system.  But then, I do have an 11/73 I'm working on that could
> run that build much more easily and appropriately..  I guess I'm up for
> whatever is most historically appropriate, a good match for the hardware
> and at least able to be present on a contemporary network without
> intermediary kludge hardware.
>
> thx
> jake
>
>
>
> On Fri, Nov 21, 2014 at 12:46 AM, Clem Cole <clemc at ccc.com> wrote:
>
>>
>> On Thu, Nov 20, 2014 at 10:55 PM, Cory Smelosky <b4 at gewt.net> wrote:
>>
>>> Well, 2.10 has SLIP,
>>
>> ​SLIP means you still need the IP stack
>> ​ (serial-line-ip)​
>> .  It ​
>> ​just replaces an ethernet driver with a serial port.
>>
>>
>>
>>
>>> but it'd certainly be easier to implement a simple userland tool to talk
>>> to a frontend!
>>
>>
>> ​Actually there was tool that was almost all in userland to support
>> multiple sessions over single serial line between a Macs a UNIX system.  My
>> memory is that it used Chesson's multiplexer (mpx) which is part of stock
>> V7 (his is pre-select system call).​  I wish I could remember the name of
>> that program.  But I bet it or something like it could be repurposed pretty
>> quickly to talk to a frontend micro.
>>
>> Biggest issue is interrupt overhead on serial ports on the 11.   If this
>> is real HW, see you can find a real DEC DH or better yet - an Able DH/DM.
>> DH style interfaces will be a huge difference over DL's or DZs.  DZs were
>> pigs on Vaxen and on an 11 a line at 19.2K continuous could kill it.
>>
>> BTW:  I thought of another option.  It's not telnet or ftp, but if your
>> desire is move files back and forth without having to use a common physical
>> media and sneaker-net, BSD 2x should have the BerkNET code in it.   That
>> will run on an serial line - although my previous comment about the type of
>> interface can matter from a performance standpoint.
>>
>> Clem
>>
>>
>> _______________________________________________
>> TUHS mailing list
>> TUHS at minnie.tuhs.org
>> https://minnie.tuhs.org/mailman/listinfo/tuhs
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20141121/c5970403/attachment.html>

[TUHS] BerkNet

[Erik E. Fair]

	Date: Fri, 21 Nov 2014 01:07:59 -0500 (EST)
	From: Cory Smelosky <b4 at gewt.net>

	I take it you actually understand BERKNET's addressing then? I could 
	never figure it out!

BerkNET was its own thing: it was effectively a store & forward batch/file
based networking system which could handle E-mail, print jobs, and remote
execution of commands for your account on another machine, if you sent the
password to the account along. It's somewhat similar to UUCP, actually. Eric
Schmidt (of Sun, Novell, & Google) wrote the code as a UCB grad student,
because (as I heard it) the Berkeley Computer Center wanted to be paid money
every time an operator had to hang a magtape on a tape drive, and the CS
department was tired of being bled to move small files around.

BerkNet used one single ASCII character designation per machine, originally
just 26 allowed, and later extended to numerals for a total of 36 (before
Ethernet & TCP/IP obsoleted it). The routing table for BerkNet was a
statically-compiled table in every instance of its primary daemon, and if the
network topology changed sufficiently, each daemon had to be modified and
recompiled. No redundancy allowed in the network, if I recall correctly.

Pretty slow convergence for changes to the routing table.

Longer names were also allowed as aliases for the single letter, and that's
what was sent to the rest of the world in E-mail addresses, e.g.
cory:cc-54 at berkeley (Computer Club account #54, on the Cory Hall PDP-11/70;
I think Cory's letter was "y") was my first ARPANET-reachable E-mail address.
There might be some instances of that in the HUMAN-NETS or SF-LOVERS archives
from 1981. I suspect that BerkNet's colon separator for host:file was how
the rcp command got that syntax, and probably how ssh inherited it.

Google turned up the following: http://typewritten.org/Articles/berk-net.html

Being RS-232 serial-based, the interrupt loading was horrific ... so they
restricted the bandwidth to 1200 baud (plus, there were some rather long RS-232
cable runs between buildings), unless you used a serial interface card that
had some input buffering & DMA I/O like the DH-11. The DZ-11 was
contraindicated. To further lower overhead, there's even a TTY line discipline
for BerkNet, so you don't wake up the daemon until a full packet arrives, even
though the TTY interface is set to "raw" mode.

I was for a time a system administrator for the "x" machine at UCB: the Onyx
Z8002 installed for the undergrads in the basement of Evans Hall (room B50).
That's also the machine on which "B news" was written by Matt Glickman.

Later, I ran a small BerkNet (before we got Ethernet) at Dual Systems in
Berkeley, between the Dual 83/80 mc68000-based S-100 systems in the various
departments (engineering, sales, manufacturing/test), before we got an S-100
Ethernet card working and ran thick Ethernet. We were able to run it at 19,200
baud because Dual made some really sweet, 256-byte input buffer, DMA I/O,
4-port serial cards: the SIO-4/DMA, based around the Zilog z8530 DUART.

I insisted that we wait for ARP to be done before we deployed Ethernet &
TCP/IP, because evil old hack of grabbing a Class A IP network number,
pretending that the first three MAC address bytes were always the same (after
all, everyone always uses Ethernet interfaces from the exact same manufacturer
in every host on a given LAN, right?) and mapping the last three MAC bytes
into the host part of the Class A wasn't going to fly in the real world.

The hacks we used to do to make these turkeys fly ...

	Erik <fair at netbsd.org>

[TUHS] BerkNet

[Cory Smelosky]

Sent from my iPhone

> On Nov 26, 2014, at 01:28, Erik E. Fair <fair-tuhs at netbsd.org> wrote:
> 
>    Date: Fri, 21 Nov 2014 01:07:59 -0500 (EST)
>    From: Cory Smelosky <b4 at gewt.net>
> 
>    I take it you actually understand BERKNET's addressing then? I could 
>    never figure it out!
> 
> BerkNET was its own thing: it was effectively a store & forward batch/file
> based networking system which could handle E-mail, print jobs, and remote
> execution of commands for your account on another machine, if you sent the
> password to the account along. It's somewhat similar to UUCP, actually. Eric
> Schmidt (of Sun, Novell, & Google) wrote the code as a UCB grad student,
> because (as I heard it) the Berkeley Computer Center wanted to be paid money
> every time an operator had to hang a magtape on a tape drive, and the CS
> department was tired of being bled to move small files around.

That explains that!

> 
> BerkNet used one single ASCII character designation per machine, originally
> just 26 allowed, and later extended to numerals for a total of 36 (before
> Ethernet & TCP/IP obsoleted it). The routing table for BerkNet was a
> statically-compiled table in every instance of its primary daemon, and if the
> network topology changed sufficiently, each daemon had to be modified and
> recompiled. No redundancy allowed in the network, if I recall correctly.

Heh, looks like I won't bother with Berknet then. ;)

> 
> Pretty slow convergence for changes to the routing table.

To say the least!

> 
> Longer names were also allowed as aliases for the single letter, and that's
> what was sent to the rest of the world in E-mail addresses, e.g.
> cory:cc-54 at berkeley (Computer Club account #54, on the Cory Hall PDP-11/70;
> I think Cory's letter was "y") was my first ARPANET-reachable E-mail address.
> There might be some instances of that in the HUMAN-NETS or SF-LOVERS archives
> from 1981. I suspect that BerkNet's colon separator for host:file was how
> the rcp command got that syntax, and probably how ssh inherited it.
> 
> Google turned up the following: http://typewritten.org/Articles/berk-net.html
> 
> Being RS-232 serial-based, the interrupt loading was horrific ... so they
> restricted the bandwidth to 1200 baud (plus, there were some rather long RS-232
> cable runs between buildings), unless you used a serial interface card that
> had some input buffering & DMA I/O like the DH-11. The DZ-11 was
> contraindicated. To further lower overhead, there's even a TTY line discipline
> for BerkNet, so you don't wake up the daemon until a full packet arrives, even
> though the TTY interface is set to "raw" mode.
> 
> I was for a time a system administrator for the "x" machine at UCB: the Onyx
> Z8002 installed for the undergrads in the basement of Evans Hall (room B50).
> That's also the machine on which "B news" was written by Matt Glickman.

What OS did that machine run? I don't think BSD unless it was elsewhere in the tree.

> 
> Later, I ran a small BerkNet (before we got Ethernet) at Dual Systems in
> Berkeley, between the Dual 83/80 mc68000-based S-100 systems in the various
> departments (engineering, sales, manufacturing/test), before we got an S-100
> Ethernet card working and ran thick Ethernet. We were able to run it at 19,200
> baud because Dual made some really sweet, 256-byte input buffer, DMA I/O,
> 4-port serial cards: the SIO-4/DMA, based around the Zilog z8530 DUART.

I'd love a 68k S-100 system.

> 
> I insisted that we wait for ARP to be done before we deployed Ethernet &
> TCP/IP, because evil old hack of grabbing a Class A IP network number,
> pretending that the first three MAC address bytes were always the same (after
> all, everyone always uses Ethernet interfaces from the exact same manufacturer
> in every host on a given LAN, right?) and mapping the last three MAC bytes
> into the host part of the Class A wasn't going to fly in the real world.

Yeah...that would not have worked well. ;)

> 
> The hacks we used to do to make these turkeys fly ...
> 
>    Erik <fair at netbsd.org>

[TUHS] BerkNet

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3825 bytes --]

Erik - nice job.   A couple of additions/corrections.

On Wed, Nov 26, 2014 at 1:28 AM, Erik E. Fair <fair-tuhs at netbsd.org> wrote:

>
>
> BerkNET was its own thing:
> ​...
> It's somewhat similar to UUCP
>
​Right , like UUCP you could copy files.​



> because (as I heard it) the Berkeley Computer Center wanted to be paid
> money
> every time an operator had to hang a magtape on a tape drive, and the CS
> department was tired of being bled to move small files around.
>
​Never heard that story.  While there was never a great deal of love
between EECS and the BCC, the reason (I believe) was so that folks in
Evan's could send email to the ArpaNET.  The only connection to the Arpanet
was the Ingress (11/70) in Cory.​   UCB did not have it's own IMP, LBL had
one up the hill and a "long host adapter" was used between Cory and one of
the ports on the LBL IMP.   It was not until much later, when UCB finally
got a C30 in Evans during the CSRG time that there was much more than email
support.  Horton lurks on this list and might remember/know for sure.




>
>  No redundancy allowed in the network, if I recall correctly.
>
​I'm not sure what you mean by this.   It was a point to point network like
UUCP, but unlike UUCP routing was handled by the protocol (as you said -
the tables were compiled into the code).​




>
> Pretty slow convergence for changes to the routing table.
>
​i.e. manually done.   BTW: the Arpanet was not much better at the time​




>
> I suspect that BerkNet's colon separator for host:file was how
> the rcp command got that syntax, and probably how ssh inherited it.
>
​Nice idea - but no.  Sam & Eric Cooper modeled rcp from the program of the
same name at PARC for the Altos.​  PARC is also what gave us routed BTW.



>
> Google turned up the following:
> http://typewritten.org/Articles/berk-net.html
>
> unless you used a serial interface card that
> had some input buffering & DMA I/O like the DH-11.

​Right - the 70s mostly had DH11's which were a full "system unit" on the
unibus (they are all SSI/MSI TTL - pretty amazing actually).    Many Vaxen
had DZ's which were a mess.   Once the Able DH/DM came out, most of us
switched to them and those lines ran at 9.6 or 19.2, but they were short
lived, with the entry the 3M ethernet board that linked the CAD group's
Vaxen, the Ingress machines and the machine room in Evans.​




> I insisted that we wait for ARP to be done before we deployed Ethernet &
> TCP/IP, because evil old hack of grabbing a Class A IP network number,
> pretending that the first three MAC address bytes were always the same
> (after
> all, everyone always uses Ethernet interfaces from the exact same
> manufacturer
> in every host on a given LAN, right?) and mapping the last three MAC bytes
> into the host part of the Class A wasn't going to fly in the real world.
>
​Sigh - that was me in 1979...  when Glaser and I did original IP stack
with 3COM (aka UNET) @ Tektronix and since we were not (yet) on the
Internet, it did not matter[BTW: look at the HyperChannel code - there are
worse addressing hacks in there].  While I knew about MIT's ChaoNet I had
never seen the code.   The MIT guys did ARP for ChaosNet which quickly
migrated down the street to BBN for the 4.1 IP stack.  Remember that BBN
had the contract to do IP for UNIX and that was the stack a number of us
ran on our Vaxen for long time [IIRC - Sam actually did the routed and rcp
stuff which the BBN stack, before Joy had rewritten it - created the
sockets interface etc].




>
> The hacks we used to do to make these turkeys fly ...

​Hey it worked just fine at the time.

Clem​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20141126/1695a0ff/attachment.html>

[TUHS] BerkNet

[Dave Horsfall]

On Tue, 25 Nov 2014, Erik E. Fair wrote:

> I suspect that BerkNet's colon separator for host:file was how the rcp 
> command got that syntax, and probably how ssh inherited it.

That could also explain why ACSnet's first incarnation also used a colon 
separator (you'll see me as "dave:csu40" in some early AUUGN editions; 
that's me at the University of NSW Computing Services Unit 11/40).

-- 
Dave Horsfall DTM (VK2KFU)  "Bliss is a MacBook with a FreeBSD server."
http://www.horsfall.org/spam.html (and check the home page whilst you're there)

[TUHS] BerkNet

[Dan Cross]

On Wed, Nov 26, 2014 at 1:24 PM, Clem Cole <clemc at ccc.com> wrote:

> [snip]  The MIT guys did ARP for ChaosNet which quickly migrated down the
> street to BBN for the 4.1 IP stack.  Remember that BBN had the contract to
> do IP for UNIX and that was the stack a number of us ran on our Vaxen for
> long time [IIRC - Sam actually did the routed and rcp stuff which the BBN
> stack, before Joy had rewritten it - created the sockets interface etc].
>

This brings up something I've been meaning to ask about for a while now.
Whatever happened to the BBN stack after the BSD stack became dominant?  Is
any of the code still available anywhere?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20141126/3b81aab7/attachment.html>

[TUHS] BerkNet

[Clem Cole]

BBN did a second release that used the sockets.    At Stellar we used that
stack, not the UCB stack, since we were taking System V and adding BSD to
it.  Since the author of the BBN stack (Rob Gurwitz) was with us, it was
felt that the BBN stack was actually better in many ways.  In particular,
we had a parallel machine and it was felt that the BBN stack would be
easier/cleaner to multi-thread.

I can ask around, I lost track of the code base after Stellar.   tjt might
still know.

On Wed, Nov 26, 2014 at 1:35 PM, Dan Cross <crossd at gmail.com> wrote:

> On Wed, Nov 26, 2014 at 1:24 PM, Clem Cole <clemc at ccc.com> wrote:
>
>> [snip]  The MIT guys did ARP for ChaosNet which quickly migrated down the
>> street to BBN for the 4.1 IP stack.  Remember that BBN had the contract to
>> do IP for UNIX and that was the stack a number of us ran on our Vaxen for
>> long time [IIRC - Sam actually did the routed and rcp stuff which the BBN
>> stack, before Joy had rewritten it - created the sockets interface etc].
>>
>
> This brings up something I've been meaning to ask about for a while now.
> Whatever happened to the BBN stack after the BSD stack became dominant?  Is
> any of the code still available anywhere?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20141126/b2561a33/attachment.html>

[TUHS] BerkNet

[Mary Ann Horton]

On 11/25/2014 10:48 PM, Cory Smelosky wrote:
>
> I was for a time a system administrator for the "x" machine at UCB: the Onyx
> Z8002 installed for the undergrads in the basement of Evans Hall (room B50).
> That's also the machine on which "B news" was written by Matt Glickman.
> What OS did that machine run? I don't think BSD unless it was elsewhere in the tree.
>
>
I seem to recall it was a V7 port.  I recall copying (initially with cu 
and ~%put, later with UUCP and Berknet) over Berkeley tools like vi and 
porting them.  The Z8000 was a 16 bit processor.

http://olduse.net/sites/ucbonyx.txt

[TUHS] BerkNet

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 528 bytes --]

On Thu, Nov 27, 2014 at 11:42 AM, Mary Ann Horton <mah at mhorton.net> wrote:

> I seem to recall it was a V7 port.


​That is right.  They showed it off/announced it at the Delaware USENIX
conference.  I remember all of us being wowed by it.​  It was a single 19"
so called 2U box and included the disk inside.   Incredible small and
(quiet) for the time.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20141129/7a513bf0/attachment.html>

[TUHS] BerkNet

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 371 bytes --]

On Thu, Nov 27, 2014 at 3:40 PM, Dave Horsfall <dave at horsfall.org> wrote:

> With any luck, that software has *not* been archived :-)


​Well other than as an example of bad programming, I agree.​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20141129/e86b2419/attachment.html>

[TUHS] BerkNet

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3672 bytes --]

On Thu, Nov 27, 2014 at 9:38 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

>
> Not sure exactly what you're referring to here (the concept of an internet
> as a collection of networks seems to have occurred to a number of people,
> see the Internet Working Group notes from the early 70s).
>
​Your probably right on this.   Dave was first person I knew that really
formalized the idea of a network of networks.  As has been pointed out by
others in lots of contexts, technologies like the Internet had many fathers
and really were the combined efforts of a lot of good ideas.

That said, at the time, the prevailing wisdom at places like IBM, DEC,
Wang, much less ISO, was the networking was a closed thing and not
something where you wanted follow "Metacalfe's Law."   But to make
Metacalfe's law working in a distributed architecture like the Arpanet and
later the Internet, the idea of the network of networks had to really
become reality.   i.e. some site change at CMU should have no bearing on
MIT.​





>
>     > Dave once quipped: "Why does a change at CMU have to affect MIT?"
>
> Subnets (which first appeared at MIT, due to our, ah, fractured
> infrastructure) again were an idea which occurred to a number of people all
> at the same time; in part because MIT's CHAOSNET already had a collection
> of
> subnets (the term may in fact come from CHAOSNET, I'd have to check) inside
> MIT.
>

​This was before IP and Subnets.  It was something we did at CMU WRT our
IMP that affected everyone else.​



> Ah, I see, it's
> described in RFC-917 - it's ARP sub-netting, but instead of the first-hop
> router answering the ARP based on its subnet routing tables, it did
> something
> where ARP requests were flooded across the entire network.
>
​I had left CMU by then.​


> MIT, CMU and Stanford all got the 3Mbit Ethernet at about the same time, as
> part of the same university donation scheme. (I don't recall UCB being part
> of that - maybe they got it later?)
>
​Right, UCB did not get Alto's or Dovers.  I'm not sure how, we did get
some of the networking cards, which we used to connect the CAD and Ingress
groups in Cory Hall to Ernie friends that CS had in Evans.




>
> The donation included a couple of UNIBUS 3Mbit Ethernet cards (a hex card,
>
> ​Yup, single hex card with TTL on it and a ethernet tap in a small
​aluminum case that was yellow IIRC
Maybe UCB was able to buy them from who ever was making them for Xerox in
the lower bay.  I really do not remember any of those details of how we got
them at UCB.  Bob Kridle and/or Asa Romberg must have been mixed up in it.
I just remember running the cables between/through the building one weekend
with Bob and Asa.   Eric Cooper giving me the BBN tape so I could hack the
code in the CAD machines and I brought the changes to Ken Arnold for the
Ingress systems.

I do not remember ARP being in that code base BTW, but it might have been.
It must have been the first time I saw references to Chaonet code base
however as I think there was a SupDup implementation in there.  The naming
scheme for open(2) was the old MIT hack of letting nami() discover the
protocol and leaving the string of the host to open in the nami buffer and
passing that to the protocol code.



> I can give you the exact data, if you care, because Dave Clark and I had
> a competition to see who could be done first, and the judge (Karen Sollins)
> declared it a draw, and I still have the certificate! :-)


​Great story...​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20141129/36b485ad/attachment.html>

[TUHS] BerkNet

[Dave Horsfall]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 597 bytes --]

On Wed, 26 Nov 2014, Clem Cole wrote:

>​Hey when we did it, we were trying to a UNIX machine to talk to CDC Cyber
> and an VMS/VAX.   No routers.  We were happy to just have those systems
> communicating ;-)

So I'm not the only one to get file transfer working with the UT-200 
protocol?  They were represented as card input and printer output, with 
some horrible kludgery.

With any luck, that software has *not* been archived :-)

-- 
Dave Horsfall DTM (VK2KFU)  "Bliss is a MacBook with a FreeBSD server."
http://www.horsfall.org/spam.html (and check the home page whilst you're there)

[TUHS] BerkNet

[Noel Chiappa]

    > From: jnc at mercury.lcs.mit.edu (Noel Chiappa)

    > The replacement, the first Link-State routing algorithm, worked much,
    > much, better; but it still had minor issues
    >
    > damping fixed most of those too).

Oop, the editor 'ate' a line there (or, rather the editor's operator spaced
out :-): it should say "it still had minor issues, such as oscillation
between two equal-cost paths, with the traffic 'chasing itself' from path to
path; proper damping fixed most of those too".


    > I always give Dave Clark credit (what I call "Clark's Observation") for
    > the most powerful part of the replacement for the ARPAnet - aka the
    > idea of a network of network.

Not sure exactly what you're referring to here (the concept of an internet
as a collection of networks seems to have occurred to a number of people,
see the Internet Working Group notes from the early 70s).

    > Dave once quipped: "Why does a change at CMU have to affect MIT?"

Subnets (which first appeared at MIT, due to our, ah, fractured
infrastructure) again were an idea which occurred to a number of people all
at the same time; in part because MIT's CHAOSNET already had a collection of
subnets (the term may in fact come from CHAOSNET, I'd have to check) inside
MIT.

    > I've forgotten what we did at CMU at the time, but I remember the MIT
    > folk were not happy about it.

I used to know the answer to that, but I've forgotten what it was! I have this
bit set that CMU did something sui generis, not plain ARP sub-netting, but I
just can't remember the details! (Quick Google search...) Ah, I see, it's
described in RFC-917 - it's ARP sub-netting, but instead of the first-hop
router answering the ARP based on its subnet routing tables, it did something
where ARP requests were flooded across the entire network.

No wonder we disapproved! :-)


    > Thought, didn't you guys have the 3Mbit stuff like we did at CMU and
    > UCB first?

MIT, CMU and Stanford all got the 3Mbit Ethernet at about the same time, as
part of the same university donation scheme. (I don't recall UCB being part
of that - maybe they got it later?)

The donation included a couple of UNIBUS 3Mbit Ethernet cards (a hex card,
IIRC) the first 3MB connections at MIT were i) kludged into one of the MIT-AI
front-end 11's (I forget the details, but I know it just translated CHAOS
protocol packets into EFTP so they could print things on the Dover laser
printer), and ii) a total kludge I whipped up which could forward IP packets
back and forth between the 3M Ethernet, and the other MIT IP-speaking LANs.
(It was written in MACRO-11, and with N interfaces, it used hairy macro
expansions to create separate code for each of all 'N^2' possible forwarding
paths!) Dave Clark did the Alto TCP/IP implementation (which was used to
create a TFTP->EFTP translating spooler for IP access to the Dover).

I can give you the exact data, if you care, because Dave Clark and I had
a competition to see who could be done first, and the judge (Karen Sollins)
declared it a draw, and I still have the certificate! :-)

	Noel

[TUHS] BerkNet

[Jesus Cea]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1020 bytes --]

On 26/11/14 19:49, Noel Chiappa wrote:
> The first attempt at this (basically a Destination-Vector algorithm, i.e. like
> RIP but with non-static per-hop costs) didn't work too well, for reasons I
> won't get into unless anyone cares.

I do care :).

-- 
Jesús Cea Avión                         _/_/      _/_/_/        _/_/_/
jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
Twitter: @jcea                        _/_/    _/_/          _/_/_/_/_/
jabber / xmpp:jcea at jabber.org  _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20141127/c874d057/attachment.sig>

[TUHS] BerkNet

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3068 bytes --]

below.

On Wed, Nov 26, 2014 at 1:49 PM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

>     > From: Clem Cole
>
> A few comments on aspects I know something of:
>
>
>     > BTW: the Arpanet was not much better at the time
>
> The people at BBN might disagree with you... :-)
>

​Fair enough...
​


>
> But seriously, throughout its life, the ARPANET had 'load-dependent
> routing',
> i.e. paths were adjusted not just in response to links going up or down,
> but
> depending on load (so that traffic would avoid loaded links).
>
> The first attempt at this (basically a Destination-Vector algorithm, i.e.
> like
> RIP but with non-static per-hop costs) didn't work too well, for reasons I
> won't get into unless anyone cares. The replacement, the first Link-State
> routing algorithm, worked much, much, better; but it still had minor issues
>
> damping fixed most of those too).
>
​You're right of course.  I was referring more to the fact that changes
tended to be an issue​.

I always give Dave Clark credit (what I call "Clark's Observation") for the
most powerful part of the replacement for the ARPAnet - aka the idea of a
network of network.   Dave once quipped:  "Why does a change at CMU have to
affect MIT?"  I've forgotten what we did at CMU at the time, but I remember
the MIT folk were not happy about it.




>
>
>     > DH11's which were a full "system unit"
>
> Actually, two; they were double (9-slot, I guess?) backplanes.
>
​Right.
​


>
>
>     > The MIT guys did ARP for ChaosNet which quickly migrated down the
> street
>     > to BBN for the 4.1 IP stack.
>
> Actually, ARP was jointly designed by David Plummer and I for use on both
> TCP/IP and CHAOS (which is why it has that whole multi-protocol thing
> going);
> we added the multi-hardware thing because, well, we'd gone half-way to
> making
> it totally general by adding multi-protocol support, so why stop there?
>
Thanks, ​I never knew that.  Makes sense.




>
> As soon as it was done it was used on a variety of IP-speaking MIT machines
> that were connected to a 10MBit Ethernet; I don't recall them all, but one
> kind was the MIT C Gateway multi-protocol routers.
>
​Thought, didn't you guys have the 3Mbit stuff like we did at CMU and UCB
first?  ​




>
>
>     > Hey it worked just fine at the time.
>
> For some definition of 'work'! (Memories of wrapping protocol A inside
> protocol B, because some intervening router/link didn't support protocol A,
> only B...)


​Hey when we did it, we were trying to a UNIX machine to talk to CDC Cyber
and an VMS/VAX.   No routers.  We were happy to just have those systems
communicating ;-)

I was not smart enough to see something like ARP - which later seemed like
such a D'oh moment.

Then again -- at the time 48 bits of Ethernet was supposed to me "enough"
and you were not going to need anything else.  Funny how it all worked out.​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20141126/e37468b1/attachment.html>

[TUHS] BerkNet

[Noel Chiappa]

    > From: Clem Cole

A few comments on aspects I know something of:


    > BTW: the Arpanet was not much better at the time

The people at BBN might disagree with you... :-)

But seriously, throughout its life, the ARPANET had 'load-dependent routing',
i.e. paths were adjusted not just in response to links going up or down, but
depending on load (so that traffic would avoid loaded links).

The first attempt at this (basically a Destination-Vector algorithm, i.e. like
RIP but with non-static per-hop costs) didn't work too well, for reasons I
won't get into unless anyone cares. The replacement, the first Link-State
routing algorithm, worked much, much, better; but it still had minor issues

damping fixed most of those too).


    > DH11's which were a full "system unit"

Actually, two; they were double (9-slot, I guess?) backplanes.


    > The MIT guys did ARP for ChaosNet which quickly migrated down the street
    > to BBN for the 4.1 IP stack.

Actually, ARP was jointly designed by David Plummer and I for use on both
TCP/IP and CHAOS (which is why it has that whole multi-protocol thing going);
we added the multi-hardware thing because, well, we'd gone half-way to making
it totally general by adding multi-protocol support, so why stop there?

As soon as it was done it was used on a variety of IP-speaking MIT machines
that were connected to a 10MBit Ethernet; I don't recall them all, but one
kind was the MIT C Gateway multi-protocol routers.


    > Hey it worked just fine at the time.

For some definition of 'work'! (Memories of wrapping protocol A inside
protocol B, because some intervening router/link didn't support protocol A,
only B...)

     Noel