|
|
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 - wantedThe 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 probes4.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 gatewayCurrently 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
| ISSN 1742-948X 01 (Online) | 2005/03/01 | Copyright 2002-2008 securitydigest.org. All rights reserved. |