----MESSAGE-BEGIN---- <1985110104555400> Received: from DCN6.ARPA by SRI-NIC.ARPA with TCP; Thu 31 Oct 85 23:31:52-PST Date: 01-Nov-85 04:55:54-UT From: mills@dcn6.arpa Subject: Time lurches on To: tcp-ip@sri-nic.arpa 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 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8511042302.AA22521%40ucb-vax.berkeley.edu] <1985110412315100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: DP4Q@TE.CC.CMU.EDU (Drew D. Perkins) Newsgroups: mod.protocols.tcp-ip Subject: IBM TR/PCIP/IBM VM Message-ID: <8511042302.AA22521@ucb-vax.berkeley.edu> Date: Mon, 4-Nov-85 17:31:51 EST Article-I.D.: ucb-vax.8511042302.AA22521 Posted: Mon Nov 4 17:31:51 1985 Date-Received: Tue, 5-Nov-85 01:00:17 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 11 Approved: tcp-ip@ucbvax.berkeley.edu 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 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985110412315101> Received: from TE.CC.CMU.EDU by SRI-NIC.ARPA with TCP; Mon 4 Nov 85 14:35:03-PST Date: Mon 4 Nov 85 17:31:51-EST From: Drew D. Perkins Subject: IBM TR/PCIP/IBM VM Sender: DP4Q@TE.CC.CMU.EDU To: tcp-ip@SRI-NIC.ARPA Office: UCC-123 x6628 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 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [376.500000409%40uci.edu] <1985110415000900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: raj@UCI.EDU (Richard Johnson) Newsgroups: mod.protocols.tcp-ip Subject: New nettime fixes Message-ID: <376.500000409@uci.edu> Date: Mon, 4-Nov-85 20:00:09 EST Article-I.D.: uci.376.500000409 Posted: Mon Nov 4 20:00:09 1985 Date-Received: Tue, 5-Nov-85 23:30:20 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 13 Approved: tcp-ip@ucbvax.berkeley.edu 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) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8511050126.AA06278%40rsch.wisc.edu] <1985110415264900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: lhl@RSCH.WISC.EDU (L.H. Landweber) Newsgroups: mod.protocols.tcp-ip Subject: Re: IBM TR/PCIP/IBM VM Message-ID: <8511050126.AA06278@rsch.wisc.edu> Date: Mon, 4-Nov-85 20:26:49 EST Article-I.D.: rsch.8511050126.AA06278 Posted: Mon Nov 4 20:26:49 1985 Date-Received: Tue, 5-Nov-85 23:31:08 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 10 Approved: tcp-ip@ucbvax.berkeley.edu 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8511050346.AA20554%40ames-nas.ARPA] <1985110417461100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: woo@AMES-NAS.ARPA (Alex Woo) Newsgroups: mod.protocols.tcp-ip Subject: Re: IBM TR/PCIP/IBM VM Message-ID: <8511050346.AA20554@ames-nas.ARPA> Date: Mon, 4-Nov-85 22:46:11 EST Article-I.D.: ames-nas.8511050346.AA20554 Posted: Mon Nov 4 22:46:11 1985 Date-Received: Tue, 5-Nov-85 23:31:51 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 4 Approved: tcp-ip@ucbvax.berkeley.edu 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8511050507.AA12067%40infoswx.UUCP] <1985110419075100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: al@infoswx.UUCP Newsgroups: mod.protocols.tcp-ip Subject: TCP/IP on Charles River Universe 68 Message-ID: <8511050507.AA12067@infoswx.UUCP> Date: Tue, 5-Nov-85 00:07:51 EST Article-I.D.: infoswx.8511050507.AA12067 Posted: Tue Nov 5 00:07:51 1985 Date-Received: Tue, 5-Nov-85 23:33:32 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 7 Approved: tcp-ip@ucbvax.berkeley.edu Has anyone ported TCP/IP to the Charles River Data Systems Computer?? Al Gettier Teknekron Infoswitch ihnp4!infoswx!al convex!infoswx!al ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8511051422.AA01720%40sabre.UUCP] <1985110504221200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: martin%sabre@MOUTON.ARPA (Martin J Levy) Newsgroups: mod.protocols.tcp-ip Subject: Subnet Code for 4.2bsd machines - wanted Message-ID: <8511051422.AA01720@sabre.UUCP> Date: Tue, 5-Nov-85 09:22:12 EST Article-I.D.: sabre.8511051422.AA01720 Posted: Tue Nov 5 09:22:12 1985 Date-Received: Wed, 6-Nov-85 00:22:26 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 13 Approved: tcp-ip@ucbvax.berkeley.edu 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8511051541.AA19001%40merlin.Purdue.EDU] <1985110505412800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: cak@PURDUE.EDU ("Christopher A. Kent") Newsgroups: mod.protocols.tcp-ip Subject: Re: Subnet Code for 4.2bsd machines - wanted Message-ID: <8511051541.AA19001@merlin.Purdue.EDU> Date: Tue, 5-Nov-85 10:41:28 EST Article-I.D.: merlin.8511051541.AA19001 Posted: Tue Nov 5 10:41:28 1985 Date-Received: Wed, 6-Nov-85 00:23:12 EST References: <8511051422.AA01720@sabre.UUCP> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 7 Approved: tcp-ip@ucbvax.berkeley.edu 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 ---------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8511051803.AA21682%40zotz.UTEXAS.EDU] <1985110508030400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: jsq@ZOTZ.UTEXAS.EDU (John Quarterman) Newsgroups: mod.protocols.tcp-ip Subject: Re: Subnet Code for 4.2bsd machines - wanted Message-ID: <8511051803.AA21682@zotz.UTEXAS.EDU> Date: Tue, 5-Nov-85 13:03:04 EST Article-I.D.: zotz.8511051803.AA21682 Posted: Tue Nov 5 13:03:04 1985 Date-Received: Thu, 7-Nov-85 02:42:01 EST Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 7 Approved: tcp-ip@ucbvax.berkeley.edu 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8511061614.AA11153%40nprdc.arpa] <1985110606140000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: bierma@NPRDC.ARPA (Larry Bierma) Newsgroups: mod.protocols.tcp-ip Subject: UUCP over a TAC? Message-ID: <8511061614.AA11153@nprdc.arpa> Date: Wed, 6-Nov-85 11:14:00 EST Article-I.D.: nprdc.8511061614.AA11153 Posted: Wed Nov 6 11:14:00 1985 Date-Received: Thu, 7-Nov-85 04:16:32 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 13 Approved: tcp-ip@ucbvax.berkeley.edu 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8511061922.AA13253%40ucbvax.berkeley.edu] <1985110608464600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: ron@BRL.ARPA (Ron Natalie) Newsgroups: mod.protocols.tcp-ip Subject: Re: UUCP over a TAC? Message-ID: <8511061922.AA13253@ucbvax.berkeley.edu> Date: Wed, 6-Nov-85 13:46:46 EST Article-I.D.: ucbvax.8511061922.AA13253 Posted: Wed Nov 6 13:46:46 1985 Date-Received: Thu, 7-Nov-85 06:19:18 EST Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 12 Approved: tcp-ip@ucbvax.berkeley.edu 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985110608464601> Received: from BRL-SEM.ARPA by SRI-NIC.ARPA with TCP; Wed 6 Nov 85 10:53:56-PST Date: Wed, 6 Nov 85 13:46:46 EST From: Ron Natalie To: Larry Bierma 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8511070058.AA19786%40ucbvax.berkeley.edu] <1985110611082100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: schoff@RPICS.CSNET (Martin Lee Schoffstall) Newsgroups: mod.protocols.tcp-ip Subject: IP/TCP for XEROX 6085 Message-ID: <8511070058.AA19786@ucbvax.berkeley.edu> Date: Wed, 6-Nov-85 16:08:21 EST Article-I.D.: ucbvax.8511070058.AA19786 Posted: Wed Nov 6 16:08:21 1985 Date-Received: Fri, 8-Nov-85 21:51:01 EST Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 13 Approved: tcp-ip@ucbvax.berkeley.edu 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985110611082101> Received: from CSNET-RELAY.ARPA by SRI-NIC.ARPA with TCP; Wed 6 Nov 85 16:45:11-PST Received: from rpics by csnet-relay.csnet id a000933; 6 Nov 85 18:43 EST Received: by rpics.RPI (4.30/4.7) id AA05702; Wed, 6 Nov 85 16:08:21 EST Date: Wed, 6 Nov 85 16:08:21 EST From: Martin Lee Schoffstall 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8511062155.AA16444%40ucbvax.berkeley.edu] <1985110611250800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: EC0N@TE.CC.CMU.EDU (Eric R. Crane) Newsgroups: mod.protocols.tcp-ip Subject: Tektronix TCP/IP for VMS Message-ID: <8511062155.AA16444@ucbvax.berkeley.edu> Date: Wed, 6-Nov-85 16:25:08 EST Article-I.D.: ucbvax.8511062155.AA16444 Posted: Wed Nov 6 16:25:08 1985 Date-Received: Thu, 7-Nov-85 06:18:52 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 Approved: tcp-ip@ucbvax.berkeley.edu 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 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985110611250801> Received: from TE.CC.CMU.EDU by SRI-NIC.ARPA with TCP; Wed 6 Nov 85 13:24:14-PST Date: Wed 6 Nov 85 16:25:08-EST From: Eric R. Crane Subject: Tektronix TCP/IP for VMS To: tcp-ip@SRI-NIC.ARPA, info-vax@SRI-KL.ARPA Office: Ucc 130 x3568 Secretary: x2638 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 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8511062134.AA15993%40nprdc.arpa] <1985110611340000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: bierma@NPRDC.ARPA (Larry Bierma) Newsgroups: mod.protocols.tcp-ip Subject: Re: Re: UUCP over a TAC? Message-ID: <8511062134.AA15993@nprdc.arpa> Date: Wed, 6-Nov-85 16:34:00 EST Article-I.D.: nprdc.8511062134.AA15993 Posted: Wed Nov 6 16:34:00 1985 Date-Received: Thu, 7-Nov-85 06:19:53 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 21 Approved: tcp-ip@ucbvax.berkeley.edu 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8511071448.AA03424%40ucbvax.berkeley.edu] <1985110704481100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: adrion@UCBVAX (Rick Adrion) Newsgroups: mod.protocols.tcp-ip Subject: Info on Integrated Network Gateways/Relays Message-ID: <8511071448.AA03424@ucbvax.berkeley.edu> Date: Thu, 7-Nov-85 09:48:11 EST Article-I.D.: ucbvax.8511071448.AA03424 Posted: Thu Nov 7 09:48:11 1985 Date-Received: Sun, 10-Nov-85 05:46:22 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: net Organization: The ARPA Internet Lines: 36 Keywords: TCP-IP,BITNET, Email Approved: tcp-ip@ucbvax.berkeley.edu 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8511072207.AA12401%40ucbvax.berkeley.edu] <1985110711271200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: ron@BRL.ARPA (Ron Natalie) Newsgroups: mod.protocols.tcp-ip Subject: Re: Re: UUCP over a TAC? Message-ID: <8511072207.AA12401@ucbvax.berkeley.edu> Date: Thu, 7-Nov-85 16:27:12 EST Article-I.D.: ucbvax.8511072207.AA12401 Posted: Thu Nov 7 16:27:12 1985 Date-Received: Sat, 9-Nov-85 06:26:05 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 7 Approved: tcp-ip@ucbvax.berkeley.edu 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985110711271201> Received: from BRL-SEM.ARPA by SRI-NIC.ARPA with TCP; Thu 7 Nov 85 13:33:24-PST Date: Thu, 7 Nov 85 16:27:12 EST From: Ron Natalie To: Larry Bierma 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8511072232.AA00369%40cmu-ws-postoffice] <1985110712283900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: leong%CMU-ITC-LINUS@PT.CS.CMU.EDU (John Leong) Newsgroups: mod.protocols.tcp-ip Subject: nasty little 4.2 bug ?? Message-ID: <8511072232.AA00369@cmu-ws-postoffice> Date: Thu, 7-Nov-85 17:28:39 EST Article-I.D.: cmu-ws-p.8511072232.AA00369 Posted: Thu Nov 7 17:28:39 1985 Date-Received: Mon, 11-Nov-85 05:14:58 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 13 Approved: tcp-ip@ucbvax.berkeley.edu 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [%5BMIT-MC.ARPA%5D.711287.851108.GJC] <1985110808374700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: GJC@MIT-MC.ARPA ("George J. Carrette") Newsgroups: mod.protocols.tcp-ip Subject: UUCP over a TAC? Message-ID: <[MIT-MC.ARPA].711287.851108.GJC> Date: Fri, 8-Nov-85 13:37:47 EST Article-I.D.: <[MIT-MC.ARPA].711287.851108.GJC> Posted: Fri Nov 8 13:37:47 1985 Date-Received: Sun, 10-Nov-85 04:04:55 EST References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 3 Approved: tcp-ip@ucbvax.berkeley.edu 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? ----MESSAGE-END---- ----MESSAGE-BEGIN---- [851108205728.000456%40CISL-SERVICE-MULTICS.ARPA] <1985110810570000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: Mills@CISL-SERVICE-MULTICS.ARPA Newsgroups: mod.protocols.tcp-ip Subject: Zero window probes Message-ID: <851108205728.000456@CISL-SERVICE-MULTICS.ARPA> Date: Fri, 8-Nov-85 15:57:00 EST Article-I.D.: CISL-SER.851108205728.000456 Posted: Fri Nov 8 15:57:00 1985 Date-Received: Tue, 12-Nov-85 04:31:41 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 17 Approved: tcp-ip@ucbvax.berkeley.edu 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12157941663.43.SCARTER%40RED.RUTGERS.EDU] <1985110910481300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: SCARTER@RED.RUTGERS.EDU (Stephen Carter) Newsgroups: mod.protocols.tcp-ip Subject: Re: Re: UUCP over a TAC? Message-ID: <12157941663.43.SCARTER@RED.RUTGERS.EDU> Date: Sat, 9-Nov-85 15:48:13 EST Article-I.D.: RED.12157941663.43.SCARTER Posted: Sat Nov 9 15:48:13 1985 Date-Received: Sun, 10-Nov-85 10:19:27 EST References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 10 Approved: tcp-ip@ucbvax.berkeley.edu >From: Ron Natalie >To: Larry Bierma >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... ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12157943524.43.SCARTER%40RED.RUTGERS.EDU] <1985110910582600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: SCARTER@RED.RUTGERS.EDU (Stephen Carter) Newsgroups: mod.protocols.tcp-ip Subject: Re: UUCP over a TAC? Message-ID: <12157943524.43.SCARTER@RED.RUTGERS.EDU> Date: Sat, 9-Nov-85 15:58:26 EST Article-I.D.: RED.12157943524.43.SCARTER Posted: Sat Nov 9 15:58:26 1985 Date-Received: Sun, 10-Nov-85 10:19:46 EST References: <[MIT-MC.ARPA].711287.851108.GJC> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 5 Approved: tcp-ip@ucbvax.berkeley.edu >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... ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8511092125.AA00688%40ucbvax.berkeley.edu] <1985110911111000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: ron@BRL.ARPA (Ron Natalie) Newsgroups: mod.protocols.tcp-ip Subject: BRL-GATEWAY Message-ID: <8511092125.AA00688@ucbvax.berkeley.edu> Date: Sat, 9-Nov-85 16:11:10 EST Article-I.D.: ucbvax.8511092125.AA00688 Posted: Sat Nov 9 16:11:10 1985 Date-Received: Sun, 10-Nov-85 10:20:03 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 121 Approved: tcp-ip@ucbvax.berkeley.edu 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985110911111001> Received: from BRL-SEM.ARPA by SRI-NIC.ARPA with TCP; Sat 9 Nov 85 13:13:49-PST Date: Sat, 9 Nov 85 16:11:10 EST From: Ron Natalie 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985111005440000> Received: from cit-ssdp.ARPA by SRI-NIC.ARPA with TCP; Sun 10 Nov 85 13:57:44-PST Date: 10 Nov 85 13:44:00 PST From: TOM MCGILL Subject: CHANGE OF ADDRESS To: info-nets cc: ,tcm Reply-To: TOM MCGILL Please change my address from mcgill@cit-20 to tcm@cit-ssdp. Tom McGill ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8511101820.AA16070%40ucbvax.berkeley.edu] <1985111008134600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: swanson@EDN-VAX.ARPA (John Swanson) Newsgroups: mod.protocols.tcp-ip Subject: (none) Message-ID: <8511101820.AA16070@ucbvax.berkeley.edu> Date: Sun, 10-Nov-85 13:13:46 EST Article-I.D.: ucbvax.8511101820.AA16070 Posted: Sun Nov 10 13:13:46 1985 Date-Received: Mon, 11-Nov-85 06:05:33 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 7 Approved: tcp-ip@ucbvax.berkeley.edu 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985111008134601> Received: from EDN-VAX.ARPA by SRI-NIC.ARPA with TCP; Sun 10 Nov 85 10:11:10-PST Received: by EDN-VAX.ARPA (4.12/4.7) 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12158190291.18.JNC%40MIT-XX.ARPA] <1985111009335800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: JNC@MIT-XX.ARPA ("J. Noel Chiappa") Newsgroups: mod.protocols.tcp-ip Subject: Re: nasty little 4.2 bug ?? Message-ID: <12158190291.18.JNC@MIT-XX.ARPA> Date: Sun, 10-Nov-85 14:33:58 EST Article-I.D.: MIT-XX.12158190291.18.JNC Posted: Sun Nov 10 14:33:58 1985 Date-Received: Mon, 11-Nov-85 06:06:30 EST References: <8511072232.AA00369@cmu-ws-postoffice> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 7 Approved: tcp-ip@ucbvax.berkeley.edu 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 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8511102028.AA23410%40BORAX.MIT.EDU] <1985111010283200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: romkey@MIT-BORAX.ARPA (John Romkey) Newsgroups: mod.protocols.tcp-ip Subject: nasty little 4.2 bug ?? Message-ID: <8511102028.AA23410@BORAX.MIT.EDU> Date: Sun, 10-Nov-85 15:28:32 EST Article-I.D.: BORAX.8511102028.AA23410 Posted: Sun Nov 10 15:28:32 1985 Date-Received: Mon, 11-Nov-85 06:07:57 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 6 Approved: tcp-ip@ucbvax.berkeley.edu 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8511102208.AA18496%40ucbvax.berkeley.edu] <1985111011440000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: tcm@CIT-SSDP.ARPA (TOM MCGILL) Newsgroups: mod.protocols.tcp-ip Subject: CHANGE OF ADDRESS Message-ID: <8511102208.AA18496@ucbvax.berkeley.edu> Date: Sun, 10-Nov-85 16:44:00 EST Article-I.D.: ucbvax.8511102208.AA18496 Posted: Sun Nov 10 16:44:00 1985 Date-Received: Mon, 11-Nov-85 06:38:33 EST Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: TOM MCGILL Organization: The ARPA Internet Lines: 7 Approved: tcp-ip@ucbvax.berkeley.edu Please change my address from mcgill@cit-20 to tcm@cit-ssdp. Tom McGill ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8511102224.AA18773%40ucbvax.berkeley.edu] <1985111012032900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: bzs@BOSTONU.CSNET (Barry Shein) Newsgroups: mod.protocols.tcp-ip Subject: Re: nasty little 4.2 bug ?? Message-ID: <8511102224.AA18773@ucbvax.berkeley.edu> Date: Sun, 10-Nov-85 17:03:29 EST Article-I.D.: ucbvax.8511102224.AA18773 Posted: Sun Nov 10 17:03:29 1985 Date-Received: Mon, 11-Nov-85 06:39:03 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 36 Approved: tcp-ip@ucbvax.berkeley.edu >From: "J. Noel Chiappa" > > 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985111012032901> Received: from CSNET-RELAY.ARPA by SRI-NIC.ARPA with TCP; Sun 10 Nov 85 14:14:37-PST Received: from bostonu by csnet-relay.csnet id a001177; 10 Nov 85 17:11 EST Received: by bu-cs.ARPA (4.12/4.7) id AA27213; Sun, 10 Nov 85 17:03:29 est Date: Sun, 10 Nov 85 17:03:29 est From: Barry Shein 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" > > 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8511111739.AA07725%40ucbvax.berkeley.edu] <1985111107273600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: MILLS@USC-ISID.ARPA Newsgroups: mod.protocols.tcp-ip Subject: Re: Zero window probes Message-ID: <8511111739.AA07725@ucbvax.berkeley.edu> Date: Mon, 11-Nov-85 12:27:36 EST Article-I.D.: ucbvax.8511111739.AA07725 Posted: Mon Nov 11 12:27:36 1985 Date-Received: Tue, 12-Nov-85 04:36:48 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 18 Approved: tcp-ip@ucbvax.berkeley.edu 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) ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12158537451.44.HEDRICK%40RED.RUTGERS.EDU] <1985111117205900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: HEDRICK@RED.RUTGERS.EDU (Charles Hedrick) Newsgroups: mod.protocols.tcp-ip Subject: Re: Zero window probes Message-ID: <12158537451.44.HEDRICK@RED.RUTGERS.EDU> Date: Mon, 11-Nov-85 22:20:59 EST Article-I.D.: RED.12158537451.44.HEDRICK Posted: Mon Nov 11 22:20:59 1985 Date-Received: Wed, 13-Nov-85 06:57:47 EST References: <851108205728.000456@CISL-SERVICE-MULTICS.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 22 Approved: tcp-ip@ucbvax.berkeley.edu 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. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [%5BUSC-ISI.ARPA%5D12-Nov-85.06:52:07.CERF] <1985111201520000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: CERF@USC-ISI.ARPA Newsgroups: mod.protocols.tcp-ip Subject: Re: Zero window probes Message-ID: <[USC-ISI.ARPA]12-Nov-85.06:52:07.CERF> Date: Tue, 12-Nov-85 06:52:00 EST Article-I.D.: <[USC-ISI.ARPA]12-Nov-85.06:52:07.CERF> Posted: Tue Nov 12 06:52:00 1985 Date-Received: Wed, 13-Nov-85 07:59:22 EST References: <851108205728.000456@CISL-SERVICE-MULTICS.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 14 Approved: tcp-ip@ucbvax.berkeley.edu 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8511121502.AA02592%40merlin.Purdue.EDU] <1985111205020500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: cak@PURDUE.EDU ("Christopher A. Kent") Newsgroups: mod.protocols.tcp-ip Subject: Re: Zero window probes Message-ID: <8511121502.AA02592@merlin.Purdue.EDU> Date: Tue, 12-Nov-85 10:02:05 EST Article-I.D.: merlin.8511121502.AA02592 Posted: Tue Nov 12 10:02:05 1985 Date-Received: Wed, 13-Nov-85 08:05:55 EST References: <12158537451.44.HEDRICK@RED.RUTGERS.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 9 Approved: tcp-ip@ucbvax.berkeley.edu 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 ---------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8511121302.AA00247%40mitre.ARPA] <1985111207183900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: raklein@MITRE.ARPA (Richard Klein) Newsgroups: mod.protocols.tcp-ip Subject: FTAM (ISO' FTP) Message-ID: <8511121302.AA00247@mitre.ARPA> Date: Tue, 12-Nov-85 12:18:39 EST Article-I.D.: mitre.8511121302.AA00247 Posted: Tue Nov 12 12:18:39 1985 Date-Received: Wed, 13-Nov-85 08:14:42 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 13 Approved: tcp-ip@ucbvax.berkeley.edu 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8511130432.AA16525%40ucbvax.berkeley.edu] <1985111218201100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: MILLS@USC-ISID.ARPA Newsgroups: mod.protocols.tcp-ip Subject: Known NTP servers Message-ID: <8511130432.AA16525@ucbvax.berkeley.edu> Date: Tue, 12-Nov-85 23:20:11 EST Article-I.D.: ucbvax.8511130432.AA16525 Posted: Tue Nov 12 23:20:11 1985 Date-Received: Thu, 14-Nov-85 01:11:40 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 67 Approved: tcp-ip@ucbvax.berkeley.edu 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 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1985.11.13.11.20.02.300.05081%40Dione.rice] <1985111307200100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: milazzo@RICE.EDU (Paul Milazzo) Newsgroups: mod.protocols.tcp-ip Subject: 2.9bsd + networking on PRO 350? Message-ID: <1985.11.13.11.20.02.300.05081@Dione.rice> Date: Wed, 13-Nov-85 12:20:01 EST Article-I.D.: Dione.1985.11.13.11.20.02.300.05081 Posted: Wed Nov 13 12:20:01 1985 Date-Received: Thu, 14-Nov-85 07:47:42 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 17 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8511140135.AA27064%40ames-nas.ARPA] <1985111315355900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: woo@AMES-NAS.ARPA (Alex Woo) Newsgroups: mod.protocols.tcp-ip Subject: drivers for the microVAX II under VMS Message-ID: <8511140135.AA27064@ames-nas.ARPA> Date: Wed, 13-Nov-85 20:35:59 EST Article-I.D.: ames-nas.8511140135.AA27064 Posted: Wed Nov 13 20:35:59 1985 Date-Received: Fri, 15-Nov-85 04:03:25 EST Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 6 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8511141619.AA12984%40rsch.wisc.edu] <1985111406194800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: lhl@RSCH.WISC.EDU (L.H. Landweber) Newsgroups: mod.protocols.tcp-ip Subject: request for information Message-ID: <8511141619.AA12984@rsch.wisc.edu> Date: Thu, 14-Nov-85 11:19:48 EST Article-I.D.: rsch.8511141619.AA12984 Posted: Thu Nov 14 11:19:48 1985 Date-Received: Fri, 15-Nov-85 05:34:03 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 12 Approved: tcp-ip@sri-nic.arpa 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 To: Larry Landweber 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985111522572400> Received: from DCN6.ARPA by SRI-NIC.ARPA with TCP; Fri 15 Nov 85 15:22:39-PST Date: 15-Nov-85 22:57:24-UT From: mills@dcn6.arpa Subject: Network Time Protocol document revisions To: tcp-ip@sri-nic.arpa 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 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8511162149.AA25268%40ucbvax.berkeley.edu] <1985111611400900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: montgmry@DEWEY.UDEL.EDU (Doug Montgomery) Newsgroups: mod.protocols.tcp-ip Subject: LAN management references Message-ID: <8511162149.AA25268@ucbvax.berkeley.edu> Date: Sat, 16-Nov-85 16:40:09 EST Article-I.D.: ucbvax.8511162149.AA25268 Posted: Sat Nov 16 16:40:09 1985 Date-Received: Mon, 18-Nov-85 06:51:13 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 25 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985111611400901> Received: from Dewey.UDEL.EDU by SRI-NIC.ARPA with TCP; Sat 16 Nov 85 13:44:09-PST Date: Sat, 16 Nov 85 16:40:09 EST From: Doug Montgomery 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [851116215921.066958%40HIS-PHOENIX-MULTICS.ARPA] <1985111611590000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: SAkers@HIS-PHOENIX-MULTICS.ARPA ("Scott C. Akers") Newsgroups: mod.protocols.tcp-ip Subject: TCP/IP on a board Message-ID: <851116215921.066958@HIS-PHOENIX-MULTICS.ARPA> Date: Sat, 16-Nov-85 16:59:00 EST Article-I.D.: HIS-PHOE.851116215921.066958 Posted: Sat Nov 16 16:59:00 1985 Date-Received: Wed, 20-Nov-85 00:45:12 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 16 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1985.11.18.10.22.42.890.24322%40Dione.rice] <1985111806224200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: milazzo@RICE.EDU (Paul Milazzo) Newsgroups: mod.protocols.tcp-ip Subject: 2.9bsd+TCP/IP for PRO 350 (SUMMARY) Message-ID: <1985.11.18.10.22.42.890.24322@Dione.rice> Date: Mon, 18-Nov-85 11:22:42 EST Article-I.D.: Dione.1985.11.18.10.22.42.890.24322 Posted: Mon Nov 18 11:22:42 1985 Date-Received: Wed, 20-Nov-85 00:44:32 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 40 Approved: tcp-ip@sri-nic.arpa 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 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 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8511181916.AA11151%40ucbopal.Berkeley.Edu] <1985111809164600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: minshall%ucbopal@UCBVAX (Greg Minshall) Newsgroups: mod.protocols.tcp-ip Subject: tn3270 Message-ID: <8511181916.AA11151@ucbopal.Berkeley.Edu> Date: Mon, 18-Nov-85 14:16:46 EST Article-I.D.: ucbopal.8511181916.AA11151 Posted: Mon Nov 18 14:16:46 1985 Date-Received: Wed, 20-Nov-85 00:45:27 EST Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 14 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985111812320000> Received: from ACC.ARPA.ARPA (ACC.ARPA) by SRI-NIC.ARPA with TCP; Mon 18 Nov 85 20:48:24-PST Date: 18 Nov 85 20:32:00 PST From: Subject: RE: 1822 HDH To: "tcp-ip" Reply-To: > 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" ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985111813302500> Received: from harvard.HARVARD.EDU by SRI-NIC.ARPA with TCP; Mon 18 Nov 85 15:29:08-PST 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? ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8511190457.AA13264%40ucbvax.berkeley.edu] <1985111818320000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: art@ACC.ARPA Newsgroups: mod.protocols.tcp-ip Subject: RE: 1822 HDH Message-ID: <8511190457.AA13264@ucbvax.berkeley.edu> Date: Mon, 18-Nov-85 23:32:00 EST Article-I.D.: ucbvax.8511190457.AA13264 Posted: Mon Nov 18 23:32:00 1985 Date-Received: Thu, 21-Nov-85 03:23:42 EST Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Organization: The ARPA Internet Lines: 16 Approved: tcp-ip@sri-nic.arpa > 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" ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [376.501355669%40uci.edu] <1985112007274900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: raj@UCI.EDU (Richard Johnson) Newsgroups: mod.protocols.tcp-ip Subject: VAX 750 Rev. 7 /boot fixes Message-ID: <376.501355669@uci.edu> Date: Wed, 20-Nov-85 12:27:49 EST Article-I.D.: uci.376.501355669 Posted: Wed Nov 20 12:27:49 1985 Date-Received: Mon, 25-Nov-85 07:36:47 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 11 Approved: tcp-ip@sri-nic.arpa 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) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [851120190050.287761%40HI-MULTICS.ARPA] <1985112009000000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: RCLee@HI-MULTICS.ARPA ("Randy C. Lee") Newsgroups: mod.protocols.tcp-ip Subject: 1822/Ethernet gateway Message-ID: <851120190050.287761@HI-MULTICS.ARPA> Date: Wed, 20-Nov-85 14:00:00 EST Article-I.D.: HI-MULTI.851120190050.287761 Posted: Wed Nov 20 14:00:00 1985 Date-Received: Mon, 25-Nov-85 07:36:58 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 23 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8511210145.AA05915%40lasspvax.tn.cornell.edu] <1985112015455900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: garry@LASSPVAX.TN.CORNELL.EDU (Garry Wiegand) Newsgroups: mod.protocols.tcp-ip Subject: Re: tn3270 Message-ID: <8511210145.AA05915@lasspvax.tn.cornell.edu> Date: Wed, 20-Nov-85 20:45:59 EST Article-I.D.: lasspvax.8511210145.AA05915 Posted: Wed Nov 20 20:45:59 1985 Date-Received: Mon, 25-Nov-85 07:37:50 EST References: <8511181916.AA11151@ucbopal.Berkeley.Edu> Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: garry%geology@cu-arpa.cornell.edu.arpa Organization: Cornell Engineering && Flying Moose Graphics Lines: 8 Approved: tcp-ip@sri-nic.arpa 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8511212100.AA01574%40ucbvax.berkeley.edu] <1985112105310000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: KNapier@DDN2.ARPA Newsgroups: mod.protocols.tcp-ip Subject: buffer allocation errors on ACC LH/DH11 Message-ID: <8511212100.AA01574@ucbvax.berkeley.edu> Date: Thu, 21-Nov-85 10:31:00 EST Article-I.D.: ucbvax.8511212100.AA01574 Posted: Thu Nov 21 10:31:00 1985 Date-Received: Sun, 24-Nov-85 07:04:02 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 12 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985112105310001> Received: from ddn2 by SRI-NIC.ARPA with TCP; Thu 21 Nov 85 09:38:42-PST Date: 21 Nov 85 10:31 EST From: KNapier @ DDN2.ARPA Subject: buffer allocation errors on ACC LH/DH11 To: tcp-ip @ sri-nic.arpa CC: KNapier @ DDN2.ARPA 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985112106360000> Received: from ACC.ARPA.ARPA (ACC.ARPA) by SRI-NIC.ARPA with TCP; Thu 21 Nov 85 14:50:43-PST Date: 21 Nov 85 14:36:00 PST From: Subject: TWG, LH/DH-11, and RFNMs To: "knapier" cc: tcp-ip@sri-nic Reply-To: > 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" ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8511220342.AA18645%40decwrl.DEC.COM] <1985112110574200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: tcp-ip@ucbvax.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Zero window probes Message-ID: <8511220342.AA18645@decwrl.DEC.COM> Date: Thu, 21-Nov-85 15:57:42 EST Article-I.D.: decwrl.8511220342.AA18645 Posted: Thu Nov 21 15:57:42 1985 Date-Received: Mon, 25-Nov-85 07:38:12 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 20 Approved: tcp-ip@sri-nic.arpa (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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8511220634.AA11475%40ucbvax.berkeley.edu] <1985112120242300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: DP4Q@TE.CC.CMU.EDU (Drew D. Perkins) Newsgroups: mod.protocols.tcp-ip Subject: terminal type subnegotiation Message-ID: <8511220634.AA11475@ucbvax.berkeley.edu> Date: Fri, 22-Nov-85 01:24:23 EST Article-I.D.: ucbvax.8511220634.AA11475 Posted: Fri Nov 22 01:24:23 1985 Date-Received: Sun, 24-Nov-85 07:05:37 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 6 Approved: tcp-ip@sri-nic.arpa 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 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985112120242301> Received: from TE.CC.CMU.EDU by SRI-NIC.ARPA with TCP; Thu 21 Nov 85 22:23:02-PST Date: Fri 22 Nov 85 01:24:23-EST From: Drew D. Perkins Subject: terminal type subnegotiation To: tcp-ip@SRI-NIC.ARPA Office: UCC-123 x6628 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 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985112211341700> Received: from trantor.UMD.EDU by SRI-NIC.ARPA with TCP; Fri 22 Nov 85 13:32:54-PST Received: by trantor.UMD.EDU (5.5d/umd.04) id AA04710; Fri, 22 Nov 85 16:34:17 EST Date: Fri, 22 Nov 85 16:34:17 EST From: Louis A. Mamakos Message-Id: <8511222134.AA04710@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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8511240219.AA04486%40pyramid] <1985112316190100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: tcp-ip@ucbvax.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: tn3270 Message-ID: <8511240219.AA04486@pyramid> Date: Sat, 23-Nov-85 21:19:01 EST Article-I.D.: pyramid.8511240219.AA04486 Posted: Sat Nov 23 21:19:01 1985 Date-Received: Mon, 25-Nov-85 21:04:16 EST References: <8511181916.AA11151@ucbopal.Berkeley.Edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: Pyramid Technology, Mountain View, CA Lines: 17 Approved: tcp-ip@sri-nic.arpa 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}! ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8511241609.AA01350%40unido.uucp] <1985112406092500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: tcp-ip@ucbvax.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Wisconsin TCP/IP software Message-ID: <8511241609.AA01350@unido.uucp> Date: Sun, 24-Nov-85 11:09:25 EST Article-I.D.: unido.8511241609.AA01350 Posted: Sun Nov 24 11:09:25 1985 Date-Received: Wed, 27-Nov-85 00:31:32 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 6 Approved: tcp-ip@sri-nic.arpa Whom can I contact about details of TCP/IP under VM? Thanks -Daniel ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1985.11.24.11.51.25.510.18984%40Iapetus.rice] <1985112407512400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: milazzo@RICE.EDU (Paul G Milazzo) Newsgroups: mod.protocols.tcp-ip Subject: terminal type subnegotiation Message-ID: <1985.11.24.11.51.25.510.18984@Iapetus.rice> Date: Sun, 24-Nov-85 12:51:24 EST Article-I.D.: Iapetus.1985.11.24.11.51.25.510.18984 Posted: Sun Nov 24 12:51:24 1985 Date-Received: Tue, 26-Nov-85 08:20:34 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 18 Approved: tcp-ip@sri-nic.arpa "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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8511261718.AA11334%40idec.UUCP] <1985112607185800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: tcp-ip@ucbvax.UUCP Newsgroups: mod.protocols.tcp-ip Subject: WANTED: TCP/IP on ICL/George 3 (don't laugh) Message-ID: <8511261718.AA11334@idec.UUCP> Date: Tue, 26-Nov-85 12:18:58 EST Article-I.D.: idec.8511261718.AA11334 Posted: Tue Nov 26 12:18:58 1985 Date-Received: Wed, 27-Nov-85 22:24:24 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 21 Approved: tcp-ip@sri-nic.arpa 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 ukc!stc!idec!howellg STC IDEC LIMITED Stevenage Herts England +44 (0)438 738294 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8511270211.AA19165%40rsch.wisc.edu] <1985112616111100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: sue@RSCH.WISC.EDU (Sue Klein Lebeck) Newsgroups: mod.protocols.tcp-ip Subject: Re: Wisconsin TCP/IP software Message-ID: <8511270211.AA19165@rsch.wisc.edu> Date: Tue, 26-Nov-85 21:11:11 EST Article-I.D.: rsch.8511270211.AA19165 Posted: Tue Nov 26 21:11:11 1985 Date-Received: Wed, 27-Nov-85 22:34:10 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 11 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8512032328.AA21073%40ucbvax.berkeley.edu] <1985112823490000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: Vshank@WEIZMANN.BITNET (Henry Nussbacher) Newsgroups: mod.protocols.tcp-ip Subject: Spartacus Knet and Wisconsin Wiscnet Message-ID: <8512032328.AA21073@ucbvax.berkeley.edu> Date: Fri, 29-Nov-85 04:49:00 EST Article-I.D.: ucbvax.8512032328.AA21073 Posted: Fri Nov 29 04:49:00 1985 Date-Received: Wed, 4-Dec-85 20:41:43 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 4 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985112908060000> Received: from SRI-CSL.ARPA by SRI-NIC.ARPA with TCP; Fri 29 Nov 85 16:07:40-PST Date: 29 Nov 1985 16:06-PST Sender: GEOFF@SRI-CSL.ARPA Subject: C/70's ICMP considered anti-social? From: the tty of Geoffrey S. Goodfellow To: TCP-IP@SRI-NIC.ARPA Message-ID: <[SRI-CSL.ARPA]29-Nov-85 16:06:58.GEOFF> 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [%5BSRI-CSL.ARPA%5D29-Nov-85.16:06:58.GEOFF] <1985112914060000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: Geoff@SRI-CSL.ARPA (the tty of Geoffrey S. Goodfellow) Newsgroups: mod.protocols.tcp-ip Subject: C/70's ICMP considered anti-social? Message-ID: <[SRI-CSL.ARPA]29-Nov-85.16:06:58.GEOFF> Date: Fri, 29-Nov-85 19:06:00 EST Article-I.D.: <[SRI-CSL.ARPA]29-Nov-85.16:06:58.GEOFF> Posted: Fri Nov 29 19:06:00 1985 Date-Received: Fri, 29-Nov-85 22:30:21 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 22 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985112915190000> Received: from WISCVM.ARPA by SRI-NIC.ARPA with TCP; Tue 3 Dec 85 15:02:44-PST Received: from (VMMAIL)WEIZMANN.BITNET by WISCVM.ARPA on 11/29/85 at 03:48:43 CST Return-path: VSHANK%WEIZMANN.BITNET@WISCVM.ARPA Received: by WEIZMANN (Mailer X1.20) id 9272; Fri, 29 Nov 85 11:51:20 O Date: Fri, 29 Nov 1985 11:49 O From: Henry Nussbacher Subject: Spartacus Knet and Wisconsin Wiscnet To: 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8511301641.AA17893%40ucbvax.berkeley.edu] <1985113006225200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: sdyer@BBNCC5.ARPA Newsgroups: mod.protocols.tcp-ip Subject: Re: C/70's ICMP considered anti-social? Message-ID: <8511301641.AA17893@ucbvax.berkeley.edu> Date: Sat, 30-Nov-85 11:22:52 EST Article-I.D.: ucbvax.8511301641.AA17893 Posted: Sat Nov 30 11:22:52 1985 Date-Received: Sat, 30-Nov-85 12:25:54 EST References: <[SRI-CSL.ARPA]29-Nov-85.16:06:58.GEOFF> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 4 Approved: tcp-ip@sri-nic.arpa 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8512010758.AA24586%40ddnt.ARPA] <1985113021585300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: nrh@DDNT.ARPA (Nat Howard) Newsgroups: mod.protocols.tcp-ip Subject: name servers Message-ID: <8512010758.AA24586@ddnt.ARPA> Date: Sun, 1-Dec-85 02:58:53 EST Article-I.D.: ddnt.8512010758.AA24586 Posted: Sun Dec 1 02:58:53 1985 Date-Received: Sun, 1-Dec-85 06:11:16 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 19 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END----