The 'Security Digest' Archives (TM)

Archive: About | Browse | Search | Contributions | Feedback
Site: Help | Index | Search | Contact | Notices | Changes

ARCHIVE: TCP-IP Distribution List - Archives (1985)
DOCUMENT: TCP-IP Distribution List for November 1985 (75 messages, 26572 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1985/11.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      01-Nov-85 04:55:54-UT
From:      mills@dcn6.arpa
To:        tcp-ip@sri-nic.arpa
Subject:   Time lurches on
Folks,

They think our giant panda is pregnant, which might be a good omen. Nevertheless,
today an ionospheric glitch blitzed our WWVB radio clock and the host caring
for our WWV clock was several times off-net. Our ritzy new clock-backup
features built into the local-net protocols switched everything around so
our timestamps served to the world had nary a hiccup. However, turns out our
third backup (GOES at Ford Research) had the wrong patchcords, so they were
tracking us. The result was that we both walked the plank, but never swayed
off more than a couple of hundred milliseconds, which is an eon around here.
It was the intent that the GOES clock be the Ford primary, while their sfirst
backup be us and second backup be a WWV clock at U Michigan.

Grin while you might at all this ticking and tocking, but it's great fun and
something refreshingly different. But, as the Potomac Electic technocrat said
when I asked howcum they couldn't keep their clocks straighter, it's not a
tariffed service...

Dave
-------
-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      Mon, 4-Nov-85 17:31:51 EST
From:      DP4Q@TE.CC.CMU.EDU (Drew D. Perkins)
To:        mod.protocols.tcp-ip
Subject:   IBM TR/PCIP/IBM VM

If anyone is interested, I have finished a port of the MIT PC/IP package
to the PC using the Microsoft C Compiler.  I'm still working on how to
distribute it, but if your interested send me mail for now.  Also, using
this code, we have a device driver working with the new IBM token ring
interface.  The code for this will be made available approximately the
same time as the boards are actually available, probably Jan 1.  On another
note, has anyone done the work to provide a UDP interface to the Wisconsin
IBM VM implementation?

Drew
-------

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      Mon 4 Nov 85 17:31:51-EST
From:      Drew D. Perkins <DP4Q@TE.CC.CMU.EDU>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   IBM TR/PCIP/IBM VM
If anyone is interested, I have finished a port of the MIT PC/IP package
to the PC using the Microsoft C Compiler.  I'm still working on how to
distribute it, but if your interested send me mail for now.  Also, using
this code, we have a device driver working with the new IBM token ring
interface.  The code for this will be made available approximately the
same time as the boards are actually available, probably Jan 1.  On another
note, has anyone done the work to provide a UDP interface to the Wisconsin
IBM VM implementation?

Drew
-------
-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      Mon, 4-Nov-85 20:00:09 EST
From:      raj@UCI.EDU (Richard Johnson)
To:        mod.protocols.tcp-ip
Subject:   New nettime fixes

A while back there was a discussion of programs which tried to
get a good idea of the correct time from many hosts on the internet.
I posted information at that time referring to a program here
called nettime.c which we use when bringing up our systems.

I have a few bugs in this program which have now been fixed. 
The newest version is now available via anonymous FTP from "uci.edu".
It is called "pub/nettime.c".  A file containing just the diffs
is called "pub/nettime.diffs".

------------------------------------------------------------------------
Richard Johnson                             raj@uci.edu           (ARPA)
UCI ICS Research Systems Manager            ucbvax!ucivax!raj     (UUCP)

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      Mon, 4-Nov-85 20:26:49 EST
From:      lhl@RSCH.WISC.EDU (L.H. Landweber)
To:        mod.protocols.tcp-ip
Subject:   Re:  IBM TR/PCIP/IBM VM

An unreleased version of wiscnet includes TFTP, a UDP interface,
IP datagram forwarding and significant performance enhancements.
A 3705 bisynch driver, implemented at the university of maryland,
is also included. Several sites are running beta test versions.
Unfortunately, we do not at present have people funding to prepare a 
proper distribution (which hopefully would also include a  domain
name resolver).  There is a possibility this situation will change
soon but this is not yet certain.

Larry Landweber

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      Mon, 4-Nov-85 22:46:11 EST
From:      woo@AMES-NAS.ARPA (Alex Woo)
To:        mod.protocols.tcp-ip
Subject:   Re:  IBM TR/PCIP/IBM VM

I'm interested in trying your PC/IP package in both the MSDOS and XENIX
environment.  Please let me know if you are going to distribute it.

Alex Woo

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      Tue, 5-Nov-85 00:07:51 EST
From:      al@infoswx.UUCP
To:        mod.protocols.tcp-ip
Subject:   TCP/IP on Charles River Universe 68


Has anyone ported TCP/IP to the Charles River Data Systems Computer??

Al Gettier
Teknekron Infoswitch
ihnp4!infoswx!al
convex!infoswx!al

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      Tue, 5-Nov-85 09:22:12 EST
From:      martin%sabre@MOUTON.ARPA (Martin J Levy)
To:        mod.protocols.tcp-ip
Subject:   Subnet Code for 4.2bsd machines - wanted

All,
	I'm looking for subnet routing code for both Suns (v1.2 & 2.0)
and 4.2bsd vaxen. I have seen various notes about code be available on
this and other mailing lists, but before i go with the one i have
(utexas), i am asking again.

	The sun code could be harder to get, but i'm sure someone has
done it.

	This code will be used with a Class B network split into
subnets.

martin levy.  bellcore, nj.

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      Tue, 5-Nov-85 10:41:28 EST
From:      cak@PURDUE.EDU ("Christopher A. Kent")
To:        mod.protocols.tcp-ip
Subject:   Re: Subnet Code for 4.2bsd machines - wanted

The code for the VAXen should work fine on the suns, too -- the IP
implementation is essentially the same. All it takes is source. Even if
you don't have source, try recompiling the inet.c that you use for the
VAX and linking a new kernel for the SUN -- that usually works well.

chris
----------

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      Tue, 5-Nov-85 13:03:04 EST
From:      jsq@ZOTZ.UTEXAS.EDU (John Quarterman)
To:        mod.protocols.tcp-ip
Subject:   Re:  Subnet Code for 4.2bsd machines - wanted

When I asked Sun about subnet code for their OS, they remarked that
they would pick it up when they updated to 4.3BSD, whenever that was
released.  As 4.3BSD has not yet picked up the ARP hack I would guess
Sun won't, either.

With Sun sources, adding the VAX 4.2BSD code should be easy.
Without, difficult.

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6-Nov-85 11:14:00 EST
From:      bierma@NPRDC.ARPA (Larry Bierma)
To:        mod.protocols.tcp-ip
Subject:   UUCP over a TAC?

Greetings,

Is it possible to run uucp through a MILNET TAC?  We are about to place
a PC-AT running XENIX in Washington DC and wan't it to be able to
routinely transfer mail and files to and from our VAX (4.2BSD) here in
San Diego.  We are a MILNET host.  I hate the thought of long distance
phone calls 3-4 times a day.  If anyone has done it would you please
send me the appropriate incantation from your L.sys file (with the
names/numbers changed to protect the innocent of course).

--Larry		ARPA: bierma@nprdc.arpa
		UUCP: {decvax,ucbvax,ihnp4}!sdcsvax!sdcsla!nprdc!bierma
		PSTN: (619) 225-2161

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6-Nov-85 13:46:46 EST
From:      ron@BRL.ARPA (Ron Natalie)
To:        mod.protocols.tcp-ip
Subject:   Re:  UUCP over a TAC?

Running KERMIT and UUCP through the TACS is a miserable idea that
DCA wishes nobody had thought of.  UUCP's link protocol is strange
enough that I don't even know if it's possible to make it work.
TACs are not and can not be made to work in transparent mode.
In addition, they operate with a TCP window of 64 bytes which
would, combined with the general low bandwidth of the MILNET these
days, make your effective rate very, very, slow.

As Col. Maybaum once said, "These guys are ruining my network a character
at a time."

-Ron

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Nov 85 13:46:46 EST
From:      Ron Natalie <ron@BRL.ARPA>
To:        Larry Bierma <bierma@nprdc.arpa>
Cc:        info-unix@BRL.ARPA, tcp-ip@sri-nic.arpa
Subject:   Re:  UUCP over a TAC?
Running KERMIT and UUCP through the TACS is a miserable idea that
DCA wishes nobody had thought of.  UUCP's link protocol is strange
enough that I don't even know if it's possible to make it work.
TACs are not and can not be made to work in transparent mode.
In addition, they operate with a TCP window of 64 bytes which
would, combined with the general low bandwidth of the MILNET these
days, make your effective rate very, very, slow.

As Col. Maybaum once said, "These guys are ruining my network a character
at a time."

-Ron
-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6-Nov-85 16:08:21 EST
From:      schoff@RPICS.CSNET (Martin Lee Schoffstall)
To:        mod.protocols.tcp-ip
Subject:   IP/TCP for XEROX 6085


does anyone know of an implementation for this beast?

marty schoffstall
schoff%rpics.csnet@csnet-relay	ARPA
schoff@rpics			CSNET
seismo!rpics!schoff		UUCP
martin_schoffstall@TROY.NY.USA.NA.EARTH.SOL	UNIVERSENET

RPI
Computer Science Department
Troy, NY  12180
(518) 271-2654

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Nov 85 16:08:21 EST
From:      Martin Lee Schoffstall <schoff%rpics.csnet@CSNET-RELAY.ARPA>
To:        tcp-ip@sri-nic.arpa
Subject:   IP/TCP for XEROX 6085

does anyone know of an implementation for this beast?

marty schoffstall
schoff%rpics.csnet@csnet-relay	ARPA
schoff@rpics			CSNET
seismo!rpics!schoff		UUCP
martin_schoffstall@TROY.NY.USA.NA.EARTH.SOL	UNIVERSENET

RPI
Computer Science Department
Troy, NY  12180
(518) 271-2654

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6-Nov-85 16:25:08 EST
From:      EC0N@TE.CC.CMU.EDU (Eric R. Crane)
To:        mod.protocols.tcp-ip
Subject:   Tektronix TCP/IP for VMS

I am trying to find contacts for any sites out there that are using the 
Tektronix package.  I am about to start doing some work with it here at
Carnegie-Mellon and would like to get others opinions about it.

- Eric R. Crane
  Carnegie-Mellon University
  Computation Center
-------

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      Wed 6 Nov 85 16:25:08-EST
From:      Eric R. Crane <EC0N@TE.CC.CMU.EDU>
To:        tcp-ip@SRI-NIC.ARPA, info-vax@SRI-KL.ARPA
Subject:   Tektronix TCP/IP for VMS
I am trying to find contacts for any sites out there that are using the 
Tektronix package.  I am about to start doing some work with it here at
Carnegie-Mellon and would like to get others opinions about it.

- Eric R. Crane
  Carnegie-Mellon University
  Computation Center
-------
-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6-Nov-85 16:34:00 EST
From:      bierma@NPRDC.ARPA (Larry Bierma)
To:        mod.protocols.tcp-ip
Subject:   Re: Re:  UUCP over a TAC?

It looks like setting up a link with a uucp site in the DC area is the
best solution (Rick@seismo has already generously offered his site).
Thank you all for you responses. 

Ironically enough I'm putting the system in DC to eliminate some of
that "charater at a time" traffic.  The people there now currently
use a TAC to access the VAX(s) here.  But, the eliminated "character"
traffic is now replace by the need for "bulk data" traffic.  Which
it appears can't be done directly.

Is anybody working on a general solution to this problem?  I hope so,
since it's going to get worse.  For the Navy, OPNAVINST 2070.4 requires
use of the DDN as the primary data communications medium.  It seems
silly to permanantly attach a PC to an IMP just for mail and an
occaisonal file transfer.

Maybe something like a dialin UDP port.

--Larry		ARPA: bierma@nprdc.arpa
		UUCP: {decvax,ucbvax,ihnp4}!sdcsvax!sdcsla!nprdc!bierma
		PSTN: (619) 225-2161

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      Thu, 7-Nov-85 09:48:11 EST
From:      adrion@UCBVAX (Rick Adrion)
To:        mod.protocols.tcp-ip
Subject:   Info on Integrated Network Gateways/Relays



The National Science Foundation is engaged in developing  a  net-
work  to  interconnect  its  new  supercomputer  centers with the
scientific community. The network, currently called NSFNET,  will
build  upon  existing  networks  such  as ARPANET, BITNET, CSNET,
MFENET, and the supercomputer center consortium networks.  NSFNET
has  adopted  TCP-IP as an initial standard with plans to move to
the ISO OSI standards when  possible.  For  more  information  on
NSFNET,  contact  Dr.  Dennis Jennings, Program Director for Net-
working, Office of Advanced Scientific Computing,  NSF  (202-357-
9777, nsf-cs@isia).

As part of the NSFNET Project, NSF needs to gain access  to  many
of  the  above  mentioned networks and is seeking information and
advice. NSF hopes to obtain a system which will provide NSF, at a
minimum,  with  direct electronic mail access to ARPANET, BITNET,
and CSNET (and perhaps uucpNET) through a single mail  agent/user
mail interface. The NSF will be directly connected to a number of
physical networks, so the system must support the entire suite of
TCP protocols (Telnet, FTP, SMTP) as well as the BITNET protocols
(RSCS).  NSF is interested in obtaining information  on  any  and
all  systems  which  will  provide these needed services.  Please
provide specifications (e.g., Digital Vax family with 4.2BSD) and
any pertinent details.

NSF has access to BITNET via a leased line to  George  Washington
University,  access to CSNET via Phonenet to the CSNET relay, and
will have ARPANET access early in 1986.

Reply to this account, or to adrion@csnet-sh.arpa

Thanks,
Rick Adrion
Deputy Director, Computer Research, NSF
(202) 357-1185

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      Thu, 7-Nov-85 16:27:12 EST
From:      ron@BRL.ARPA (Ron Natalie)
To:        mod.protocols.tcp-ip
Subject:   Re:  Re: UUCP over a TAC?

You can run TCP/IP over dial up lines, Dave Mills is perhaps the pioneer
in hooking up micros in this fashion.  However, there is no TCP/IP for
the PC yet outside of the MIT code which is pretty bad.  Perhaps Excelan
or CMC will make one of their little protocol cards that will fit into
a PC slot someday.

-Ron

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      Thu, 7 Nov 85 16:27:12 EST
From:      Ron Natalie <ron@BRL.ARPA>
To:        Larry Bierma <bierma@nprdc.arpa>
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re:  Re: UUCP over a TAC?
You can run TCP/IP over dial up lines, Dave Mills is perhaps the pioneer
in hooking up micros in this fashion.  However, there is no TCP/IP for
the PC yet outside of the MIT code which is pretty bad.  Perhaps Excelan
or CMC will make one of their little protocol cards that will fit into
a PC slot someday.

-Ron
-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      Thu, 7-Nov-85 17:28:39 EST
From:      leong%CMU-ITC-LINUS@PT.CS.CMU.EDU (John Leong)
To:        mod.protocols.tcp-ip
Subject:   nasty little 4.2 bug ??


We have encountered a nasty little UNIX 4.2 bug in the way it processes
IP options. If the option length field is 0, it will loop forever. 

It happened that someone (with a PC) accidentally generated an IP packet
with such incorrect option parameter and it also happened that the packet
was sent as an IP broadcast .... quite spectacularly, all our 30 odd
SUN's and miscellaneous 4.2 machines died instantly ......

Is that a known bug and will that be fixed in 4.3 ????

John Leong@*
leong%cmu-itc-linus@@cmu-cs-h

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8-Nov-85 13:37:47 EST
From:      GJC@MIT-MC.ARPA ("George J. Carrette")
To:        mod.protocols.tcp-ip
Subject:   UUCP over a TAC?

Excelan has made one of their protocol boards to fit in the PC slot,
it is on their latest price list. BTW, has anyone used one of these
CMC or Excelan boards with its optional serial port?

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8-Nov-85 15:57:00 EST
From:      Mills@CISL-SERVICE-MULTICS.ARPA
To:        mod.protocols.tcp-ip
Subject:   Zero window probes


          I am wondering what the appropriate action for a TCP
connection that is sending out zero window probes and
recieveing ACKS for the last octet of the window.  For a small
amount of time you obviously want to keep the connection
around in case the window opens. The real question comes in
when the window has been closed for some time.  One argument
is, that if you are recieving valid ACKS the other end is
alive so keep the connection open.  The other is that if has
been that long since you were able to transmit something is
probably wrong with the connection.  In looking in RFC-793
this issue seems to be rather glossed over.  I am using the
September '81 version of the RFC form the protocol transition
workbook.  Is this the up-to-date spec?   Any information or
pointers into the specs would be very helpful.

Thanks,  John Mills

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      Sat, 9-Nov-85 15:48:13 EST
From:      SCARTER@RED.RUTGERS.EDU (Stephen Carter)
To:        mod.protocols.tcp-ip
Subject:   Re:  Re: UUCP over a TAC?

>From: Ron Natalie <ron@BRL.ARPA> 
>To: Larry Bierma <bierma@nprdc.arpa> 
>cc: tcp-ip@sri-nic.arpa 
>Subject: Re: Re: UUCP over a TAC?  
>
> Perhaps Excelan or CMC will make one of their little protocol cards 
>that will fit into a PC slot someday.

Excelan told me that something should be coming in about three months...
-------

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      Sat, 9-Nov-85 15:58:26 EST
From:      SCARTER@RED.RUTGERS.EDU (Stephen Carter)
To:        mod.protocols.tcp-ip
Subject:   Re: UUCP over a TAC?

>Excelan has made one of their protocol boards to fit in the PC slot,
>it is on their latest price list. 

ouch, maybe I was caught in a time warp...
-------

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      Sat, 9-Nov-85 16:11:10 EST
From:      ron@BRL.ARPA (Ron Natalie)
To:        mod.protocols.tcp-ip
Subject:   BRL-GATEWAY

Well the first release of the BRL Gateway has been tested
and known to compile on non-BRL PDP-11 UNIX systems.  Here
is what is supported:

	Ethernet and ARP on Interlan NI1010A boards
	IMPS for both ARPANET and CLASS-B network using LH/DH-11
	DEC PCL-11B
	Hyperchannel on Class C networks
	Proteon Ring Net (V2LNI)
	EGP - Perhaps in a non-standard way, but it is optimized
		for dealing with the way the core is administered today

Hardware Required:
	A PDP-11 with 18 bit memory management.
		This means 11/23,24,44,45,55,60,70,73,84
		or an 11/34 or 40 with the memory management option.

	256KB (well 248 really) of memory.

	The console board for the PDP-11 if required and a termianl
		to use for a console (Pity the fool who tries to run a
		a PDP-11 without a console).

	Some sort of clock.  The line clock on the LSI's will do, most
		any clock that will allow you to run UNIX will work.
		Some constants may need to be changed if you are going
		to use something really esoteric.

	Boot Disk.  RX02's recommended.  Their heads don't crash.  Actually
		the hard part of the "boot" program will support nearly
		every disk imaginable and will allow either version 6 or
		version 7 UNIX file systems to be used.  However, I only
		provide the boot block (the thing that goes in sector
		zero and starts boot up) for the RX.  I do have one for
		RK05's on a V6 filesystem, but I don't think anyone besides
		BRL still has the capability of writing V6 filesystems
		conveniently.

	Network Interfaces.  Of course, you need interfaces for nets
		you are going to support.
	
YOU WILL ALSO NEED:
	Some development machine capable of producing PDP-11 UNIX C
	binaries.  A PDP-11 running UNIX is preferable.  In addition,
	you will need some way to write the boot media.

Other kludges, er, um, FEATURES of the gateway:

	All IP options supported (for whoever is silly enough to use
		them)
	The Dave Mills Memorial ICMP Timestamp message is supported.
	ICMP echos to the gateway itself.
	The BRL always up host idea (i.e. the ability to route packets
		destined for the gateway to some other host masquerading
		as the gaetways internet address).

Known bugs:
	I broke the monitoring code which include all the neat packet
	spy code.  I am currently working on making it non-VAX specific.

	Only one ethernet can be used at a time.  I'll accept fixes
	from someone who wants to do this, or anyone who wants to
	give me a second ethernet board.  It's not going to be a
	hard modification.

Future Work:
	Fix the above bugs.
	Port to 68K (as soon as they get here...@#%&$@ Procurement.
	Network up/down detection in the drivers to modify routes.
	ROUTER service similar to that on BRL VAX's.
	Over the net bootup.
	Esoteric packet log mode.
	Better logging with notification of network control of
		abnormal events.

RESTRICTIONS ON USE:

	I have only a few restrictions on use.  The first two are my
own.  Please give credit to the code you are using from this gateway
as being from the BRL gateway.  Second, if you get this via FTP or
you get a copy from somewhere else, PLEASE, send me a letter saying
that you wish to use the gateway.  You need not wait for an answer,
but I need documentation on who has obtained copies of the gateway
so I can use it on our internal paperwork.

	The remaining restriction is that this code is NOT PUBLIC DOMAIN.
It is owned by the GOVERNMENT of the UNITED STATES.  This means you can
use it, copy it, give it away (as long as you identify that it is the
BRL Gateway).  If you wish to sell it, you need to contact me for further
restrictions.  Generally, selling the gateway as the gateway is not allowed.
You may include it in you product at no charge and may charge for maintenance
of the code once you do so.

HOW TO GET ONE:

	The gateway is available for anonymous FTP from the host BRL-VGR
in the file arch/brl-gw.tar.  This is a UNIX tar file of the entire gateway
source tree.  In the documentation directory there is a paper called
install which is step by step instructions on setting up the gateway.
If you don't have nroff, there is a copy already formatted in install.n.

Soon I will be setting up a dedicated development machines and there will
me better ways of getting updates if you already have access to the net.

	If you don't have access to FTP, send me a tape and a letter
asking for the gateway to

		Ron Natalie
		Ballistic Research Laboratory
		ATTN: SLCBR-SE
		APG, MD  21005-5066

To contact me by electronic mail, I am:
	Ron@BRL (.ARPA, .MIL, etc...)
or	...!{decvax, unc, umcp-cs,...}!brl-bmd!ron or ...!seismo!brl-tgr!ron

I have also established a mailing list called
		BRL-GATEWAY@BRL
for discussion of things pertaining to the BRL-GATEWAY.

-Ron

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      Sat, 9 Nov 85 16:11:10 EST
From:      Ron Natalie <ron@BRL.ARPA>
To:        tcp-ip@sri-nic.arpa
Cc:        brl-gateway@BRL.ARPA
Subject:   BRL-GATEWAY
Well the first release of the BRL Gateway has been tested
and known to compile on non-BRL PDP-11 UNIX systems.  Here
is what is supported:

	Ethernet and ARP on Interlan NI1010A boards
	IMPS for both ARPANET and CLASS-B network using LH/DH-11
	DEC PCL-11B
	Hyperchannel on Class C networks
	Proteon Ring Net (V2LNI)
	EGP - Perhaps in a non-standard way, but it is optimized
		for dealing with the way the core is administered today

Hardware Required:
	A PDP-11 with 18 bit memory management.
		This means 11/23,24,44,45,55,60,70,73,84
		or an 11/34 or 40 with the memory management option.

	256KB (well 248 really) of memory.

	The console board for the PDP-11 if required and a termianl
		to use for a console (Pity the fool who tries to run a
		a PDP-11 without a console).

	Some sort of clock.  The line clock on the LSI's will do, most
		any clock that will allow you to run UNIX will work.
		Some constants may need to be changed if you are going
		to use something really esoteric.

	Boot Disk.  RX02's recommended.  Their heads don't crash.  Actually
		the hard part of the "boot" program will support nearly
		every disk imaginable and will allow either version 6 or
		version 7 UNIX file systems to be used.  However, I only
		provide the boot block (the thing that goes in sector
		zero and starts boot up) for the RX.  I do have one for
		RK05's on a V6 filesystem, but I don't think anyone besides
		BRL still has the capability of writing V6 filesystems
		conveniently.

	Network Interfaces.  Of course, you need interfaces for nets
		you are going to support.
	
YOU WILL ALSO NEED:
	Some development machine capable of producing PDP-11 UNIX C
	binaries.  A PDP-11 running UNIX is preferable.  In addition,
	you will need some way to write the boot media.

Other kludges, er, um, FEATURES of the gateway:

	All IP options supported (for whoever is silly enough to use
		them)
	The Dave Mills Memorial ICMP Timestamp message is supported.
	ICMP echos to the gateway itself.
	The BRL always up host idea (i.e. the ability to route packets
		destined for the gateway to some other host masquerading
		as the gaetways internet address).

Known bugs:
	I broke the monitoring code which include all the neat packet
	spy code.  I am currently working on making it non-VAX specific.

	Only one ethernet can be used at a time.  I'll accept fixes
	from someone who wants to do this, or anyone who wants to
	give me a second ethernet board.  It's not going to be a
	hard modification.

Future Work:
	Fix the above bugs.
	Port to 68K (as soon as they get here...@#%&$@ Procurement.
	Network up/down detection in the drivers to modify routes.
	ROUTER service similar to that on BRL VAX's.
	Over the net bootup.
	Esoteric packet log mode.
	Better logging with notification of network control of
		abnormal events.

RESTRICTIONS ON USE:

	I have only a few restrictions on use.  The first two are my
own.  Please give credit to the code you are using from this gateway
as being from the BRL gateway.  Second, if you get this via FTP or
you get a copy from somewhere else, PLEASE, send me a letter saying
that you wish to use the gateway.  You need not wait for an answer,
but I need documentation on who has obtained copies of the gateway
so I can use it on our internal paperwork.

	The remaining restriction is that this code is NOT PUBLIC DOMAIN.
It is owned by the GOVERNMENT of the UNITED STATES.  This means you can
use it, copy it, give it away (as long as you identify that it is the
BRL Gateway).  If you wish to sell it, you need to contact me for further
restrictions.  Generally, selling the gateway as the gateway is not allowed.
You may include it in you product at no charge and may charge for maintenance
of the code once you do so.

HOW TO GET ONE:

	The gateway is available for anonymous FTP from the host BRL-VGR
in the file arch/brl-gw.tar.  This is a UNIX tar file of the entire gateway
source tree.  In the documentation directory there is a paper called
install which is step by step instructions on setting up the gateway.
If you don't have nroff, there is a copy already formatted in install.n.

Soon I will be setting up a dedicated development machines and there will
me better ways of getting updates if you already have access to the net.

	If you don't have access to FTP, send me a tape and a letter
asking for the gateway to

		Ron Natalie
		Ballistic Research Laboratory
		ATTN: SLCBR-SE
		APG, MD  21005-5066

To contact me by electronic mail, I am:
	Ron@BRL (.ARPA, .MIL, etc...)
or	...!{decvax, unc, umcp-cs,...}!brl-bmd!ron or ...!seismo!brl-tgr!ron

I have also established a mailing list called
		BRL-GATEWAY@BRL
for discussion of things pertaining to the BRL-GATEWAY.

-Ron
-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 85 13:44:00 PST
From:      TOM MCGILL <tcm@cit-ssdp>
To:        info-nets <info-nets@mit-mc>
Cc:        <tcp-ip@sri-nic>,tcm
Subject:   CHANGE OF ADDRESS
Please change my address from
mcgill@cit-20
to
tcm@cit-ssdp.

Tom McGill
------
-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      Sun, 10-Nov-85 13:13:46 EST
From:      swanson@EDN-VAX.ARPA (John Swanson)
To:        mod.protocols.tcp-ip
Subject:   (none)

I am trying to compile a list of functions FTAM would have to support
if it were to be used instead of FTP.  So I am looking for any input from
current FTP users about any novel ways they are using FTP services so
that I can report on those special functions of FTP or its user interface
that will have to be supported.  Thanks in advance for any information
you may be able to give me.
John 

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      Sun, 10 Nov 85 13:13:46 est
From:      swanson@EDN-VAX.ARPA (John Swanson)
To:        tcp-ip@sri-nic.ARPA
I am trying to compile a list of functions FTAM would have to support
if it were to be used instead of FTP.  So I am looking for any input from
current FTP users about any novel ways they are using FTP services so
that I can report on those special functions of FTP or its user interface
that will have to be supported.  Thanks in advance for any information
you may be able to give me.
John 
-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      Sun, 10-Nov-85 14:33:58 EST
From:      JNC@MIT-XX.ARPA ("J. Noel Chiappa")
To:        mod.protocols.tcp-ip
Subject:   Re: nasty little 4.2 bug ??


	Larry Allen found this several years ago and reported it to
Berkeley. Perhaps they have (or should have) set up a mailing list for
4.2 bug reports that people with 4.2 systems can get on, so that everyone
wouldn't have to rediscover things like this?
		Noel
-------

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      Sun, 10-Nov-85 15:28:32 EST
From:      romkey@MIT-BORAX.ARPA (John Romkey)
To:        mod.protocols.tcp-ip
Subject:   nasty little 4.2 bug ??

The bug in the PC code which sent these bogus packets was also fixed
in the January '85 release. We found it one day when a VAX went away
while someone was trying to TFTP files to it. Then she moved to
another VAX and it happened again and we "that's absurd". Then it was
a third VAX...
						- john romkey

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      Sun, 10-Nov-85 16:44:00 EST
From:      tcm@CIT-SSDP.ARPA (TOM MCGILL)
To:        mod.protocols.tcp-ip
Subject:   CHANGE OF ADDRESS

Please change my address from
mcgill@cit-20
to
tcm@cit-ssdp.

Tom McGill
------

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      Sun, 10-Nov-85 17:03:29 EST
From:      bzs@BOSTONU.CSNET (Barry Shein)
To:        mod.protocols.tcp-ip
Subject:   Re: nasty little 4.2 bug ??


>From: "J. Noel Chiappa" <JNC@mit-xx.ARPA>
>
>	Larry Allen found this several years ago and reported it to
>Berkeley. Perhaps they have (or should have) set up a mailing list for
>4.2 bug reports that people with 4.2 systems can get on, so that everyone
>wouldn't have to rediscover things like this?
>		Noel

There are in fact a few ways to keep up with bugs on 4.2 systems. All 4.2
tapes came with the program 'sendbug' which posts bugs to Berkeley. In
addition it is generally reasonable practice to also post such bugs/fixes
to unix-wizards*. Anyone responsible for 4.2 administration should be reading
unix-wizards for bug reports/fixes. Further, Mt. Xinu has provided a service
where either they will support your 4.2 system or provide you with bugreports.

I am surprised after "several years" people still aren't aware of these
things.

Of course, bugs and fixes still slip through the cracks as they will on any
system, and they will get re-discovered, I doubt there is any fix for that
ultimately (if you think vendor supported O/S's are better, think again.)

Perhaps what is really needed here is some tracking of Internet implementations
by some more global organization (such as the NIC) as many of these bugs
only exhibit themselves when heterogeneous environments are tried (that is,
beyond a list of implementations.) One also cannot help but note that almost
all internet implementations (with perhaps the exception of SUN) are barely
supported (or not at all, eg: vms) by the vendors of the hardware on which
the software runs, and the third party vendors are often too small to really
do the job well.

	-Barry Shein, Boston University

* USENET also has a separate address for this, net.bugs.4bsd, tho not nearly
as used as unix-wizards.

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      Sun, 10 Nov 85 17:03:29 est
From:      Barry Shein <bzs%bostonu.csnet@CSNET-RELAY.ARPA>
To:        JNC@mit-xx.ARPA, leong%CMU-ITC-LINUS@pt.cs.cmu.edu, tcp-ip@sri-nic.ARPA
Subject:   Re: nasty little 4.2 bug ??

>From: "J. Noel Chiappa" <JNC@mit-xx.ARPA>
>
>	Larry Allen found this several years ago and reported it to
>Berkeley. Perhaps they have (or should have) set up a mailing list for
>4.2 bug reports that people with 4.2 systems can get on, so that everyone
>wouldn't have to rediscover things like this?
>		Noel

There are in fact a few ways to keep up with bugs on 4.2 systems. All 4.2
tapes came with the program 'sendbug' which posts bugs to Berkeley. In
addition it is generally reasonable practice to also post such bugs/fixes
to unix-wizards*. Anyone responsible for 4.2 administration should be reading
unix-wizards for bug reports/fixes. Further, Mt. Xinu has provided a service
where either they will support your 4.2 system or provide you with bugreports.

I am surprised after "several years" people still aren't aware of these
things.

Of course, bugs and fixes still slip through the cracks as they will on any
system, and they will get re-discovered, I doubt there is any fix for that
ultimately (if you think vendor supported O/S's are better, think again.)

Perhaps what is really needed here is some tracking of Internet implementations
by some more global organization (such as the NIC) as many of these bugs
only exhibit themselves when heterogeneous environments are tried (that is,
beyond a list of implementations.) One also cannot help but note that almost
all internet implementations (with perhaps the exception of SUN) are barely
supported (or not at all, eg: vms) by the vendors of the hardware on which
the software runs, and the third party vendors are often too small to really
do the job well.

	-Barry Shein, Boston University

* USENET also has a separate address for this, net.bugs.4bsd, tho not nearly
as used as unix-wizards.

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11-Nov-85 12:27:36 EST
From:      MILLS@USC-ISID.ARPA
To:        mod.protocols.tcp-ip
Subject:   Re: Zero window probes

In response to the message sent   Fri, 8 Nov 85 15:57 EST from Mills@CISL-SERVICE-MULTICS.ARPA

John,

See MIL-STD-1778 for another view of the TCP spec, although officially
this and RFC-793 define the same protocol. Speaking pragmatically, the TOPS-20
TCP abandons the connection if the window soes not open in five minutes. The
Fuzzball TCP does the same. You have a similar problem when you send a
FIN, which is ACKed, and the other end never sends a FIN.

If data are queued beyond the right window edge, the user timeout will
catch it. If not, the zero-window probe could continue indefinately, at
least until either new data appears or the connection is closed. This means,
of course that the use would have to proved exactly enough data to fill the
window and then never provide any more.

Dave (no relation)
-------

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11-Nov-85 22:20:59 EST
From:      HEDRICK@RED.RUTGERS.EDU (Charles Hedrick)
To:        mod.protocols.tcp-ip
Subject:   Re: Zero window probes

If this is what I think it is, I think it depends upon the
application.  If you are a TCP user process, and the other
end doesn't accept any data in 5 minutes, there is probably
something wrong.  But suppose you are a print spooler talking
to a remote printer.  We have a situation just like that.
When the printer runs out of paper, or is otherwise in need
of attention, it XOFF's the connection.  Eventually, the result
is that TCP refuses to accept any data.  The operator may take
a long time to get to this.  We'd like to keep the connection
open as long as necessary.  Similarly, consider the connection
between a host and one of our terminal servers.  The terminal
server allows a user to have several connections open at once.
However the terminal is connected to only one session at a time.
There are commands to let you go back and forth between connections.
Obviously the server has only a finite buffer.  When you are
not connected to a session, and its buffer fills, TCP will
stop accepting data.  Again, we would like the host to keep the
connection open indefinitely.  Currently TOPS-20 will time out
after a certain time.  Our users all consider this to be a bug.
They are annoyed when they reconnect to a TOPS-20 session and
find that TOPS-20 has given up.
-------

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      Tue, 12-Nov-85 06:52:00 EST
From:      CERF@USC-ISI.ARPA
To:        mod.protocols.tcp-ip
Subject:   Re:  Zero window probes

John,

The philosophical basis for the TCP design, if not stated explicitly,
was that the TCP protocol and implmentation could not and should not
make too many timeout decisions on behalf of a using process. Only
the using process (or perhaps a person) knows how long it is willing
to "wait" for some action.  Consequently we assigned no value for
timing out the condition you describe and instead assumed that the
using process would eventually close the connection unilaterally
when it wanted to.  of course, if you get no ACK back from the probe,
you timeout and report this to the using process but you still do not
unilaterally close the connection at the TCP level.  

Vint

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      Tue, 12-Nov-85 10:02:05 EST
From:      cak@PURDUE.EDU ("Christopher A. Kent")
To:        mod.protocols.tcp-ip
Subject:   Re: Zero window probes

4.2 has the silliness of closing down a connection after a (short)
finite amount of time of pushing against a zero window. The behaviour
is much as described for Rutgers' terminal server; rlogin somewhere,
cat /etc/termcap, suspend, work a while, come back and find the
connection dead. Get pissed off.

Sigh,
chris
----------

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      Tue, 12-Nov-85 12:18:39 EST
From:      raklein@MITRE.ARPA (Richard Klein)
To:        mod.protocols.tcp-ip
Subject:   FTAM (ISO' FTP)


     John D. Day is working on FTAM for ANSI (and ISO), and knows FTP as well.
Contact him at 

     CODEX Inc.
     20 Cabot Blvd.
     Mansfield, MA 02048
     (617) 364-2000

John is intimately aware of the issues that must be addressed for file access 
and management.

Richard

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      Tue, 12-Nov-85 23:20:11 EST
From:      MILLS@USC-ISID.ARPA
To:        mod.protocols.tcp-ip
Subject:   Known NTP servers

Folks,

In response to questions from several clockwatchers, the following list gives
the names of known NTP servers, their addresses and related information.

Host Name	Address		Clock	System		Contact
---------------------------------------------------------------------------
DCN1.ARPA	128.4.0.1	WWVB	fuzz		mills@usc-isid.arpa
DCN5.ARPA	128.4.0.5	DCN	fuzz		mills@usc-isid.arpa
DCN6.ARPA	128.4.0.6	DCN	fuzz		mills@dcn6.arpa	
DCN7.ARPA	128.4.0.7	DCN	fuzz		mills@usc-isid.arpa
DCN8.ARPA	128.4.0.8	DCN	fuzz		mills@usc-isid.arpa
DCN9.ARPA	128.4.0.9	none	Sun 4.2bsd	oconnor@dcn9.arpa
FORD1.ARPA	128.5.0.1	GOES	fuzz		jay@ford1.arpa
TRANTOR.UMD.EDU	128.8.0.14	none	VAX 4.2bsd	louie@trantor.umd.edu
GW-UMICH.EDU	128.82.0.1	WWV	fuzz		hwb@gw-umich.edu

The System column indicates the processor and operating system. The "fuzz" are
various LSI-11 systems running a protocol-workbench system implemented by me.
Mike O'Connor wrote an NTP server for 4.2bsd, which is in test on the hosts
indicated. The Clock column above indicates the normal soruce of
synchronization information:

WWVB	NBS Radio WWVB, Boulder, CO. (Spectracom 8170 WWVB Receiver)
WWV	NBS Radio WWV, Ft. Collins, CO. (Heath GC-1000 Most Accurate Clock)
GOES	GOES Satellite (True-Time 468DC Satellite Synchronized Clock)
DCN	DCNet local-net protocols
none	unknown or unspecified

The DCNet hosts 128.4 normally synchronize using DCNet local-net protocols to
the WWVB primary clock connected to DCN1.ARPA. If this clock or DCN1.ARPA
itself should fail, the first-order backup is the WWV secondary clock
connected to DCN6.ARPA, while the second-order backup is via the FORDnet
gateway to 128.5. The FORDnet hosts 128.5 normally synchronize using DCNet
protocols to the GOES primary clock connected to FORD1.ARPA, with first-order
backup via DCNet 128.5 and second-order backup via UMICHnet 128.82.

Hosts requesting NTP time should normally use only those hosts with directly
connected primary clocks, in this case DCN1.ARPA, FORD1.ARPA and GW.UMICH.EDU.
If any of these hosts indicate in an NTP response other than code 1 in the
Status field (clock operating normally) or code 1 in the Reference Clock Type
Field (primary reference), the primary clock is down or operating incorrectly,
and the time indicated may be in gross error. If any of these hosts indicate
code 3 in the latter field (secondary reference not using NTP), the primary
clock is down but the host has synchronized to another source presumably
operating correctly.

Depending on the synchronizing source and path, the NTP time indicated by
various hosts may have small offsets (in the order of milliseconds) relative
to the source. In order to calibrate these offsets, certain special hosts have
been instrumented to return time directly from the radio clock. In order to
preserve the highest accuracy, the time is available only in ICMP Timestamp
messages. Following is a list of these special hosts:

		Host Name	Address		Clock
		-------------------------------------
		DCN-WWV.ARPA	128.4.0.14	WWV
		DCN-WWVB.ARPA	128.4.0.15	WWVB
		unspecified	128.5.0.19	GOES
		unspecified	128.82.0.17	WWV

These hosts can be used to obtain time from the specified clock regardless of
the current synchronizing source used by the directly connected host or state
of the clock itself.

Dave
-------

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      Wed, 13-Nov-85 12:20:01 EST
From:      milazzo@RICE.EDU (Paul Milazzo)
To:        mod.protocols.tcp-ip
Subject:   2.9bsd + networking on PRO 350?

I recently saw a message from someone who has 2.9bsd with TCP/IP
networking running on a PRO 350.  Unfortunately, now that I have a use
for that very thing, I can no longer find this message.  I am in fact
beginning to doubt it ever existed.

If anyone out there knows about this code, please tell me!  If you
think it's just a sign that I'm getting old, feel free to tell me that,
too. :-)

				Thanks,
				Paul G. Milazzo
				Dept. of Computer Science
				Rice University, Houston, TX
Domain:	milazzo@rice.EDU
ARPA:	milazzo@rice.ARPA
BITNET:	milazzo@ricecsvm
UUCP:	{cbosgd,convex,cornell,hp-pcd,shell,sun,ut-sally,waltz}!rice!milazzo

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      Wed, 13-Nov-85 20:35:59 EST
From:      woo@AMES-NAS.ARPA (Alex Woo)
To:        mod.protocols.tcp-ip
Subject:   drivers for the microVAX II under VMS


Does anyone know of a driver and a board for TCP/IP on a microVAX II
using micro VMS ver4.1?

Alex Woo
woo@ames-nas

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14-Nov-85 11:19:48 EST
From:      lhl@RSCH.WISC.EDU (L.H. Landweber)
To:        mod.protocols.tcp-ip
Subject:   request for information

The following request is from David Lord at CERN. Please respond
directly to him (PFKDN%CERNVM.BITNET@WISCVM).

Date:         Tue, 12 Nov 1985 15:06 GVA
From:         David Lord <PFKDN@CERNVM>
To:           Larry Landweber <LHL@WISCVM>

Can you help me, I need to implement TCP/IP etc. on a single board 68000 based
processor. I have versions written in C but I have no suitable real time system
( monitor, exec call it what you will )for the 68000. do you know of anything
that could help, or could you suggest someone who could help me?
Many thanks Best wishes David.

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      15-Nov-85 22:57:24-UT
From:      mills@dcn6.arpa
To:        tcp-ip@sri-nic.arpa
Subject:   Network Time Protocol document revisions
Folks,

There is a revised document on NTP on USC-ISID.ARPA in the directory MILLS
called NTP.DOC. The document updates RFC-958 with several typo corrections
kindly contributed by several people, as well as a new section 6 that contains
suggestions on a distributed implementation model and how to compute the
error and drift-rate estimates.

Dave
-------
-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      Sat, 16-Nov-85 16:40:09 EST
From:      montgmry@DEWEY.UDEL.EDU (Doug Montgomery)
To:        mod.protocols.tcp-ip
Subject:   LAN management references


I am interested in gathering information on the management of LANs.  In
particular, I am interested in  the automated management/control of
LANs.

Information/references/comments pertaining to:

   * LAN management goals and philosophies.
   * LAN management architectures.
   * LAN management protocols.
   * LAN management applications.
   * management of LANs based upon IEEE 802 
     MAC-sublayer standards.
   * potential application of AI techniques to 
     the automated management of LANs.

would be greatly appreciated.  If there is interest I will
summarize responses.

 Network Addresses:
   ARPA:  montgmry@udel-dewey
  CSNET:  montgmry%udel-dewey@csnet-relay
   UUCP:  ...!harvard!montgmry@udel-dewey
 
 

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      Sat, 16 Nov 85 16:40:09 EST
From:      Doug Montgomery <montgmry@dewey.udel.EDU>
To:        tcp-ip@sri-nic.ARPA
Subject:   LAN management references

I am interested in gathering information on the management of LANs.  In
particular, I am interested in  the automated management/control of
LANs.

Information/references/comments pertaining to:

   * LAN management goals and philosophies.
   * LAN management architectures.
   * LAN management protocols.
   * LAN management applications.
   * management of LANs based upon IEEE 802 
     MAC-sublayer standards.
   * potential application of AI techniques to 
     the automated management of LANs.

would be greatly appreciated.  If there is interest I will
summarize responses.

 Network Addresses:
   ARPA:  montgmry@udel-dewey
  CSNET:  montgmry%udel-dewey@csnet-relay
   UUCP:  ...!harvard!montgmry@udel-dewey
 
 
-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      Sat, 16-Nov-85 16:59:00 EST
From:      SAkers@HIS-PHOENIX-MULTICS.ARPA ("Scott C. Akers")
To:        mod.protocols.tcp-ip
Subject:   TCP/IP on a board

SCOPE, Incorporated makes at DCA-qualified single-board product which
implements the link, network, and transport layer protocols for DDN.  It
comes in MULTIBUS (tm) and IBM PC versions, with others planned.  For
information, call or write:

          Sue Gruszewski
          SCOPE, Incorporated
          1860 Michael Faraday Drive
          Reston, VA  22090  USA

          Phone:  800-336-0155 or
                  703-471-5600, ext 153

or send mail to me at:

          SAkers%pco@CISL-SERVICE-MULTICS.ARPA

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18-Nov-85 11:22:42 EST
From:      milazzo@RICE.EDU (Paul Milazzo)
To:        mod.protocols.tcp-ip
Subject:   2.9bsd+TCP/IP for PRO 350 (SUMMARY)

Last week I posted a request for pointers to a 2.9bsd with TCP/IP for
the PRO 350.  It now appears that there are two separate 2.9bsd ports
to the PRO 350, one of which does indeed include the network code.  I
have excerpted several of the relevant messages below:

______________________________________________________________________________
Date: Wed 13 Nov 85 11:41:12-PST
From: Greg Satz <SATZ@SU-SIERRA.ARPA>

BST@Mojave did a port of 2.9 to the PRO. However he didn't get
the networking code in. [...]
______________________________________________________________________________
Date: Fri 15 Nov 85 11:16:27-EST
From: Charlie C Kim <US.CCK@CU20B.COLUMBIA.EDU>

The PRO-350/380 kernels we're running were on the Usenix 85.1 tape as
contributed by Rick Macklem of the University of Guelph, Ontario.
[...]  Rick's stuff includes a console, comm port, lp port, rx50,
rd50/51 and an ra (for QBus machines) driver.  [...]
______________________________________________________________________________
And finally (save the best for last), the message I thought I had seen:
______________________________________________________________________________
Date: Thu, 25 Jul 85 10:48:04 edt
From: rick%uogvax2.BITNET@wiscvm.ARPA

One thing that may be of interest to someone out there is that i have
2.9bsd unix working on a pro350 and the tcp/ip part working for the
11/23 and up. If anyone with an A.T.&T. license wants it, they are
welcome.  [...]
______________________________________________________________________________

My thanks to all who replied!

				Paul G. Milazzo
				Dept. of Computer Science
				Rice University, Houston, TX
Domain:	milazzo@rice.EDU
ARPA:	milazzo@rice.ARPA
BITNET:	milazzo@ricecsvm
UUCP:	{cbosgd,convex,hp-pcd,shell,sun,ut-sally,waltz}!rice!milazzo

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18-Nov-85 14:16:46 EST
From:      minshall%ucbopal@UCBVAX (Greg Minshall)
To:        mod.protocols.tcp-ip
Subject:   tn3270

Hi.  Tn3270 is a program that will be distributed along with 4.3 of Berkeley
Unix.  It is a 3270 emulator that runs under Unix and talks to IBM/CMS systems
running the Wisconsin TCP/IP code (also, there is a rumor that a soon-to-be
released version of the Spartacus TCP/IP for IBM/CMS will also support 3270-
over-telnet in the same way the Wisconsin code does).

We've been running it at Berkeley for the last six to eight months.

The source code for tn3270 is available for public ftp from host ucb-arpa.
You should "cwd" (or "cd" for Unix folks) to pub, then get the file
"tn3270tar".  The file is a Unix tar file.  I'm interested in getting bug
reports.

Greg Minshall

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      18 Nov 85 20:32:00 PST
From:      <art@acc.arpa>
To:        "tcp-ip" <tcp-ip@sri-nic>
Subject:   RE: 1822 HDH

> What application is 1822 HDH intended for? Is it a reasonable
> cheap alternative to standard 1822?

1822 HDH stands for HDLC HOST.  This is a Host/IMP interface which
uses a synchronous communication protocol.  HDH uses HDLC LAPB
with a protocol layered on top to emulate the direct connect
interface.  HDH is intended for use when the Host is more than
2000 ft from the IMP (Distant Host limit).  Whereas the direct
connect interfaces are capable of running several hundred KB/s,
HDH is limited to about 76.8KB/s.  Since most synchronous modems
operate in the 9600 to 56KB/s range, HDH is acceptable in those
applications.
				"Art Berggreen"<Art@ACC.ARPA>

------
-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18 Nov 85 18:30:25 EST
From:      rtm@harvard.HARVARD.EDU (Robert Morris)
To:        tcp-ip@sri-nic.arpa
Subject:   1822 HDH
What application is 1822 HDH intended for? Is it a reasonable
cheap alternative to standard 1822?
-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18-Nov-85 23:32:00 EST
From:      art@ACC.ARPA
To:        mod.protocols.tcp-ip
Subject:   RE: 1822 HDH


> What application is 1822 HDH intended for? Is it a reasonable
> cheap alternative to standard 1822?

1822 HDH stands for HDLC HOST.  This is a Host/IMP interface which
uses a synchronous communication protocol.  HDH uses HDLC LAPB
with a protocol layered on top to emulate the direct connect
interface.  HDH is intended for use when the Host is more than
2000 ft from the IMP (Distant Host limit).  Whereas the direct
connect interfaces are capable of running several hundred KB/s,
HDH is limited to about 76.8KB/s.  Since most synchronous modems
operate in the 9600 to 56KB/s range, HDH is acceptable in those
applications.
				"Art Berggreen"<Art@ACC.ARPA>

------

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      Wed, 20-Nov-85 12:27:49 EST
From:      raj@UCI.EDU (Richard Johnson)
To:        mod.protocols.tcp-ip
Subject:   VAX 750 Rev. 7 /boot fixes

There have been a few messages recently asking for the needed
changes to /boot under 4.2BSD on a VAX 750 in order to have it
automatically load the new microcode under Revision 7.  We got
a fix from Jim McKie at "mcvax.uucp" a long time ago and it works
just fine.  I recently got his permission to make it FTPable from
here.  You can get it via anonymous FTP from UCI.EDU.  It is called
"pub/rev7.shar".  This includes a uuencoded copy of the new microcode.

------------------------------------------------------------------------
Richard Johnson                             raj@uci.edu           (ARPA)
UCI ICS Research Systems Manager            ucbvax!ucivax!raj     (UUCP)

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      Wed, 20-Nov-85 14:00:00 EST
From:      RCLee@HI-MULTICS.ARPA ("Randy C. Lee")
To:        mod.protocols.tcp-ip
Subject:   1822/Ethernet gateway

Currently the HI-Multics.ARPA machine is a directly connected to the U.
Wisc IMP by an H6000/1822 ABSI and a couple of ECUs.  I would like to
talk the administrators into replacing this direct connection with
Multics hanging of the gateway as a host on a Class C network.  To do
this, I need a gateway that can act a local host and talk to the UWisc
IMP via the ECUs.  I guess that it also needs to be able act as an IMP
to handle the 1822 connection from Multics.  Finally, it must be able to
support Ethernet with ARP.

Does such a creature exists?

A option would be to replace the LH/1822 box with a Multics HDH
connection.  Does this help in any way?

Ideally, this gateway would run on a PDP 11/23, Sun, Apollo, or
Symbolics.  However, I am not adverse to spending a little money for
another box if it is a supported product.

Please reply directly to me as I am not a regular member of this list.
Thanks.

--Randy C.  Lee
  rcl@hi-multics.arpa

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      Wed, 20-Nov-85 20:45:59 EST
From:      garry@LASSPVAX.TN.CORNELL.EDU (Garry Wiegand)
To:        mod.protocols.tcp-ip
Subject:   Re: tn3270

We have obtained this program a couple weeks ago. We were unable to
do the Make under 4.2BSD for lack of a utility called "sccs", but we
found that the load image provided just came up and ran. (!)

We wrote more pleasing key definitions; and your vt100/200 has to have 
"auto-wrap" turned on by hand.

She emulates very well on all the things I've tried.

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      Thu, 21-Nov-85 10:31:00 EST
From:      KNapier@DDN2.ARPA
To:        mod.protocols.tcp-ip
Subject:   buffer allocation errors on ACC LH/DH11

Sometime time during the last few months I thought I received a message from this list with reguards to a buffer allocation error. I was talking to a
Host Administrator who is having a problem. He has a VAX 11/750, ACC LH/DH11
interface and Wollongong software. He complaind that during normal operations
for no particular reason he wold get a buffer error and his interface would 
die. I belief I seen somthing about this on the net would like to know if the
message does in exist if someone can forward another copy of it. Secondly if the author of the mesage notes and has an update to please respond to directly.

Let me say in advance ... Thanks for any help.

Ken Napier
KNapier@ddn2
(703)734-1360

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      21 Nov 85 10:31 EST
From:      KNapier @ DDN2.ARPA
To:        tcp-ip @ sri-nic.arpa
Cc:        KNapier @ DDN2.ARPA
Subject:   buffer allocation errors on ACC LH/DH11
Sometime time during the last few months I thought I received a message from this list with reguards to a buffer allocation error. I was talking to a
Host Administrator who is having a problem. He has a VAX 11/750, ACC LH/DH11
interface and Wollongong software. He complaind that during normal operations
for no particular reason he wold get a buffer error and his interface would 
die. I belief I seen somthing about this on the net would like to know if the
message does in exist if someone can forward another copy of it. Secondly if the author of the mesage notes and has an update to please respond to directly.

Let me say in advance ... Thanks for any help.

Ken Napier
KNapier@ddn2
(703)734-1360

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      21 Nov 85 14:36:00 PST
From:      <art@acc.arpa>
To:        "knapier" <knapier@ddn2>
Cc:        tcp-ip@sri-nic
Subject:   TWG, LH/DH-11, and RFNMs

> Sometime time during the last few months I thought I received a message from
> this list with reguards to a buffer allocation error. I was talking to a
> Host Administrator who is having a problem. He has a VAX 11/750, ACC LH/DH11
> interface and Wollongong software. He complaind that during normal operations
> for no particular reason he wold get a buffer error and his interface would 
> die. I belief I seen somthing about this on the net would like to know if the
> message does in exist if someone can forward another copy of it. Secondly if
> the author of the mesage notes and has an update to please respond to directly.

If a site is running TWG TCP/IP (or Berkeley UNIX), and network programs such
as ftp fail with a "No Buffer Space" type of error, they should invoke
"netstat -h" to dump the IMP-Host tables.  Of particular interest are the
RFNM and Qcnt counters.  The IMP limits the number messages that each host
can have outstanding to another host to 8.  The Request For Next Message
(RFNM) is the mechanism to allow another message to be sent.  If the Host
and the IMP get out of sync with RFNM counting, the Host may believe that
it has eight messages pending to a particular host and the IMP believes that
there are none.  This causes the Host to stop sending to that host, but
it continues to queue up messages for that host (Qcnt) for another 8 messages
and then report a NOBUF error.  This condition is indicated when netstat -h
reports both RFNM and Qcnt equal to 8.

There are two causes (that I know of) that can cause this.  First, there is
a very old bug that involves IMP reset.  When the IMP resets the interface,
it flaps it relay, clears it RFNM counters and sends an IMP Reset Message
to the host.  The original Berkeley code did not reset its RFNM counters
under this circumstance, and could gradually lose sync with the IMP.
Secondly, some of the more recent TCP patches that set the TCP segment
size based on device MTU have brought out another way.  The original
Berkeley code does not allocate an LH/DH receive buffer that is quite large
enough to receive a maximum sized IMP message.  This causes the LH/DH to
have to handle the IMP message in multiple DMAs.  Although the hardware
and driver are supposed to be able to handle this, it appears that some
LH/DHs under specific conditions, will concatonate two messages.  Since
the protocol code uses the length in the front of the first message, the
second message is effectively lost.  If RFNMs are lost this way, the
interface will eventually block.  The first failure mode will typically
take many days (or frequent IMP resets) to show up.  The second mode
tends to be traffic dependent.

If you are having RFNM blocking problems using an LH/DH, there are patches
which solve both of these problems.  Talk to TWG if running their software.

				"Art Berggreen"<Art@ACC.ARPA>

------
-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      Thu, 21-Nov-85 15:57:42 EST
From:      tcp-ip@ucbvax.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Zero window probes

(Sorry for the delay in sending this, we've been off the net for a week)
Charles Hedrick's printer is probably one of ours, and I agree with him
heartily.  I believe that you have to take flow control at face value:
it allows the RECEIVER to receive data as slow as IT wants.  The sender
should always allow the receiver to arbitrarily delay the connection, as
long as the sender has evidence that the connection is still valid --
acks coming back across the connection.  Higher level protocols may
proclaim higher-level timeouts if they cannot accept this behavior.

If you don't take this policy, then you require arbitrary buffering in
slow hosts.  I know this to be true, because I'm responsible for the
TCP on about the slowest host out there -- an Imagen laser printer.  The
printer has no place to buffer files as they are received, it processes
and prints them as it receives them across the TCP connection.  There is
no zero window timeout which is "reasonable."  If the printer runs out of
paper or jams in the middle of the night, it might hold the connection in
zero window until morning.

- Geof Cooper
  Imagen

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      Fri, 22-Nov-85 01:24:23 EST
From:      DP4Q@TE.CC.CMU.EDU (Drew D. Perkins)
To:        mod.protocols.tcp-ip
Subject:   terminal type subnegotiation

Has anyone implemented terminal type subnegotiation for telnet under 4.2?
I'm especially interested in the server end, but I'd like to here about
the client end too.  How about for TOPS20?

Drew
-------

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      Fri 22 Nov 85 01:24:23-EST
From:      Drew D. Perkins <DP4Q@TE.CC.CMU.EDU>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   terminal type subnegotiation
Has anyone implemented terminal type subnegotiation for telnet under 4.2?
I'm especially interested in the server end, but I'd like to here about
the client end too.  How about for TOPS20?

Drew
-------
-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      Fri, 22 Nov 85 16:34:17 EST
From:      Louis A. Mamakos <louie@trantor.UMD.EDU>
To:        tcp-ip@sri-nic.arpa
Subject:   Information about AUSCOM Byte Channel ETHERNET
We're thinking of adding an ethernet interface to our Sperry 1100/90
system.  Currently, we're running our own TCP/IP software package on
the Sperry which is connected via 40KB sync line to another host which
acts as a packet switch to get our traffic on and off our ethernet.
We would be adding a network interface driver to our code to support
an ethernet interface, but don't have any experience with this AUSCOM
box or their software.  Does anyone have anything good or bad to say
about their hardware?  Note that we WILL NOT be running TCP/IP protocols
in the box; we just want a dumb ethernet interface that we can hang off
of our IBM compatable byte channel.

If anyone know of alternate vendors, I would like to hear from you.  Again,
we just want a dumb ethernet interface; no protocol processing is necessary
or desired.

Louis A. Mamakos  WA3YMH    Internet: louie@TRANTOR.UMD.EDU
  University of Maryland, Computer Science Center - Systems Programming

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      Sat, 23-Nov-85 21:19:01 EST
From:      tcp-ip@ucbvax.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: tn3270

In article <8511181916.AA11151@ucbopal.Berkeley.Edu> you write:
>The source code for tn3270 is available for public ftp from host ucb-arpa.
>You should "cwd" (or "cd" for Unix folks) to pub, then get the file
>"tn3270tar".  The file is a Unix tar file.  I'm interested in getting bug
>reports.
We have a UNIX source license, and the latest 4.3 source, but I cannot find
anything regarding tn3270. Could you please give me some info on how I can 
get a hold of a copy. Also is this to run with a KMC11 front-end on a VAX,
or is it reasnoably protable.

-thanks mikeb

-- 
      -m-------   Pyramid Technology       Mike Brennan, Software R&D
    ---mmm-----   1295 Charleston Rd         {cmcl2,topaz}!pyrnj!
  -----mmmmm---   Mt. View, CA 94039        {ihnp4,uwvax}!pyrchi!pyramid!mikeb
-------mmmmmmm-   +1 415 965 7200      {allegra,decwrl,dual,sun}!

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      Sun, 24-Nov-85 11:09:25 EST
From:      tcp-ip@ucbvax.UUCP
To:        mod.protocols.tcp-ip
Subject:   Wisconsin TCP/IP software


Whom can I contact about details of TCP/IP under VM?

Thanks 

-Daniel

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      Sun, 24-Nov-85 12:51:24 EST
From:      milazzo@RICE.EDU (Paul G Milazzo)
To:        mod.protocols.tcp-ip
Subject:   terminal type subnegotiation


	"Has anyone implemented terminal type subnegotiation for telnet
	under 4.2?" - Drew D. Perkins

My additions to 4.2bsd client telnet to support 3270 emulation include
a limited form of terminal type subnegotiation.  Unfortunately, since
only servers on IBM mainframes currently invite terminal type
subnegotiation, my code takes that as a hint that it should reply with
the name of some sort of 3270.  If you are uninterested in IBM
mainframes, you could change that code to return the value of $TERM.

				Paul G. Milazzo
				Dept. of Computer Science
				Rice University, Houston, TX
Domain:	milazzo@rice.EDU
ARPA:	milazzo@rice.ARPA
BITNET:	milazzo@ricecsvm
UUCP:	{cbosgd,convex,hp-pcd,shell,sun,ut-sally,waltz}!rice!milazzo

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      Tue, 26-Nov-85 12:18:58 EST
From:      tcp-ip@ucbvax.UUCP
To:        mod.protocols.tcp-ip
Subject:   WANTED: TCP/IP on ICL/George 3 (don't laugh)

WANTED: TCP/IP implementation on ICL running George 3 operating
system.

I know this is going back some time, but can anybody help me in this
area.  I am going to attempt to connect an ICL host running George 3
operating system to a local network running TCP/IP.
	Connection medium will most likely be private wire for this
machine, although the rest of the net uses Ethernet.  The other
machines are running Unix.  I will also require at the least an ftp
package.

	Any help will be gratefully accepted.  If you know of a
product that fits the bill or if you have suitable software,
please let me know.

	cheers and beers
		gareth.
--
	Gareth Howell  <howellg@idec.UUCP>
		<UK>ukc!stc!idec!howellg
STC IDEC LIMITED Stevenage Herts England	+44 (0)438 738294

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      Tue, 26-Nov-85 21:11:11 EST
From:      sue@RSCH.WISC.EDU (Sue Klein Lebeck)
To:        mod.protocols.tcp-ip
Subject:   Re:  Wisconsin TCP/IP software

Any University may receive information about the
Wisconsin TCP/IP software for VM ("WISCNET") by
dropping a note to me (sue@wiscvm.wisc.edu)
containing your name and surface mail address.

Upon receipt of your note, I will see that a 
"WISCNET Information Packet" is sent to you.

Sue Lebeck
sue@wiscvm.wisc.edu -or-
sue@rsch.wisc.edu

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      Fri, 29-Nov-85 04:49:00 EST
From:      Vshank@WEIZMANN.BITNET (Henry Nussbacher)
To:        mod.protocols.tcp-ip
Subject:   Spartacus Knet and Wisconsin Wiscnet

Has anyone tried and/or suceeded in 3270 Telnet from a VM system running
Wiscnet to a VM system running Knet and visa versa?

Hank

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      29 Nov 1985 16:06-PST
From:      the tty of Geoffrey S. Goodfellow <Geoff@SRI-CSL.ARPA>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   C/70's ICMP considered anti-social?
Having recently rehomed our system to a local Ethernet, behind a
LSI-11/23 gateway running the BBN software, i've made notice of
strange behavior on the part of BBN C/70 hosts.

It seems that whenever a host on our local net (192.12.33) opens
up a connection to a C/70 host on the ARPANET, the C/70 starts
sending a never ending stream of ICMP messages to us ever 4
seconds -- these messages never stop -- even after we close the
connection.  Currently, our gateway is being bombarded by four
such systems every 4 seconds.

This behavior seems undesirable at best.  Can anyone explain it?
What purpose it serve?  What would one need to know from our
gateway at the frequency of every 4 seconds?  Is their a method
to issue a cease and desist order to the originating host?

This would seem a great hog of IMP and gateway resources,
inter-IMP trunk bandwidth, and in a worst case scenario, a tad
bit expen$ive if ones gateway were on the other side of a Value
Added Network.

g
-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      Fri, 29-Nov-85 19:06:00 EST
From:      Geoff@SRI-CSL.ARPA (the tty of Geoffrey S. Goodfellow)
To:        mod.protocols.tcp-ip
Subject:   C/70's ICMP considered anti-social?

Having recently rehomed our system to a local Ethernet, behind a
LSI-11/23 gateway running the BBN software, i've made notice of
strange behavior on the part of BBN C/70 hosts.

It seems that whenever a host on our local net (192.12.33) opens
up a connection to a C/70 host on the ARPANET, the C/70 starts
sending a never ending stream of ICMP messages to us ever 4
seconds -- these messages never stop -- even after we close the
connection.  Currently, our gateway is being bombarded by four
such systems every 4 seconds.

This behavior seems undesirable at best.  Can anyone explain it?
What purpose it serve?  What would one need to know from our
gateway at the frequency of every 4 seconds?  Is their a method
to issue a cease and desist order to the originating host?

This would seem a great hog of IMP and gateway resources,
inter-IMP trunk bandwidth, and in a worst case scenario, a tad
bit expen$ive if ones gateway were on the other side of a Value
Added Network.

g

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      Fri, 29 Nov 1985 11:49 O
From:      Henry Nussbacher  <Vshank%Weizmann.BITNET@WISCVM.ARPA>
To:        <tcp-ip@sri-nic.ARPA>
Subject:   Spartacus Knet and Wisconsin Wiscnet
Has anyone tried and/or suceeded in 3270 Telnet from a VM system running
Wiscnet to a VM system running Knet and visa versa?

Hank
-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      Sat, 30-Nov-85 11:22:52 EST
From:      sdyer@BBNCC5.ARPA
To:        mod.protocols.tcp-ip
Subject:   Re: C/70's ICMP considered anti-social?

It's a bug.  I'd be interested to know what hosts you're connecting to,
since we haven't had this problem here in quite some time.
Why don't we take this "off line"--I'm sure the rest of the list
can do without such methods of problem reporting.

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      Sun, 1-Dec-85 02:58:53 EST
From:      nrh@DDNT.ARPA (Nat Howard)
To:        mod.protocols.tcp-ip
Subject:   name servers

What do people use for name servers under 4.2 or 2.9+ BSD?  I hacked
one together, but am just mature enough to want to use a standard one
if standard code is available.

The machines involved can't reach the Internet, so I can't depend on
servers there.  What I'd really like is to hear that there's standard
4.2 stuff that I've simply missed in my search.

If it turns out there's no name server stuff available, and people 
want mine, I suppose it could be made available.

Please send a copy of your reply to me, nrh@ddnt, as we occasionally
lose mod.protocols.tcp-ip on usenet (the netnews/notes gateway is
changing), but I don't want to miss anything.

Thanks, folks.

						Nat Howard
						nrh@ddnt

END OF DOCUMENT