|
|
ARCHIVE: TCP-IP Distribution List - Archives (1984)
DOCUMENT: TCP-IP Distribution List for December 1984 (52 messages, 23064 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1984/12.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.
START OF DOCUMENT
-----------[000000][next][prev][last][first]---------------------------------------------------- Date: Tue 4 Dec 84 11:42:33-PST From: Mark Crispin <MRC@SU-SCORE.ARPA> To: louie@UMD5.ARPA Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: SMTP Max recpients reply code
In my admittedly biased opinion, the mention of 552 in the SMTP specification is a bug in the specification. It should be 452. I would interpret 552 as meaning "too many people on this site have gotten this message, do not send it to any more people" as opposed to 442 which would mean "too many addressees in this SMTP transaction, please send this message to this addressee in another transaction." I'm pretty down on SMTP servers which place limits on the number of recipients. Many of them actually deliver the message to each recipient at the end of the transaction, forcing the SMTP sender to wait (and wait) for the acknowledgement to come back that the DATA command completed. I feel a superior approach is to queue the list of recipients and the message to some mailer process and get the SMTP connection out of the way as soon as possible. This has the side effect of maximizing SMTP throughput. -------
-----------[000001][next][prev][last][first]---------------------------------------------------- Date: 4 Dec 1984 12:04:53 PST From: POSTEL@USC-ISIF.ARPA To: tcp-ip@SRI-NIC.ARPA Subject: SMTP max recipients reply code
Louie: It has been suggested before that the reply code for "too many recipients" should be 452 (i.e., a temporary instead of permenant error). This would mean changing the second to last line on page 43 and the example on page 63 of RFC 821. I suggest that you go ahead an change the UMD2 system to return the 452 code. Let us know if that results in any further problems. --jon. -------
-----------[000002][next][prev][last][first]---------------------------------------------------- Date: Tue, 4 Dec 84 13:45:24 EST From: louie@umd5 (Louis Mamakos) To: tcp-ip@sri-nic Subject: SMTP Max recpients reply code
I'm so confused.. I observed a strangeness in the interaction between UMD5.ARPA (PDP 11/44 2.9BSD UNIX, running sendmail) and UMD2.ARPA (Sperry 1100/82, with our own IP/TCP networking code). UMD5's sendmail was attempting to deliver mail to multiple recpients on UMD2. When the local recpient storage space filled up, UMD2 returned a '552 Max recpients' reply to UMD5's sendmail for each of the remaining recpients, which marked each of the remaining recpients as perm failures. This caused an advisory message to be generated for those recpients rather than another SMTP transaction to be attempted. When I implemented the SMTP server on the Sperry (UMD2) system, I decided to return the 552 reply in this case, rather than the 452 reply since that agreed with the example scenario in RFC 821 on page 63. Sendmail looks like it might work if this reply is changed to a 452, but I haven't gone too deep in the code to make sure (and I'm not sure I want to if I can avoid it). So the questions are: Is sendmail on UMD5 broken? Is the SMTP server on UMD2 broken? Are they both broken? Should I use Federal Express instead? Louis A. Mamakos Computer Science Center - Systems Programming University of Maryland, College Park Internet: louie@umd5.arpa UUCP: ..!seismo!cvl!umd5!louie
-----------[000003][next][prev][last][first]---------------------------------------------------- Date: Wed, 5 Dec 84 12:09 PST From: Provan@LLL-MFE.ARPA To: tcp-ip@nic.arpa Subject: bug in UNIX telnet
I've run into a bug in UNIX telnet several times, and I'm wondering if there's any awareness of it in the TCP-IP club. I won't go into great detail, but the problem is that UNIX sends <LF> when the user types the return key. With most systems in the ARPAnet, this causes no problem, but we have a particular application where it is unacceptable (<LF> means something different than <CR><LF>). There's a fix to UNIX Telnet that solves this problem around. It's apparently a trivial one, but I can't remember just now who has it. The site we're currently having trouble with is ORNL-MSR. Could someone get the fix to them? Is there any chance of this being fixed more universally? I get tired of hearing about the same bugs over and over.
-----------[000004][next][prev][last][first]---------------------------------------------------- Date: Thu, 06 Dec 84 08:38:58 EST From: Dennis Rockwell <drockwel@CSNET-SH.ARPA> To: Tom Daniel <tom@UCL-CS.ARPA> Cc: Provan@LLL-MFE.ARPA, tcp-ip@SRI-NIC.ARPA Subject: Re: bug in UNIX telnet
Gee, I was hoping to stay out of this... I do indeed have a version of user telnet for 4.2 that behaves correctly when talking to the UCL TG (which switches back & forth between local and remote echo), which requires all the right things to happen at end-of-line. This version works *much* better when you're using telnet to talk to an SMTP server (or other local-echo netascii server) because it stays in cooked mode when doing local echo (thus, local line-editing works). It also implements word mode (transmit on non-alphanumeric or timeout); I put this in for use over low-bandwidth, high-delay, or charged nets (like X.25, which is all of the above). It cuts the packet count considerably, and perceived performance is better. This helps when using lossy gateways as well. If there's enough demand, I can probably make it available. I'll soak up requests for a while and see. Distribution will probably have to be in the form of a diff listing due to license hassles. Dennis Rockwell CSNET Technical Staff
-----------[000005][next][prev][last][first]---------------------------------------------------- Date: Thu, 6 Dec 84 14:36 EST From: Henry Nussbacher <HJNCU%CUNYVM.BITNET@Berkeley> To: <tcp-ip@sri-nic.ARPA>
Can you please register the following user in your list: arpalist%cunyvm.BITNET Thank you, Henry Nussbacher BITNET Network Information Center
-----------[000006][next][prev][last][first]---------------------------------------------------- Date: Thu, 6 Dec 84 10:44:51 GMT From: Tom Daniel <tom@ucl-cs.arpa> To: Provan@lll-mfe.arpa Cc: tcp-ip@sri-nic.arpa Subject: Re: bug in UNIX telnet
Yes I have come across this bug on a couple of hosts when
people were trying to acess the Terminal gateway at UCL. The
TELNET in the TG works line at a time and is very particular
about end of line being CRLF or CRNULL thus these
implementations wont work. One of the hosts was CSNET-SH and I
believe the person who fixed ithe problem there was Denis
Rockwell - drockwel@csnet-sh
Tom Daniel
-----------[000007][next][prev][last][first]---------------------------------------------------- Date: Thu, 6 Dec 84 21:32:06 EST From: Ron Natalie <ron@BRL-TGR.ARPA> To: Provan@LLL-MFE.ARPA Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: bug in UNIX telnet
UNIX telnet (I assume you mean the BSD one since there really isn't any others) has a number of bugs. First there is buffer boundry condition in the server that causes characters to be thrown away when dealing with large quantities of output. Second the server handles "Are you There" by sticking a bell in the input stream. Third, the user program sends out not linefeed when you type return but CR-NUL rather than CR-LF. This causes problem with some sites and makes it difficult to use telnet to debug other things like the mail system. If you still need the new versions, I could send you our locally enhanced version that also includes an option for local flow mode. -Ron
-----------[000008][next][prev][last][first]---------------------------------------------------- Date: 7 Dec 1984 1708 PST From: Ron Tencati <TENCATI@JPL-VLSI.ARPA> To: tcp-ip@sri-nic Subject: Implementing GATEWAYS
Hello again, As Christmastime approaches, I find it that it is time for my monthly network inquiry. This month's topic is GATEWAYS. I am trying to come up with some kind of scheme whereby I could network together some computers here at JPL via some kind of Local Area Net, and then gateway those computers to the ARPANET. Currently, there is a broadband Ungermann/Bass LAN installed at the Lab. One method would be to net some machines together on this LAN, and put one of them onto the ARPANET to act as the gateway. Another idea is to implement some other kind of network for the LAN, and then do the gateway. I am seeking information (general and technical) from persons who have implemented LANs with ARPA gateways at their facilities. In general, I'm interested in types of configurations that are being used, and your experiences with them. I would also appreciate getting a feel for how traffic affects the gateways, as well as a feel for an implementation estimate with respect to manpower, software, time, and resources that were needed to implement your particular configuration. Our initial configuration will probably be all VAXes, but we would like to plan a LAN/GATEWAY that is flexible enough to support many different CPUs on the same LAN. If you'd rather not clog up the mailing list with replies, feel free to send them directly to me. Thank you for any help/info/assistance anyone can send my way. Ron Tencati JPL-VLSI.ARPA Tech. Liaison ------
-----------[000009][next][prev][last][first]---------------------------------------------------- Date: Sat 8 Dec 84 04:14:26-PST From: Ken Harrenstien <KLH@SRI-NIC.ARPA> To: ron@BRL-TGR.ARPA, Provan@LLL-MFE.ARPA Cc: tcp-ip@SRI-NIC.ARPA, KLH@SRI-NIC.ARPA Subject: Re: bug in UNIX telnet
There is definitely another bug in UNIX telnet, at the other end -- the server. If you connect to a 2.9 or 4.2 BSD system, and do something that generates a lot of terminal output, you will see short glitches every so many lines where a string of characters is output twice. It looks something like thiut twice. It looks something like this. Output doesn't seem to be lost, but it iseem to be lost, but it is definitely annoying, especially if you are trying to look at an otherwise nicely formatted table (or paragraph!) I doubt it is a problem with TCP retransmitting (and resequencing!) output, because I have done massive FTPs without problems. The culprit is probably either in the Telnet server buffering code, or the UNIX pseudo-TTY kernel code. This may be the same thing that Ron Natalie mentioned, although he says output is dropped, whereas this bug manages to repeat a chunk of text. Granted, unless you look carefully you will immediately assume subtraction instead of addition. I am sure this has been fixed somewhere, but it seems to be the nature of things that such fixes are rarely distributed where they should be. This is one service that lists such as TCP-IP can perform. Houch as TCP-IP can perform. How about it? -------
-----------[000010][next][prev][last][first]---------------------------------------------------- Date: 8 Dec 84 1:18:13 EST From: DonWinter.pasa@XEROX.ARPA To: Postel@USC-ISIF.ARPA Cc: TCP-IP@SRI-NIC.ARPA, DonWinter.pasa@XEROX.ARPA Subject: IEEE 802.3 vs. IP Datagram on Ethernet
Jon, IEEE 802.3 redefines the "Type" field of an Ethernet packet as "length" for values from 0000H to 05FFH. Values of 0600H and greater are available for other uses. This clears Xerox NS packets, since they have a "Type" value of 0600H. However, IP Datagrams have "Type" value 0400H, and thus cannot co-exist with IEEE 802.3 packets on the same Ethernet. (The same is true of the earlier Xerox PUPs.) What impact does this have on the burgeoning number of Ethernet-based LANs out there in TCP/IP land, and what would be the reaction to an attempt to change the legal "Type" value of IP Datagrams to a value greater than 0600H? Don
-----------[000011][next][prev][last][first]---------------------------------------------------- Date: 8 Dec 1984 0757-PST (Saturday) From: lou@aero3 (Lou Nelson (ISRO)) To: TENCATI@JPL-VLSI.ARPA Cc: tcp-ip@sri-nic, sills@aero1, crocker@aero1, gal@aero1, lou@aero3 Subject: Re: Implementing GATEWAYS
>Date: 7 Dec 1984 1708 PST >From: Ron Tencati <TENCATI@JPL-VLSI.ARPA> >Subject: Implementing GATEWAYS >To: tcp-ip@sri-nic >Reply-To: TENCATI@JPL-VLSI.ARPA > >I am trying to come up with some kind of scheme whereby I could network >together some computers here at JPL via some kind of Local Area Net, and >then gateway those computers to the ARPANET. > >Currently, there is a broadband Ungermann/Bass LAN installed at the Lab. >One method would be to net some machines together on this LAN, and put one >of them onto the ARPANET to act as the gateway. Another idea is to >implement some other kind of network for the LAN, and then do the gateway. > >I am seeking information (general and technical) from persons who have >implemented LANs with ARPA gateways at their facilities. In general, I'm >interested in types of configurations that are being used, and your >experiences with them. I would also appreciate getting a feel for how >traffic affects the gateways, as well as a feel for an implementation >estimate with respect to manpower, software, time, and resources that were >needed to implement your particular configuration. > >Our initial configuration will probably be all VAXes, but we would like to >plan a LAN/GATEWAY that is flexible enough to support many different CPUs >on the same LAN. > Ron, Here at Aerospace in El Segundo, we have been running three LANs connecting VAXes, Apollos, Dolphins, an Alto, PDP11 gateways, and IBM PCs for a while now. Our backbone net is a Proteon proNET that serves as the inter-building medium and all 4 VAXes and the 2 PDP11/23 gateways are connected to it. The primary gateway is the AERONET-GW host in the NIC host table and it connects the Aeronet, 192.5.9, to the MILNET, 26. The gateways run the standard BBN Internet gateway code, GGP I think. I haven't really kept track so we may be running EGP by now. We also have two intra-building Ethernets; one is connected to the backbone net via another gateway and the other is not officially connected at all, but in practice is connected via a VAX. I won't go on at length about this but would rather encourage you to call and/or visit for a tour. Lou Nelson (213) 615-4424
-----------[000012][next][prev][last][first]---------------------------------------------------- Date: Sat, 8 Dec 84 7:38:37 EST From: Ron Natalie <ron@BRL-TGR.ARPA> To: Ken Harrenstien <KLH@SRI-NIC.ARPA> Cc: ron@BRL-TGR.ARPA, Provan@LLL-MFE.ARPA, tcp-ip@SRI-NIC.ARPA, KLH@SRI-NIC.ARPA Subject: Re: bug in UNIX telnet
I believe I mentioned that bug. The problem is with when the buffer totally fills, i.e. you are catting a big file, every 1024th char gets dropped. If you repetatively cat /usr/pub/ascii (all the lines are the same length) you'll see that every 20 lines or so is missing a character. Actually, I've got a telnet for 4.2 that has these fixed, and a much nicer telnet for 4.1 that includes transcript mode, the ability to send things like AYT, AO, IP, etc..., flow mode and the ability to set these from the command line. If anybody wants these for 4.1 or they want to convert them to use the 4.2 network calls and give them out, they are welcome to them (I don't have time right now to do this). _Ron
-----------[000013][next][prev][last][first]---------------------------------------------------- Date: Monday, 10 Dec 1984 10:00-PST From: imagen!geof@su-shasta.arpa To: shasta!DonWinter.pasa@XEROX.ARPA Cc: shasta!TCP-IP@SRI-NIC.ARPA Subject: Re: IEEE 802.3 vs. IP Datagram on Ethernet
I beg to differ, the type of Internet datagrams is 0x800 (800 hex), and fits in with the IEEE 802.3 loophole nicely. In the recent ``XNS Implementors Group'' meeting, one of the Xerox people discussed this problem. The discrimination algorithm is: if ( ieeeheader.length > ethMaxLength ) then interpret as Ethernet type field else interpret as IEEE packet This does not solve the problem of the IEEE 802.3 header not having a type field, that is, of how to figure out what protocol header is next in the packet. The Xerox people at the XNS group said that xerox will continue to manage type numbers for the immediate future, and will allocate them to make this algorithm work. However, they acknowledged that this was useful only during the transition to IEEE 802.3, and was not an ultimate solution to the problem. There are two non-xerox-internal type fields that have been assigned that don't work with this algorithm. One is PUP (sorry to Stanford), which is 0x200, [I think], and the other was assigned to some unmentioned private organization. Both of these will be reassigned in the future. The xerox people also indicated that they consider IEEE 802.3 to be the `next release' of the Ethernet spec, and intend to switch to it. - Geof
-----------[000014][next][prev][last][first]---------------------------------------------------- Date: Mon 10 Dec 84 15:31:23-EST From: J. Noel Chiappa <JNC@MIT-XX.ARPA> To: TENCATI@JPL-VLSI.ARPA, tcp-ip@SRI-NIC.ARPA Cc: JNC@MIT-XX.ARPA Subject: Re: Implementing GATEWAYS
To add to what someone else just said, Proteon (mfrs of Pronet, with whom I am associated) are also going to be offering a gateway product based on the MIT CGW (which has been in service for several years at MIT and Stanford); this code can handle up to 280 packets/second running on an 11/23; a considerably faster MC68000 version is under way. People who want more details should contact Proteon at (617)-655-3340 (or me if they want real technical details). Noel -------
-----------[000015][next][prev][last][first]---------------------------------------------------- Date: Mon 10 Dec 84 15:58:40-EST From: J. Noel Chiappa <JNC@MIT-XX.ARPA> To: DonWinter.pasa@XEROX.ARPA, Postel@USC-ISIF.ARPA Cc: TCP-IP@SRI-NIC.ARPA, JNC@MIT-XX.ARPA Subject: Re: IEEE 802.3 vs. IP Datagram on Ethernet
It is technically possible to switch to a different field, albeit quite painful due to the extremely large number of machines deplayed in the field (probably way over several thousand by now). For easiest implementation there would be three stages: a) in which all existing software has to be taught that the new number exists to recognize it on input, b) in which this number is generated by default on output, and c) recognition of the old number as an IP packet is deleted to allow it to be used as a length. The questions I have so far heard no commentary on involve how this new length field is supposed to fit in. For instances of the new style header, will multiple protocols on a single wire be supported? Did the people writing the spec even consider this? Will it be done by a new 'type field' after the existing header? Will the the format of this field and the numbers in it be a standard? What mechanism will a host use to decide whether to send, say, an IP packet in the 'type' format or the 'length' one? Will people build hardware that recognizes and uses the length field? What will it do when given a header without a length field? Since the hardware has to work without a length field anyway, what use is adding hardware to use it? Why couldn't people put a length field in the protocol header if they needed one? If people build hardware that generates a length field, will it be possible to supress this insertion to use type codes instead? I could go on but you get the idea. I try not to flame much any more, but I have got to say that this 'Length' bit is one of the stupidest ideas I have heard in 8 years of building network hardware and software. With any luck the marketplace will laugh it off; however, the IEEE's extremely foolish action in promulgating this drivel may well stick. God help us all. Noel -------
-----------[000016][next][prev][last][first]---------------------------------------------------- Date: Mon, 10 Dec 84 17:34:10 CST From: Mike Caplinger <mike@rice.ARPA> To: tcp-ip@nic.ARPA Subject: "all messages" data in RFC 918
Is there any standard way of separating messages transmitted in a big blob, as in response to a RCEV command? Perhaps it would be better to use a Grapevine-like primitive to read a single message, rather than receiving all available messages at one go. A (possibly crude) user interface based on the single-message per transaction would be easier to write, too. - Mike
-----------[000017][next][prev][last][first]---------------------------------------------------- Date: 10 Dec 1984 2317 PST From: Ron Tencati <TENCATI@JPL-VLSI.ARPA> To: tcp-ip@sri-nic Cc: info-vax@sri-kl Subject: Gateway Information
I want to thank all the people who are responding to my inquiry into gateways. The information I am getting is quite informative. This week, I will be at DECUS and will be unavailable. Next week, I will follow up on the msgs I am recieving. Keep those cards and letters coming! Thanks again, Ron ------
-----------[000018][next][prev][last][first]---------------------------------------------------- Date: Tue, 11 Dec 84 17:20 EST From: Mike StJohns <StJohns@MIT-MULTICS.ARPA> To: tcp-ip@SRI-NIC.ARPA Subject: expansions to FTP spec
Is there any interest in expanding FTP to handle LINE and RECORD
oriented file transfers? What I mean by this is the ability to open a
remote file and transfer only specific portions of the file, rather than
the entire file. I see at LEAST the following commands being added to
handle this.
OPMD - Open Mode, read, write, or read/write (append?)
OPEN - Actually open the file and connect to the currently
specified data port.
POSN - Depends on type of file, could be a key seek, relative or
absolute position. Depends on TYPE of transfer.
READ - Read one line (or record) from the file and throw it at the
data port.
WRIT - Grab a line (or record) of data from the data port and write
it at the current position in the file.
CLFL - Close file. Housekeeping.
This would be the beginnings of a standardized distributed database
system (well, at least some of the primitives needed to implement one)
Mike .
-----------[000019][next][prev][last][first]---------------------------------------------------- Date: Tue, 11 Dec 84 19:24:00 EST From: Doug Kingston <dpk@BRL-TGR.ARPA> To: Mike StJohns <StJohns@MIT-MULTICS.ARPA> Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: expansions to FTP spec
Your ideas for an expanded file access service have merit,
but DO NOT add it to FTP. The range of file access services required
should be completely thought out and a NEW service defined and
implemented. I suggest that a virtual file system interface be defined,
and a set of remote procedure calls be defined upon it. Include
locking and whatever other facilities you might want. FTP is not the
place to start adding things. You might even call this new service
"CFTP", for ...
"Complex File Transfer Protocal"!
-Doug-
FTP Preservation Committee
PS. There is a great deal of active work on remote procedure call (RPC)
interfaces, particularly for communications between UNIX systems
across TCP connections, but not limited to such connections.
The basic RPC mechanism for most of these would easily adapt to
that addition of other RPC types, mapping to expanded services,
such as keyed file access.
-----------[000020][next][prev][last][first]---------------------------------------------------- Date: Tue 11 Dec 84 19:39:24-EST From: J. Noel Chiappa <JNC@MIT-XX.ARPA> To: StJohns@MIT-MULTICS.ARPA, tcp-ip@SRI-NIC.ARPA Cc: JNC@MIT-XX.ARPA Subject: Re: expansions to FTP spec
What you really want is a file access protocol, not a file transfer protocol. Several have been proposed and at least one implemented. -------
-----------[000021][next][prev][last][first]---------------------------------------------------- Date: 12 December 1984 05:36-EST From: Christopher C. Stacy <CSTACY @ MIT-MC> To: TCP-IP @ SRI-NIC Subject: Unix host table software query
Could anyone please send me information on C programs to compile an RFC810-style host table for 4.2 Unix systems?
-----------[000022][next][prev][last][first]---------------------------------------------------- Date: 12 Dec 84 10:29:12 PST (Wednesday) From: Lansford.PASA@XEROX.ARPA To: Mike StJohns <StJohns@MIT-MULTICS.ARPA> Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: expansions to FTP spec
"This would be the beginnings of a standardized distributed database system (well, at least some of the primitives needed to implement one)" While random access to a remote file is a very useful thing to have, FTP is an inappropriate protocol to use to achieve this. Bob
-----------[000023][next][prev][last][first]---------------------------------------------------- Date: 13 Dec 1984 15:47-PST From: Postel@isif To: TCP-IP@SRI-NIC.ARPA Subject: "all messages" data in RFC 918
Mike Caplinger: We are working on a revised PoP specification that includes a detailed description of the message separator. --jon
-----------[000024][next][prev][last][first]---------------------------------------------------- Date: Fri 14 Dec 84 05:40:31-PST From: Ken Harrenstien <KLH@SRI-NIC.ARPA> To: ron@BRL-TGR.ARPA Cc: Provan@LLL-MFE.ARPA, tcp-ip@SRI-NIC.ARPA, KLH@SRI-NIC.ARPA Subject: Re: bug in UNIX telnet
Sorry, but it's clear that the bug you mentioned is not the one I am talking about. I have not seen the char-drop bug. What I see is short segments of text that are REPEATED. This happens on a 4.2BSD system (SRI-TSCA). Someone mentioned that this was a 4.1 and 2.8 problem with TCP that was supposedly fixed by 4.2 and 2.9. That obviously is not the case either. Isn't there anyone out there who has also seen this happen when telnetting to such a system? -------
-----------[000025][next][prev][last][first]---------------------------------------------------- Date: Fri 14 Dec 84 06:38:23-PST From: Witold Paluszynski <Witold@WASHINGTON.ARPA> To: KLH@SRI-NIC.ARPA Cc: ron@BRL-TGR.ARPA, Provan@LLL-MFE.ARPA, tcp-ip@SRI-NIC.ARPA Subject: Re: bug in UNIX telnet
The bug you are talking about must be really common as I used to see it quite often (like once in 4 telnet sessions). Just as you said, some portion of output is repeated. It is 4.1 telnet server that must be at fault. I can't be sure if I saw it with 4.2. I seem to recall other people here confirmed having seen it too when I reported this. Witold -------
-----------[000026][next][prev][last][first]---------------------------------------------------- Date: Friday, 14 Dec 1984 09:34-PST From: imagen!geof@su-shasta.arpa To: shasta!KLH@SRI-NIC.ARPA Cc: shasta!tcp-ip@SRI-NIC.ARP Subject: Re: bug in UNIX telnet
Ken, Yes, I too have seen the bug that you mentioned, where characters are replicated in the telnet input stream. I get it telnetting to our 4.1a system. It appears to happen when a packet is lost, from the delays on the typeout. I seem to remember the old BBN 4.1 code doing the same thing about two years ago. I seem to remember a new release from BBN that fixed the problem, about two years ago; the Berkeley code had diverged by then. Anyone out there on TCP-IP remember the bug fix? - Geof
-----------[000027][next][prev][last][first]---------------------------------------------------- Date: Fri, 14 Dec 84 14:27:26 EST From: Dennis Rockwell <drockwel@CSNET-SH.ARPA> To: imagen!geof@SU-SHASTA.ARPA Cc: KLH@SRI-NIC.ARPA, tcp-ip@SRI-NIC.ARPA Subject: Re: bug in UNIX telnet
From: imagen!geof@SU-SHASTA.ARPA Subject: Re: bug in UNIX telnet Date: Friday, 14 Dec 1984 09:34-PST Anyone out there on TCP-IP remember the bug fix? - Geof Sure, I remember it; I wrote it. The bug was an off-by-one in the TCP resequencing code; if a multi-data-byte segment arrived that was a retransmission of some single-data-byte segments, the last byte that was retransmitted would be doubled. This doesn't sound like the bug under discussionh (which invloved segments of text being repeated, not single characters). Dennis
-----------[000028][next][prev][last][first]---------------------------------------------------- Date: 14 Dec 1984 1457-EST (Friday) From: Christopher A Kent <cak@Purdue.ARPA> To: imagen!geof@shasta.ARPA Cc: tcp-ip@SRI-NIC.ARPA, KLH@SRI-NIC.ARPA Subject: Re: bug in UNIX telnet
I think I have it here somewhere .... it got fixed before 4.2, as I recall, but maybe not before 4.1c. Aha. It looks like there were at least two tries. Good luck. Cheers, chris ------------------ From: daemon Subject: Fix to Stuttering Bug To: ucbtcp11@Sri-Tsc Date: 25 May 1983 1059-PDT (Wednesday) Date: 25 May 1983 at 0932-PDT Reply-To: dan @ Sri-Tsc From: Shasta!dan%SRI-TSC@SCORE Bill Croft sent me this fix to the (telnet) stuttering bug. Apparently Bill Joy went through some back versions of tcp_usrreq.c looking for the bug, and found that it was caused when fixing a different bug. Anyway, here is a diff listing, followed by the change in context. Thanks, Bill's, for the fix! ---------- diff tcp_usrreq.c tcp_usrreq.c- ---------- 189c189 < (void) tcp_output(tp); /* stutter bug fix */ --- > error = tcp_output(tp); ------------------------------------------------------ /* * Do a send by putting data in output queue and updating urgent * marker if URG set. Possibly send more data. */ case PRU_SEND: sbappend(&so->so_snd, m); #ifdef notdef if (tp->t_flags & TF_PUSH) tp->snd_end = tp->snd_una + so->so_snd.sb_cc; #endif (void) tcp_output(tp); /* stutter bug fix */ break; /* * Abort the TCP. */ case PRU_ABORT: tcp_drop(tp, ECONNABORTED); tp = 0; break; From: uucp Subject: Fix to Stuttering Bug fix! To: ucbtcp11@Sri-Tsc Date: 27 May 1983 1004-PDT (Friday) Date: 27 May 1983 at 0922-PDT Reply-To: dan @ Sri-Tsc From: Shasta!dan%SRI-TSC@SCORE ------- Forwarded Message Date: 25 May 1983 1346-PDT (Wednesday) From: sam%UCBARPA@Berkeley (Sam Leffler) Subject: Re: Fix to Stuttering Bug Message-Id: <8305252046.AA00860@UCBARPA.ARPA> Received: by UCBARPA.ARPA (3.342/3.29) id AA00860; 25 May 83 13:46:37 PDT (Wed) Received: from UCBARPA.ARPA by UCBVAX.ARPA (3.341/3.29) id AA03678; 25 May 83 13:46:57 PDT (Wed) To: dan@Sri-Tsc In-Reply-To: Your message of 25 May 1983 at 0932-PDT. <8305251658.AA03270@UCBARPA.ARPA> Received: from Ucb-Vax.arpa by SRI-TSC.arpa with TCP; 25 May 83 13:48-PDT This is actually not the proper way to fix the bug. By ignoring all errors, callers never see errors returned from the routing and interface layers (as well as some important ones from the ip layer). I found long ago that the reason for stuttering was ENOBUFS being returned to the telnet daemon (which would then resend the data). Consequently I added something of the form if (error == ENOBUFS) error = 0; in the PRU_SEND case of tcp_usrreq (the delta was subsequently lost). Understand however this forces errors such as "net unreachable" to be considered fatal errors (often not the case). The general problem is difficult due to the "mushy" way that errors are defined in the Internet, but it's safe to say returning errors directly back through subroutine calls was a mistake (I'm responsible). The proper way is probably to place only fatal errors in so_error and then never have tcp_output return a value. ------- End of Forwarded Message ---------- ----------
-----------[000029][next][prev][last][first]---------------------------------------------------- Date: Fri, 14 Dec 84 15:16:27 EST From: Ron Natalie <ron@BRL-TGR.ARPA> To: Witold Paluszynski <Witold@WASHINGTON.ARPA> Cc: KLH@SRI-NIC.ARPA, ron@BRL-TGR.ARPA, Provan@LLL-MFE.ARPA, tcp-ip@SRI-NIC.ARPA Subject: Re: bug in UNIX telnet
Is this differnet than the stuttering bug, where the contents of a small (usually single character) packet are repeat 10 or so times. If it is, it was a problem with TCP and has been fixed. -Ron
-----------[000030][next][prev][last][first]---------------------------------------------------- Date: Fri 14 Dec 84 22:16:27-PST From: Witold Paluszynski <Witold@WASHINGTON.ARPA> To: ron@BRL-TGR.ARPA Cc: KLH@SRI-NIC.ARPA, Provan@LLL-MFE.ARPA, tcp-ip@SRI-NIC.ARPA Subject: Re: bug in UNIX telnet
Yes, it is a different bug. I never counted how long string gets errouneously retransmitted but it should be order of 50-100. I also doubt if it is in the TCP code since it only shows up in telnet. But I am not sure. What I am sure about is that it is on the Unix side. I usually telnet from TOPS-20. Witold -------
-----------[000031][next][prev][last][first]---------------------------------------------------- Date: Fri, 14 Dec 84 23:31 EST From: Mike StJohns <StJohns@MIT-MULTICS.ARPA> To: Lansford.PASA@XEROX.ARPA Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: expansions to FTP spec
Date: 12 December 1984 13:29 est
From: Lansford.PASA at XEROX
Subject: Re: expansions to FTP spec
"This would be the beginnings of a standardized distributed database
system (well, at least some of the primitives needed to implement one)"
While random access to a remote file is a very useful thing to have, FTP
is an inappropriate protocol to use to achieve this.
Bob
_______________________________________ I got another response which
said the same thing... i.e. don't add it to FTP. I really don't
understand why. Why go through the fuss and bother of totally designing
another protocol when FTP has most of the hooks in it already? Granted
FTP is an established protocol, but why consign it to a static life?
Also, it bothers me to proliferate protocols when others exist that can
do the job.
As a system developer given the choice between programming a totally new
system or adding commands to an already working, modularly designed
system, I would take the latter. (Dust off that soapbox.....)
Mike
-----------[000032][next][prev][last][first]---------------------------------------------------- Date: 15-Dec-84 17:07:54-UT From: mills@dcn6 To: tcp-ip@nic Subject: Reflections on a segment trace
Folks, While trying to find the source of a bug recently I observed an interesting TCP segment trace from ECLB. That host was sending a message to the DCN6 fuzzball, which apparently received it with no problem. During the transfer, however, ECLB sent at least one jumbogram clearly violating the DCN6 window constraint. While this, by itself, does not violate current specifications - the excess was neatly trimmed off and ECLB eventually retransmitted it - it may be symptomatic of previously known TOPS-20 bugs in which this happened and did cause connections to hang in bizarre ways. Following is an extract from the segment trace showing how the segment sequence received at DCN6 covers the sequence space. In the following "Time" is the time of arrival (16-bit field, in milliseconds), "Seq" is the IP sequence number, "LWE" is relative position in sequence space of the first octet of the segment, "Size" is the number of octets in the segment and "Window" is the remaining receive window size after the segment is stored and which is returned in the subsequent ACK. A negative number in the "LWE" column indicates a retransmission, while a positive number greater than zero indicates a hole, which ordinarily is due to a dropped datagram. The first part of the trace shows normal operation, with no retransmitted or lost datagrams. The maximum receiver window size is 450. Note that the sum of the "Size" and "Window" quantities in each row sum to 450, indicating the SMTP server client of the TCP layer is gobbling up the data as fast as received. (disregard) Time Seq LWE Size Window ---------------------------------------------------------------------- 15:48:38 002 ?TRAP-I-TCP rcv 33207 49104 0 400 50 15:48:41 002 ?TRAP-I-TCP rcv 35741 49107 0 130 320 15:48:41 002 ?TRAP-I-TCP rcv 36124 49108 0 80 370 15:48:42 002 ?TRAP-I-TCP rcv 37024 49109 0 430 20 15:48:44 002 ?TRAP-I-TCP rcv 38808 49112 0 100 350 15:48:45 002 ?TRAP-I-TCP rcv 39791 49113 0 410 40 15:48:46 002 ?TRAP-I-TCP rcv 41524 49119 0 170 280 15:48:47 002 ?TRAP-I-TCP rcv 42025 49120 0 190 260 15:48:48 002 ?TRAP-I-TCP rcv 43475 49123 0 260 190 15:48:49 002 ?TRAP-I-TCP rcv 43991 49124 0 190 260 15:48:50 002 ?TRAP-I-TCP rcv 44958 49125 0 120 330 15:48:50 002 ?TRAP-I-TCP rcv 45441 49126 0 140 310 15:48:51 002 ?TRAP-I-TCP rcv 46441 49127 0 370 80 Now something wicked happens. Out of the blue ECLB sends a 536-octet jumbogram, clearly overflowing the receive window. The first 450 octets of it are stored and an ACK returned specifying a zero window. Shortly after that the SMTP server client empties the buffer and returns an ACK specifying 450 octets. Meanwhile, ECLB trots along with a 74-octet segment followed by a 160-octet segment, which are saved in the reassembly buffer, leaving a 536 - 450 = 86 octet hole at the beginning. Finally, ECLB retranmsits the 536-octet segment, the last 86 octets of which fill in the missing hole, and everything returns to normal. 15:48:54 002 ?TRAP-I-TCP rcv 49658 49132 0 536 0 15:48:56 002 ?TRAP-I-TCP rcv 50909 49137 86 74 450 15:48:57 002 ?TRAP-I-TCP rcv 52225 49138 160 290 450 15:49:01 002 ?TRAP-I-TCP rcv 56609 49132 -450 536 0 15:49:02 002 ?TRAP-I-TCP rcv 57643 49140 0 80 370 15:49:03 002 ?TRAP-I-TCP rcv 58243 49141 0 110 340 15:49:03 002 ?TRAP-I-TCP rcv 58443 49142 0 -3 447 I have no explanation why ECLB suddenly decided to send a 536-octet segment; however, it is nice to see that both ECLB and DCN6 do the Right Thing and data continue to flow anyway. Several months ago this problem was observed at other TOPS-20 sites, but in these cases something drastic went wrong in the TOPS-20 and the connection broke. Bugfixes were subsequently distributed by BBN and ISI; however, the data recorded here may indicate that not all of them have been installed at ECLB. Dave -------
-----------[000033][next][prev][last][first]---------------------------------------------------- Date: Mon 17 Dec 84 11:13:32-EST From: J. Noel Chiappa <JNC@MIT-XX.ARPA> To: StJohns@MIT-MULTICS.ARPA, Lansford.PASA@XEROX.ARPA Cc: tcp-ip@SRI-NIC.ARPA, JNC@MIT-XX.ARPA Subject: Re: expansions to FTP spec
It might be the case that server FTP contains large pieces that can be reused, but the user end will certainly be useless, since a File Access Protocol would have to be integrated with the application, unless you are going to run it in a separate process, in which case the performance will be terrible. In general, it is better to build new small things to do exactly what you want, rather than modifying the bits at hand, for several reasons. To begin with, you are not limited by the preexisting structure: when SMTP was done as a new mail transfer protocol, the designers had a free hand. Secondly, performance can be optimized to the application at hand: many FAP's use UDP rather than TCP for data transfer since UDP is better suited to applications where the round trip delay limits performance; FTP can use the ability of TCP to 'keep the pipe full'. Finally, it is much easier to maintain and find bugs in small systems than larger; FTP is a large jumble already (the spec is longer than any other one in the book except TCP), and it doesn't need to get worse. Noel -------
-----------[000034][next][prev][last][first]---------------------------------------------------- Date: 17 Dec 1984 16:41:05 PST From: POSTEL@USC-ISIF.ARPA To: TCP-IP@SRI-NIC.ARPA Subject: re: IEEE 802.3 and Ethernet Types
Geof Cooper: Thanks for straightening out that problem. By the way, do you know how the Service Access Point or SAP fits into this situation? There is a SAP assigned for IP (RFC-923 pg. 20). --jon. -------
-----------[000035][next][prev][last][first]---------------------------------------------------- Date: Tuesday, 18 Dec 1984 09:24-PST From: imagen!geof@su-shasta.arpa To: shasta!POSTEL@USC-ISIF.ARPA Cc: shasta!TCP-IP@SRI-NIC.ARPA Subject: re: IEEE 802.3 and Ethernet Types
Jon, I must confess general ignorance about the SAP issue. There was some off-handed mention of it at the XNS conference, from which I gathered that SAP's were proposed as a solution to the lack-of-type-field problem. I believe that a SAP is a small (16-bit?) header that goes above the IEEE 802.3 header. There were two gripes expressed about SAP's: [1] The portion of the header used as a type field is apparently 6 bits. Not much foresight in that. [2] There is both a `source' type field and a `destination' type field for each packet. The concept was that one represented what the sender of the packet put in the packet, and the other how the sender wanted the receiver to interpret the packet. No one could think of any useful situation where these would be different. Again, I don't really know what this is all about. Maybe someone else on the net can fill in more details. - Geof
-----------[000036][next][prev][last][first]---------------------------------------------------- Date: Wed 19 Dec 84 07:10:58-PST From: Ken Harrenstien <KLH@SRI-NIC.ARPA> To: mike@BRL-TGR.ARPA, Action@SRI-NIC.ARPA Cc: tcp-ip@SRI-NIC.ARPA, KLH@SRI-NIC.ARPA Subject: Re: NIC TABLE FAILURE!!!
There turned out to be 5 nulls in the host-table file just at that exact point. This is rather suspicious. I have written out a new version so that things will work for you while I start tracking down the original problem. It may turn out to be a disk error at some stage (ugh). -------
-----------[000037][next][prev][last][first]---------------------------------------------------- Date: 19 Dec 84 09:20:04 PST (Wednesday) From: Lansford.PASA@XEROX.ARPA To: Mike StJohns <StJohns@MIT-MULTICS.ARPA> Cc: Lansford.PASA@XEROX.ARPA, J. Noel Chiappa <JNC@MIT-XX.ARPA>, tcp-ip@SRI-NIC.ARPA Subject: Re: expansions to FTP spec
"....Why go through the fuss and bother of totally designing another protocol when FTP has most of the hooks in it already? Granted FTP is an established protocol, but why consign it to a static life? Also, it bothers me to proliferate protocols when others exist that can do the job." FTP is an end-to-end protocol which is assumed to be (fairly) transient - and can thus have a large amount of baggage associated with it for reliability, etc. However, "remote files" are quite another matter. In this case, you want to keep the connection open for considerable lengths of time, and allow many such simultaneous connections. thus any such protocol must be "light weight" (little "state", etc.) so as to minimize the resources expanded at the server end. For instance, restricting a server to say, 8 simultaneous FTP connections might result in quite adequate service to the user community because of the short duration of the connections; but you would find that you must allow perhaps an order of magnitude more "remote file " connections to satisfy user demands. Bob
-----------[000038][next][prev][last][first]---------------------------------------------------- Date: Wed, 19 Dec 84 9:46:30 EST From: Mike Muuss <mike@brl-tgr> To: Action@sri-nic.ARPA, KLH@sri-nic.ARPA Cc: tcp-ip@sri-nic.ARPA Subject: NIC TABLE FAILURE!!!
This morning, all the hosts at BRL were crippled, because the copy of the NIC table that we downloaded at 0400 was defective. At 0930, the probelm still existed at the NIC, and I notified the NIC operator. Very simply, the NIC table service on port 101 would return 1069 lines, and then break off and print "END:". No BRL hosts apear in the abbreviated table. This has destroyed connectivity at BRL, and interrupted the flow of mail between our hosts. This service is vital, please try to get the difficulty fixed quickly. -Mike Muuss Host Administrator for BRL-* Here is an excerpt from a TELNET session with the NIC on port 101: Script started on Wed Dec 19 09:37:36 1984 1 brl-tgr> telnet nic 101 Trying... Connected to sri-nic.arpa. Escape character is '^]'. ALL BEGIN: ; DoD Internet Host Table ; 18-Dec-84 ; Version number 410 ; ; Changes, corrections, comments or questions to (HOSTMASTER@SRI-NIC) ; ; The format of this file is documented in RFC 810, "DoD Internet ; Host Table Specification", which is available online at SRI-NIC ; as the file ; [SRI-NIC]<RFC>RFC810.TXT ; It may be retrieved via FTP using username ANONYMOUS with ; any password. ; ; NOTE CAREFULLY: RFC 810 has been slightly revised since the original ; version was written. In particular, the version printed in the ; "Internet Protocol Transition Workbook" does not document the ; added "machine type" field (between the host-name and system-name ; fields). ; ; The format for entries is: ; ; NET : NET-ADDR : NETNAME : ; GATEWAY : ADDR, ADDR : NAME : CPUTYPE : OPSYS : PROTOCOLS : ; HOST : ADDR, ALTERNATE-ADDR (if any): HOSTNAME,NICKNAME : CPUTYPE : ; OPSYS : PROTOCOLS : ; ; Where: ;; ADDR = internet address in decimal, e.g., 26.0.0.73 ;; CPUTYPE = machine type (PDP-11/70, VAX-11/780, FOONLY-F3, C/30, etc.) ;; OPSYS = operating system (UNIX, TOPS20, TENEX, ITS, etc.) ;; PROTOCOLS = transport/service (TCP/TELNET,TCP/FTP, etc.) ;; : (colon) = field delimiter ;; :: (2 colons) = null field NET : 4.0.0.0 : SATNET : NET : 6.0.0.0 : YPG-NET-TEMP : NET : 7.0.0.0 : EDN-TEMP : NET : 8.0.0.0 : BBN-NET-TEMP : NET : 10.0.0.0 : ARPANET : NET : 11.0.0.0 : DODIIS : NET : 12.0.0.0 : ATT : ...... lots of text removed here, for brevity ...... HOST : 128.32.0.19 : UCBINGRES.ARPA,UCBINGRES : VAX-11/780 : UNIX : TCP/TELNET,TCP/FTP,UDP : HOST : 128.36.0.19 : YALE-ZOO.ARPA,YALE-ZOO : APOLLO : AEGIS : TCP/FTP,TCP/TELNET,TCP/SMTP : HOST : 128.42.1.19 : RICE-ATEN.ARPA,RICE-ATEN,ATEN : SUN-120 : UNIX : TCP/FTP,TCP/SMTP,TCP/TELNET,ICMP,UDP : HOST : 128.5.32.20 : FORD-WDL20.ARPA,FORD-WDL20 : SUN-2/170 : UNIX : TCP/FTP,TCP/SMTP,TCP/TELNET,ICMP,UDP : HOST : 128.42.1.20 : RICE-ENDYMION.ARPA,RICE-ENDYMION,ENDYMION : SUN-120 : UNIX : TCP/FTP,TCP/SMTP,TCP/TELNET,ICMP,UDP : HOST : 128.3.0.21 : LBL-G.ARPA,LBL-G : VAX-11/780 : VMS : TCP/TELNET,TCP/FTP,TCP/SMTP,ICMP : HOST : 128.5.32.21 : FORD-WDL21.ARPA,FORD-WDL21 : SUN-2/120 : UNIX : TCP/FTP,TCP/SMTP,TCP/TELNET,ICMP,UDP : HOST : 128.42.1.21 : RICE-HEKTOR.ARPA,RICE-HEKTOR,HEKTOR : SUN-120 : UNIX : TCP/FTP,TCP/SMTP,TCP/TELNET,ICMP,UDP : HOST : 128.2.250.22 : CMU-CS-SC.ARPA,CMU-CS-SC : VAX-11/750 : VMS : TCP/TELNET,TCP/FTP,TCP/FINGER,TCP/SMTP : HOST : 128.3.0.22 : LBL-H.ARPA,LBL-H : VAX-11/780 : VMS : TCP/TELNET,TCP/FTP,TCP/SMTP,ICMP : HOST : 128.5.32.22 : FORD-WDL22.ARPA,FORD-WDL22 : SUN-2/120 : UNIX : TCP/FTP,TCP/SMTP,TCP/TELNET,ICMP,UDP : HOST : 128.32.0.22 : UCBDEGAS.ARPA,UCBDEGAS : VAX-11/750 : UNIX : TCP/TELNET,TCP/FTP,UDP : HOST : 128.42.1.22 : RICE-CERBERUS.ARPA,RICE-CERBERUS,CERBERUS : SUN-120 : UNIX : TCP/FTP,TCP/SMTP,TCP/TELNET,ICMP,UDP : HOST : 128.52.22.22 : MIT-HTVAX.ARPA,MIT-HTVAX,HTVAX,MIT-HT,HT : VAX-11/780 : UNIX : TCP/TELNET,TCP/SMTP,TCP/FTP : HOST : 128.2.250.23 : CMU-CS-FT.ARPA,CMU-CS-FT : VAX-11/750 : VMS : TCP/TELNET,TCP/FTP,TCP/FINGER,TCP/SMTP : HOST : 128.5.32.23 : FORD-WDL23.ARPA,FORD-WDL23 : SUN-2/120 : UNIX : TCP/FTP,TCP/SMTP,TCP/TELNET,ICMP,UDP : HOST : 128.42.1.23 : RICE-PROSERPINA.ARPA,RICE-PROSERPINA,PROSERPINA : SUN-120 : UNIX : TCP/FTP,TCP/SMTP,TCP/TELNET,ICMP,UDP : HOST : 128.5.32.24 : FORD-WDL24.ARPA,FORD-WDL24 : SUN-2/120 : UNIX : TCP/FTP,TCP/SMTP,TCP/TELNET,ICMP,UDP : HOST : 128.8.128.24 : CHESSIE.ARPA,CHESSIE,UMD-CHESSIE : PDP-11/24 : UNIX : TCP/TELNET,TCP/FTP,TCP/SMTP,TCP/ECHO,TCP/FINGER,ICMP,UDP : HOST : 128.9.0.24 : ISI-ACCUTEST.ARPA,ISI-ACCUTEST : LSI-11/23 : RSX11M : UDP : HOST : 128.32.0.24 : UCBMIRO.ARPA,UCBMIRO,MIRO : VAX-11/730 : UNIX : TCP/TELNET,TCP/FTP,TCP/SMTP,TCP/FINGER : HOST : 128.42.1.24 : RICE-ASTRAEA END: Connection closed by foreign host. NOTE how it aborts in the middle of RICE-ASTRAEA, yet gives the END: indication.
-----------[000039][next][prev][last][first]---------------------------------------------------- Date: 19 Dec 84 10:35:19 EST From: ddn-navy @ DDN1.ARPA To: tcp-ip @ sri-nic.arpa Cc: fnoc-mry @ ddn2.arpa, ddn-navy @ DDN1.ARPA Subject: Query on Data Gen AOS/VS <--> ARPANet Capability
A few weeks ago there was an extensive dialogue on the net concerning Data Gen AOS systems. I have a user at Fleet Numerical Oceanography Center who is procurring a Data Gen running VS. Has Data Gen announced a full Internet interface and if so does anyone have a POC so I can get them into the certification cycle here at DDN. Many thanks. Rod Richardson Navy Systems Implementor DDN Prog Mgt Office
-----------[000040][next][prev][last][first]---------------------------------------------------- Date: Thu, 20 Dec 84 14:03:23 est From: Alan Parker <parker@nrl-css> To: tcp-ip@nic Subject: Internet Gateways
We are in the market for an IP gateway to sit between our TCP/IP ethernet and a C/30 IMP. Where should we look? Any sellers welcome to call at (202) 767-3477 or send mail. Any other pointers appreciated. Thanks. -Alan
-----------[000041][next][prev][last][first]---------------------------------------------------- Date: 20 Dec 1984 1418-EST (Thursday) From: jnc@proteon To: parker@nrl-css Cc: tcp-ip at nic,jnc, hs,acm,jas Subject: Internet Gateways
This question seems to be getting asked a lot lately. Among others, Proteon, makers of the Pronet ring network, will be selling gateways based on the MIT C gateway. The code currently runs on PDP11's, with several years of service at MIT and Stanford; it is in the process of beig transported to the MC68000. People wanting more information should contact Proteon at (617)-655-3340 for marketing information, or me if they want technical details. Noel -------
-----------[000042][next][prev][last][first]---------------------------------------------------- Date: Thu, 20 Dec 84 14:59:21 EST From: Doug Kingston <dpk@BRL-TGR.ARPA> To: tcp-ip@sri-nic.ARPA Subject: TCP/IP for IBM MVS
Does an implementation exist that does not require the existence of VM (I know about WISCVM and Spartacus) -Doug-
-----------[000043][next][prev][last][first]---------------------------------------------------- Date: Fri, 21 Dec 84 06:40:38 cst From: lhl@wisc-rsch.arpa (L.H. Landweber) To: dpk@BRL-TGR.ARPA Cc: tcp-ip@sri-nic.ARPA Subject: Re: TCP/IP for IBM MVS
Bob Braden at UCLA has a TCP/IP for MVS.
-----------[000044][next][prev][last][first]---------------------------------------------------- Date: 21 Dec 1984 15:43 PST From: Gary Krall <GARY@ACC> To: TCP-IP@SRI-NIC Subject: IBM MVS support
In addition to Network Solutions supplying the software, ACC jointly with NS was awarded a contract to provide host interfaces for attaching IBM 4300, IBM 3300, IBM 370 and other IBM compatible mainframes to the Defense Data Network. ACC's IF-370/DDN hardware interface attaches directlty to the block multiplexor channel of IBM-type mainframes and offers both X.25 and HDH connection. The IF-370/DDN is capable of transferring data at rates in excess of 1.5M bits per second. The DDN/MVS package proposed to the DCA by Network Solutions and ACC includes on-site surveys, on-site customized installation of software, operational testing, ongoing support and maintenance and access to a toll- free service number. Gary Krall ------
-----------[000045][next][prev][last][first]---------------------------------------------------- Date: 21 Dec 1984 15:44 PST From: Gary Krall <GARY@ACC> To: TCP-IP@SRI-NIC Subject: XNS on 4.2
Does anyone know of any work and the status of that work of implementing Xerox XNS under the 4.2 networking kernal? Also any info about any work on having Courier run on top of TCP/IP? Thanks for the help, Gary Krall ------
-----------[000046][next][prev][last][first]---------------------------------------------------- Date: 21 Dec 1984 17:04:54 EST From: BRADEN@USC-ISI.ARPA To: dpk@BRL-TGR.ARPA, tcp-ip@SRI-NIC.ARPA Cc: BRADEN@USC-ISI.ARPA Subject: Re: TCP/IP for IBM MVS
In response to the message sent Thu, 20 Dec 84 14:59:21 EST from dpk@BRL-TGR.ARPA As noted in a recent DDN Newsletter, Network Solutions, Inc is under contract to provide support oninstallation and operation of the UCLA TCP/Ip code for OS/MVS. Call Will McDuffie at (703) 356 1411, or send mail to him at netsol@acc.arpa. Bob Braden -------
-----------[000047][next][prev][last][first]---------------------------------------------------- Date: Sat, 22 Dec 84 14:57:28 est From: James O'Toole <james@gyre> To: gary@acc Cc: tcp-ip@sri-nic Subject: Re: XNS on 4.2
Does anyone know of any work and the status of that work of
implementing Xerox XNS under the 4.2 networking kernal?
I know of mine. Chris Torek and I have made many changes to the 4.2
kernel so that we could try to implement the two lowest layers of XNS
inside the kernel (IDP and SPP). We have implemented IDP and SPP, except
for two things:
1) We haven't had time to test our implementations with our Xerox
workstations yet, so we almost certainly have small changes to make involving
packet formats.
2) The SPP implementation is not complete; we haven't done out of band
data, for example.
Also any info about any work on having Courier run on top of TCP/IP?
4.2 as distributed contains someone's experimental versions of courier
under TCP...see code in /usr/src/new/courier (Eric C. Cooper <cooper@berkeley>
is the name that comes to mind).
jqj@cornell and cu-arpa.bill@cornell are two people at (guess where?) cornell
who have been improving the courier-tcp code in /usr/new, intending to
implement courier on top of our SPP.
If you want more details about our implementation, contact me.
--Jim
-----------[000048][next][prev][last][first]---------------------------------------------------- Date: Thursday, 27 Dec 1984 09:27-PST From: imagen!cpr@su-shasta.arpa To: shasta!TCP-IP@SRI-NIC Subject: "TCP/IP for VM Systems Available Commercially"
FYI, the following article appeared in the latest CSNET News, Fall, 1984, No. 6, and is reprinted without permission in its entirety (please, someone at the CIC let me know if this is Bad Practice): "IBM has formally announced that it will market the software known as ''The VM Interface Program for TCP/IP,'' developed jointly by IBM and the University of Wisconsin. With this software, IBM VM hosts can connect to CSNET X25Net and use the ARPANET/DoD protocols for mail, file transfer, and remote login. Previously, the software was available to universities and colleges only, as the ''WISCNET'' package. (See CSNET News, No. 5.) "The VM Interface Program for TCP/IP provides the following functions: - An implementation of the standard DoD protocols TCP and IP under VM/SP Release 2 or 3. - File transfer to and from remote sites using file transfer protocol (FTP) - Electronic mail to remote sites using the VM NOTE facility as an interface to simple mail transfer protocol (SMTP) - Remote terminal login using the TELNET protocol "Sample programs are also provided for the Series/1 EDX system, Series/1 RPS system, or Device Access Control Unit to support interfaces to local area and packet-switched networks, including ProNet, Ethernet, and X.25. "There is a one-time chare of $17,000 for the software. "If you would like more specific information about the net TCP/IP interface software, please contact your local IBM sales representative and refer to Availability Notice G320-9219."
-----------[000049][next][prev][last][first]---------------------------------------------------- Date: 30 Dec 84 15:43:56 EST (Sun) From: Marshall Rose <mrose@udel-dewey> To: tcp-ip@sri-nic.arpa Subject: The Netweaver's Sourcebook
[ This probably belongs to info-micro, but ... ]
I picked up a copy of "The Netweaver's Sourcebook" by Dean Gengle.
It's got lots of interesting information on micros and networks
along with a long treatise on the information society. This book
is a lot like the hitchhikers's guide to the galaxy: parts of it
are really great, other parts are woefully untrue. Here's the
description about TCP/IP (which is why I sent this message to this
list):
"This is the Internet Protocol/Transmission Control Protocol,
set and used by the U.S. Department of Defense since 1980. It
is oriented towards peer-to-peer communications. It is only
important to the military, and those wishing to interface to
the military."
The back of the book has a "Netweaver's Feedback Form", so I'm
going to drop him a quick note politely stating my discuss.
My question to the group is: have you seen other descriptions of
TCP/IP outside of "our community", and if so, are they as misguided
as this? Or, if this is on the mark, how did I get so misguided?
Thanks,
/mtr
-----------[000050][next][prev][last][first]---------------------------------------------------- Date: 31 Dec 1984 07:30-EST From: CERF@USC-ISI.ARPA To: mrose@UDEL-DEWEY.ARPA Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: The Netweaver's Sourcebook
Perhaps the reason the author is misguided is the strong emphasis placed, during design and internal standardization, on meeting military needs for high reliability under extremely hostile (in the communications sense) conditions. Also, it is only in the last year or so that commercial versions of TCP/IP and related higher-level protocols have attracted some of the mainframe vendors - and I imagine much of this attraction stemmed from the need to link up with local area nets. From my present perspective, anything which stimulates commercial interest in marketing and supporting these protocols can only help since the ISO standards are still a long way from being complete or even available. Vint Cerf
-----------[000051][next][prev][last][first]---------------------------------------------------- Date: Mon 31 Dec 84 13:03:40-PST From: David Roode <ROODE@SRI-NIC.ARPA> To: CERF@USC-ISI.ARPA, mrose@UDEL-DEWEY.ARPA Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: The Netweaver's Sourcebook
Perhaps it would interest the people on this list to hear of two recent examples of support by DEC for TCP/IP. At the December DECUS Symposium, DEC relied on TCP/IP as the network link between VAXes running Ultrix (Unix) and the rest of their product line (VMS particularly). They thereby endorsed use of the Wollongong Group's supported TCP/IP (essentially the Unix version running under the Eunice emulator) for VMS. Furthermore, DEC has extended availability of TOPS-20 TCP/IP supported configurations to include its new Ethernet device, with non-ARPANET/MILNET customers in mind. -------
END OF DOCUMENT
| ISSN 1742-948X 01 (Online) | 2005/03/01 | Copyright 2002-2008 securitydigest.org. All rights reserved. |