----MESSAGE-BEGIN---- [8708011747.AA29905@bu-cs.BU.EDU] <1987080109475400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: bzs@BU-CS.BU.EDU (Barry Shein) Newsgroups: comp.protocols.tcp-ip Subject: Wollongong TCP/IP for Sys V Message-ID: <8708011747.AA29905@bu-cs.BU.EDU> Date: Sat, 1-Aug-87 13:47:54 EDT Article-I.D.: bu-cs.8708011747.AA29905 Posted: Sat Aug 1 13:47:54 1987 Date-Received: Sun, 2-Aug-87 09:54:15 EDT References: <8707311241.AA20146@nic.nyser.net> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 12 From: Marty Schoffstall >PS: RPI told AT&T that we HAD to have tcp/ip and ethernet on > ours or we simply wouldn't use them, AT&T delivered > tcp/ip. From my discussions with others who took > donated equipment, stances like that were rare. Or fell on deaf ears (we waited 24 months for an ethernet board and finally just gave up.) -Barry Shein, Boston University Moderator, INFO-3B ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12323076988.8.MRC@PANDA] <1987080111233900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: MRC@PANDA.COM (Mark Crispin) Newsgroups: comp.protocols.tcp-ip Subject: Re: Telnet, , etc. Message-ID: <12323076988.8.MRC@PANDA> Date: Sat, 1-Aug-87 15:23:39 EDT Article-I.D.: PANDA.12323076988.8.MRC Posted: Sat Aug 1 15:23:39 1987 Date-Received: Sun, 2-Aug-87 10:04:52 EDT References: <8707311950.AA12026@opal.berkeley.edu> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 47 Greg Minshall - The last time I used a hardwired terminal connected to a Unix system, I found that the RETURN key on the terminal's keyboard would cause the Unix system to believe that it had received a newline. While it is possible that the terminal had been modified so that the RETURN key sent a linefeed, there was a separate LINE FEED key. I forget whether or not I tried using the LINE FEED key as an alternative newline. What your Telnet implement has, in effect, done is eliminate transparency. Most implementors of Telnet programs across the network have been very careful to make sure that transparency is preserved, since the ARPANET was traditionally a heterogenous network. Now, it may be true that today's Internet is a mostly homogenous Unix network, but there are still some non-Unix boxes out there. I cannot help but get the impression from the tone of your message that you have no real justification for your implementation's behavior other than a possible interpretation of admittedly ambiguous standards. You haven't offered any operational explanation as to why your implementation must behave in the way it does. Is there something particularly special about 4.3 that demands this behavior that other versions of Unix did not have? Please don't get me wrong; I have been a frequent critic of the explanations in the Telnet standards as they are presently reflected in the RFC's. I have periodically pontificated about various finer operational details that are glossed over in the standards or are inadequately explained; during a recent TCP/IP conference I had a presentation on these details (I'm also supposed to write an article about this for Connexions...). We're not out to criticize you or make your life difficult. Your mistake is only one of many that have come up in various Telnet implementations over the years. Please accept our judgement not as a criticism of your basically fine work, but rather as a source of information on what you must do to get your implementation interoperating correctly with the rest of the network. We all have a shared interest in maximizing interoperability, and the folklore we have developed over the years is based on long, hard experience and much compromise. Thank you. -- Mark -- ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [182600001@uiucdcsb] <1987080117400000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: richards@uiucdcsb.cs.uiuc.edu Newsgroups: comp.protocols.tcp-ip Subject: Re: telnet CR processing, bridge comm s Message-ID: <182600001@uiucdcsb> Date: Sat, 1-Aug-87 21:40:00 EDT Article-I.D.: uiucdcsb.182600001 Posted: Sat Aug 1 21:40:00 1987 Date-Received: Sun, 2-Aug-87 19:54:52 EDT References: <27@abvax.icd.ab.com> Lines: 21 Nf-ID: #R:abvax.icd.ab.com:27:uiucdcsb:182600001:000:1045 Nf-From: uiucdcsb.cs.uiuc.edu!richards Aug 1 20:40:00 1987 Be careful here... We, too, got the 13000 software to fix that problem, and another, insidious bug popped up. Enabling "NetAscii" on ports caused those ports to send a non-printable ASCII character (I think Ctrl-A) at various times out the serial port of telnet sessions. I believe they corresponded to times when a packet arrived with the tcp "PUSH" option set. Run a telnet session on the CS/1 with a terminal that can be set to display the entire ascii character set, and run VI. See if you get some unwanted characters inserted at random places. We observed it when it started appearing inside escape sequences (e.g. ESC-Y-Row-Col types of character sequences would become something like ESC-Y-CTRLA-Row-Col, with obviously wrong results). I called this in to Bridge a few months ago, but aside from verifying that they observed the behaviour, havn't heard anything about a fix yet. Paul Richards University of Illinois at Urbana-Champaign, Dept of Comp Sci UUCP: {pur-ee,convex,inhp4}!uiucdcs!richards ARPA: richards@b.cs.uiuc.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708020346.AA18518@TOTO] <1987080119460200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mar@ATHENA.MIT.EDU Newsgroups: comp.protocols.tcp-ip Subject: adversity or perversity Message-ID: <8708020346.AA18518@TOTO> Date: Sat, 1-Aug-87 23:46:02 EDT Article-I.D.: TOTO.8708020346.AA18518 Posted: Sat Aug 1 23:46:02 1987 Date-Received: Sun, 2-Aug-87 11:02:42 EDT References: <8707310016.aa04873@Huey.UDEL.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 6 Multiple network numbers on a single wire can work if you are careful. Proteon gateways will support this, as will 4.3BSD acting as a gateway. What you really have to watch out for are broadcast packets. But if you don't run the rwhod or routed, it is unlikely that there will be any IP broadcasts on your net. -Mark ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708021056.AA14725@ucbvax.Berkeley.EDU] <1987080202220500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: HANK@BARILVM.BITNET (Henry Nussbacher) Newsgroups: comp.protocols.tcp-ip Subject: Mitek MVS solutions? Message-ID: <8708021056.AA14725@ucbvax.Berkeley.EDU> Date: Sun, 2-Aug-87 06:22:05 EDT Article-I.D.: ucbvax.8708021056.AA14725 Posted: Sun Aug 2 06:22:05 1987 Date-Received: Sun, 2-Aug-87 20:21:42 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 17 I have been looking into various solutions for MVS systems. I have looked at Fibronics KNET, Network Solutions DDN/MVS and have recently been talking to ACC and their ACCES/MVS. Just now I found a new company called Mitek that does not appear in the Vendors Guide. They have two boxes - M2130 which talks to a 37xx (SDLC) and an M2030 that talks directly to a channel. The other side of the connection is an Ethernet. They have 2 models of the M2130 - low speed (RS232) and hi speed (V.35). On the software side, they have an SNA Kernel, Ethernet Tcp/Ip software and the M2x30 Supervisor. They claim to support Telnet and FTP. No doc on ARP, SMTP, ICMP, etc. I'd like to hear from people who are using Mitek for connecting an MVS to Ethernet. Does their stuff work? Thanks, Hank ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987080216520500> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Sun 2 Aug 87 03:38:26-PDT Received: from VM1.BIU.AC.IL by wiscvm.wisc.edu ; Sun, 02 Aug 87 05:39:24 CDT Received: by BARILVM (Mailer X1.24) id 4503; Sun, 02 Aug 87 13:39:04 P Date: Sun, 02 Aug 87 13:22:05 P From: Henry Nussbacher Subject: Mitek MVS solutions? To: IBM mainframes and networking conference cc: tcp-ip@sri-nic.ARPA I have been looking into various solutions for MVS systems. I have looked at Fibronics KNET, Network Solutions DDN/MVS and have recently been talking to ACC and their ACCES/MVS. Just now I found a new company called Mitek that does not appear in the Vendors Guide. They have two boxes - M2130 which talks to a 37xx (SDLC) and an M2030 that talks directly to a channel. The other side of the connection is an Ethernet. They have 2 models of the M2130 - low speed (RS232) and hi speed (V.35). On the software side, they have an SNA Kernel, Ethernet Tcp/Ip software and the M2x30 Supervisor. They claim to support Telnet and FTP. No doc on ARP, SMTP, ICMP, etc. I'd like to hear from people who are using Mitek for connecting an MVS to Ethernet. Does their stuff work? Thanks, Hank ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708030222.AA12902@topaz.rutgers.edu] <1987080218221400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick) Newsgroups: comp.protocols.tcp-ip Subject: Re: How do you break up a B class number? Message-ID: <8708030222.AA12902@topaz.rutgers.edu> Date: Sun, 2-Aug-87 22:22:14 EDT Article-I.D.: topaz.8708030222.AA12902 Posted: Sun Aug 2 22:22:14 1987 Date-Received: Mon, 3-Aug-87 03:38:00 EDT References: <8707291901.AA06038@EDDIE.MIT.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 5 There is a compromise possible on the variable net mask issue. Many implementations of IP allow for more than one subnet on a given Ethernet. So you could pick a single mask that led to smallish network sizes, and then for a few networks with lots of hosts, simply use more than one subnet number for tmemq ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708030231.AA12937@topaz.rutgers.edu] <1987080218311400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick) Newsgroups: comp.protocols.tcp-ip Subject: Re: How do you break up a B class number? Message-ID: <8708030231.AA12937@topaz.rutgers.edu> Date: Sun, 2-Aug-87 22:31:14 EDT Article-I.D.: topaz.8708030231.AA12937 Posted: Sun Aug 2 22:31:14 1987 Date-Received: Mon, 3-Aug-87 03:48:22 EDT References: <8707310648.AA04517@RUTGERS.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 20 We currently use multiple subnet numbers for two cases: a system of Ethernets connected by bridges, and a single Ethernet that has 3 different groups on it that expect to move to different Ethernets shortly. Our gateways are from Cisco. Unix can be set up to know that several different networks are on the same cable. Add the extra subnets by using route add ..subnet.. ..local host address.. 0 The Cisco gateways have a similar ability. The only problem we have is that I don't like putting route commands in all the startup files for the individual machines. At the moment we are using route add default ..local host address.. 0 and depending upon the Cisco gateways to do proxy ARP. (For non-Unix hosts, we just don't tell them about subnetting, which gives the same effect.) Thus we don't have to make any changes on our hosts. But this is not my favorite way of doing routing. I'd rather be able to have a default route to a gateway, and have a form of ICMP redirect that says "do it yourself, dummy" for hosts that are on the same Ethernet but have different network numbers. But if you are willing to access proxy ARP, there doesn't seem to be any problem with using multiple subnet numbers on one network. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708030237.AA12981@topaz.rutgers.edu] <1987080218373100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick) Newsgroups: comp.protocols.tcp-ip Subject: Re: Streams TCP/IP Message-ID: <8708030237.AA12981@topaz.rutgers.edu> Date: Sun, 2-Aug-87 22:37:31 EDT Article-I.D.: topaz.8708030237.AA12981 Posted: Sun Aug 2 22:37:31 1987 Date-Received: Mon, 3-Aug-87 03:48:46 EDT References: <8707311109.AA17318@RUTGERS.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 14 Does it bother anyone else that streams doesn't seem to make provisions for multi-processor implementations? With BSD, you can hack the kernel all you like to allow for multiple processors. As long as your sockets behave the same to the user, he doesn't care. But with streams, users are supposed to be able to write portable code to do protocols. Clearly that level of code is going to need to do synchronization on multi-processor machines. As far as I can tell, the only reason multi-processor implementations are going to be able to pass the validation tests is because the validation tests don't do anything non-trivial. If they included something like a portable TCP/IP, then it would not be possible to run them unmodified on a multi-processor system. Since most non-workstation Unix systems these days are multi-processor, this is of some practical concern. What are implementors doing about this? ----MESSAGE-END---- ----MESSAGE-BEGIN---- [870803092021.7.DCP@KOYAANISQATSI.S4CC.Symbolics.COM] <1987080305200000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer) Newsgroups: comp.protocols.tcp-ip Subject: Re: IBM TCP. Message-ID: <870803092021.7.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Date: Mon, 3-Aug-87 09:20:00 EDT Article-I.D.: KOYAANIS.870803092021.7.DCP Posted: Mon Aug 3 09:20:00 1987 Date-Received: Tue, 4-Aug-87 02:03:15 EDT References: <171500006@uxc.cso.uiuc.edu> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 30 Date: 31 Jul 87 16:30:00 GMT From: uxc.cso.uiuc.edu!sandrock@a.cs.uiuc.edu DECnet uses the node address to set the least significant 16 bits of the 48-bit Ethernet hardware address while setting the most significant 32 bits to a "known" constant value. Specifically, the Ethernet address will be AA-00-04-00-xx-xx, where the xx-xx fields are the DECnet node address (area-number * 1024) + node-number. There may be both certain advantages and also disadvantages to this approach, but is it true that these addresses are not globally unique? Mark Sandrock, (sandrock@uxc.cso.uiuc.edu) The DECnet scheme "only" allows 64K hosts, or probably more precisly, only 64 areas. I would be quite surprised if there are only 64 installations of DECnet in the world. Therefore, if we assume that people conventionally number node within an area starting with 1, then there is likely a global non-uniqueness between machines of two installations that have the same area number. I have no idea how DECnet area numbers are assigned. The major disadvantage is that if ACME Computers (read: some other vendor) also used an algorithmic approach, it would be impossible, 100% impossible, for a machine to be able to support both protocols at once on one transciever, since it would require the transceiver to have two Ethernet addresses. Such multi-protocol machines do exist. Luckily, there is only one vendor that I know of (DEC) that uses an algorithmic Ethernet address. I'm pretty sure DEC knew about ARP in time; I'd have to get some ancient mail files off of tape to make sure. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [080387.095837.yakov@ibm.com] <1987080306565300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: YAKOV@IBM.COM (Jacob Rekhter) Newsgroups: comp.protocols.tcp-ip Subject: TCP/IP on IBM Token Ring and Source Routing Message-ID: <080387.095837.yakov@ibm.com> Date: Mon, 3-Aug-87 10:56:53 EDT Article-I.D.: ibm.080387.095837.yakov Posted: Mon Aug 3 10:56:53 1987 Date-Received: Tue, 4-Aug-87 02:58:48 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 36 I am the person who introduced source routing into TCP/IP code for AIX on IBM Token Ring. Note, that both PC and VM implementations were based on AIX code and therefore can interoperate with each other. First of all Source Routing which is implemented on AIX has nothing to do with IP source routing (IP source routing is part of IP header, while Token Ring Source Routing is part of MAC (Medium Access Control) header). Originally I though of ignoring MAC Source Routing completely. However, since IBM Token Ring has support for MAC layer Bridges and since AIX requirement was to support both TCP/IP and SNA over the token ring, I introduced MAC Source Routing. MAC Source Routing is implemented as a part of ARP. ARP cache is extended to include both hardware address and routing information (if present). Initial ARP broadcast is done either to all rings/all stations or to local ring/all stations (this is a configurable parameter). Notice, that both VM and PC doing broadcast to all ring/all stations. I made this option in order to decrease the number of broadcasts when multiple rings are connected via both MAC layer bridges (used for SNA) and by real IP routers (used by TCP). I asked J. Postel whether it would be feasable to (1) include MAC layer routing information into ARP reply (2) assign separate ARP hardware type for 802.5. The answer to both were "no". I would suggest, that other implementations which do not want to support MAC layer Source Routing should accept ARP requests with RCF (Route Control Field), but should indicate in reply that MAC Routing Information is not present (just turn off bit 0 of byte 0 of your source hardware address in MAC header in ARP reply). I would appreciate any comments/suggestions. Jacob Rekhter (YAKOV@IBM.COM) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [870803162359.017191@RADC-MULTICS.ARPA] <1987080308230000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Ata@RADC-MULTICS.ARPA ("John G. Ata") Newsgroups: comp.protocols.tcp-ip Subject: Re: Telnet, , etc. Message-ID: <870803162359.017191@RADC-MULTICS.ARPA> Date: Mon, 3-Aug-87 12:23:00 EDT Article-I.D.: RADC-MUL.870803162359.017191 Posted: Mon Aug 3 12:23:00 1987 Date-Received: Tue, 4-Aug-87 03:50:13 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 18 Greg, I have to disagree with your TELNET sending a if the user types a with local echoing and sending a if remote echoing takes place. While this may be useful in some UNIX applications, who expect this convention, it certainly confuses some of us non-UNIX hosts out there trying to talk to you. For example, we use remote echoing to supress the local echo of a password. Thus, when a user types her password, remote echoing takes place and the typed at the end of the password gets sent as a . This gets interpreted at our end as a which is NOT our end-of-line character. Of course, this causes a hang which can be very frustrating. Please, do not confuse local/remote echoing with some sort of private mode where TELNET ASCII characters get interpreted differently. I realize that this may be convenient for you, but it makes talking to different machines on the network, much more difficult. John G. Ata ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708031750.AA16190@devvax.TN.CORNELL.EDU] <1987080309503300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: fedor@DEVVAX.TN.CORNELL.EDU (Mark Fedor) Newsgroups: comp.protocols.tcp-ip Subject: Re: Wollongon TCP/IP for AT&T 3B2 Message-ID: <8708031750.AA16190@devvax.TN.CORNELL.EDU> Date: Mon, 3-Aug-87 13:50:33 EDT Article-I.D.: devvax.8708031750.AA16190 Posted: Mon Aug 3 13:50:33 1987 Date-Received: Tue, 4-Aug-87 04:22:05 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 23 Yeah, I run the same wollengong software on my 3b2/300 and the 513/udp port is the rwhod. I have a gateway (Proteon p4200) that picks these up all the time (since they are a broadcast) and reports "no server port 513" or some such and throws it away. Kill the rwhod if you don't want the port 513 annoyance. BTW, port 513/tcp is the rlogin port. Mark Also, my sendmail accepts "."'s I believe..... I have noticed that the wollongong telnet sometimes has difficulty establishing a connection with other telnet daemons. Have you? Also, the routed program doesn't seem to work, but early versions of routed never worked anyways..... :^) This tcp/ip software really makes the 3b2 halfway useable! ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1517@ihdev.ATT.COM] <1987080310032700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: pdg@ihdev.ATT.COM (Joe Isuzu) Newsgroups: comp.protocols.tcp-ip Subject: Re: Streams TCP/IP Message-ID: <1517@ihdev.ATT.COM> Date: Mon, 3-Aug-87 14:03:27 EDT Article-I.D.: ihdev.1517 Posted: Mon Aug 3 14:03:27 1987 Date-Received: Tue, 4-Aug-87 04:52:55 EDT References: <8707311655.AA20489@topaz.rutgers.edu> Reply-To: pdg@ihdev.UUCP (Joe Isuzu) Distribution: world Organization: American Nasal Amputation Centre Lines: 12 In article <8707311655.AA20489@topaz.rutgers.edu> ron@TOPAZ.RUTGERS.EDU (Ron Natalie) writes: >Is streams in the SVID? Really? Well DAMN ship back this AT&T SVR3 >release because streams ain't in it. Actually, streams is (are?) an extension in SVID (SVID is a broken into base and extension requirements). TLI is the same way. -- Paul Guthrie "Another day, another Jaguar" ihnp4!ihdev!pdg -- Pat Sajak ----MESSAGE-END---- ----MESSAGE-BEGIN---- [281@rruxa.UUCP] <1987080310170700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: gwl@rruxa.UUCP (George W. Leach) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Streams TCP/IP Message-ID: <281@rruxa.UUCP> Date: Mon, 3-Aug-87 14:17:07 EDT Article-I.D.: rruxa.281 Posted: Mon Aug 3 14:17:07 1987 Date-Received: Tue, 4-Aug-87 05:43:14 EDT References: <725@hjuxa.UUCP> <649@houxa.UUCP> <278@unixprt.UUCP> <561@applix.UUCP> <24336@sun.uucp> Organization: Bell Communications Research Lines: 25 Summary: 8th Edition Streams versus System V Rel 3 Streams In article <24336@sun.uucp>, guy@gorodish.UUCP writes: > > The concept is the same in Dennis Ritchie's version and in the S5R3 > version, but some of the details are different. I believe the S5R3 > version is bigger and more complicated. > I beleive that I have seen a socket interface built on top of streams in 8th Edition UNIX. Has anyone else? Also, has anyone noticed if the interface to stream i/o has changed between the 8th Edition and System V implementations? George W. Leach Bell Communications Research New Jersey Institute of Technology 444 Hoes Lane 4A-1129 Computer & Information Sciences Dept. Piscataway, New Jersey 08854 Newark, New Jersey 07102 (201) 699-8639 UUCP: ..!bellcore!indra!reggie ARPA: reggie%njit-eies.MAILNET@MIT-MULTICS.ARPA From there to here, from here to there, funny things are everywhere Dr. Seuss "One fish two fish red fish blue fish" ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708031835.AA24234@gr.utah.edu] <1987080310355800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: haas%gr@CS.UTAH.EDU (Walt Haas) Newsgroups: comp.protocols.tcp-ip Subject: Re: IBM TCP. Message-ID: <8708031835.AA24234@gr.utah.edu> Date: Mon, 3-Aug-87 14:35:58 EDT Article-I.D.: gr.8708031835.AA24234 Posted: Mon Aug 3 14:35:58 1987 Date-Received: Tue, 4-Aug-87 04:23:44 EDT References: <11@<12320729020> <171500006@uxc.cso.uiuc.edu> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 42 In article <171500006@uxc.cso.uiuc.edu>, sandrock@uxc.cso.uiuc.edu writes: > DECnet uses the node address to set the least significant 16 bits of the > 48-bit Ethernet hardware address while setting the most significant 32 > bits to a "known" constant value. Specifically, the Ethernet address > will be AA-00-04-00-xx-xx, where the xx-xx fields are the DECnet node > address (area-number * 1024) + node-number. > There may be both certain advantages and also disadvantages to this > approach, but is it true that these addresses are not globally unique? > > Mark Sandrock, (sandrock@uxc.cso.uiuc.edu) Not globally unique by a long shot - there can be only 65534 DECnet addresses by this number system. However there is an even more embarrassing problem with this arrangement- (and this problem also occurs with XNS which does the same thing). Suppose you have a DECnet (XNS) host which is connected to two Ethernets. Now each DECnet (XNS) node is allowed only a single DECnet (XNS) address, which the software loads into [all of] the Ethernet interface[s] attached to the node. This means that the node has the same 48-bit Ethernet address on both Ethernets. OK, now what happens when you attach a learning Ethernet bridge, such as the DEC LANbridge 100 or any of the numerous competitors between the same pair of Ethernets? Well, what happens is that when the node sends a packet on one Ethernet, the bridge learns the node is on that net, and starts routing all packets with that destination to the net where it saw the node's address. Then the same node sends a packet on the other net, using the same Ethernet source address, and the bridge says "whoops, that node just moved" and commences to route all packets for the node across to the other Ethernet! ----------------* Cheers -- Walt ARPA: haas@cs.utah.edu uucp: ...utah-cs!haas "...The unforgivable but by no means uncommited sin in this connection occurs when, A calling down that his rope is caught, it devolves that B is himself standing upon it. Any second man once guilty of this precious bit deserves to be demoted from his position for the remainder of the season!" Robert L. M. Underhill, "ON THE USE AND MANAGEMENT OF THE ROPE IN ROCK WORK," Sierra Club Bulletin, February 1931, p. 80. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12323617830.139.SY.KEN@CU20B.COLUMBIA.EDU] <1987080312543500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: sy.Ken@CU20B.COLUMBIA.EDU (Ken Rossman) Newsgroups: comp.protocols.tcp-ip Subject: Re: IBM TCP. Message-ID: <12323617830.139.SY.KEN@CU20B.COLUMBIA.EDU> Date: Mon, 3-Aug-87 16:54:35 EDT Article-I.D.: CU20B.12323617830.139.SY.KEN Posted: Mon Aug 3 16:54:35 1987 Date-Received: Tue, 4-Aug-87 05:29:28 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 28 We've had a reasonable amount of experience with medium to large DECnet networks here at Columbia. We have our own internal network, and we also connect to various other sites who also have their own DECnet networks. I am not sure how Ethernet addresses are administered (I was under the impression that one or more of the larger corporations plugging Ethernet divvy up the board addresses by board manufacturer). In any case, the first four bytes of a DECnet transformed Ethernet address are, by some "global allocation" method, preassigned to DEC as I understand it. Since, as David Plummer points out, DECnet IV only currently supports 64K nodes on any single DECnet (well, really 63K --- area 0 is not a real area, and generally designates Phase III nodes), it doesn't really matter whether the limitation occurs at the ethernet addressing level or at the DECnet addressing level. The limit is still the same -- 63K. There is no "global" administration of DECnet areas that I know of. I deal them out for CCnet (the DECnet here that spans the CU campus and several other schools). In fact, awhile back, we were looking at connecting to other large DECnets (PHYSnet, I think, was the name of one of them, or something close to that), and we were given AN area to live in by the PHYSnet administrators. Since we were already multi-area, this made it basically impossible for us to connect with them, and we bagged the idea. As for DECnet, ARP, and ethernet addresses, Ultrix handles this just fine. We just make sure that DECnet comes up before IP does, so that the ethernet address that ARP uses is the DECnet-transformed one. /Ken ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987080314412100> Received: from NNSC.NSF.NET (WS6.NNSC.NSF.NET) by SRI-NIC.ARPA with TCP; Mon 3 Aug 87 18:23:16-PDT To: postel@isi.edu cc: tcp-ip@sri-nic.ARPA Subject: re: What to Name the NIC Date: Mon, 03 Aug 87 21:21:21 -0400 From: Craig Partridge > Wrong. The namedroppers list is for the discussion of the design > and operation of the domain name system, not for the discussion > of what the names are or what names would be nice. Jon: I'm afraid you and I are working from different definitions. According to list-of-lists (23 Jun 87) , the namedroppers mailing list is to be used for "discussing the concepts, principles, design and implementation of the domain style *names*". (Italics mine). Now I understand that doesn't mean arguing about how to restructure the namespace (i.e., the debate about whether the choice of top-level domains was correct, which seems to be the particular bane of namedroppers) but I think the definition easily permits the discussion of questions about proper selection of names within the existing namespace. And NAMEDROPPERS is certainly more appropriate than TCP-IP. If you think that's the wrong definition of the list, then let's get it changed. Craig ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708040036.AA06461@bel.isi.edu] <1987080316365600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: postel@ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Naming the NIC Message-ID: <8708040036.AA06461@bel.isi.edu> Date: Mon, 3-Aug-87 20:36:56 EDT Article-I.D.: bel.8708040036.AA06461 Posted: Mon Aug 3 20:36:56 1987 Date-Received: Tue, 4-Aug-87 06:32:04 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 28 Craig: Wrong. The namedroppers list is for discussion of the design and operation of the domain name system, not for the discussion of what the names are or what names would be nice. --jon. ----- Begin Forwarded Message ----- To: tcp-ip@sri-nic.ARPA Subject: Naming the NIC Date: Fri, 24 Jul 87 13:18:42 -0400 From: Craig Partridge Hey guys, There is a forum for these sorts of naming issues -- the namedroppers list. I recommend that any continued debate migrate to that list and will even be so good as to resist the instinct to point out that the issue of how to name NICs and NOCs was settled (I thought) over a year ago. Craig Partridge ----- End Forwarded Message ----- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708040140.AA14086@ucbvax.Berkeley.EDU] <1987080317422700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: craig@NNSC.NSF.NET (Craig Partridge) Newsgroups: comp.protocols.tcp-ip Subject: re: What to Name the NIC Message-ID: <8708040140.AA14086@ucbvax.Berkeley.EDU> Date: Mon, 3-Aug-87 21:42:27 EDT Article-I.D.: ucbvax.8708040140.AA14086 Posted: Mon Aug 3 21:42:27 1987 Date-Received: Tue, 4-Aug-87 06:33:13 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 24 > Wrong. The namedroppers list is for the discussion of the design > and operation of the domain name system, not for the discussion > of what the names are or what names would be nice. Jon: I'm afraid you and I are working from different definitions. According to list-of-lists (23 Jun 87) , the namedroppers mailing list is to be used for "discussing the concepts, principles, design and implementation of the domain style *names*". (Italics mine). Now I understand that doesn't mean arguing about how to restructure the namespace (i.e., the debate about whether the choice of top-level domains was correct, which seems to be the particular bane of namedroppers) but I think the definition easily permits the discussion of questions about proper selection of names within the existing namespace. And NAMEDROPPERS is certainly more appropriate than TCP-IP. If you think that's the wrong definition of the list, then let's get it changed. Craig ----MESSAGE-END---- ----MESSAGE-BEGIN---- [870804093337.8.DCP@KOYAANISQATSI.S4CC.Symbolics.COM] <1987080405330000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer) Newsgroups: comp.protocols.tcp-ip Subject: Re: IBM TCP. Message-ID: <870804093337.8.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Date: Tue, 4-Aug-87 09:33:00 EDT Article-I.D.: KOYAANIS.870804093337.8.DCP Posted: Tue Aug 4 09:33:00 1987 Date-Received: Thu, 6-Aug-87 01:25:35 EDT References: <12323617830.139.SY.KEN@CU20B.COLUMBIA.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 35 Date: Mon 3 Aug 87 16:54:35-EDT From: Ken Rossman We've had a reasonable amount of experience with medium to large DECnet networks here at Columbia. We have our own internal network, and we also connect to various other sites who also have their own DECnet networks. I am not sure how Ethernet addresses are administered (I was under the impression that one or more of the larger corporations plugging Ethernet divvy up the board addresses by board manufacturer). In any case, the first four bytes of a DECnet transformed Ethernet address are, by some "global allocation" method, preassigned to DEC as I understand it. Sorry. Ethernet addresses are, in theory, assigned to hardware manufacturers in 2^24 address chunks and the manufacturer is responsible for administering its 2^24 addresses. DEC is "reassigning" the original hardware Ethernet address to be a DEC-specific protocol-related hardware address. That is not the intention of the Blue Book. DEC does not "manufacture" Interlan, 3Com, Symbolics, TI, etc, hardware, yet the hardware Ethernet addresses used would indicate DEC does. ... As for DECnet, ARP, and ethernet addresses, Ultrix handles this just fine. We just make sure that DECnet comes up before IP does, so that the ethernet address that ARP uses is the DECnet-transformed one. /Ken That's not what I meant. What I meant was that ARP existed in time for DECnet IV to use it, and that if DECnet used ARP instead of its current algorithmic translation, (a) we could preserve globally unique addresses, (b) you wouldn't have to worry about bringing up DECnet before IP (or any other protocol), and (c) if somebody else goes against the intention of the Blue Book we could still run DECnet and that other protocol at the same time (since it wouldn't then require different Ethernet addresses). ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987080407260000> Received: from ford-cos1.arpa.ARPA (FORD-COS1.ARPA) by SRI-NIC.ARPA with TCP; Tue 4 Aug 87 12:27:25-PDT Received: by ford-cos1.arpa.ARPA (5.15/4.7) id AA18482; Tue, 4 Aug 87 13:26:00 MDT Date: Tue, 4 Aug 87 13:26:00 MDT From: paclark%ford-cos1.arpa@ford-cos1.ARPA (Patricia A. Clark) Message-Id: <8708041926.AA18482@ford-cos1.arpa.ARPA> To: haas%gr%cs.utah.edu@ford-cos1.arpa, tcp-ip@sri-nic.ARPA Subject: Re: IBM TCP. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [3910002@hpindda.HP.COM] <1987080408342600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: unit@hpindda.HP.COM (Tom Engleman) Newsgroups: comp.protocols.tcp-ip Subject: Re: fyi Wollongong TCP/IP for VAX/VMS - Reply to Mark Crispin Message-ID: <3910002@hpindda.HP.COM> Date: Tue, 4-Aug-87 12:34:26 EDT Article-I.D.: hpindda.3910002 Posted: Tue Aug 4 12:34:26 1987 Date-Received: Fri, 7-Aug-87 05:19:50 EDT References: <8707151440.AA25042@nic.nyser.net> Organization: Hewlett Packard, Cupertino Lines: 74 / hpindda:comp.protocols.tcp-ip / JERRY@STAR.STANFORD.EDU / 2:29 pm Jul 15, 1987 / This is Dave Crocker, not Jerry Scott. I recently joined The Wollongong Group as Vice President, Software Engineering. We will soon be a host on MilNet, so I have not established an interim mailbox elsewhere. Please direct any short-term mail to me via Jerry at this address. The recent flurry of messages about Wollongong requires a formal response. As you are aware, The Wollongong Group has been selling TCP/IP-based products for some years. While we have been successful in doing so, we have been less successful in maintaining an unblemished reputation within the Internet community. Recently, we began taking actions to improve user perceptions. From a technical standpoint, the most significant of these actions involves upgrades to our VAX/VMS product called WIN/TCP, especially converting to the use of 4.3BSD as a code base for the TCP/IP implementation. By doing so, many long-standing problems were solved and performance has been substantially improved. On reviewing the messages that were sent to this distribution list, it appears that the basis for two of the three explicitly critical notes was a) system administration errors, and b) the use of very old software. At the present time, the new release (3.0) does not have any major TCP/IP bugs known to us, nor does it crash the operating system. The immediately previous version (2.3) has not had any bugs that crash VAXes for a time longer that any Wollongong personnel can remember. It is our policy to work closely with all users of our products to satisfy their needs. Mark Crispin's July 6 email message, while it contained no specific details, has been partially addressed in a public reply citing cockpit error, rather than faulty software. The message was sent by a system administrator whose contact with Mark triggered Mark's note. The system administrator cockpit error we identified does not involve any software bugs, but it does result in setting the hosts's own name to a constant ("Unknown"). To eliminate this confusion, we are changing the software to simply use the text version of the IP address, whenever a similar administrator error is made. As part of a test against one of the systems running Mark's TCP, we did encounter a client SMTP bug. WIN/TCP 3.1, which will be released shortly, fixes it. It was only discovered because of high delay in the Arpanet, thereby causing an extraordinary timeout. In addition to providing technically competent software, Wollongong must provide support for our products. This is critical. Although admittedly flawed in the past, this, too, is being significantly improved, as the recent TCP/IP activity cited above demonstrates. "Support" is a separate product and has to be purchased. There have been some customers who purchased the TCP product but did not, for whatever reason, purchase support. They then passed on the product to the real end-users and claimed, falsely, that we would not provide support. The cited case of our software crashing a VAX cluster appears to be an example of this. Although we subsequently established direct contact with a portion of the actual end-users affected in this way, we were unfortunately unable to find the remainder. The suggestion about our connecting the the Internet is extremely well- taken. Part of the reason I was asked to join Wollongong was to bring some Internet experience in-house. The wheels were already in motion, I discovered, to get a connection when I came on-board. We were supposed to be on MilNet about 4 months ago, and are in the final stages of debugging the telecom link. Lastly, with regard to our AT&T version of TCP/IP...it should be noted that we developed this product at the specification of AT&T and we are not free to add features on our own (AT&T markets the product; we do not). Hence, please ask them to suggest to us any changes that you deem appropriate. Dave ---------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708041647.AA07379@bel.isi.edu] <1987080408472400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: postel@ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: the namedroppers list policy Message-ID: <8708041647.AA07379@bel.isi.edu> Date: Tue, 4-Aug-87 12:47:24 EDT Article-I.D.: bel.8708041647.AA07379 Posted: Tue Aug 4 12:47:24 1987 Date-Received: Thu, 6-Aug-87 02:28:05 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 103 NAMEDROPPERS POLICY Scope: This NAMEDROPPERS mailing list is to be used for discussion of the concepts, principles, design, and implementation of the domain style names. The main focus of this group is the review of documents describing domain style name system (currently RFCs 882, 883, 973, 974) and discussion of the implementation of the system. The scope is limited to the technical aspects of the system. It does not include discussion of the actual names selected, or the semantics of those names. There are other forums for those discussions (for example, HEADER-PEOPLE, and ARPA-MHS). Policy: While one of the advantages of computer mail and mailing lists mechanisms is fast response, in this list we prefer to go a little slow to ensure thoughtful discussion. In general, one should let some time go by (a day) between first reading a message and composing a response. Even during periods of intense activity on this list one should not send more than one message per day. Typically this would allow one to discuss several other contributions in one message. * Wait a day between reading and sending. * Send at most one message per day. On the other hand, this is a list for participants in a discussion, not observers. Everyone on the list is expected to contribute from time to time. To get on or off NAMEDROPPERS send your request to NAMEDROPPERS-REQUEST@SRI-NIC.ARPA. Related mailing lists: HEADER-PEOPLE This group is for the discussion of issues in the design and implementation of the Internet community Text mail system (based on RFCs 821 and 822). Comments are welcome from any community that uses these conventions. This may include the interaction of the domain style names with the operation of this mail system. To get on or off HEADER-PEOPLE send your request to HEADER-PEOPLE-REQUEST@MIT-MC.ARPA. ARPA-MHS This group is explicitly focused on the development of means for interoperation and interconnection of the Internety community Text mail system and the international standards community X.400/MHS mail systems. This includes developing a mapping between the naming procedures used in these two systems. To get on or off ARPA-MHS send your request to ARPA-MHS-REQUEST@BRL.ARPA. MMM-PEOPLE This group is exploring the issues in multimedia computer mail (i.e., mail that includes text, bitmap, voice, graphics, and other special data types). This is based on work that has gone on for several years under both DARPA and NAVY sponsorship. There is consideration in this group of the use of X.400/MHS as a basis for further work on multimedia mail. To get on or off MMM-PEOPLE send your request to MMM-PEOPLE-REQUEST@C.ISI.EDU. Multiple Addresses: Nearly everyone in NAMEDROPPERS is also on HEADER-PEOPLE. There is no need to send a message to both NAMEDROPPERS and any other list. People are pretty careful about which lists they are and are not on. It is really best to send your message to exactly one list. If it was the wrong one, someone will let you know. Sending a message to more than one list will surely waste a significant amount of both computer and people time and resources. In fact, when sending to NAMEDROPPERS the only address needed is NAMEDROPPERS@SRI-NIC.ARPA. If you are responding to a particular comment by someone he or she will get the message without being explicitly addressed, and you will get a copy back too. History: All of the previous discussion of the NAMEDROPPERS can be found in the files NAMEDROPPERS.YYYY on SRI-NIC.ARPA, where YYYY is the year. There are currently files for 1983, 1984, and 1985. NAMEDROPPERS.MAIL contains the most current NAMEDROPPERS dialog. These files can be accessed via anonymous FTP. New member of NAMEDROPPERS may which to copy and read these archives before joining the discussion. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1249@bgsuvax.UUCP] <1987080409254600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: herber@bgsuvax.UUCP Newsgroups: comp.protocols.tcp-ip,comp.unix.wizards,comp.bugs.4bsd Subject: Problems starting vv0 Proteon PROnet-10 driver Message-ID: <1249@bgsuvax.UUCP> Date: Tue, 4-Aug-87 13:25:46 EDT Article-I.D.: bgsuvax.1249 Posted: Tue Aug 4 13:25:46 1987 Date-Received: Fri, 7-Aug-87 05:46:19 EDT Organization: Bowling Green State University B.G., Oh. Lines: 53 Keywords: proteon ifconfig phases_of_the_moon OK, this is a good one...... I have 2 4.3BSD VAXen on an ethernet using Interlan interfaces (il0) and a Proteon, PROnet-10 using Proteon pronet interfaces (vv0). I have just changed from using class A address numbers (we didn't talk to anyone else in the world) to a class B Internet address using subnetting. Everything worked all along with the class A addresses. When I tried the following sequence of commands in /etc/rc.local, ifconfig vv0 inet 129.1.1.1 netmask 0xffffff00 ifconfig il0 inet 129.1.2.3 netmask 0xffffff00 ifconfig lo0 localhost the ifconfig for the vv0 interface fails with an "ifconfig: ioctl (SIOCSIFADDR): Can't assign requested address" and the internet address is left at 0.0.0.0. The netmast is correctly set at 0xffffff00 though (see below); # ifconfig vv0 vv0: flags=63,UP,BROADCAST,NOTRAILERS,RUNNING> inet: 0.0.0.0 netmask ffffff00 # If I try the EXACT SAME ifconfig vv0 statement AFTER the initial failure, it works and the address is correctly set at 129.1.1.1. I then switched the order of the statements in the /etc/rc.local to ifconfig lo0 localhost ifconfig il0 inet 129.1.2.3 netmask 0xffffff00 ifconfig vv0 inet 129.1.1.1 netmask 0xffffff00 and reboot, it works just fine the FIRST TIME........ ARGH!!!!!!!!! I looked at the if_vv.c driver and the error is returned to the ioctl() that is used in ifconfig to initialize the address. The error is returned in if_vv.c when the host node number on the board is not the same as that of the host number in the address. It looks to be some kind of a problem when using the subnetting/netmask features. Now that I found a combination that works, I will continue to use it but I would love to hear someone's opinion (guess, even:-) of why this doesn't work consistantly. -- Steve Herber CSNET herber@bgsu.edu Sr. Systems Programmer UUCP ...!osu-eddie!bgsuvax!herber Bowling Green State Univ. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987080410060000> Received: from bluto.scc.com by SRI-NIC.ARPA with TCP; Tue 4 Aug 87 12:14:38-PDT Date: 4 Aug 87 15:06:00 EST From: "GBURG::ENGER" Subject: No echo from the NIC To: "tcp-ip" cc: enger Reply-To: "GBURG::ENGER" I experienced some difficulty connecting to the NIC on Sunday night. This led me to try to PING off of them (issue ICMP echo request). I did not receive any response from them on either their net-10 or net-26 address. I was able to receive ICMP echo replies from hosts on a number of networks so I wrote it off as a temporary network problem. I PINGed them again on monday, still no response. I called the NOC. They used TELNET to test connectivity, and they got through. The NOC was also able to TELNET to my host. When I told them I couldn't PING off the NIC, they became concerned. Taking their lead, I tried to TELNET to the NIC, and lo I got through as well. Yet, when I closed out the session, and tried PINGing them again, still nothing. I called up the NIC. They took down my complaint, and the next day someone from engineering called me back. He said the NIC has turned off their ICMP echo replies. He said they were getting too many ECHO requests and that it was loading the machine down. ICMP ECHO request/reply has been a usefull debugging tool. I hope this doesn't start a trend. ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708041925.AA00615@ucbvax.Berkeley.EDU] <1987080412060000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: enger%gburg.DECnet@BLUTO.SCC.COM ("GBURG::ENGER") Newsgroups: comp.protocols.tcp-ip Subject: No echo from the NIC Message-ID: <8708041925.AA00615@ucbvax.Berkeley.EDU> Date: Tue, 4-Aug-87 16:06:00 EDT Article-I.D.: ucbvax.8708041925.AA00615 Posted: Tue Aug 4 16:06:00 1987 Date-Received: Thu, 6-Aug-87 04:13:32 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: "GBURG::ENGER" Distribution: world Organization: The ARPA Internet Lines: 21 I experienced some difficulty connecting to the NIC on Sunday night. This led me to try to PING off of them (issue ICMP echo request). I did not receive any response from them on either their net-10 or net-26 address. I was able to receive ICMP echo replies from hosts on a number of networks so I wrote it off as a temporary network problem. I PINGed them again on monday, still no response. I called the NOC. They used TELNET to test connectivity, and they got through. The NOC was also able to TELNET to my host. When I told them I couldn't PING off the NIC, they became concerned. Taking their lead, I tried to TELNET to the NIC, and lo I got through as well. Yet, when I closed out the session, and tried PINGing them again, still nothing. I called up the NIC. They took down my complaint, and the next day someone from engineering called me back. He said the NIC has turned off their ICMP echo replies. He said they were getting too many ECHO requests and that it was loading the machine down. ICMP ECHO request/reply has been a usefull debugging tool. I hope this doesn't start a trend. ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [WANCHO.12323875172.BABYL@SIMTEL20.ARPA] <1987080412280000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: WANCHO@SIMTEL20.ARPA ("Frank J. Wancho") Newsgroups: comp.protocols.tcp-ip Subject: TAC "noise" Message-ID: Date: Tue, 4-Aug-87 16:28:00 EDT Article-I.D.: SIMTEL20.WANCHO.12323875172.BABYL Posted: Tue Aug 4 16:28:00 1987 Date-Received: Thu, 6-Aug-87 04:43:26 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 42 This one has got me stumped, and I'd appreciate it if this message was redirected to a more appropriate forum if there is one. We have noticed this "noise" problem on and off for quite some time and are now realizing that perhaps what we and our users are seeing is not line noise but something else. In general, when a user calls to complain about seeing "noise" from a TAC connection, we naturally assume the problem is caused by line noise in the phone circuit between the user and the TAC port modem. However, it has turned out that we have not been asking the right question in determining the noise characteristic. The question is: are you seeing "noise" when there is supposed to be no activity on the line, or are you seeing it as garbage only when the remote host is sending a long string of characters. If the answer is yes to the former, the problem is probably a "bad" circuit. However, if the answer is yes to the latter, then we have a whole new problem, or so it seems. I've seen the latter problem only at 2400bps. Others have reported the problem at 1200, and some even at 300. With the rumored eventual upgrade to 9600bps dialup TAC access, I am concerned that there may be an underlying basic TAC-to-modem interface problem that needs to be found and fixed before higher speeds become commonly available and useable. The characteristic of this form of "noise" is that the first several lines of expected output appear OK, then garbage (noise). This is consistently repeatable. We have empirically ruled out several possible causes, including real line noise, and noise caused by level settings in the modems themselves. It seems one possibility remains: that there is a "slight" speed mismatch between what the TAC outputs and what the modem expects and bits eventually get shifted... There is one further complication that makes things harder to track: it appears that the TAC software *may* have been undergoing "minor" changes during this time without the version number changing in the TAC herald. Thus, it is somewhat difficult to pinpoint when this problem started to occur relative to TAC version. I suggest that followups to this message be made privately amongst interested parties unless there is some general interest in this subject on this list. The only reason for bringing this up here is that I have several high level users wanting answers *now* and I can't evade the queries for much longer... --Frank ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708050046.AA07011@ucbvax.Berkeley.EDU] <1987080413030000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JOHNSON@NUHUB.ACS.NORTHEASTERN.EDU ("I am only an egg.") Newsgroups: comp.protocols.tcp-ip Subject: ethernet interface perversity Message-ID: <8708050046.AA07011@ucbvax.Berkeley.EDU> Date: Tue, 4-Aug-87 17:03:00 EDT Article-I.D.: ucbvax.8708050046.AA07011 Posted: Tue Aug 4 17:03:00 1987 Date-Received: Thu, 6-Aug-87 07:02:28 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 55 Hold it a minute. I have received many responses from my query about network numbers on an ethernet. Thank you for all the positive help for those who gave it but . . . I NEVER intended to complain or panic about IP. I was in search of verification of something and perhaps I phrased it poorly. And yes I know that one ethernet wire can have large numbers of internet addresses floating around on it. We did some experimentation with our various ethernet interfaces and discovered that something which was hinted at in many of the responses seems to be true. The ethernet interfaces we have will each respond to only one internet number at a time. I talked to Micom for example and they even said as much for their np100 board. *FLAME ON* It seems very dumb that I need at least one gateway node on one ethernet wire so that nodes on that wire can all talk to each other when some of the nodes run with different internet numbers. Although my problem is really an administrative one (I don't run the whole network here, I just get dumped on when it doesn't work), I don't see why I should be having a problem at all. I read ARP, rfc 826, and it talks about an address translation table. Note the use of the word TABLE. In this age of micro-processors it seems more than feasible to put some real table driven ARP intelligence out there so that interface boards can RESPOND TO MORE THAN ONE BLOODY ADDRESS. I suppose someone is going to ask how big the table should be. I don't know. Memory is cheap. It could easily be big enough to handle 16 or 32 network numbers. It could even be content addressable and thus FAST. Allowing for 16 or 32 network numbers (or more) should reduce the frequency of ether_type$ADDRESS_RESOLUTION packets to small for most cases. *FLAME OFF* I'm just upset with the vendors for giving me ulcers again. So what else is new :-(. USnail: Chris Johnson Academic Computer Services Northeastern University 39RI 360 Huntington Ave. Boston, MA. U.S.A. 02115 AT&T: (617) 437-2335 CSNET: johnson@nuhub.acs.northeastern.edu ARPANET: johnson%nuhub.acs.northeastern.edu@relay.cs.net BITNET: johnson%nuhub.acs.northeastern.edu@csnet-relay (Always vote. There may not be anything you want to vote for, but there might be something you want to vote against.) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987080413030001> Received: from RELAY.CS.NET by SRI-NIC.ARPA with TCP; Tue 4 Aug 87 17:30:41-PDT Received: from relay2.cs.net by RELAY.CS.NET id ac13281; 4 Aug 87 20:05 EDT Received: from northeastern.edu by RELAY.CS.NET id ae15312; 4 Aug 87 19:59 EDT Date: Tue, 4 Aug 87 17:03 EDT From: "I am only an egg." Subject: ethernet interface perversity To: tcp-ip@SRI-NIC.ARPA X-VMS-To: NET%"tcp-ip@sri-nic.arpa" Hold it a minute. I have received many responses from my query about network numbers on an ethernet. Thank you for all the positive help for those who gave it but . . . I NEVER intended to complain or panic about IP. I was in search of verification of something and perhaps I phrased it poorly. And yes I know that one ethernet wire can have large numbers of internet addresses floating around on it. We did some experimentation with our various ethernet interfaces and discovered that something which was hinted at in many of the responses seems to be true. The ethernet interfaces we have will each respond to only one internet number at a time. I talked to Micom for example and they even said as much for their np100 board. *FLAME ON* It seems very dumb that I need at least one gateway node on one ethernet wire so that nodes on that wire can all talk to each other when some of the nodes run with different internet numbers. Although my problem is really an administrative one (I don't run the whole network here, I just get dumped on when it doesn't work), I don't see why I should be having a problem at all. I read ARP, rfc 826, and it talks about an address translation table. Note the use of the word TABLE. In this age of micro-processors it seems more than feasible to put some real table driven ARP intelligence out there so that interface boards can RESPOND TO MORE THAN ONE BLOODY ADDRESS. I suppose someone is going to ask how big the table should be. I don't know. Memory is cheap. It could easily be big enough to handle 16 or 32 network numbers. It could even be content addressable and thus FAST. Allowing for 16 or 32 network numbers (or more) should reduce the frequency of ether_type$ADDRESS_RESOLUTION packets to small for most cases. *FLAME OFF* I'm just upset with the vendors for giving me ulcers again. So what else is new :-(. USnail: Chris Johnson Academic Computer Services Northeastern University 39RI 360 Huntington Ave. Boston, MA. U.S.A. 02115 AT&T: (617) 437-2335 CSNET: johnson@nuhub.acs.northeastern.edu ARPANET: johnson%nuhub.acs.northeastern.edu@relay.cs.net BITNET: johnson%nuhub.acs.northeastern.edu@csnet-relay (Always vote. There may not be anything you want to vote for, but there might be something you want to vote against.) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12323913936.15.M.JSOL@DEEP-THOUGHT.MIT.EDU] <1987080416010900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: M.JSOL@DEEP-THOUGHT.MIT.EDU (Jon Solomon) Newsgroups: comp.protocols.tcp-ip Subject: Dr. Postel's comments about the namedroppers list Message-ID: <12323913936.15.M.JSOL@DEEP-THOUGHT.MIT.EDU> Date: Tue, 4-Aug-87 20:01:09 EDT Article-I.D.: DEEP-THO.12323913936.15.M.JSOL Posted: Tue Aug 4 20:01:09 1987 Date-Received: Thu, 6-Aug-87 07:19:24 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 23 I agree with KLH's comments that there is a need to discuss naming conventions and names. Now that the internet (small-i) is much larger than just the TCP/IP speaking Internet, it is useful to recognize that not all people agree on what things should be called. HOWEVER: I think there is policy which can be used to handle the naming of the NIC, which is to ask the people who run the NIC for the DDN. When we started using domains, we were given fairly free reign over what we wanted to call our second-level domain, we eventually chose bu.edu. Also, our host names all contain "bu" in them in addition to the .bu.edu suffix (i.e. buit1.bu.edu, bu-cs.bu.edu, bu-ma.bu.edu). We find this preferrable to "it1.bu.edu" or "1.it.bu.edu". The point is, it was our choice, and now what I see here is a consensus of people who want to name the NIC, and it is really the NIC admin's responsibility to name it. SO, Ken, if you want to start a list to discuss naming, feel free, but remember that you have the ultimate authority to name the NIC however seems convenient and useful. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [555127536.0.CASNER@VENERA.ISI.EDU] <1987080418053600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: CASNER@VENERA.ISI.EDU (Stephen Casner) Newsgroups: comp.protocols.tcp-ip Subject: Re: Telnet, , etc. Message-ID: <555127536.0.CASNER@VENERA.ISI.EDU> Date: Tue, 4-Aug-87 22:05:36 EDT Article-I.D.: VENERA.555127536.0.CASNER Posted: Tue Aug 4 22:05:36 1987 Date-Received: Fri, 7-Aug-87 01:18:19 EDT References: <8707311950.AA12026@opal.berkeley.edu> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 95 (Another LONG MESSAGE) Greg Minshall - You are correct, the Telnet spec does NOT make it clear whether the client program should send CR-LF or CR-NUL when the user hits the "return" key. The discussion is clear for characters flowing in the opposite direction to the NVT printer, and we are left to infer a choice for the NVT keyboard to server direction from statements about symmetry. The following sentence is the one that I think causes trouble; you have undoubtedly read it before, but I'll quote it here for discussion: Therefore, the sequence "CR LF" must be treated as a single "new line" character and used whenever their combined action is intended; the sequence "CR NUL" must be used where a carriage return alone is actually desired; and the CR character must be avoided in other contexts. What is intended when the user hits the "return" or "enter" key? Those who believe the return key means the user is finished with the current line and wants a new line might quote the first part of the sentence to show that CR-LF "must be ... used". Those who believe that carriage return alone is desired, because on many (most?) terminals the "return" key generates a single CR character, might quote the second part of the sentence to show that CR-NUL "must be used". NEITHER group can "prove" its case from the spec, but this is not a legal contest. As Mark Crispin says, "we all have a shared interest in maximizing interoperability". I believe the Telnet spec should say exactly which of these two choices should be used, just to avoid the present confusion of interpretation. In any case, by the "robustness principle", EITHER sequence (CR-LF or CR-NUL) should be accepted by the Telnet server to mean that the "return" / "enter" key was pushed because we know there are some systems that send one and some systems that send the other. So, for the moment at least, my complaint was and is not that the 4.3BSD telnet client sends CR-NUL but only about the 4.3BSD telnetd maps CR-LF to '\n' instead of '\r'. You say that you could have mapped CR-LF to '\r', but that it would have violated the philosophy of Unix that '\n' is the newline character. I disagree, because the philosophy of Unix does not require that terminals send '\n' to the tty driver; instead the tty driver receives '\r' from the terminal and maps it to '\n' WHEN APPROPRIATE. Since telnetd does not feed the application program directly, but rather feeds a pty, I claim telnetd should map CR-LF to '\r' and let the pty driver map to '\n' when appropriate. This is the same argument that Kevin Carosso wrote. This change was also posted to comp.bugs.4bsd on 29-Jan-87 by J. Robert Ward. You gave a second reason that anyone unfortunate enough to be connecting from a client unwilling to send a LF alone would face a problem getting a '\n' sent towards their program. Again I disagree, because the pty will map '\r' to '\n' for those programs that don't distinguish between the two characters and expect only '\n'. To fully utilize a program that uses cbreak or raw mode and does distinguish between '\r' and '\n', the telnet client must be able to send two distinct codes: CR-LF or CR-NUL when the "return" key is pushed, and LF alone when the "linefeed" key is pushed. Some keyboards don't have "linefeed", but they probably do have "control" and "J" keys. Is there any client that won't send LF alone? There are many clients that don't provide any mechanism to send CR-NUL instead of CR-LF. They are NOT violating the spec either! Dave Borman, Kevin Carosso and Dan Hoey suggest the Bridge box may be in error because it doesn't or can't send CR-NUL. While it might be more robust to have an option to send either CR-LF or CR-NUL, it's certainly not a bug to send CR-LF. As you point out, many of the old hands in the Telnet business, participants in the "let's define and bring up TELNET meetings", believe CR-LF to be the correct choice over CR-NUL. Bob Braden refreshed my memory that at the "TCP Bakeoffs" when the first implementations of TCP/TELNET were being tested against each other, only Charles Lynn's TENEX implementation sent CR-NUL and everyone else sent CR-LF. It was subsequently agreed that CR-LF was the correct choice, but obviously that choice wasn't clearly stated in the spec. BSD Unix chooses CR-NUL and that causes trouble for some of the older server implementations (cf John G. Ata's message). My personal choice would be for BSD Unix to change to send CR-LF, but I recognize that this would cause trouble when connecting to telnetd's that map CR-LF to '\n'. Perhaps it would be wise to enhance the BSD telnet program so the user can select whether CR-LF or CR-NUL will be sent. Our goal should be to clarify this issue in the spec so that eventually all machines can interoperate naturally without the need for such inconveniences. You have stated your case well for the choices made in the 4.3 BSD implementation. But given the additional information put forth by several people since then, do you still believe telnetd should map CR-LF to '\n' and not to '\r'? What will 4.4 BSD do? -- Steve Casner ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708051321.AA18509@ucbvax.Berkeley.EDU] <1987080504414000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: pogran@CCQ.BBN.COM (Ken Pogran) Newsgroups: comp.protocols.tcp-ip Subject: Re: No echo from the NIC Message-ID: <8708051321.AA18509@ucbvax.Berkeley.EDU> Date: Wed, 5-Aug-87 08:41:40 EDT Article-I.D.: ucbvax.8708051321.AA18509 Posted: Wed Aug 5 08:41:40 1987 Date-Received: Sat, 8-Aug-87 01:18:42 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 42 Regarding PINGing and the report that the NIC has elected to turn off ICMP echo replies ("He said they were getting too many ECHO requests and that it was loading the machine down. ICMP ECHO request/reply has been a usefull debugging tool. I hope this doesn't start a trend."): This issue is only about thirteen or fourteen years old. Perhaps Mike Padlipsky will supply us with the correct bibliographic reference; back in the NCP days he wrote an RFC entitled something like, "... but my NCP costs $500 a day!" complaining about incessant NCP ECHO requests from TENEX hosts that were causing the MIT-Multics Network Daemon to wake up constantly to send ECHO REPLYs. The solution for us at MIT, back then, was two-fold: 1) Get the TENEXes to stop frequent pinging which was being done for the sole purpose of keeping track who was really up on the ARPANET and who was not, and 2) move the Multics ECHO-processing code into an interrupt handler and out of a process that needed to be awakend for each echo. Both were accomplished. Yes, pings are nice. They provide you with assurance that someone is really there. As the Internet grows though (and we're over 250 truly active nets, now), unnecessary or gratuitous pings are a waste of everyone's cycles -- hosts, gateways, PSNs. And at a well-known, heavily-used host like the NIC -- imagine the horror experienced by a system manager who, trying to respond to user complaints of slow service, does a profile of where his cycles are going and discovers that a substantial fraction is going into ICMP ECHO replying! (I haven't talked with the NIC, so my description here is purely hypothetical.) Here, clearly, is a way to "buy back" cycles that can be used to improve service to users. Is it going to start a trend? Given the ever-increasing number of nets out there, we might indeed begin to see more "defensive" moves made by major service hosts who begin to perceive completely open, full, and friendly participation as a drain on their resources. Food for thought. Ken Pogran ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987080504414001> Received: from ccq.bbn.com by SRI-NIC.ARPA with TCP; Wed 5 Aug 87 06:08:52-PDT Date: Wed, 5 Aug 87 8:41:40 EDT From: Ken Pogran Subject: Re: No echo from the NIC In-Reply-To: Your message of 4 Aug 87 15:06:00 EST To: "GBURG::ENGER" Cc: "tcp-ip" , enger@bluto.scc.com, pogran@ccq.bbn.com Regarding PINGing and the report that the NIC has elected to turn off ICMP echo replies ("He said they were getting too many ECHO requests and that it was loading the machine down. ICMP ECHO request/reply has been a usefull debugging tool. I hope this doesn't start a trend."): This issue is only about thirteen or fourteen years old. Perhaps Mike Padlipsky will supply us with the correct bibliographic reference; back in the NCP days he wrote an RFC entitled something like, "... but my NCP costs $500 a day!" complaining about incessant NCP ECHO requests from TENEX hosts that were causing the MIT-Multics Network Daemon to wake up constantly to send ECHO REPLYs. The solution for us at MIT, back then, was two-fold: 1) Get the TENEXes to stop frequent pinging which was being done for the sole purpose of keeping track who was really up on the ARPANET and who was not, and 2) move the Multics ECHO-processing code into an interrupt handler and out of a process that needed to be awakend for each echo. Both were accomplished. Yes, pings are nice. They provide you with assurance that someone is really there. As the Internet grows though (and we're over 250 truly active nets, now), unnecessary or gratuitous pings are a waste of everyone's cycles -- hosts, gateways, PSNs. And at a well-known, heavily-used host like the NIC -- imagine the horror experienced by a system manager who, trying to respond to user complaints of slow service, does a profile of where his cycles are going and discovers that a substantial fraction is going into ICMP ECHO replying! (I haven't talked with the NIC, so my description here is purely hypothetical.) Here, clearly, is a way to "buy back" cycles that can be used to improve service to users. Is it going to start a trend? Given the ever-increasing number of nets out there, we might indeed begin to see more "defensive" moves made by major service hosts who begin to perceive completely open, full, and friendly participation as a drain on their resources. Food for thought. Ken Pogran ----MESSAGE-END---- ----MESSAGE-BEGIN---- [337@blnt1.UUCP] <1987080506025700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jat@blnt1.UUCP (John A Tamplin) Newsgroups: comp.protocols.tcp-ip Subject: Re: Streams TCP/IP Message-ID: <337@blnt1.UUCP> Date: Wed, 5-Aug-87 10:02:57 EDT Article-I.D.: blnt1.337 Posted: Wed Aug 5 10:02:57 1987 Date-Received: Sun, 9-Aug-87 02:00:40 EDT References: <24335@sun.uucp> <8707300326.AA06674@ucbvax.Berkeley.EDU> Reply-To: jat@blnt1.UUCP (John A Tamplin) Distribution: world Organization: Blount Brothers Corp., Montgomery AL Lines: 10 Streams TLI should not keep any state information in user space. I have written a streams TLI provider that keeps the state inside the driver (kernel space) for each upper stream. There is no reason to do otherwise. The only interface a user process has to the state machine is by issuing or receiving primitives. -- John Tamplin Blount Brothers Corporation gatech!blnt1!jat 2511 Fairlane Drive 205/244-6231 Montgomery, AL 36116 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [870805102757.2.DCP@KOYAANISQATSI.S4CC.Symbolics.COM] <1987080506270000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer) Newsgroups: comp.protocols.tcp-ip Subject: ethernet interface perversity Message-ID: <870805102757.2.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Date: Wed, 5-Aug-87 10:27:00 EDT Article-I.D.: KOYAANIS.870805102757.2.DCP Posted: Wed Aug 5 10:27:00 1987 Date-Received: Sat, 8-Aug-87 01:40:26 EDT References: Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 57 Date: Tue, 4 Aug 87 17:03 EDT From: "I am only an egg." *FLAME ON* It seems very dumb that I need at least one gateway node on one ethernet wire so that nodes on that wire can all talk to each other when some of the nodes run with different internet numbers. What does this have to do with Ethernet numbers? Judging by the rest of the message, you may be a little confused. My guess is that the reason you need a gateway is because the structure of the Internet implementation on the system(s) you are running requires it, and has little to do with Ethernet. I'm guessing that if your IP were convincible that A.B.C.0 and X.Y.Z.0 were both on the same cable, then A.B.C.D would send an ARP for X.Y.Z.W and communicate directly instead of sending it to a gateway that is on both A.B.C.0 and X.Y.Z.0. Although my problem is really an administrative one (I don't run the whole network here, I just get dumped on when it doesn't work), I don't see why I should be having a problem at all. I read ARP, rfc 826, and it talks about an address translation table. Note the use of the word TABLE. In this age of micro-processors it seems more than feasible to put some real table driven ARP intelligence out there so that interface boards can RESPOND TO MORE THAN ONE BLOODY ADDRESS. How many addresses? If you are going to relate hardware addresses with network protocols, you need to respond to at least as many addresses as there are protocols. One way to interpret the current situation is that we already have such a scheme! "Addresses" are 64 bits long. 24 are assigned to a hardware manufacturer, 24 are assigned by the hardware manufacturer (these two give the 48 bit Ethernet address we know of today), and 16 describe the protocol (the Ethernet type field). Using this interpretation, boards already respond to 64K "addresses." I suppose someone is going to ask how big the table should be. I don't know. Memory is cheap. It could easily be big enough to handle 16 or 32 network numbers. It could even be content addressable and thus FAST. Allowing for 16 or 32 network numbers (or more) should reduce the frequency of ether_type$ADDRESS_RESOLUTION packets to small for most cases. Again, only if you relate hardware addresses to protocol addresses, as DEC did. If the Ethernet were designed this way from the start, perhaps we wouldn't be in this bind. Unfortunately, there are at least two problems back then: (1) Content addressable memories weren't commodity, and (2) algorithmic translation only works well if the protocol address length is sufficiently smaller than the hardware address length. With L(IP) being 4 and L(Ether) being 6, this leaves 2 bytes to denote it as an IP address. Some people believe that IP addresses are too small; being bigger makes the problem worse. The practical problem is convincing every implementation to change at this late date. *FLAhavfonts ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708051605.AA25783@uxc.cso.uiuc.edu] <1987080508054900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: sandrock@UXC.CSO.UIUC.EDU (Mark Sandrock) Newsgroups: comp.protocols.tcp-ip Subject: Re: IBM TCP. Message-ID: <8708051605.AA25783@uxc.cso.uiuc.edu> Date: Wed, 5-Aug-87 12:05:49 EDT Article-I.D.: uxc.8708051605.AA25783 Posted: Wed Aug 5 12:05:49 1987 Date-Received: Sat, 8-Aug-87 02:13:04 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 10 We don't have a DECnet host 1.1, and neither should any site which has links to the "outside world". All DECnet addresses on our campus are assigned by the PHYSnet management, which includes international address assignments as well. Also, I doubt that if "ACME" vendor tries to market a network that conflicts with DECnet that they will have many sales to systems which already have DECnet installed. They would most likely (and deservedly) soon be a defunct company. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708051618.AA26134@uxc.cso.uiuc.edu] <1987080508182100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: sandrock@UXC.CSO.UIUC.EDU (Mark Sandrock) Newsgroups: comp.protocols.tcp-ip Subject: Re: IBM TCP. Message-ID: <8708051618.AA26134@uxc.cso.uiuc.edu> Date: Wed, 5-Aug-87 12:18:21 EDT Article-I.D.: uxc.8708051618.AA26134 Posted: Wed Aug 5 12:18:21 1987 Date-Received: Sat, 8-Aug-87 02:51:27 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 7 Thanks for your message re: DECnet and Ethernet. All of our DECnet addresses here at the University of Illinois are assigned by the PHYSnet management (whoever that is). We have not yet seen the need for multiple areas on this campus. Also, one would expect that DEC might anticipate the need and expand the DECnet addressing scheme to something reasonable in a future version (Phase V?). ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708051624.AA26323@uxc.cso.uiuc.edu] <1987080508241800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: sandrock@UXC.CSO.UIUC.EDU (Mark Sandrock) Newsgroups: comp.protocols.tcp-ip Subject: Re: IBM TCP. Message-ID: <8708051624.AA26323@uxc.cso.uiuc.edu> Date: Wed, 5-Aug-87 12:24:18 EDT Article-I.D.: uxc.8708051624.AA26323 Posted: Wed Aug 5 12:24:18 1987 Date-Received: Sat, 8-Aug-87 02:57:33 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 5 It sounds like you are claiming that DEC preempts Ethernet hardware addresses which have been officially assigned to other vendors, but I have yet to see a specific example of such an address. Is it asking to much either to see an example or else have everyone drop this claim? ----MESSAGE-END---- ----MESSAGE-BEGIN---- [171500007@uxc.cso.uiuc.edu] <1987080509180000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: sandrock@uxc.cso.uiuc.edu Newsgroups: comp.protocols.tcp-ip Subject: Re: IBM TCP. Message-ID: <171500007@uxc.cso.uiuc.edu> Date: Wed, 5-Aug-87 13:18:00 EDT Article-I.D.: uxc.171500007 Posted: Wed Aug 5 13:18:00 1987 Date-Received: Sat, 8-Aug-87 09:29:18 EDT References: <11@<12320729020> Lines: 30 Nf-ID: #R:<12320729020:11:uxc.cso.uiuc.edu:171500007:000:1717 Nf-From: uxc.cso.uiuc.edu!sandrock Aug 5 12:18:00 1987 I hope you will bear with me... not being yet familiar with the workings of UNIX mail I don't know if my responses to individual mail will also be posted here, but I would like to clarify my statements re: DECnet... I still have not seen any example of a DECnet-assigned Ethernet address which is NOT globally unique. Can someone give such an example of DEC's preemption of another vendor's Ethernet address? I realize that it would be possible for 2 DECnet nodes to choose the same DECnet address thereby choosing the same Ethernet address, but in practice of course this is not supposed to happen, anymore than 2 sites choosing the same IP address. While I also do not know of any "global administration" of DECnet ad- dresses, it so happens that here at the University of Illinois we make all DECnet address assignments through a contact with the PHYSnet man- agement (no, I don't know any more details than that). To say this another way, I am free to bring up my own Ethernet (in my office, right!) and choose any DECnet and/or IP addresses I want for my personal machines, but once I connect my net to the Internet or PHYSnet or whatever, I obviously must choose to coexist in harmony (or suffer the consequences!). Also, I agree that 2**16 unique addresses is an undesirable limitation, but at one time it was only 2**10 addresses, and so one might surmise that DEC will once again respond to the perceived need for more addresses in due time. This may all be a moot discussion in light of newer protocols being developed (?), but then who can really say? (Not me anyway (:^)) Mark Sandrock, (sandrock@uiucuxc.UUCP) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [4116@burdvax.PRC.Unisys.COM] <1987080510570100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: starner@burdvax.PRC.Unisys.COM (Mark L. Starner) Newsgroups: comp.protocols.tcp-ip,comp.bugs.4bsd Subject: ACC IF-11/HDH 4.3 Driver Message-ID: <4116@burdvax.PRC.Unisys.COM> Date: Wed, 5-Aug-87 14:57:01 EDT Article-I.D.: burdvax.4116 Posted: Wed Aug 5 14:57:01 1987 Date-Received: Sat, 8-Aug-87 10:42:44 EDT Sender: news@burdvax.PRC.Unisys.COM Organization: Unisys/Paoli Research Center, Paoli, PA Lines: 38 Keywords: ACC IF-11HDH 4.3BSD We have had a problem with our ACC IF-11/HDH IMP (sorry, PSN) interface since our conversion to 4.3 BSD. We finally tracked it down to be limited to fragmented or full size (1006) packets. For example, when we would do an FTP get from ucbvax, we would never receive the large 1006 byte packet. All we would get is a 58 byte packet. Eventually, after 3 minutes, we would get a message: netin: connection reset by peer I contacted ACC for help once I discovered the the exact nature of the problem and they told me that there was a bug in the 4.3BSD released vaxif/if_hdh.c and that all 4.3 sites should get the new driver. A temporary fix until you can receive the new driver is to change all occurences of IMPMTU to IMPMTU+2 in if_hdh.c. (this in fact solves the problem). It is reccomended that you contact ACC to receive a copy of the newest driver. They can be reached at: SERVICE@ACC-SB-UNIX.ARPA or at: 1-800-222-7308 (ask for Software Support) The problem also shows itself with SYSERR from your sendmail daemon and with "whois" returning nothing but your prompt if what the NIC is trying to send you is more than 1006 bytes long. Hope this saves someone the 4 months of frustration it caused me. BTW, I would be interested to hear if anyone else knew about or has this problem. -- Mark Starner starner@prc.unisys.com Unisys Corporation/Paoli Research Center {cbmvax,sdcrdcf}!burdvax!starner Paoli, PA ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708052021.AA28164@osupyr.UUCP] <1987080512215800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hsu_f@osupyr.UUCP (Frank Hsu) Newsgroups: comp.protocols.tcp-ip Subject: Re: Wollongon TCP/IP for AT&T 3B2 Message-ID: <8708052021.AA28164@osupyr.UUCP> Date: Wed, 5-Aug-87 16:21:58 EDT Article-I.D.: osupyr.8708052021.AA28164 Posted: Wed Aug 5 16:21:58 1987 Date-Received: Sat, 8-Aug-87 09:58:53 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 21 I got your message. Yes, our Physics Dept. told me that their CAD/CAM IBM 4341 always receive packets from the 3B2 looking for port 513. I did not the reason. Now I stopped the RWHO daemon. Our "mailx" really have problems with dots in the host names. I reported this problem to AT&T, a technical support person in AT&T information system told me that "telnet" and "ftp" have no problem with dots. But "mailx" just can not take any dots in the host name. I kept the mail message from AT&T, I will mail it to you later. Our "telnet" on the 3B2/300 works fine. It can login to Pyramid, IBM 3081, iBM 4341, DEC VAX 11/780, Sun work stations, DEC-20. I can not see any difficulty in connecting to other hosts. I never tried routed "mailx". Frank C. Hsu IRCC, Ohio State Univ. Columbus, Ohio 43210 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [30@dover.uucp] <1987080513045200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: leivian@dover.uucp (Bob Leivian) Newsgroups: comp.protocols.tcp-ip Subject: Anybody have a socket interface library for SPARTACUS's K-routines Message-ID: <30@dover.uucp> Date: Wed, 5-Aug-87 17:04:52 EDT Article-I.D.: dover.30 Posted: Wed Aug 5 17:04:52 1987 Date-Received: Sat, 8-Aug-87 07:16:46 EDT Organization: Motorola CAD Mesa, AZ {Dover} Lines: 14 Keywords: IBM TCP-IP K-routines I am working to port a private protocol to IBM CMS using Spartacus's KNET for TCP. The code is written in C for Berkeley sockets and un*x. Has anyone written a socket, bind, etc that interfaces to the ASM lang routines supplied by Spartacus that they call K-Routines. If not, I will write one so anyone with like tasks might want to contact me to share horror stories about IBM TCP-IP. --Bob L -- Bob Leivian Motorola, Dover Shores (CAD Support) 602-994-6778 ...{mcdsun, sun}!sunburn!dover!leivian Mesa, AZ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708052107.AA13918@bel.isi.edu] <1987080513073500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: postel@ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: SMTP question Message-ID: <8708052107.AA13918@bel.isi.edu> Date: Wed, 5-Aug-87 17:07:35 EDT Article-I.D.: bel.8708052107.AA13918 Posted: Wed Aug 5 17:07:35 1987 Date-Received: Sat, 8-Aug-87 09:03:42 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 25 Drew: Once upon a time long ago and far away there were computers that internally stored characters as 7-bit bytes. At the time that the mail protocols were designed such computers were a significant part of the network population. There are still some of these computers in existance, and some of them do a lot of mail forwarding. If a message passes through one of these computers the (high-order) eighth bit will be lost as it is stored (however temporarally) and a zero value (high-order) eighth bit will be supplied as the message is forwarded on. If somehow your message does not pass through any of these aging beasts and passes only through computers that work on eight-bit bytes internally it probably will keep all eight-bits of every byte just the way you wanted them. But there are no guarantees about it. Go ask some old time BBN-er "What does 'TENEX' mean?". --jon. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1975.555200203@gremlin.nrtc.northrop.com] <1987080514562300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mrose@GREMLIN.NRTC.NORTHROP.COM (Marshall Rose) Newsgroups: comp.protocols.tcp-ip Subject: tcp on 802.4 Message-ID: <1975.555200203@gremlin.nrtc.northrop.com> Date: Wed, 5-Aug-87 18:56:23 EDT Article-I.D.: gremlin.1975.555200203 Posted: Wed Aug 5 18:56:23 1987 Date-Received: Sat, 8-Aug-87 06:16:02 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 5 Hi. I recall this being discussed, but don't remember the outcome. Can someone give me a pointer to the authoritative source for how one speaks TCP on an 802.4 net? Replies to me only. Thanks! /mtr ----MESSAGE-END---- ----MESSAGE-BEGIN---- [64200003@uiucuxe] <1987080516510000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: alexandr@uiucuxe.cso.uiuc.edu Newsgroups: comp.protocols.tcp-ip Subject: Re: Telnet, , etc. Message-ID: <64200003@uiucuxe> Date: Wed, 5-Aug-87 20:51:00 EDT Article-I.D.: uiucuxe.64200003 Posted: Wed Aug 5 20:51:00 1987 Date-Received: Sat, 8-Aug-87 09:27:38 EDT Lines: 24 Nf-ID: #R:<8707311950.AA12026@opal.berkele:-38:uiucuxe:64200003:000:956 Nf-From: uiucuxe.cso.uiuc.edu!alexandr Aug 5 19:51:00 1987 Sorry if this is too much UNIX for the rest of you... Well, I think Greg has explained things very nicely. Since he feels that this is a UNIX related issue, let me toss my two cents in. 1) Pty(4), like tty(4) has CRMOD. Therefore, it can already map to for you. in.telnetd should take advantage of this fact. 2) Programs such as tip run in raw mode, expecting carriage returns, not line-feeds. Therefore, it should always be easy to give them one. Again, sending seems more reasonable. Therefore, it seems to me that in.telnetd should always send a to the pty unless the user explicitly sends an . This seems to allow maximum compatibilty w/ existing software and other operating systems. -- Steve Alexander, Workstation Programmer, National Center for Supercomputing Applications stevea@lurch.ncsa.uiuc.edu stevea%lurch@uxc.cso.uiuc.edu stevea@uiucvmd.bitnet ...!{ihnp4,convex,pur-ee}!uiucdcs!uiucuxc!lurch!stevea ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708060201.AA17853@devvax.TN.CORNELL.EDU] <1987080518015600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: fedor@DEVVAX.TN.CORNELL.EDU (Mark Fedor) Newsgroups: comp.protocols.tcp-ip Subject: Re: Problems starting vv0 Proteon PROnet-10 driver Message-ID: <8708060201.AA17853@devvax.TN.CORNELL.EDU> Date: Wed, 5-Aug-87 22:01:56 EDT Article-I.D.: devvax.8708060201.AA17853 Posted: Wed Aug 5 22:01:56 1987 Date-Received: Sat, 8-Aug-87 07:13:38 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 52 Here is a fix and explanation to the problem.... This was posted to USENET some time ago, I get no credit for this fix, but I should get something for finding this article out of all the tons of News articles I have saved.... :^) Hope this helps! Mark ----------------------------------- Article 3887 of net.unix-wizards: >From: ron@BRL.ARPA Newsgroups: net.unix-wizards Subject: brl-vgr Bug Report Message-ID: <4577@brl-smoke.ARPA> Date: 13 Oct 86 23:15:30 GMT Sender: news@brl-smoke.ARPA Subject: Unable to set vv address on subnet Index: sys/vaxif/if_vv.c 4.3BSD Description: Ifconfig returns an error when you try to set the address on the proteon when using subneting. Repeat-By: ifconfig vv0 128.63.4.3 netmask 255.255.255.0 Fix: The vv driver checks to see if the local net part of address corresponds to the hardware address of the interface installed in your system. The subnet mask can not be set before the address because the mask has to be tied to a particular internet address. The fix is to make the vv driver mask off all but the lowest eight bits of the address before making the validity check. This is OK since the device can only deal with eight local address bits. In vvioctl: /* * Attempt to check agreement of protocol address * and board address. */ switch (ifa->ifa_addr.sa_family) { case AF_INET: if ((in_lnaof(IA_SIN(ifa)->sin_addr) & 0xFF) != vv_softc[ifp->if_unit].vs_host) error = EADDRNOTAVAIL; break; } break; ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708052356.aa15855@Huey.UDEL.EDU] <1987080519565700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: No echo from the NIC Message-ID: <8708052356.aa15855@Huey.UDEL.EDU> Date: Wed, 5-Aug-87 23:56:57 EDT Article-I.D.: Huey.8708052356.aa15855 Posted: Wed Aug 5 23:56:57 1987 Date-Received: Sat, 8-Aug-87 08:36:36 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 12 Bob, I can't believe this. Nobody (!?) pings the NIC unless they can't connect and wants to find out why not. So the NIC turns off ICMP as a defense measure? My prior experience has been that ICMP worked, but TCP connections took a v e r y long time to complete. It is certainly obvious that the NIC is overloaded; however, if a significant contributory factor is ICMP echoes, I submit turning them off will only result in their replacement by TCP connection attempts. Considering the TOPS-20 initial-connection TCP design, this would be an even worse disaster. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [WANCHO.12324223653.BABYL@SIMTEL20.ARPA] <1987080520220000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: WANCHO@SIMTEL20.ARPA ("Frank J. Wancho") Newsgroups: comp.protocols.tcp-ip Subject: TAC "noise" Message-ID: Date: Thu, 6-Aug-87 00:22:00 EDT Article-I.D.: SIMTEL20.WANCHO.12324223653.BABYL Posted: Thu Aug 6 00:22:00 1987 Date-Received: Sat, 8-Aug-87 08:35:30 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 31 Apparently some readers of my message about TAC "noise" inferred that we had reported this bug and received no action. We have not yet reported this problem, although we believe others elsewhere may have reported something similar with no resolution. My intent in sending that message was to try to gather some hypotheses to present when I do report the problem to give the problem more credibility and a higher likelihood of receiving attention and maybe even getting fixed. After all, the "true" nature of the problem is often easily misunderstood. It was also an attempt to discover if anyone else has experienced the same problem - TAC users are an individually isolated contigent of users with no one to represent them and no forum to bring up their problems, except, maybe NIC folks who mainly handle TAC Access card problems and refer technical problems to the NOC. Most TAC users aren't technical enough to push their statement of the problem past the "well, it must be line noise" answer, and the problem is not properly surfaced. However, the readership of this forum, not necessarily the forum itself, is, as hoped, quite technically knowledgeable. I immediately received several detailed responses basically supporting my suspicion that clock tolerances are the most likely culprit. In fact one respondent was actually able to prove the point by using an old 300 bps modem with a clock heavily suspected of having drifted over the years and observing the same "noise" characteristic as I described. So, with apologies to BBN for not having made my message clear, I will now go off and report the problem through conventional channels. Thank you all for bearing with me while I interrupted your discussions on the more esoteric aspects of TCP/IP. --Frank ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708060434.AA15065@topaz.rutgers.edu] <1987080520345900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick) Newsgroups: comp.protocols.tcp-ip Subject: Re: IBM TCP. Message-ID: <8708060434.AA15065@topaz.rutgers.edu> Date: Thu, 6-Aug-87 00:34:59 EDT Article-I.D.: topaz.8708060434.AA15065 Posted: Thu Aug 6 00:34:59 1987 Date-Received: Sat, 8-Aug-87 07:37:51 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 21 As far as I know, in phase V the DECnet address will consist of two bytes of subnet and then the Ethernet address. Once phase IV compatibility is not needed (typically this would be at the next phase), one could presumably stop using the special Ethernet address forced on you by the phase IV DECnet design, and use the preassigned Ethernet address. So at that point, machines using DECnet would have unique addresses. I think this discussion has diverged from its intent. I was simply trying to explain what was meant when someone said that machines running DECnet did not have globally unique Ethernet addresses. Your comments about how DECnet addresses are assigned on your campus show that there can't be any conflict in DECnet addresses at your installation. However the fact remains that your hosts no longer have globally unique Ethernet addresses. There are almost certainly at least two hosts on the DEC corporate network with the same address (since they have several DECnet networks each of which have very full address space), and presumably some on other large corporate networks as well. This is not a criticism: obviously your machine will not become confused with those other machines. It is simply an explanation of a statement in a previous posting. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987080601375500> Received: from CCV.BBN.COM by SRI-NIC.ARPA with TCP; Thu 6 Aug 87 05:20:13-PDT To: "Frank J. Wancho" cc: TCP-IP@SRI-NIC.ARPA, haverty@CCV.BBN.COM Subject: Re: TAC "noise" In-reply-to: Your message of Wed, 05 Aug 87 22:22:00 -0600. Date: Thu, 06 Aug 87 08:17:55 -0400 From: haverty@CCV.BBN.COM Frank -- from my experience, it would be worth looking at "stop bits" in addition to clock tolerances. If a receiver expects more stop bits than a sender sends, things tend to work when there is a non-continuous stream of characters, but get garbled when the line is running flat out - the first bit or two of the "next character" get eaten up as if they were stop bits for the current character. You can test this hypothesis by comparing the characters as received with those as sent, and seeing if bit-shifting would cause a match. Jack ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708061226.AA12583@ucbvax.Berkeley.EDU] <1987080603541300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: HANK@BARILVM.BITNET (Henry Nussbacher) Newsgroups: comp.protocols.tcp-ip Subject: Tcp/Ip for MVS and Mitek revisited Message-ID: <8708061226.AA12583@ucbvax.Berkeley.EDU> Date: Thu, 6-Aug-87 07:54:13 EDT Article-I.D.: ucbvax.8708061226.AA12583 Posted: Thu Aug 6 07:54:13 1987 Date-Received: Sat, 8-Aug-87 10:09:34 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 27 Last week I asked for info on Mitek and their MVS solutions to Tcp/Ip. To date only one person has replied and that was only to tell me that he thinks that Mitek has signed to be a MAP of IBM. He did not know what MAP was. I did some further checking. IBM has a IMAP program (Industry Marketing Assistance Program). It is sort of like a 3rd party developer for IBM. Last year, IBM recruited several IMAP companies to promote DEC to System/370 connectivity. IBM has now been courting Mitek to develop System/36 and System/38 Tcp/Ip connectivity. Mitek has produced something called FTP/6.2 for 36 & 38 systems. Mitek was formed in 1982 by Bernie Hogan who previously owned Hogan Systems, Inc. This company suffered a pretax loss of $20 million in 1985 after delivering allegedly faulty software to 40 customers. Mitek now claims to have solutions for System/36, System/38, MVS, and SNA in the Tcp/Ip realm. This entire "thing" has me nervous. If IBM has decided to enter into an IMAP agreement with Mitek, why hasn't anyone on the network ever heard of them? Is there a single site out there using Mitek equipment? Thanks, Hank ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708061239.AA12746@ucbvax.Berkeley.EDU] <1987080604405700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: haverty@CCV.BBN.COM Newsgroups: comp.protocols.tcp-ip Subject: Re: TAC "noise" Message-ID: <8708061239.AA12746@ucbvax.Berkeley.EDU> Date: Thu, 6-Aug-87 08:40:57 EDT Article-I.D.: ucbvax.8708061239.AA12746 Posted: Thu Aug 6 08:40:57 1987 Date-Received: Sat, 8-Aug-87 10:09:56 EDT References: Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 9 Frank -- from my experience, it would be worth looking at "stop bits" in addition to clock tolerances. If a receiver expects more stop bits than a sender sends, things tend to work when there is a non-continuous stream of characters, but get garbled when the line is running flat out - the first bit or two of the "next character" get eaten up as if they were stop bits for the current character. You can test this hypothesis by comparing the characters as received with those as sent, and seeing if bit-shifting would cause a match. Jack ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708061430.AA19988@etn-wlv.eaton.com] <1987080606305800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mcc@ETN-WLV.EATON.COM (Crockett) Newsgroups: comp.protocols.tcp-ip Subject: TELNET ELF Message-ID: <8708061430.AA19988@etn-wlv.eaton.com> Date: Thu, 6-Aug-87 10:30:58 EDT Article-I.D.: etn-wlv.8708061430.AA19988 Posted: Thu Aug 6 10:30:58 1987 Date-Received: Sat, 8-Aug-87 10:48:32 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 87 (yet another long message) 1) Before I am chastised severely for my interpretations of the TELNET protocol, I would like to note that much of the work that I perform is related to communications over networks used within the DoDIIS community. The acceptance of the DDN network architecture to replace AUTODIN, DSSCS/DIN, IDHSC II, etc. presents some interesting problems. First, the DoDIIS community has a significant involvement with Digital Equipment Corporation and, in particular, PDP11 processors and the IAS operating system. Second, there is a desire not to invalidate a rather significant investment in software that has been developed over the last ten (10) years. Third, there is a migration to LAN architectures which permit workstations (PCs) to replace directly connected terminals. As a result, the implementation and interpretation of TELNET is rather significant. The Digital IAS, RSX-11M (PLUS), and VMS TT drivers/handlers trigger on as the end-of-line terminator. From the perspective of these operating systems, an is generally regarded simply as a vertical positioning command to the next line from the current cursor/ print head position. TELNET software provided with various DDN protocol suite packages present particular problems when they are too blatant in their UNIX style treatment of an end-of-line condition (\n). 2) For the DDN three (3) different TELNET specifications/standards have been established. They are: a. RFC 854 which governs the ARPANET, b. MIL-STD-1782 which governs the MILNET, and c. DoDIIS TELNET Specification which governs other subnets that are currently separated from the ARPANET and MILNET. RFC 854 does not have the legal stature of a standard and cannot be specified for government procurements; therefore, MIL-STD-1782 which is a legal standard is the document that must be conformed to when providing TELNET to DoD or other governmental agencies. The RFC and the MIL-STD are essentially the same except that some of the asides and discussions contained in the RFC have been abbreviated or deleted. The most significant departure from the RFC is the deletion of the reference to "...a companion document, 'TELNET Option Specifications', which should be consulted..." and the inclusion of a set of appendices which define the options that are required in the MIL-STD. The DoDIIS TELNET Specification has the most significant differences primarily as a result of the Network Virtual Data Entry Terminal (NVDET) abstraction definition. In contracts, the DoDIIS TELNET is generally specified in addition to the MIL-STD to include the NVDET. [The neat trick is how to determine whether the remote terminal is an NVT or an NVDET since some of the option defaults are different.] 3) My original comments on the use and were based on my interpretation of MIL-STD-1782. From my reading of RFC 854, there is no reason for me to change my interpretation. Both documents state that a "... must be treated as a single 'new line' character and used whenever their combined action is intended; the sequence must be used where a carriage return alone is actually desired...". The following excerpt is from the discussion of the GA option but is equally valid when discussing the action taken when a is encount- ered. "The 'local' computer is no longer able to decide whether to retain control after seeing an end-of-line signal or not; this decision can only be made by the 'remote' computer which is processing the data." When the ENTER or RETURN key is struck, the local host has no idea what the intended action is to be and therefore should transmit a and allow the remote host to provide the interpretation. The transmission of a is presumptuous except when the user enters a as the next character. In the case of a 'gateway' computer, it should perform absolutely no conversions and pass the data on as it was received. input, output. input, output. 4) An interesting question is what will happen when a TELNET connection is used to edit, read, or write an AUTODIN message. The AUTODIN ELF is . (Believe it or not, there are still devices out there that require the before the to compensate for head travel time) Merton Campbell Crockett AN/GYQ-21(V) Program EATON Information Management Systems mcc@etn-wlv.EATON.COM ----MESSAGE-END---- ----MESSAGE-BEGIN---- [3681fb61.b8ab@apollo.uucp] <1987080607000000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: rees@apollo.uucp (Jim Rees) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Streams TCP/IP Message-ID: <3681fb61.b8ab@apollo.uucp> Date: Thu, 6-Aug-87 11:00:00 EDT Article-I.D.: apollo.3681fb61.b8ab Posted: Thu Aug 6 11:00:00 1987 Date-Received: Sat, 8-Aug-87 11:17:22 EDT References: <649@houxa.UUCP> <278@unixprt.UUCP> <561@applix.UUCP> <24336@sun.uucp> <281@rruxa.UUCP> Organization: Apollo Computer, Chelmsford, Mass. Lines: 40 First, this is probably obvious, but "sockets" is an interface, and is best compared to TLI. Streams is an implementation framework, and has no direct counterpart in bsd4.3, although it was originally intended as a replacement for clists and parts of tty.c. I'm doing a streams implementation here (see my paper in the Phoenix Usenix Proceedings). It has a TLI interface and a socket interface too. The two don't always cooperate very well, but it sort of works. 8th edition has a socket interface too, but I haven't seen it and don't know how it works. Guy Harris: If you want a STREAMS-based terminal driver, there will be some problems with sharing a single pool of buffer resources between the networking code and the terminal driver; it makes it more likely that networking operations will exhaust these resources. SysV neatly avoids this problem by not using streams for ttys! There is a simple priority scheme that tries to avoid this problem, but it isn't really adequate, especially since the guy (no relation to Guy) who wrote the tty driver probably didn't talk to the guy who wrote the IP multiplexor about who was going to allocate how much of which priority. The concept is the same in Dennis Ritchie's version and in the S5R3 version, but some of the details are different. I believe the S5R3 version is bigger and more complicated. AT&T added multiplexors (I believe), which are really necessary for doing protocols. They also added the clone driver, a crock if I've ever seen one. My version of this uses a special minor device number to indicate a clone open, and there is no separate clone driver. The sysV version of streams is indeed bigger and hairier than the v8. The big potential advantage to streams, from my point of view, is that it allows you to mix and match protocol modules. Want to run TCP on top of X.25 transport? Buy a TCP multiplexor module from vendor A, a X.25 network multiplexor from vendor B, and a driver from vendor C. Plug them all in and it just works. In practice, this requires everyone to use the same messsages between all their modules, and the interconnectivity problems make the TCP/IP interoperability problems we are all so painfully aware of look as easy as tying your shoes in comparison. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [870806110524.3.DCP@KOYAANISQATSI.S4CC.Symbolics.COM] <1987080607050000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer) Newsgroups: comp.protocols.tcp-ip Subject: Re: IBM TCP. Message-ID: <870806110524.3.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Date: Thu, 6-Aug-87 11:05:00 EDT Article-I.D.: KOYAANIS.870806110524.3.DCP Posted: Thu Aug 6 11:05:00 1987 Date-Received: Sat, 8-Aug-87 11:03:08 EDT References: <8708051605.AA25783@uxc.cso.uiuc.edu> <8708051618.AA26134@uxc.cso.uiuc.edu> <8708051624.AA26323@uxc.cso.uiuc.edu> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 57 Date: Wed, 5 Aug 87 11:05:49 CDT From: sandrock@uxc.cso.uiuc.edu (Mark Sandrock) Also, I doubt that if "ACME" vendor tries to market a network that conflicts with DECnet that they will have many sales to systems which already have DECnet installed. They would most likely (and deservedly) soon be a defunct company. Well, what if it were UniSYS, IBM or GM? Muscle flexing is a very impolite thing to do anyway, and in open network environments it may achieve a marketing objective at the expense of thwarting the kinds of atmospheres that lead to experimentation and creativity. Date: Wed, 5 Aug 87 11:18:21 CDT From: sandrock@uxc.cso.uiuc.edu (Mark Sandrock) Thanks for your message re: DECnet and Ethernet. All of our DECnet addresses here at the University of Illinois are assigned by the PHYSnet management (whoever that is). We have not yet seen the need for multiple areas on this campus. Also, one would expect that DEC might anticipate the need and expand the DECnet addressing scheme to something reasonable in a future version (Phase V?). So Hedrick believes (Phase V). Unfortunately, it sounds like they are going off in another wrong direction. From Hedrick's description, they will in the future be basing DECnet protocol addresses on the Ethernet hardware address. Well, what happens if your Ethernet hardware breaks and you need to replace it? Answer as far as I can tell: you have to force the new Ethernet address to be the same as the old. What happens if you recommision the old board on the same net? Another problem: Does this mean that DECnet Phase V has variable length addresses? What do they do for networks that have a different number of hardware address bytes than the Ethernet has? My belief is that protocol addresses are logically attached to the machine as an entity, that hardware network addresses are attached to hardware interfaces, and that they should not be related because of the current problems with (1) DECnet Phase IV and (2) my understand of Hedrick's description of Phase V. IP, Chaos and PUP (and probably others I don't know about) do it right. Date: Wed, 5 Aug 87 11:24:18 CDT From: sandrock@uxc.cso.uiuc.edu (Mark Sandrock) It sounds like you are claiming that DEC preempts Ethernet hardware addresses which have been officially assigned to other vendors, but I have yet to see a specific example of such an address. Is it asking to much either to see an example or else have everyone drop this claim? Sure. There is a Symbolics 3600 at our site that has an Ethernet hardware address of 08-00-05-03-00-38. The 08-00-05- portion was assigned to Symbolics by the Ethernet number Czar for use by Symbolics for its Ethernet interfaces. That is the "official" hardware address of the interface on that machine. That machine also has a DNA address of 41.69. Because of the way DNA works, the booting procedure for the machine changes the Ethernet address of the interface to AA-00-04-00-45-A4. Therefore, DNA has preempted our officially assigned address. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708061542.AA15402@ucbvax.Berkeley.EDU] <1987080607370000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: SYSTEM@CRNLNS.BITNET Newsgroups: comp.protocols.tcp-ip Subject: Re: IBM TCP. Message-ID: <8708061542.AA15402@ucbvax.Berkeley.EDU> Date: Thu, 6-Aug-87 11:37:00 EDT Article-I.D.: ucbvax.8708061542.AA15402 Posted: Thu Aug 6 11:37:00 1987 Date-Received: Sat, 8-Aug-87 11:03:31 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 22 Mark, > It sounds like you are claiming that DEC preempts Ethernet hardware > addresses which have been officially assigned to other vendors, but > I have yet to see a specific example of such an address. Is it asking > to much either to see an example or else have everyone drop this claim? Herewith the DECnet Ethernet address for node 19.53, aka 19509:: AA-00-03-01-10-E7 I do not know if this conflicts with any other vendor's address assignments. Selden E. Ball, Jr. (Wilson Lab's network and system manager) Cornell University NYNEX: +1-607-255-0688 Laboratory of Nuclear Studies BITNET: SYSTEM@CRNLNS Wilson Synchrotron Lab ARPA: SYSTEM%CRNLNS.BITNET@WISCVM.WISC.EDU Judd Falls & Dryden Road PHYSnet/HEPnet/SPAN: Ithaca, NY, USA 14853 LNS61::SYSTEM = 44283::SYSTEM (node 43.251) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987080607370001> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Thu 6 Aug 87 08:33:49-PDT Received: from CRNLNS.BITNET by wiscvm.wisc.edu ; Thu, 06 Aug 87 10:34:37 CDT Date: Thu, 6 Aug 87 11:37 EDT From: Subject: Re: IBM TCP. To: tcp-ip@sri-nic.arpa X-Original-To: "sandrock@uxc.cso.uiuc.edu" ,"tcp-ip@sri-nic.arpa" , SYSTEM Mark, > It sounds like you are claiming that DEC preempts Ethernet hardware > addresses which have been officially assigned to other vendors, but > I have yet to see a specific example of such an address. Is it asking > to much either to see an example or else have everyone drop this claim? Herewith the DECnet Ethernet address for node 19.53, aka 19509:: AA-00-03-01-10-E7 I do not know if this conflicts with any other vendor's address assignments. Selden E. Ball, Jr. (Wilson Lab's network and system manager) Cornell University NYNEX: +1-607-255-0688 Laboratory of Nuclear Studies BITNET: SYSTEM@CRNLNS Wilson Synchrotron Lab ARPA: SYSTEM%CRNLNS.BITNET@WISCVM.WISC.EDU Judd Falls & Dryden Road PHYSnet/HEPnet/SPAN: Ithaca, NY, USA 14853 LNS61::SYSTEM = 44283::SYSTEM (node 43.251) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708061546.AA27048@monk.proteon.com] <1987080607462300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jas@MONK.PROTEON.COM (John A. Shriver) Newsgroups: comp.protocols.tcp-ip Subject: TELNET ELF Message-ID: <8708061546.AA27048@monk.proteon.com> Date: Thu, 6-Aug-87 11:46:23 EDT Article-I.D.: monk.8708061546.AA27048 Posted: Thu Aug 6 11:46:23 1987 Date-Received: Sat, 8-Aug-87 11:05:14 EDT References: <8708061430.AA19988@etn-wlv.eaton.com> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 12 So why can't the IAS system be generous and accept or and type on the virtual teletype, and type on the virtual teletype when is received? The general interpretation in the Internet community is that is what is sent as the generic end-of-line on input. (Making this change would be consonant with the robustness principle of TCP.) Of course, IAS can generate whatever it want on output, and it the user Telnet does the wrong thing with it, then shame on it. I think part of the clarity problem in the spec is that it does not adequately seperate the meanings on input and output. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12324351037.26.ROODE@BIONET-20.ARPA] <1987080608021300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ROODE@BIONET-20.ARPA (David Roode) Newsgroups: comp.protocols.tcp-ip Subject: Re: How do you break up a B class number? Message-ID: <12324351037.26.ROODE@BIONET-20.ARPA> Date: Thu, 6-Aug-87 12:02:13 EDT Article-I.D.: BIONET-2.12324351037.26.ROODE Posted: Thu Aug 6 12:02:13 1987 Date-Received: Sat, 8-Aug-87 14:12:02 EDT References: <8707271742.AA26964@hi> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 12 Why don't you replace your DEC LANBridges with something at the IP level. In your description of the main ethernet, you indicate you use these to connect together a combination of thin and fat wires using these and repeaters. For the price of a DEC LANBridge, you can buy something like a cisco gateway, and voila, no more 100 host subnet. I can't see the real argument for ever desiring to put 1000 hosts on a single subnet, or even 300. Organizations that large are going to be naturally broken into administrative units of smaller size, each of which might be allocated a subnet, or a portion of a subnet shared with a limited number of other units. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708061743.AA27139@topaz.rutgers.edu] <1987080609435300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick) Newsgroups: comp.protocols.tcp-ip Subject: Re: IBM TCP. Message-ID: <8708061743.AA27139@topaz.rutgers.edu> Date: Thu, 6-Aug-87 13:43:53 EDT Article-I.D.: topaz.8708061743.AA27139 Posted: Thu Aug 6 13:43:53 1987 Date-Received: Sat, 8-Aug-87 11:45:09 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 45 No, DEC does not preempt other vendors' addresses. Let's try this again. The Ethernet spec requires that a vendor allocate each Ethernet interface an address which is globally unique. That is, there is no other interface in the world with the same number. DEC interfaces have such an address. However when you turn on DECnet, the processor causes the interface to change addresses. It no longer uses its globally unique address, but instead uses an address that is produced algorithmically from the DECnet address. The first 4 bytes of the address are a constant. The last two are the DECnet address with various bit twiddling. (The exact algorithm is documented in the DECnet manual.) This address is obviously unique within your site, and even within the set of sites that are connected by DECnet, but is no longer globally unique, because any other site with the same DECnet address will now have the same Ethernet address. The Ethernet address is otherwise legal. The vendor prefix is DEC's. However the address as a whole is not unique across the whole world. Perhaps the confusion is whether DECnet addresses are globally unique? A DECnet address has two parts: area and host. There are 64 possible area numbers and 1024 possible host numbers. This is not a large enough address space to allow DECnet addresses to be globally unique. Again, they are obviously unique for any given DECnet network. But your DECnet network, DEC's, GM's, etc., may and probably do use the same addresses. The physics net, in which both of us participate, controls allocation of area numbers for the schools that participate. So among that set of schools DECnet addresses are unique. But there can only be 62 schools in that network, because the network itself uses one area number, and 0 is not allowable. There are certainly more than 62 universities in the country. Indeed there was a message on dcom.lan not long ago from someone who couldn't join the network because their local DECnet needed several areas, and therefore their address allocations conflicted with the physics nets'. There are other large organizations, such as DEC's engineering network, that use most of the possible DECnet addresses. So the conclusion is: DECnet addresses are unique within the specific DECnet network, but not on a world-wide basis. Furthermore, the address space is small enough that there could not be a DECnet network as large as the IP internet. Simple arithmetic will show that. DECnet uses 16 bits for its address. In general 16 bit addresses do not provide enough address space to allow globally unique addresses. Thus the 16-bit networks, including chaos, PUP, and DECnet, are used primarily as local networks, or between specific sets of institutions. For a large network, at least 32 bits is needed, and even that may be marginal. IP uses 32 bits, DECnet phase V uses 64 bits, and XNS uses 96 bits. All of these are designed to be used with large-scale networks. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [5093@j.cc.purdue.edu] <1987080611274600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: abe@j.cc.purdue.edu (Vic Abell) Newsgroups: comp.protocols.tcp-ip Subject: Re: Telnet, , etc. Message-ID: <5093@j.cc.purdue.edu> Date: Thu, 6-Aug-87 15:27:46 EDT Article-I.D.: j.5093 Posted: Thu Aug 6 15:27:46 1987 Date-Received: Sun, 9-Aug-87 05:59:43 EDT References: <8707311950.AA12026@opal.berkeley.edu> <555127536.0.CASNER@VENERA.ISI.EDU> Organization: Purdue University Computing Center Lines: 32 Among the five telnet client and server applications available to me for for testing - 2.9BSD (4.1c/4.2 ancestry), 4.3BSD, ULTRIX 1.2, Wollongong VMS 3.0, and WISCNET/VM (IBM) - only one combination passes all my operability tests: 4.3BSD. (My tests did not including chaining - client to server to client to server, etc., etc.) 2.9BSD has all the 4.2 failings and more - particularly with respect to local character processing and CR forwarding. ULTRIX 1.2 telnet doesn't process local characters at all, but it does echo them. Its telnetd is reputed to have problems with echo mode changes. Both are 4.2 based. Wollongong telnet emits unnecessary NUL characters and doesn't seem to send anything but for end of line. WISCNET works well with everyone, but has only line-at-a-time mode, so character oriented applications (e. g., vi) don't work. Dave Borman and Greg Minshall should be complimented for having done well a difficult job of practical engineering in 4.3BSD. They managed to strike a reasonable compromise with the leaky and overloaded telnet protocol. It would be even better if 4.3BSD telnetd were changed to forward '\r' instead of '\n' to the application. That would represent another, good, practical compromise for assisting chaining and other character-oriented applications. Vic Abell Purdue University Computing Center ----MESSAGE-END---- ----MESSAGE-BEGIN---- [2443@ames.arpa] <1987080613492400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: lamaster@pioneer.arpa (Hugh LaMaster) Newsgroups: comp.protocols.tcp-ip Subject: Re: Telnet, , etc. Message-ID: <2443@ames.arpa> Date: Thu, 6-Aug-87 17:49:24 EDT Article-I.D.: ames.2443 Posted: Thu Aug 6 17:49:24 1987 Date-Received: Sat, 8-Aug-87 12:52:22 EDT References: <8707311950.AA12026@opal.berkeley.edu> <555127536.0.CASNER@VENERA.ISI.EDU> Sender: usenet@ames.arpa Reply-To: lamaster@ames.UUCP (Hugh LaMaster) Distribution: world Organization: NASA Ames Research Center, Moffett Field, Calif. Lines: 85 Stephen Casner writes: ********************** >You are correct, the Telnet spec does NOT make it clear whether the >client program should send CR-LF or CR-NUL when the user hits the >"return" key. The discussion is clear for characters flowing in the : >The following sentence is the one that I think causes trouble; you have >undoubtedly read it before, but I'll quote it here for discussion: Therefore, the sequence "CR LF" must be treated as a single "new line" character and used whenever their combined action is intended; the sequence "CR NUL" must be used where a carriage return alone is actually desired; and the CR character must be avoided in other contexts. >show that CR-LF "must be ... used". Those who believe that carriage >return alone is desired, because on many (most?) terminals the "return" >key generates a single CR character, might quote the second part of the >sentence to show that CR-NUL "must be used". I agree with ALMOST all of this. Now, I have just read the spec carefully again myself, and it seemed clear to me that CR-NUL was intended originally to be used on output for NVT printer overstrikes on the same line. It isn't clear what, if anything, it means on input. However, through long use (misuse?), CR-NUL should, it seems, ALSO be INTERPRETED as a newline on input. Does anyone know what a TAC sends when it gets a CR from a keyboard? >NEITHER group can "prove" its case from the spec, but this is not a >legal contest. As Mark Crispin says, "we all have a shared interest in >maximizing interoperability". EXACTLY. Since interoperability is the PURPOSE, implementors have an OBLIGATION to follow the robustness principle, even if it inconveniences Un*x raw mode I/O. >I believe the Telnet spec should say exactly which of these two choices >should be used, just to avoid the present confusion of interpretation. >In any case, by the "robustness principle", EITHER sequence (CR-LF or >CR-NUL) should be accepted by the Telnet server to mean that the >"return" / "enter" key was pushed because we know there are some systems >that send one and some systems that send the other. Yes, the spec should have defined ONE sequence exactly for what user telnet should send to mean "newline". However, the spec does state very clearly that CR-LF MUST (read it again) be INTERPRETED as a newline. Therefore, user telnet MUST SEND CR-LF unless it has negotiated or otherwise knows that something else is preferable. Versions of BSD telnet which don't follow this are not consistent with the standard, pure and simple. In my opinion (let us not get personal). >So, for the moment at least, my complaint was and is not that the 4.3BSD >telnet client sends CR-NUL but only about the 4.3BSD telnetd maps CR-LF >to '\n' instead of '\r'. I do not follow this. 4.3BSD telnetd MUST interpret CR-LF as a "newline" (which means that a user PROCESS must receive \n (or \n\0 depending on how you look at the \0) - whatever happens in between is the implementors problem) and MUST SEND CR-LF as a "newline" to a (non-Unix) host. Obviously, there is disagreement about this, but it seems very clear to me. Read the spec again. The convention used to handle the raw-mode case must be consistent with this. Some discussion seems to point to the need for programs in raw mode receiving a \r or \r\0. I am not sure I follow this, but if the cooked mode case is clear, then the raw mode case should make more sense. (discussion about the difference between terminals and what a process receives internally deleted - the discussion is correct: there is NO necessary connection between the characters that telnet NVT uses and what Unix uses internally, although 99% of the time they are the same). Hugh LaMaster, m/s 233-9, UUCP {seismo,topaz,lll-crg,ucbvax}! NASA Ames Research Center ames!pioneer!lamaster Moffett Field, CA 94035 ARPA lamaster@ames-pioneer.arpa Phone: (415)694-6117 ARPA lamaster@pioneer.arc.nasa.gov "IBM will have it soon" (Disclaimer: "All opinions solely the author's responsibility") ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987080614400000> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Thu 6 Aug 87 12:13:59-PDT Received: by ucbvax.Berkeley.EDU (5.58/1.27) id AA18839; Thu, 6 Aug 87 11:52:01 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Aug 87 14:40:00 GMT From: apollo!rees@eddie.mit.edu (Jim Rees) Organization: Apollo Computer, Chelmsford, Mass. Subject: RFS vs NFS Message-Id: <3681e98d.b8ab@apollo.uucp> References: <725@hjuxa.UUCP>, <649@houxa.UUCP>, <255@srs.UUCP> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa While we're at it, could anybody summarize the differences between RFS and NFS? I wrote an article for Unix/World a while ago on this topic. The big technical difference is that NFS is stateless, and RFS statefull. This means you get exact unix file system semantics with RFS, but not with NFS. On the other hand, NFS clients are able to recover from server crashes without a glitch, and continue processing where they left off before the crash. If you want file locking (and I do; there are ~2000 machines on my local network sharing a single file system) then you can't get it on NFS without adding state to the servers. If you do that, you've lost much of the advantage of having a stateless server. Most people don't care about this (yet). I won't go into all the politics, but right now (and for the foreseeable future) NFS is much more widely available. Disclaimer: I dislike both RFS and NFS, but for different reasons. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [4609@felix.UUCP] <1987080615401900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: martin@felix.UUCP (Martin McKendry) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Streams TCP/IP Message-ID: <4609@felix.UUCP> Date: Thu, 6-Aug-87 19:40:19 EDT Article-I.D.: felix.4609 Posted: Thu Aug 6 19:40:19 1987 Date-Received: Sun, 9-Aug-87 06:21:44 EDT References: <725@hjuxa.UUCP> <649@houxa.UUCP> <278@unixprt.UUCP> <561@applix.UUCP> <965@geac.UUCP> <24336@sun.uucp> Sender: daemon@felix.UUCP Reply-To: martin@felix.UUCP (Martin McKendry) Organization: FileNet Corp., Costa Mesa, CA Lines: 31 In article <24336@sun.uucp> guy%gorodish@Sun.COM (Guy Harris) writes: > >Since streams modules and drivers do not necessarily run in the >context of a process, even when servicing a request made in a process >(e.g., a "write" or an "ioctl"), they cannot block; thus, if a memory >allocation fails, you have to go through some amount of contortions >to retry the allocation if it's important to do so. Were STREAMS to >be implemented on top of a kernel that supported "lightweight >processes", one could guarantee that streams modules and drivers ran >in the context of a thread of control that could safely block, which >would considerably simplify this. We are considering using streams as a basis for some future work on our distributed file system, as well as for networking. The problem Guy cites above, inability to block on resources, seems to be a MAJOR one. The code I have seen seems to do mutual exclusion via spl, which is pretty crude but works. I guess we could do that, but often we need to block to read from disk, or to get long-held resources, such as inodes. So what work-arounds exist? I cannot believe that real software has been implemented with streams without this problem coming up. Any experience or suggestions? Or are the applications implemented so far sufficiently simple that this is not a problem? In which case, Streams are maybe half of a message handling mechanism, which is probably worse than none at all. Sadly. -- Martin S. McKendry FileNet Corp {hplabs,trwrb}!felix!martin ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708070054.AA08618@speed.sun.com] <1987080616545700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: nowicki@SUN.COM (Bill Nowicki) Newsgroups: comp.protocols.tcp-ip Subject: Re: Telnet, , etc. Message-ID: <8708070054.AA08618@speed.sun.com> Date: Thu, 6-Aug-87 20:54:57 EDT Article-I.D.: speed.8708070054.AA08618 Posted: Thu Aug 6 20:54:57 1987 Date-Received: Sun, 9-Aug-87 12:38:50 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 29 My two cents worth on this subject: In SunOS 3.4 I changed the telnet daemon to send \r instead of \n to the pty when it gets . However, this broke the local line edit mode. In SunOS 4.0 I originally put in a check to see if local editing was being done, and if so sent \n to the pty, otherwise \r. Steve Casner's message, however, convinced me that a slightly cleaner fix would be to just keep the pty in the mode that treats \r as \n when doing local editing. I don't understand the rationale behind the code that explicitly cleared it. The change is simple (your line numbers may vary). In the function dontoption(): 922,927c924,925 < case TELOPT_ECHO: < /* < * we should stop echoing, since the client side will be doing it, < * but keep mapping CR since CR-LF will be mapped to it. < */ < mode(0, ECHO); --- > case TELOPT_ECHO: /* we should stop echoing */ > mode(0, ECHO|CRMOD); This, in combination with the change from \n to \r for incoming s seems to work for most telnets in both line and character modes. - WIN ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987080618241300> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Thu 6 Aug 87 05:15:03-PDT Received: from VM1.BIU.AC.IL by wiscvm.wisc.edu ; Thu, 06 Aug 87 07:15:43 CDT Received: by BARILVM (Mailer X1.24) id 1908; Thu, 06 Aug 87 15:13:49 P Date: Thu, 06 Aug 87 14:54:13 P From: Henry Nussbacher Subject: Tcp/Ip for MVS and Mitek revisited To: IBM mainframes and networking conference cc: tcp-ip@sri-nic.ARPA Last week I asked for info on Mitek and their MVS solutions to Tcp/Ip. To date only one person has replied and that was only to tell me that he thinks that Mitek has signed to be a MAP of IBM. He did not know what MAP was. I did some further checking. IBM has a IMAP program (Industry Marketing Assistance Program). It is sort of like a 3rd party developer for IBM. Last year, IBM recruited several IMAP companies to promote DEC to System/370 connectivity. IBM has now been courting Mitek to develop System/36 and System/38 Tcp/Ip connectivity. Mitek has produced something called FTP/6.2 for 36 & 38 systems. Mitek was formed in 1982 by Bernie Hogan who previously owned Hogan Systems, Inc. This company suffered a pretax loss of $20 million in 1985 after delivering allegedly faulty software to 40 customers. Mitek now claims to have solutions for System/36, System/38, MVS, and SNA in the Tcp/Ip realm. This entire "thing" has me nervous. If IBM has decided to enter into an IMAP agreement with Mitek, why hasn't anyone on the network ever heard of them? Is there a single site out there using Mitek equipment? Thanks, Hank ----MESSAGE-END---- ----MESSAGE-BEGIN---- [2631@oliveb.UUCP] <1987080620244400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jerry@oliveb.UUCP (Jerry F Aguirre) Newsgroups: comp.protocols.tcp-ip Subject: Re: Telnet, , etc. Message-ID: <2631@oliveb.UUCP> Date: Fri, 7-Aug-87 00:24:44 EDT Article-I.D.: oliveb.2631 Posted: Fri Aug 7 00:24:44 1987 Date-Received: Sat, 8-Aug-87 18:06:43 EDT References: <8707311950.AA12026@opal.berkeley.edu> <555127536.0.CASNER@VENERA.ISI.EDU> Reply-To: jerry@oliveb.UUCP (Jerry F Aguirre) Distribution: world Organization: Olivetti ATC; Cupertino, Ca Lines: 21 Keywords: telnet pty newline Unix Summary: The mode of the pty defines the end of line character In article <555127536.0.CASNER@VENERA.ISI.EDU> CASNER@VENERA.ISI.EDU (Stephen Casner) writes: >You say that you could have mapped CR-LF to '\r', but that it would have >violated the philosophy of Unix that '\n' is the newline character. I >disagree, because the philosophy of Unix does not require that terminals >send '\n' to the tty driver; instead the tty driver receives '\r' from >the terminal and maps it to '\n' WHEN APPROPRIATE. Since telnetd does >not feed the application program directly, but rather feeds a pty, I >claim telnetd should map CR-LF to '\r' and let the pty driver map to >'\n' when appropriate. I agree. The telnet daemon is not talking to "Unix" but to the pty. For the pty driver linefeed is not necessarily the end of line character. The end of line character depends on the mode of the pty. I would add that the telnet daemon should map CR-LF to '\n' if the pty is in newline mode but should map it to '\r' if the mode is not newline. The user can then, either automatically (via getty), or explicitly (via stty), set the newline processing as appropriate for their terminal. This offers greater functionality with no loss that I can perceive. Jerry Aguirre ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987080622355300> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Fri 7 Aug 87 02:41:31-PDT Received: by ucbvax.Berkeley.EDU (5.58/1.27) id AA04068; Fri, 7 Aug 87 02:23:03 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Aug 87 22:35:53 GMT From: hi!kurt@hc.dspo.gov (Kurt Zeilenga) Organization: U. of New Mexico, Albuquerque Subject: Re: RFS vs NFS Message-Id: <12831@hi.UUCP> References: <649@houxa.UUCP>, <255@srs.UUCP>, <3681e98d.b8ab@apollo.uucp> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa In article <3681e98d.b8ab@apollo.uucp> rees@apollo.uucp (Jim Rees) writes: >If you want file locking (and I do; there are ~2000 machines on my >local network sharing a single file system) then you can't get it on >NFS without adding state to the servers. If you do that, you've lost >much of the advantage of having a stateless server. Most people don't >care about this (yet). That's why we run statd and lockd along side of NFS on our systems. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [517@cernvax.UUCP] <1987080704203200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ben@cernvax.UUCP (ben) Newsgroups: comp.sys.m68k,comp.protocols.tcp-ip Subject: TCP/IP for Motorola RMS68K O/S ?? Message-ID: <517@cernvax.UUCP> Date: Fri, 7-Aug-87 08:20:32 EDT Article-I.D.: cernvax.517 Posted: Fri Aug 7 08:20:32 1987 Date-Received: Sun, 9-Aug-87 10:09:52 EDT Reply-To: ben@cernvax.UUCP (via mcvax) / ben@cernvax.bitnet Distribution: world Organization: CERN European Laboratory for Particle Physics, CH-1211 Geneva, Switzerland Lines: 5 Keywords: TCP/IP RMS68K NFS We are looking for possible TCP/IP implementations for 68K systems running the Motorola RMS68k operating system. We are interested both in the case where all of the protocols and utilities run on the 68K, or where an intelligent board is used, e.g. Excelan, CMC, etc. (for VME-based systems). A big bonus would be the additional availability of (at least client) NFS. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987080706325000> Received: from parmesan.wisc.edu by SRI-NIC.ARPA with TCP; Sat 8 Aug 87 09:05:23-PDT Date: Fri, 7 Aug 87 11:32:50 CDT From: lhl@parmesan.wisc.edu (L.H. Landweber) Message-Id: <8708071632.AA02863@parmesan.wisc.edu> Received: by parmesan.wisc.edu; Fri, 7 Aug 87 11:32:50 CDT To: info-nets@think.com, namedroppers@sri-nic.arpa, tcp-ip@sri-nic.arpa Subject: WISCVM FUTURE Cc: lhl@parmesan.wisc.edu PLEASE DISTRIBUTE THIS ANNOUNCEMENT On December 1, WISCVM will be shut down. Hence, as of that date, we will no longer be able to provide a mail relay service between Arpanet and BITNET. WISCVM currently handles between 5 and 10 thousand messages per day. Clearly, this service is very important to the academic/research network community. As such it should be fully supported. Many of you may not be aware that at present the WISCVM relay is only supported by a volunteer student (indeed, this summer he has a full-time job off campus). Because of the (admittedly) inadequate level of support, problems arise periodically. For example, for the past day most messages have been rejected. The current problem occurred because there was some ambiguity in our instructions for installing new host tables. We would be happy to provide advice on what is required to run a supported mail relay. Besides operations and bug fixing, such support should include consulting for system administrators (if not for users). Hopefully, some suitable organization will be found to provide this service. Larry Landweber ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708071452.AA22004@topaz.rutgers.edu] <1987080706524900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ron@TOPAZ.RUTGERS.EDU (Ron Natalie) Newsgroups: comp.protocols.tcp-ip Subject: Re: TAC "noise" Message-ID: <8708071452.AA22004@topaz.rutgers.edu> Date: Fri, 7-Aug-87 10:52:49 EDT Article-I.D.: topaz.8708071452.AA22004 Posted: Fri Aug 7 10:52:49 1987 Date-Received: Sun, 9-Aug-87 02:12:56 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 4 Ether that or someone has their terminal set to 7 data-bits and no parity. -Ron ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12886@hi.UUCP] <1987080711421200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: kurt@hi.UUCP (Kurt Zeilenga) Newsgroups: comp.unix.wizards,comp.protocols.tcp-ip Subject: BSD route daemon Message-ID: <12886@hi.UUCP> Date: Fri, 7-Aug-87 15:42:12 EDT Article-I.D.: hi.12886 Posted: Fri Aug 7 15:42:12 1987 Date-Received: Sun, 9-Aug-87 06:11:27 EDT Organization: U. of New Mexico, Albuquerque Lines: 13 Most of the systems on our network run some form of the route daemon 'routed'. Network == multiple (but few) IP networks (and subnets) on ethernets. Gateways are all 4.X BSD UNIX host computers. No Internet gateway, YET (but we are hoping). I would like to know the pros and cons of replacing the daemons with hardcoded routes. We are having problems with a few non-gateway systems adverstising incorrect info. Like today one system (Ultrix 1.2) said: "I'm a gateway to 255.255.255.255"! Subjects I am interested in are: system overhead, network drain, static vs dynamic route tables, etc. We will be bring up EGP on our gateways to Internet. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [25133@sun.uucp] <1987080712105200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: guy%gorodish@Sun.COM (Guy Harris) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Streams TCP/IP Message-ID: <25133@sun.uucp> Date: Fri, 7-Aug-87 16:10:52 EDT Article-I.D.: sun.25133 Posted: Fri Aug 7 16:10:52 1987 Date-Received: Sun, 9-Aug-87 08:47:56 EDT References: <725@hjuxa.UUCP> <649@houxa.UUCP> <278@unixprt.UUCP> <561@applix.UUCP> <4609@felix.UUCP> Sender: news@sun.uucp Lines: 38 > We are considering using streams as a basis for some future work on > our distributed file system, as well as for networking. The problem > Guy cites above, inability to block on resources, seems to be a > MAJOR one. Nope. AT&T's RFS uses STREAMS to talk to the transport layer it uses, so there is an existence proof. The secret is that the AT&T RFS (or NFS, or probably Todd Brunhoff's RFS) server is implemented as a separate UNIX process; the server code runs in the context of that process (or processes, if you have more than one server). *That* process can block waiting for a disk, or other resource, if it wants to. The client code probably also runs in the context of a UNIX process; if it's running in the process that makes the request, it obviously is, and NFS has a daemon to handle asynchronous requests. This code can also block if it has to. The trick here is that none of the file system code is implemented as a STREAMS module; that's not really what STREAMS were developed for. However, there may be cases where something that STREAMS *was* developed for, such as a network protocol implementation, would want to block. There are cases, both in the STREAMS framework and the 4BSD sockets/protocols framework, where it can't do this conveniently. The problem with the STREAMS mechanism is that there are *no* places where you can *guarantee* that you can block, if you want to follow the letter of the law. If you "know" that there are no modules with service procedures above you, and you "know" the way put procedures are called, so that you "know" that your module's "put" procedure will be called in the context of the process making the request that causes the message to be sent downstream, you could cheat; however, you can't really "know" any of those things. Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987080714004400> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Sat 8 Aug 87 02:14:37-PDT Received: by ucbvax.Berkeley.EDU (5.58/1.27) id AA26062; Sat, 8 Aug 87 01:44:39 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Aug 87 14:00:44 GMT From: mcvax!ukc!its63b!adam@seismo.css.gov (ERCF02 Adam Hamilton) Organization: I.T. School, Univ. of Edinburgh, U.K. Subject: Re: IBM TCP. Really DECnet and Ethernet addresses Message-Id: <566@its63b.ed.ac.uk> References: <8708051618.AA26134@uxc.cso.uiuc.edu>, <8708051624.AA26323@uxc.cso.uiuc.edu>, <870806110524.3.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa > Date: Wed, 5 Aug 87 11:24:18 CDT > From: sandrock@uxc.cso.uiuc.edu (Mark Sandrock) > > It sounds like you are claiming that DEC preempts Ethernet hardware > addresses which have been officially assigned to other vendors, but > I have yet to see a specific example of such an address. Is it asking > to much either to see an example or else have everyone drop this claim? > >Sure. There is a Symbolics 3600 at our site that has an Ethernet >hardware address of 08-00-05-03-00-38. The 08-00-05- portion was >assigned to Symbolics by the Ethernet number Czar for use by Symbolics >for its Ethernet interfaces. That is the "official" hardware address of >the interface on that machine. That machine also has a DNA address of >41.69. Because of the way DNA works, the booting procedure for the >machine changes the Ethernet address of the interface to >AA-00-04-00-45-A4. Therefore, DNA has preempted our officially assigned >address. In IEEE802 and also XEROX Blue book, the format of an Ethernet address is defined as having two special bits; these are the first two to be transmitted. Note that bits in an octet are transmitted LEAST significant bit first, therefore these bits are the LEAST significant bits of the first octet. The first bit signifies whether the address is individual or local, the second signifies whether the address is globally (value 0) or locally administered. In the above example (AA-00- etc.) the second bit is set, therefore the address is locally administered. All address allocations to manufacturers are globally administered. All VMS machines I have seen have addresses which start AA-00. All this means that DECnet style addresses are NOT globally unique (as discussed) but do NOT use values which are globally administered. This should make no difference unless the same address is used on more than one Ethernet when a bridge (specifically selective frame-level repeater) may well get confused. Presumably this bit was put in for DEC's benefit, but I'm just guessing here. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708072223.AA00090@apolling.imagen.uucp] <1987080714234800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: geof@imagen.UUCP (Geof Cooper) Newsgroups: comp.protocols.tcp-ip Subject: Telnet CRLF's Message-ID: <8708072223.AA00090@apolling.imagen.uucp> Date: Fri, 7-Aug-87 18:23:48 EDT Article-I.D.: apolling.8708072223.AA00090 Posted: Fri Aug 7 18:23:48 1987 Date-Received: Sun, 9-Aug-87 08:27:41 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: imagen!geof@decwrl.dec.com Distribution: world Organization: The ARPA Internet Lines: 35 The problem is REALLY: How do I get RETURN to work properly both at the command level and in EMACS (or other RAW mode application, like vi, tip, etc....). At the command level (in "cooked tty" applications), the "big key" on the terminal (which is usually RETURN these days) is the one you want to type to end a command. Unix helps tty's to do this by internally mapping the '\r' character into '\n' (newline == linefeed) in the default terminal mode. When you go into a raw-mode application, it usually turns off this translation. Thus, it must "know" what key is the "big one" and let you use it. Emacs wants to see a '\r' to generate its "newline" function. So on Unix itself, it would be better to use CR-NUL and never generate newline, since the system will map CR-NUL into the local newline convention. BUT, in the generic case, you MIGHT be talking (perhaps from a Unix machine) to a machine that isn't Unix, and needs the CR-LF newline sequence. Or you might want the "big key" to generate the <> without having to worry about it. So you DO want to generate newline in your telnet user program. The only resolution of this, in my mind, is for telnet user programs to always provide an OPTION for what mapping to use. After all, how does the telnet program know what the "big key" is, anyway! - Geof Cooper ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708072248.AA00094@apolling.imagen.uucp] <1987080714482200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: geof@imagen.UUCP (Geof Cooper) Newsgroups: comp.protocols.tcp-ip Subject: Recursive Subnets Message-ID: <8708072248.AA00094@apolling.imagen.uucp> Date: Fri, 7-Aug-87 18:48:22 EDT Article-I.D.: apolling.8708072248.AA00094 Posted: Fri Aug 7 18:48:22 1987 Date-Received: Sun, 9-Aug-87 08:32:49 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: imagen!geof@decwrl.dec.com Distribution: world Organization: The ARPA Internet Lines: 72 In all this discussion of how you can't accomodate different sized subnets, I just wanted to mention that recursive subnets offer a legal solution to the problem -- if you can build the gateways to make them work. In fact, I remember thinking of recursive subnets as a solution to exactly this problem when the subnet specs were being sledgehammered out. The idea of using a subnet mask was partly to allow obscure things like this. The idea is to use higher order bits of the subnet address to label "top-level subnets", and lower bits to label "bottom-level" subnets. The address might look like: NNNNNNNN NNNNNNNN TSSSSSSS HHHHHHHH N => network number bits T => top-level subnet number S => bottom-level subnet bits H => host number There is one "top-level net" in this example (T=1), with a 15-bit host address. The other top-level subnetwork (T=0) is really a subdivision of 128 different subnets, each of which can have 256 hosts. The bottom-level subnets use a mask of 0xffffff00. The top-level subnet uses a mask of 0xffff8000. It is easy to generalize the above example to multiple top-level nets (or even multiple levels of recursive subnets - gawk!). All the gateways in all the subnets have to know the global subnet configuration (at the levels to which they are connected). This means that the configuration tables that were mentioned on the list -- with different subnet masks for different subnets or hosts -- still exist (they map to interfaces now), but only within the gateways. Hosts just use the regular subnet routing, and don't know about recursive subnets. The usual restriction of subnets, that there be only a single entry into the subnet world, still holds (I think) between the top and bottom levels. You could have redundant gateways, but all would have to be equally connected. I guess that you could remove this restriction with smarter gateways (all gateways know about all subnets, regardless of size). Hosts on the top-level network can send to hosts on the bottom-level networks, because bottom level network addresses look like hosts on the "other" top-level network (with T=0), so the packets are sent to a gateway. The Gateway Knows. Hosts on a bottom-level network can send to hosts on other bottom-level networks using the usual subnet- routing algorithm. Hosts on a bottom-level network can send to hosts on a top-level network because all hosts on the top-level network look like hosts on some other bottom-level subnet (which happens to have T=1), so the packets are sent to a gateway. The Gateway Knows. Everybody can send to hosts that are not on the subnet, because such packets always look like they are on a different "subnet", and are sent to a gateway, and The Gateway Knows. Of course, you still have to do the work to make the Gateways Know. - Geof ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708080055.AA07117@topaz.rutgers.edu] <1987080716553500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick) Newsgroups: comp.protocols.tcp-ip Subject: Re: No echo from the NIC Message-ID: <8708080055.AA07117@topaz.rutgers.edu> Date: Fri, 7-Aug-87 20:55:35 EDT Article-I.D.: topaz.8708080055.AA07117 Posted: Fri Aug 7 20:55:35 1987 Date-Received: Sun, 9-Aug-87 07:14:58 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 3 That's certainly true for us. Since the NIC is not a gateway, the only reason we would ever ping it is if we didn't get response from the root name server and wanted to help diagnosi ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708080204.AA23240@nrl-css.ARPA] <1987080718044400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mullen@NRL-CSS.ARPA (Preston Mullen) Newsgroups: comp.protocols.tcp-ip Subject: Ethernet problems induced by bogus ICMP Address Mask Reply Message-ID: <8708080204.AA23240@nrl-css.ARPA> Date: Fri, 7-Aug-87 22:04:44 EDT Article-I.D.: nrl-css.8708080204.AA23240 Posted: Fri Aug 7 22:04:44 1987 Date-Received: Sun, 9-Aug-87 08:16:24 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 87 Here's a new one to add to the list of things that can induce broadcast storms and other serious problems. It involves an unpleasant interaction between SunOS 3.3 and 3.4 and Wollongong's WIN/VX software version 3.0. (Ironically, this problem was noticed when the Suns and VAXes were upgraded to what is generally considered to be better networking software.) When a diskless Sun 3 workstation running SunOS 3.3 or 3.4 boots, at some point it sends out a broadcast ICMP Address Mask Request. This is in accordance with RFC950; unfortunately, an incorrect reply from any machine on the network can be accepted by the workstation, and some incorrect masks can induce the workstation to start sending all packets as Ethernet broadcasts, which instantly leads to a broadcast storm. If this happens, the workstation will probably fail to finish booting completely, usually stopping during the NFS mount with "RPC: not registered" messages, but sometimes sooner. Also, the workstation may itself then generate an incorrect reply (sent as an Ethernet broadcast) to a subsequent ICMP Address Mask Request from some other machine, thus spreading the virus. Other symptoms that may be observed include extremely sluggish operation of diskless machines and "no carrier" and "Ethernet jammed" notices from Suns (aside from those generated during broadcast storms). This happened here on a non-subnetted Class B network when the 3.0 release of Wollongong's IP/TCP software was installed on two VAXes running VMS. Both VAXes replied to a Sun's ICMP Address Mask Request with network masks of 0000FFFF instead of the correct FFFF0000. The diskless Sun gullibly swallowed this and began to encapsulate every IP packet in an Ethernet broadcast packet. Even after we isolated our network from the offending VAXes, any Sun in this state would respond with the bogus netmask to a broadcast from another Sun and thus continue the problem. The solution was to disconnect the offending VAXes from the network, halt ALL the diskless Suns, then reboot them. After that, we could let the VAXes back on the network, but it was not really safe since any diskless Sun reboot would start the cycle over again. The people who own the VAXes that started the problem have told me that the problem is really in the Wollongong software (i.e., not a configuration error) and is a holdover from some "broken 4.3bsd code". Evidently there are also problems with setting the address mask. They report that Wollongong has sent them a fix. ==> Potential users of Wollongong 3.0 software should get a fix from Wollongong before running 3.0 on a network where a machine might broadcast an ICMP address mask request. ==> Sun should make their networking code smarter. There is no way a netmask of 0000FFFF could ever be valid, since it must include the normal network part of the address as well as the subnet part. The Suns should have ignored the faulty replies instead of being driven berserk by them. I've reported this to Sun. The problem doesn't affect Suns running 3.2 or earlier releases since those releases have no subnetting support. It would probably be better if the diskless Sun did not broadcast the Address Mask Request but instead sent it directly to the server. I think that the request is broadcast after the ifconfig of the diskless Sun's Ethernet interface (anyway, an "address mask set to FFFF0000" report appears on the console quite a while before the problem shows itself). If that is so, then it's not clear why an ICMP Address Mask Request needs to be sent at all, since the network mask can be specified in the ifconfig in the rc.boot file. By the way, our class B network is partitioned by level 2 bridges (Digital DEBETs). Needless to say, they passed every bad packet and broadcast right through. (The VAXes were on the other side of a bridge from my Suns.) Yep, I'll be moving my stuff behind an IP gateway now. Many, many thanks to Van Jacobson for 'tcpdump', which proved instrumental in tracking this down. I hope Sun will let Van release the source code for tcpdump. Preston Mullen Computer Science and Systems Branch Information Technology Division Naval Research Laboratory Washington DC 20375-5000 P.S. Why do diskless Sun workstations running SunOS 3.4 broadcast an ARP request for IP address 0.0.60.216 very early in the boot sequence? (The ARP packet asks that replies go to 0.0.60.216.) This appears to be wired into the Sun networking software. It's harmless enough, but it should not be there. Maybe someone forgot to take out some debugging code. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1896@umn-cs.UUCP] <1987080721483000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: haque@umn-cs.UUCP (Samudra E. Haque) Newsgroups: comp.protocols.tcp-ip Subject: Re: IBM TCP. Message-ID: <1896@umn-cs.UUCP> Date: Sat, 8-Aug-87 01:48:30 EDT Article-I.D.: umn-cs.1896 Posted: Sat Aug 8 01:48:30 1987 Date-Received: Sun, 9-Aug-87 10:46:12 EDT References: <8708061542.AA15402@ucbvax.Berkeley.EDU> Organization: CSci Systems Group,University of Minnesota,Mpls. Lines: 27 Summary: nothing much .. just another query > Herewith the DECnet Ethernet address for node 19.53, aka 19509:: > > AA-00-03-01-10-E7 > > I do not know if this conflicts with any other vendor's address > assignments. > This message possibly has got nothing to do with the actual subject.. But is there ANY gateway from the INTERNET to DECNET (dec's private network). Specifically I am interested in contacting an individual who works in the Sunnyvale Digital ?Plant? ?office?. He has often said that there is no way that we can get messages accross the network walls. Is there anybody out there willing to give me a route to his node? If you mail me a note I will mail you back what information he gave me and will try your suggestion. I am not that terribly familiar of VMS based networking. Samudra E. Haque Computer Science Systems Group (CSSG) Computer Science Department University of Minnesota, Minneapolis (612) 625-0876 haque@umn-cs.ARPA , haque@umn.UUCP ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708081946.AA01449@etn-wlv.eaton.com] <1987080811460400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mcc@ETN-WLV.EATON.COM (Crockett) Newsgroups: comp.protocols.tcp-ip Subject: Re: TELNET ELF Message-ID: <8708081946.AA01449@etn-wlv.eaton.com> Date: Sat, 8-Aug-87 15:46:04 EDT Article-I.D.: etn-wlv.8708081946.AA01449 Posted: Sat Aug 8 15:46:04 1987 Date-Received: Sun, 9-Aug-87 12:00:58 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 38 Sorry for not responding earlier to your message, John. I fully intend to have a robust implementation under IAS; however, I want to be sure that I understand what TELNET is doing and what it expects. There are some IAS processes that a user could invoke during a TELNET session that utilize , , or as line terminators. What the process will do is dependent upon which line terminator is used. I would prefer not to change any of these processes to distinguish between a local terminal and a TELNET terminal or to prohibit the use of these processes to a TELNET terminal. At the moment we have a crude brute force TELNET port which suffers due to archtectural differences between UNIX and IAS and will produce an unacceptable system load in the target application system environment. Our current TELNET port is based on one of our vendors upper layer protocol support package for his TCP/IP board level implementation for an Ethernet interface. It's attrocious! The code looks okay until you notice '/*' and '*/' surrounding rather significant portions of code. When linked to our 4.3bsd gateway machine, we found that it lies about its ability to perform some of the options. Unlike Unix, VMS, RSX-11M (11M PLUS), etc. which have device and pseudo drivers that are integrated into the operating system; IAS has independent tasks referred to as handlers to support devices and pseudo devices. The thought was to split "telnetd" into one portion that was to listen for and accept connections and to integrate the remainder of it with the pseudo terminal handler which significantly reduces the number of context switches that would be required to pass data between the Ethernet interface handler, telnetd, and pseudo terminal handler. I could go off and do whatever I please since the rest of the world won't be permitted access to the network until a "secure" gateway can be developed but it seemed nicer to plan for the future when there will be a common backbone for all the networks. Merton Campbell Crockett ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708082015.AA15628@okeeffe.Berkeley.EDU] <1987080812150400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: karels%okeeffe@UCBVAX.BERKELEY.EDU (Mike Karels) Newsgroups: comp.protocols.tcp-ip Subject: Re: Recursive Subnets Message-ID: <8708082015.AA15628@okeeffe.Berkeley.EDU> Date: Sat, 8-Aug-87 16:15:04 EDT Article-I.D.: okeeffe.8708082015.AA15628 Posted: Sat Aug 8 16:15:04 1987 Date-Received: Sun, 9-Aug-87 12:01:21 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 6 Round and round and round we go! Your suggestion for recursive subnets is exactly the original Berkeley subnet scheme and proposal (in RFC-something or other), with the bit T inverted. (We used T=1 to indicate bottom-level subnets, T=0 for the trunk network.) Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708082300.AA11966@topaz.rutgers.edu] <1987080815005900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick) Newsgroups: comp.protocols.tcp-ip Subject: decnet phase V Message-ID: <8708082300.AA11966@topaz.rutgers.edu> Date: Sat, 8-Aug-87 19:00:59 EDT Article-I.D.: topaz.8708082300.AA11966 Posted: Sat Aug 8 19:00:59 1987 Date-Received: Sun, 9-Aug-87 12:36:10 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 23 Sorry, I should have been more clear about the phase V DECnet addressing. First let me note that I am basing this on a paper given a few months ago at an IETF meeting. I have not seen full documentation for phase V. According to this paper the basic DECnet address will involve 2 bytes of area number and 6 bytes of system ID. "DEC uses Ethernet absolute host ids in this field to ease address administration. The only requirement, however, is that the ID be unique within an area for level 1 ISs and ESs, and unique within the domain for level 2 ISs". It appears that the ISO IS-ES (the ISO equivalent to ARP) is used, so that there would be no problem handling machines whose DECnet address differs from the Ethernet address. There are other features of their addressing that makes it somewhat more general than what is implied by the description here, but the document is too vague for me to be sure what it means. In particular, an entire set of addresses, using the full 8 bytes described above, is a "domain". There is some provision for connecting multiple domains, using fixed routing tables at the border nodes. The DECnet format is designed to use only 8 bytes in a fixed portion of the full ISO address, in order to facilitate hashing. There was also a comment in the talk that if necessary other address formats could be used, but handling them would be less efficient. The upshot is that I know of no problems with phase V DECnet addressing. Maybe I'll find some once I see it in detail, of course. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [109@quick.UUCP] <1987080815404400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: srg@quick.UUCP (Spencer Garrett) Newsgroups: comp.protocols.tcp-ip Subject: Re: telnet CR processing, bridge comm servers and TWG telnet Message-ID: <109@quick.UUCP> Date: Sat, 8-Aug-87 19:40:44 EDT Article-I.D.: quick.109 Posted: Sat Aug 8 19:40:44 1987 Date-Received: Sun, 9-Aug-87 23:08:49 EDT References: <27@abvax.icd.ab.com> Organization: Quicksilver Engineering, Seattle Lines: 34 Keywords: telnet TWG Bridge BSD4.3 Summary: Much confusion about line terminators In article <27@abvax.icd.ab.com>, wrk@abvax.icd.ab.com (William R. King) writes: > Last week I posted a query about CR processing. > The problem stemed from the connection between the Bridge CS/1 and > the BSD 4.3 telnetd. The CS/1 was incorrectly sending \r\n as the > line terminator instead of the correct \r\0 sequence. The BSD telnetd > converted the \r\n sequence into \n and sent that into the pty. The > \n was passed on to TWG telnet which interpeted \n as "delete the > word to the left of the cursor". So much for logging in. > > I have since obtained a new release of Bridge CS/1 software (version > 13000) which fixes the problem. They now offer the option (per port) > of sending \r\n or \r\0 as the line terminator. But this is incorrect! The Bridge box SHOULD be sending \r\n when you hit or or whatever it's labelled on your keyboard. This is the TELNET "end of line" indicator. Telnetd correctly converts this to \n which is the equivalent sequence in a UNIX context. The problem appears to be the Berkeley telnet program (as opposed to the daemon) which is failing to convert \n to \n\r like it should, or perhaps TWG telnet is failing to accept \r\n as the TELNET eol. The sequence \r\0 is a "bare" carriage return which should get you to the beginning of the line WITHOUT ending the line. This is the behaviour you would get under UNIX with CRMOD turned off. The proper sequence should be: You hit The Bridge box sends \r\n telnetd converts \r\n to \n and feeds it to the pty telnet reads \n from its tty (pseudo-tty, but it shouldn't matter) telnet sends \r\n through its tcp stream to the vax the vax should convert \r\n to whatever it wants for EOL Making the Bridge box precompensate for a bug elsewhere by sending an incorrect sequence is not good polican ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708090056.AA13369@topaz.rutgers.edu] <1987080816562800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick) Newsgroups: comp.protocols.tcp-ip Subject: 4.3 telnet handling of newline Message-ID: <8708090056.AA13369@topaz.rutgers.edu> Date: Sat, 8-Aug-87 20:56:28 EDT Article-I.D.: topaz.8708090056.AA13369 Posted: Sat Aug 8 20:56:28 1987 Date-Received: Sun, 9-Aug-87 12:49:45 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 47 As far as I can see, the Unix implementors have failed to note that there are in effect two different end of line conventions in Unix, conventions for files and those for terminals. They are turning telnet NEWLINE into because is what you put in a file to indicate an end of line. The problem is that telnetd is feeding its output into a pty, and pty's are terminals. On a terminal, we expect a user to type to indicate end of line. This is why there is a special kernel mode to map one convention into the other by turning into . That allows naive programs to treat a terminal like any other file, and to see as newline. However when a program goes into raw mode, it see what is actually typed, and so it needs to be prepared to handle the device-dependent terminal conventions. Thus raw-mode programs expect to find as end of line, since that is in fact the end of line convention used by terminals. This is completely consistent with the rest of Unix, where by default, there is a uniform model for all device types, but it is possible to set up modes wherein you see device-specific behavior. Since telnetd is in effect typing on a terminal, it is going to have to do things in a device-dependent way, and issue a for NEWLINE. Pragmatically, it probably makes sense to do this conversion in two stages. All 4.3 implementations should immediately change telnetd to turn both and into . Only a should be turned into . I don't see any way that this change can break things. And it will allow people to run Emacs and other terminal- dependent software when connected from implementations that do things the right way. Unfortunately, the matching change, which is fixing telnet to send (telenet NEWLINE) when the user types , may have to be delayed until a site has updated all of its copies of telnetd. The problem is if a fixed telnet talks to a broken telnetd, we will be back into the situation where you can't run Emacs. One user suggested an option to select which behavior you want. I'm sorry to say that this may really be necessary, or we can dream up a hack (of a sort that is in fact already in telnetd) for determining automatically whether the other end is running a broken copy of telnetd, and adjust accordingly. The most helpful thing would be for Berkeley to make an official announcement that telnetd is regarded as broken and should be fixed. We will attempt to issue SPR's against all of our supported Unix implementations anyway, but it will be a mess if Berkeley persists in maintaining that no fix is needed, while most of the users are convinced that one is. Since the fixed to telnetd it to accept connections from either style of telnet, this can't possibly lose anything, except for the ability to have hitting the CR key put LF into a pty at the other end. And I can't figure out any practical use for that. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708071419.aa29476@SMOKE.BRL.ARPA] <1987080817462300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: phil@BRL.ARPA (Phil Dykstra) Newsgroups: comp.protocols.tcp-ip Subject: Re: No echo from the NIC Message-ID: <8708071419.aa29476@SMOKE.BRL.ARPA> Date: Sat, 8-Aug-87 21:46:23 EDT Article-I.D.: SMOKE.8708071419.aa29476 Posted: Sat Aug 8 21:46:23 1987 Date-Received: Sun, 9-Aug-87 12:52:50 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 7 Last time I looked at traffic from the NIC they seemed to be spending most of their time sending ICMP Source Quenches in response to nameserver requests. The nameserver system is probably the major reason for their load. Some statistics gathered a month or two ago showed them fielding an average of four queries a second. - Phil ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708090930.AA11940@columbia.edu] <1987080901304000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: chris@COLUMBIA.EDU (Chris Maio) Newsgroups: comp.protocols.tcp-ip Subject: Re: BSD route daemon Message-ID: <8708090930.AA11940@columbia.edu> Date: Sun, 9-Aug-87 05:30:40 EDT Article-I.D.: columbia.8708090930.AA11940 Posted: Sun Aug 9 05:30:40 1987 Date-Received: Sun, 9-Aug-87 20:43:15 EDT References: <12886@hi.UUCP> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 44 Kurt, you might be interested in what we did at Columbia. We needed to partition our network into different sized subnets, had to make the subnetting transparent to hosts that don't implement subnets, and needed to support ethernet bridges as well as IP gateways (for DECnet, etc), with multiple subnets on the same ethernet cable, etc. Surprisingly, all it took to make this work was a few small changes to the 4.3bsd kernel in our IP gateways, to support proxy arp and a limited form of variable width subnets; static routes (other than a default route) and routed aren't necessary at all. Subnet numbers are assigned naturally, e.g. large departments have larger subnets than small departments, and a departmental subnet can be further subdivided into smaller subnets. The basic strategy is that, since our network is more or less hierarchical, every gateway has exactly one interface which is closest to the backbone, and because subnet number/mask assignments match the physical topology, in the absence of static routes the interface to which a packet should be sent is a simple function of the destination address and the address and subnet mask for each interface. Even if a gateway isn't sure where the destination host is, it always knows the correct interface to route to, and then proxy arp can be used to find the next hop. The proxy arp support in the gateways also means that no changes are necessary to any host implementations. The two obvious restrictions are that (a) you have to stick to a hierarchical topology, and (b) you have to put up with proxy arp broadcasts, which have to be processed or discarded by every host on the ethernet cable. In practice, these aren't a problem for us; the hierarchical network is a fine match for the structure of the university, and there are various ways to reduce the proxy arp overhead, which is much less than you'd have if you used only ethernet bridges. Of course, we're stuck with using either 4.3bsd gateways or ethernet bridges until gateway vendors decide to support variable-width subnets. The advantages are that we can use different sized subnets, divide subnets up into smaller subnets, replace ethernet bridges with IP gateways or vice versa (or run them in parallel) with minimal hassles, and we don't need to run routed or install static routes. Most importantly, hosts that don't support subnets can still talk to everybody else. Obviously this isn't a general solution, particularly because it depends on the misuse of arp, but it's the only one available today that works in our environment. Chris ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708091202.AA20575@topaz.rutgers.edu] <1987080904024400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick) Newsgroups: comp.protocols.tcp-ip Subject: Re: Ethernet problems induced by bogus ICMP Address Mask Reply Message-ID: <8708091202.AA20575@topaz.rutgers.edu> Date: Sun, 9-Aug-87 08:02:44 EDT Article-I.D.: topaz.8708091202.AA20575 Posted: Sun Aug 9 08:02:44 1987 Date-Received: Sun, 9-Aug-87 21:45:14 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 6 I believe your ARP request for 0.0.60.216 is used during the boot sequence, at a point when the Suns don't know their Internet address. They seem to use their serial number as an address. You'll also find such addressing in the routing tables in certain versions of SunOS. I suggest that you take 60 * 256 + 216, and see if you don't have a Sun with that serial number. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [555526645.0.PERRY@VAX.DARPA.MIL] <1987080908572500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PERRY@VAX.DARPA.MIL (Dennis G. Perry) Newsgroups: comp.protocols.tcp-ip Subject: Re: WISCVM FUTURE Message-ID: <555526645.0.PERRY@VAX.DARPA.MIL> Date: Sun, 9-Aug-87 12:57:25 EDT Article-I.D.: VAX.555526645.0.PERRY Posted: Sun Aug 9 12:57:25 1987 Date-Received: Sun, 9-Aug-87 22:13:00 EDT References: <8708071632.AA02863@parmesan.wisc.edu> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 5 I should point out that any official gateway to BITNET from the Arpanet need approval from DARPA. dennis ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708091911.AA26305@topaz.rutgers.edu] <1987080911115900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ron@TOPAZ.RUTGERS.EDU (Ron Natalie) Newsgroups: comp.protocols.tcp-ip Subject: Re: Telnet CRLF's Message-ID: <8708091911.AA26305@topaz.rutgers.edu> Date: Sun, 9-Aug-87 15:11:59 EDT Article-I.D.: topaz.8708091911.AA26305 Posted: Sun Aug 9 15:11:59 1987 Date-Received: Sun, 9-Aug-87 22:42:26 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 55 I think the issue is getting a little confused here between what is in the SPEC, what UNIX wants to do, and how UNIX accomplishes it's goal. THE SPEC: The image of a terminal is something with a big RETURN, ENTER, or <--|, (I cant draw this) key. The latter label is perhaps the most descriptive showing both the down and return indicating a new line. If you just want a down motion, then press the LINE FEED. If for some reason you want to return without new lining (<-<-- key) then send CR-NUL. So the terminal should RETURN (down and left) send CR-LF LF (down) send LF <-<--- key or perhaps an escaped (quoted) RETURN (^Q^M for EMACS users) send CR-NUL. on receipt, the exact same semantics should apply. UNIX: The UNIX internal model is that LF is the end of line. CR is just a character and there is no explicit way to do other positioning. Since about the only terminal that works this way is the Model 37 teletype, there is a compatibility feature, referred to as CRMOD or -nl mode. This maps CR to NL on input and NL to CRLF on output. THE PROBLEM: The reason UNIX gets really confusing in TELNET is that CRMOD can not be turned off in only one direction, so anyone who wants to buypass the output mapping to do finer positioning must suddenly start doing the processing for CR as end-of-line in their user code. So the question is should the translation go TERMINAL (CR) -> NVT (CR-LF) -> UNIX (LF) for line termination we can emulate what UNIX thinks a terminal ought to me (like a Model 37) or TERMINAL (CR) -> NVT (CR-LF) -> Real World Virtual Terminal (CR) -> UNIX (LF) for line termination. The answer is probably the latter. NVTs and the rest of the world look a whole lot more like the VT100s than Model 37s. Hence, the UNIX telnet server should try to map the NVT back into the CR terminated world before passing it to the UNIX tty driver. UNIX programs violate the LF termination rule all the time to do things such as line editing and such because they know that there just aren't that many Model 37s left in operation. To avoid surprises the NVT->UNIX transformation ought to make the incoming TELNET look like that rather than attempting to map directly from NVT to UNIX tty conventions. -Ron ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987080922580300> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Sun 9 Aug 87 17:43:16-PDT Received: by ucbvax.Berkeley.EDU (5.58/1.27) id AA22297; Sun, 9 Aug 87 17:37:28 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 9 Aug 87 22:58:03 GMT From: mangler@csvax.caltech.edu (System Mangler) Organization: California Institute of Technology Subject: Re: RFS vs NFS Message-Id: <3537@cit-vax.Caltech.Edu> References: <649@houxa.UUCP>, <255@srs.UUCP>, <3681e98d.b8ab@apollo.uucp> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa In article <3681e98d.b8ab@apollo.uucp>, rees@apollo.uucp (Jim Rees) writes: > technical difference is that NFS is stateless, and RFS statefull. > This means you get exact unix file system semantics with RFS, but > not with NFS. On the other hand, NFS clients are able to recover > from server crashes without a glitch, and continue processing where > they left off before the crash. The claim of statelessness should not be taken too literally. When one of our disks got trashed (@*#% Xylogics!), we did the "obvious" thing - we took the server down, created the filesystem afresh, restored all of the backup tapes, and then let the clients continue where they left off before the crash. Talk about some confused clients... "Stateless" only means that the state is kept on disk rather than RAM. Don Speck speck@vlsi.caltech.edu {ll-xn,rutgers,amdahl}!cit-vax!speck ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987081003562100> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Sun 9 Aug 87 21:43:01-PDT Received: by ucbvax.Berkeley.EDU (5.58/1.27) id AA25001; Sun, 9 Aug 87 21:33:22 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Aug 87 03:56:21 GMT From: soliloquy.rutgers.edu!dpz@RUTGERS.EDU (David P. Zimmerman) Organization: Rutgers Univ., New Brunswick, N.J. Subject: Re: RFS vs NFS Message-Id: <929@soliloquy.rutgers.edu> References: <255@srs.UUCP>, <3681e98d.b8ab@apollo.uucp>, <3537@cit-vax.Caltech.Edu> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa In article <3537@cit-vax.Caltech.Edu> mangler@cit-vax.Caltech.Edu (System Mangler) writes: > The claim of statelessness should not be taken too literally. When one ... > before the crash. Talk about some confused clients... Sun's ND (one of the weirdest beasts around) isn't stateless, you can't use that as an example in this case. dpz -- David P. Zimmerman rutgers!dpz dpz@rutgers.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708101228.AA00780@ucbvax.Berkeley.EDU] <1987081004151600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: snorthc@NSWC-OAS.ARPA Newsgroups: comp.protocols.tcp-ip Subject: Re: No echo from the NIC Message-ID: <8708101228.AA00780@ucbvax.Berkeley.EDU> Date: Mon, 10-Aug-87 08:15:16 EDT Article-I.D.: ucbvax.8708101228.AA00780 Posted: Mon Aug 10 08:15:16 1987 Date-Received: Tue, 11-Aug-87 02:19:29 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 6 I have seen several replies from users saying they only ping the NIC when they can't make a connection. I was just looking through a manual for TCP for PCs. The example they give for ping is: ping -t sri-nic.arpa where -t is an option to ping repeatedly. Stephen Northcutt (snorthc@nswc-g.arpa) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708101331.AA20759@newton.ncsa.uiuc.edu] <1987081005311200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: timk@NEWTON.NCSA.UIUC.EDU (Tim Krauskopf) Newsgroups: comp.protocols.tcp-ip Subject: Re: Ethernet problems induced by bogus ICMP Address Mask Reply Message-ID: <8708101331.AA20759@newton.ncsa.uiuc.edu> Date: Mon, 10-Aug-87 09:31:12 EDT Article-I.D.: newton.8708101331.AA20759 Posted: Mon Aug 10 09:31:12 1987 Date-Received: Tue, 11-Aug-87 02:25:58 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 19 We encountered the exact same problem (diagnosed with tcpdump) between our diskless Sun 3/50 (SunOS 3.3) and a Vaxstation (TWG under VMS). The icmpmask response from TWG is backwards. Easy work-around while waiting for bug fixes from TWG: Install the netmask parameter in the rc.boot files (ifconfig lines) of as many diskless Suns as you feel like. Each of the Suns with the mask installed will operate correctly. For the rest of the machines, the russian roulette has much better odds: When the ICMP request goes out, there are several Suns waiting to respond and they are faster at responding than the VAXen. Whoever gets there first wins. Isn't this fun? Tim Krauskopf National Center for Supercomputing Applications University of Illinois timk%newton@uxc.cso.uiuc.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [870810101059.5.DCP@KOYAANISQATSI.S4CC.Symbolics.COM] <1987081006100000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer) Newsgroups: comp.protocols.tcp-ip Subject: Re: IBM TCP. Really DECnet and Ethernet addresses Message-ID: <870810101059.5.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Date: Mon, 10-Aug-87 10:10:00 EDT Article-I.D.: KOYAANIS.870810101059.5.DCP Posted: Mon Aug 10 10:10:00 1987 Date-Received: Tue, 11-Aug-87 02:37:46 EDT References: <566@its63b.ed.ac.uk> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 30 Date: 7 Aug 87 14:00:44 GMT From: mcvax!ukc!its63b!adam@seismo.css.gov (ERCF02 Adam Hamilton) In IEEE802 and also XEROX Blue book, the format of an Ethernet address is defined as having two special bits; these are the first two to be transmitted. Note that bits in an octet are transmitted LEAST significant bit first, therefore these bits are the LEAST significant bits of the first octet. The first bit signifies whether the address is individual or local, the second signifies whether the address is globally (value 0) or locally administered. In the above example (AA-00- etc.) the second bit is set, therefore the address is locally administered. All address allocations to manufacturers are globally administered. All VMS machines I have seen have addresses which start AA-00. All this means that DECnet style addresses are NOT globally unique (as discussed) but do NOT use values which are globally administered. This should make no difference unless the same address is used on more than one Ethernet when a bridge (specifically selective frame-level repeater) may well get confused. Presumably this bit was put in for DEC's benefit, but I'm just guessing here. I guess I'm hopelessly out of date. My copy of the Blue Book is Version 1.0, Sepetmber 30, 1980. In it, in section 6.2.1 on page 21, there is no mention of this second bit being for local/global administration. In fact, of the physical address it says "A station's physical address should be distinct from the physical address of any other station on @i(any) Ethernet." The italics are in the book. Time marches on... standards change... ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708101644.AA04454@ucbvax.Berkeley.EDU] <1987081009175500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: HANK@TAUNIVM.BITNET (Hank Nussbacher) Newsgroups: comp.protocols.tcp-ip Subject: VMS and X.25 Message-ID: <8708101644.AA04454@ucbvax.Berkeley.EDU> Date: Mon, 10-Aug-87 13:17:55 EDT Article-I.D.: ucbvax.8708101644.AA04454 Posted: Mon Aug 10 13:17:55 1987 Date-Received: Tue, 11-Aug-87 04:39:07 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Hank Nussbacher Distribution: world Organization: The ARPA Internet Lines: 15 I have been looking at various VMS and microVMS solutions for Tcp/Ip (Excelan, Interlan-Micom, Wollongong, SRI, Hyperlink, etc.) and all of them assume an Ethernet. How do sites connect lone VMS systems that are geographically scattered over many kilometers? The expensive solution is to build a 1 meter Ethernet, buy a bridge and connect that way. Do any of these systems handle X.25? What h/w do you need to buy? Will the Excelan and Interlan solutions work with an X.25 card or can an X.25 solution only be handled by a strictly software implementation (like Wollongong or Hyperlink)? Is there a way to do it with a leased line without Ethernet or a bridge? Thanks, Hank P.S. Plz send all replies directly to me. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1120@rtech.UUCP] <1987081010385200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: sid@llama.rtech.UUCP (Sid Shapiro) Newsgroups: comp.protocols.tcp-ip Subject: Re: telnet CR processing, bridge comm servers and TWG telnet Message-ID: <1120@rtech.UUCP> Date: Mon, 10-Aug-87 14:38:52 EDT Article-I.D.: rtech.1120 Posted: Mon Aug 10 14:38:52 1987 Date-Received: Thu, 13-Aug-87 00:36:22 EDT References: <27@abvax.icd.ab.com> <109@quick.UUCP> Sender: news@rtech.UUCP Reply-To: sid@llama.UUCP (Sid Shapiro) Organization: Relational Technology, Inc. Alameda, CA Lines: 8 This is going back a bit, and may not even be the same thing, but when I switched a system to 4.3, we could no longer get a characters into emacs (or vi for that matter, but vi didn't really care too much). If I remember correctly, the 4.3 telnetd was "smarter" - it could map s to s if you wanted it to (default behavior). This screwed up the Bridge boxes, cause the bridge telnet client didn't have a command to reset the telnetd to go back to the less smart behavior. I had to hack telnetd to turn off the mapping. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [495@utacs.UTA.FI] <1987081011095800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jaj@utacs.UTA.FI (Jari J{ntti) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: NCSA Telnet for micros? Message-ID: <495@utacs.UTA.FI> Date: Mon, 10-Aug-87 15:09:58 EDT Article-I.D.: utacs.495 Posted: Mon Aug 10 15:09:58 1987 Date-Received: Thu, 13-Aug-87 05:43:58 EDT References: <725@hjuxa.UUCP> <649@houxa.UUCP> Reply-To: jaj@utacs.UUCP (Jari J{ntti) Organization: University of Tampere, Computing Centre, Finland Lines: 114 Keywords: TCP/IP, TELNET, micros Please, anybody with ARPANET access, make the new NCSA TELNET for micros available through UUCP. Below is the original announcement seen here a while ago. Jari Jantti Computing Centre Univ. of Tampere, FINLAND JJANTTI@FINFUN.BITNET <<>> From: timk%newton@UXC.CSO.UIUC.EDU (Tim Krauskopf, NCSA) Newsgroups: comp.protocols.tcp-ip Subject: Telnet for micros available Message-ID: <8706282321.AA11880@babbage.ncsa.uiuc.edu> Date: 28 Jun 87 23:41:57 GMT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 87 --------------------------------------------- The National Center for Supercomputing Applications (NCSA) at the University of Illinois has prepared and is distributing a telnet package for IBM compatibles and Macintoshes. It has many features that we haven't found in anyone else's software. If you have trouble getting it to run, make sure I get a full description of your hardware setup including DOS version. I hope you like it. Tim Krauskopf Project leader, NCSA Telnet release info: National Center for Supercomputing Applications presents: NCSA Telnet for the PC, version 1.1 NCSA Telnet for the Macintosh, version 1.1 These programs are copyrighted, but distributed in binary form with no license fee. Source code is not available. We are exploring the possibility of distributing linkable libraries which support TCP/IP. Features included in version 1.1 of NCSA Telnet: ----------------------------------------------- DARPA standard telnet Built-in standard FTP server for file transfer VT102 emulation in multiple, simultaneous sessions Class A,B and C addressing with standard subnetting Each session in a different window (Macintosh) Tektronix 4010 graphics emulation (Macintosh) Supports Croft gateway, i.e. KIP (Macintosh) Capture text to a file (PC) Full color support (PC) How to obtain: ------------- Anonymous FTP from uxc.cso.uiuc.edu in the NCSA subdirectory. The PC version is a tar file which contain binary files. After the files are extracted from the tar file, some binary transfer (e.g. kermit) should be used to download the files to the PC. The Macintosh version is several files encoded with BinHex 4.0. Download them with a similar transfer method (kermit) and use BinHex 4.0 to extract the files. Printable documentation is included with each version; the Mac documentation is in MacWrite format. After downloading, you may copy the files as often as you wish, unmodified, in binary form, with the copyright notices intact. The PC version is also on this dial-up BBS: The University of Illinois Excel project BBS: (217)333-8301 file name: NCSATEL.ARC 300-1200-2400 baud size: 85K Kermit/Xmodem On-disk copies, with a printed manual are available for $20 each, which covers handling and postage. Orders can only be accepted if accompanied by a check made out to the University of Illinois. Send to: NCSA Telnet orders (specify PC or Macintosh version) 152 Computing Applications Building 605 E. Springfield Ave. Champaign, IL 61820 Hardware required: ----------------- PC: IBM PC, AT or 100% compatible. 3COM 3C501 Etherlink board. Support for other boards planned, which would you require? Mac: Macintosh 512K, Plus, SE or Macintosh II. Kinetics, Inc. FastPath, EtherSC or Etherport SE board. Kinetics gateway software or Stanford KIP (Croft) gateway software. The best source of information about Kinetics is directly from the company. Kinetics Inc. FastPath approx. $2500 Suite 110 EtherSC approx. $1250 2500 Camino Diablo educational and volume discounts Walnut Creek, CA 94596 (415) 947-0998 Other questions: --------------- mail to telbug%newton@uxc.cso.uiuc.edu <<<<<>>>>>> ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708102034.AA09028@ucbvax.Berkeley.EDU] <1987081012153400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PADLIPSKY@A.ISI.EDU (Michael Padlipsky) Newsgroups: comp.protocols.tcp-ip Subject: Re: No echo from the NIC Message-ID: <8708102034.AA09028@ucbvax.Berkeley.EDU> Date: Mon, 10-Aug-87 16:15:34 EDT Article-I.D.: ucbvax.8708102034.AA09028 Posted: Mon Aug 10 16:15:34 1987 Date-Received: Tue, 11-Aug-87 06:10:12 EDT References: Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 25 Ken [and interested onlookers]-- I am appalled to have to report that I can't find "But My NCP Costs $X00 a Day..." despite the facts that 1) I could have sworn I'd done such a thing and 2) running my finger down all the lines of RFC 1012 should have confirmed it. Either it was done as a Project MAC Memo and didn't get out on the net, or it's hidden away under some other title (RFC 411, "New Multics Network Software Features," is a possibility, but I can't get through to the NIC to check up), or (shudder) perhaps there's an error of omission in RFC 1012.... Of course, the incident is immortalized, albeit in highly capsulized form, in The Book: Horror Story Number 5, pp. 85-6 (and corresponding Trailer Cartoon on p. 88); indeed, it seems to me I just cited it the other week in a somewhat different context here on the List. But that isn't as gratifying as being able to point to a 14 (at least) year old RFC (or MAC Memo, I guess). Perhaps needless to say, I join you in urging all readers of this List to be particularly cautious not to cause squandering of others' cpu cycles, even if we can't prove just how long we've been preaching that particular position. cheers, map ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987081012153401> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Mon 10 Aug 87 13:19:49-PDT Date: 10 Aug 1987 16:15:34 EDT Subject: Re: No echo from the NIC From: Michael Padlipsky To: Ken Pogran cc: "GBURG::ENGER" , "tcp-ip" , enger@BLUTO.SCC.COM In-Reply-To: (Message from "Ken Pogran " of Wed, 5 Aug 87 8:41:40 EDT) Ken [and interested onlookers]-- I am appalled to have to report that I can't find "But My NCP Costs $X00 a Day..." despite the facts that 1) I could have sworn I'd done such a thing and 2) running my finger down all the lines of RFC 1012 should have confirmed it. Either it was done as a Project MAC Memo and didn't get out on the net, or it's hidden away under some other title (RFC 411, "New Multics Network Software Features," is a possibility, but I can't get through to the NIC to check up), or (shudder) perhaps there's an error of omission in RFC 1012.... Of course, the incident is immortalized, albeit in highly capsulized form, in The Book: Horror Story Number 5, pp. 85-6 (and corresponding Trailer Cartoon on p. 88); indeed, it seems to me I just cited it the other week in a somewhat different context here on the List. But that isn't as gratifying as being able to point to a 14 (at least) year old RFC (or MAC Memo, I guess). Perhaps needless to say, I join you in urging all readers of this List to be particularly cautious not to cause squandering of others' cpu cycles, even if we can't prove just how long we've been preaching that particular position. cheers, map ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [586@saturn.ucsc.edu] <1987081012215600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: haynes@ucscc.UCSC.EDU.ucsc.edu (99700000) Newsgroups: comp.protocols.tcp-ip Subject: Subnets on TEK/CMU package Message-ID: <586@saturn.ucsc.edu> Date: Mon, 10-Aug-87 16:21:56 EDT Article-I.D.: saturn.586 Posted: Mon Aug 10 16:21:56 1987 Date-Received: Fri, 14-Aug-87 04:27:59 EDT Sender: usenet@saturn.ucsc.edu Reply-To: haynes@ucscc.UCSC.EDU (Jim Haynes) Distribution: na Organization: California State Home for the Weird Lines: 8 Keywords: subnet Tektronix CMU Summary: does it have them? We'd like to know if the CMU distribution supports subnetting class B network numbers, and if so how to configure it, and if not is anybody planning to add this feature? haynes@ucscc.ucsc.edu haynes@ucscc.bitnet ..ucbvax!ucscc!haynes ----MESSAGE-END---- ----MESSAGE-BEGIN---- [7419@think.UUCP] <1987081013351900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: barmar@think.COM (Barry Margolin) Newsgroups: comp.protocols.tcp-ip Subject: Re: telnet CR processing, bridge comm servers and TWG telnet Message-ID: <7419@think.UUCP> Date: Mon, 10-Aug-87 17:35:19 EDT Article-I.D.: think.7419 Posted: Mon Aug 10 17:35:19 1987 Date-Received: Tue, 11-Aug-87 06:46:15 EDT References: <27@abvax.icd.ab.com> <109@quick.UUCP> Sender: news@think.UUCP Reply-To: barmar@godot.think.com.UUCP (Barry Margolin) Organization: Thinking Machines Corporation, Cambridge, MA Lines: 38 Keywords: telnet TWG Bridge BSD4.3 In article <109@quick.UUCP> srg@quick.UUCP (Spencer Garrett) writes: > You hit > The Bridge box sends \r\n You said this twice in your message without justifying it. The key is labeled RETURN, which is generally taken to be a synonym for CR. The TELNET spec says that CR should be represented in NETASCII as CRNUL. Why should the Bridge box assume that CR is NEWLINE? > telnetd converts \r\n to \n and feeds it to the pty > telnet reads \n from its tty (pseudo-tty, but it shouldn't matter) > telnet sends \r\n through its tcp stream to the vax > the vax should convert \r\n to whatever it wants for EOL What if the program on the VAX wants to see the raw characters that the user typed, which happens in programs such as EMACS? This means that if the user types CR it will get translated into the VAX's EOL sequence, and the program may not see the CR that the user typed. Your scenario only works if the remote system is in line-at-a-time mode. The reason for all the confusion that the TELNET spec has caused is that NETASCII is used for more than terminal emulation. It is used in FTP, for example, to support the control connection and text-mode file transfers. In these cases, things like End-of-Line have much more obvious meaning, or at least the need for a standard representation is obvious (some systems use a character sequence to indicate newline, others use a record structure). In terminal emulation, whether the RETURN key indicates End-of-Line is totally context dependent. In EMACS I can map any key to any operation, and I don't want the network to transform my keyboard for me. --- Barry Margolin Thinking Machines Corp. barmar@think.com seismo!think!barmar ----MESSAGE-END---- ----MESSAGE-BEGIN---- [579@btnix.axion.bt.co.uk] <1987081014340400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: titley@btnix.axion.bt.co.uk (Nigel Titley) Newsgroups: comp.protocols.tcp-ip Subject: Re: fyi Wollongong TCP/IP for VAX/VMS - Reply to Mark Crispin Message-ID: <579@btnix.axion.bt.co.uk> Date: Mon, 10-Aug-87 18:34:04 EDT Article-I.D.: btnix.579 Posted: Mon Aug 10 18:34:04 1987 Date-Received: Fri, 14-Aug-87 01:43:59 EDT References: <3910002@hpindda.HP.COM> Organization: British Telecom Research Labs, Martlesham Heath, IPSWICH, UK Lines: 9 The latest release of Woolongong TCP/IP may well be bug free but at 5000 pounds per VaxStation (the price we were quoted by GEC who distribute it over here in the UK), it's not likely that we're going for it in a hurry. For comparison the VaxStation sells for about 4000 pounds. -- Email: NTitley@axion.bt.co.uk Snail: British Telecom Research labs, Martlesham Heath, Ipswich, Suffolk, UK "I do not care what happens now: I have seen dragons on the wings of morning" ----MESSAGE-END---- ----MESSAGE-BEGIN---- [719@gargoyle.UChicago.EDU] <1987081016151000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: chris@gargoyle.UChicago.EDU (Chris Johnston) Newsgroups: comp.protocols.tcp-ip Subject: Re: How do you break up a B class number? Message-ID: <719@gargoyle.UChicago.EDU> Date: Mon, 10-Aug-87 20:15:10 EDT Article-I.D.: gargoyle.719 Posted: Mon Aug 10 20:15:10 1987 Date-Received: Wed, 12-Aug-87 00:47:33 EDT References: <8707271742.AA26964@hi> Reply-To: chris@gargoyle.uchicago.edu.UUCP (Chris Johnston) Distribution: world Organization: U of Chicago - Computer Science Lines: 29 > [paraphrased] we intend to put around 1000 hosts on our backbone. This has got to be a big lose. I can think of all kinds of problems... And never mind whether or not one segment can support all that traffic. Each of the hosts connected to our backbone is a gateway. Our backbone is implemented with fiber optics rather than coax. By isolating the major segments of our net behind gateways, we isolate broken subnets from the rest of the world. Subnets get broken in an amazing number of ways. Electrician/plumber/carpenter walks near the cable. Professor unplugs the two thin ethernet cables from the back of his workstation to rearrange his furniture (no thin coax in this dept.) Technician makes a lousy tap and shorts out the segment. Technician disconnects the 50 ohm terminator to put an oscilloscope on the cable (!!!). The fiber discourages people from making unauthorized taps and is small enough to be secured out of the way of most harm. Breaking the net into reasonably small segments is a major debugging assist. Of course we are limited to a single protocol (TCP/IP), but since we want to talk to the rest of the planet we have no choice. And one can always pull another pair of fiber and run other protocols on it. cj ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987081017440000> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Mon 10 Aug 87 09:34:54-PDT Received: from VM1.TAU.AC.IL by wiscvm.wisc.edu ; Mon, 10 Aug 87 11:35:14 CDT Received: by TAUNIVM (Mailer X1.24) id 5167; Mon, 10 Aug 87 14:19:46 IST Date: Mon, 10 Aug 87 14:14 IST From: Hank Nussbacher Subject: VMS and X.25 To: Reply-To: Hank Nussbacher I have been looking at various VMS and microVMS solutions for Tcp/Ip (Excelan, Interlan-Micom, Wollongong, SRI, Hyperlink, etc.) and all of them assume an Ethernet. How do sites connect lone VMS systems that are geographically scattered over many kilometers? The expensive solution is to build a 1 meter Ethernet, buy a bridge and connect that way. Do any of these systems handle X.25? What h/w do you need to buy? Will the Excelan and Interlan solutions work with an X.25 card or can an X.25 solution only be handled by a strictly software implementation (like Wollongong or Hyperlink)? Is there a way to do it with a leased line without Ethernet or a bridge? Thanks, Hank P.S. Plz send all replies directly to me. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [2837@phri.UUCP] <1987081018242100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: roy@phri.UUCP (Roy Smith) Newsgroups: comp.protocols.tcp-ip Subject: Blue Book Message-ID: <2837@phri.UUCP> Date: Mon, 10-Aug-87 22:24:21 EDT Article-I.D.: phri.2837 Posted: Mon Aug 10 22:24:21 1987 Date-Received: Thu, 13-Aug-87 00:43:24 EDT References: <12323617830.139.SY.KEN@CU20B.COLUMBIA.EDU> <870804093337.8.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Reply-To: roy@phri.UUCP (Roy Smith) Distribution: world Organization: Public Health Research Inst. (NY, NY) Lines: 8 I keep seeing references to "The Blue Book". What, exactly, is that? I have a small (about the size of the 11/45 hardware manual) blue-covered paperback book that DEC put out a few years back called something like "Introduction to Local Area Networks". Is that "The Blue Book"? -- Roy Smith, {allegra,cmcl2,philabs}!phri!roy System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708110359.AA17570@ucbvax.Berkeley.EDU] <1987081018580000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: BEAME@MCMASTER.BITNET Newsgroups: comp.protocols.tcp-ip Subject: Re: TELNET Message-ID: <8708110359.AA17570@ucbvax.Berkeley.EDU> Date: Mon, 10-Aug-87 22:58:00 EDT Article-I.D.: ucbvax.8708110359.AA17570 Posted: Mon Aug 10 22:58:00 1987 Date-Received: Wed, 12-Aug-87 01:58:10 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 21 When I was converting my PC VT100 emulator to run TELNET TCP/IP, I found myself with a problem. My emulator allows the user to define ANY key to mean ANYTHING. Therefore the big key with the arrow ( <-- ) on it did not always mean the End-Of-Line character. What should I send when it was hit ? Though it violated the spec. I decided not to have an EOL key, but to send exactly what the user requested when he defined the keyboard. The normal mapping had go to and go to , no conversion was done. GUESS WHAT !!!! When running to BSD 4.2/4.3, TWG, Ultrix 1.2, KNET and Bridge CS/100's to VMS vaxen and an IBM 7171, EVERYTHING worked. The VMS vax recognised the as a on a terminal and the as delete the last word. BSD and Ultrix had no problems in determining what was meant by the user. Could this not be an interm solution till all is well (assuming all is not considered well now) ? Carl Beame BEAME@MCMASTER.BITNET ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987081018580001> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Mon 10 Aug 87 20:41:17-PDT Received: from MCMASTER.BITNET by wiscvm.wisc.edu ; Mon, 10 Aug 87 22:00:24 CDT Date: Mon, 10 Aug 87 22:58 EDT From: Subject: Re: TELNET To: tcp-ip@sri-nic.arpa X-Original-To: tcp-ip@sri-nic.arpa, BEAME When I was converting my PC VT100 emulator to run TELNET TCP/IP, I found myself with a problem. My emulator allows the user to define ANY key to mean ANYTHING. Therefore the big key with the arrow ( <-- ) on it did not always mean the End-Of-Line character. What should I send when it was hit ? Though it violated the spec. I decided not to have an EOL key, but to send exactly what the user requested when he defined the keyboard. The normal mapping had go to and go to , no conversion was done. GUESS WHAT !!!! When running to BSD 4.2/4.3, TWG, Ultrix 1.2, KNET and Bridge CS/100's to VMS vaxen and an IBM 7171, EVERYTHING worked. The VMS vax recognised the as a on a terminal and the as delete the last word. BSD and Ultrix had no problems in determining what was meant by the user. Could this not be an interm solution till all is well (assuming all is not considered well now) ? Carl Beame BEAME@MCMASTER.BITNET ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12325520704.139.SY.KEN@CU20B.COLUMBIA.EDU] <1987081019072300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: sy.Ken@CU20B.COLUMBIA.EDU (Ken Rossman) Newsgroups: comp.protocols.tcp-ip Subject: Re: IBM TCP. Message-ID: <12325520704.139.SY.KEN@CU20B.COLUMBIA.EDU> Date: Mon, 10-Aug-87 23:07:23 EDT Article-I.D.: CU20B.12325520704.139.SY.KEN Posted: Mon Aug 10 23:07:23 1987 Date-Received: Wed, 12-Aug-87 01:49:41 EDT References: <8708081502.AA09066@columbia.edu> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 23 Herewith the DECnet Ethernet address for node 19.53, aka 19509:: AA-00-03-01-10-E7 I'm afraid I fail to see where you get AA-00-03-01-10-E7 from 19.53. First of all, the DECnet-transformed ethernet address should start with AA-00-04-00. Secondly, the last two octets of the DECnet/ethernet address is the 16 bit DECnet node number, which consists of 6 high order bits of area, and 10 low order bits of node number. The bytes are swapped also. So in the above example, if you take the last two bytes, 10 and E7, swap them to get E710, and then break them down to 6 and 10 bit groups, you get: 111001 1100010000 (area) (node num) or, node 57.784. This ethernet address was probably still the original hardware address before DECnet got ahold of it and mangled it. /Ken ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12325522493.139.SY.KEN@CU20B.COLUMBIA.EDU] <1987081019171300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: sy.Ken@CU20B.COLUMBIA.EDU (Ken Rossman) Newsgroups: comp.protocols.tcp-ip Subject: Re: IBM TCP. Really DECnet and Ethernet addresses Message-ID: <12325522493.139.SY.KEN@CU20B.COLUMBIA.EDU> Date: Mon, 10-Aug-87 23:17:13 EDT Article-I.D.: CU20B.12325522493.139.SY.KEN Posted: Mon Aug 10 23:17:13 1987 Date-Received: Wed, 12-Aug-87 02:02:46 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 26 "A station's physical address should be distinct from the physical address of any other station on @i(any) Ethernet." The italics are in the book. Time marches on... standards change... It would seem to me that it would be hopelessly difficult to try to administer a flat global set of ethernet addresses, and that some sort of mechanism, such as the global/local bits at the beginning would have to exist. In any case, regardless of how a spec says it SHOULD be, the real world appears to be allocating blocks of ethernet addresses to vendors to be used as they (or their customers) see fit. Along slightly different lines, I fail to see how the global ethernet addressing scheme, whether managed as a flat address space or in some hierarchical fashion, hasn't blown up yet. I mean there just aren't that many addresses available. Just as an isolated example, what happens to ethernet addresses on failing boards? We've probably had the ethernet board on one of our -20's replaced three times already. Am I to believe that DEC Field Service records these hardware addresses, and when bad boards come back that can't be repaired, they tell some global address administrator that this particular hardware address has now been freed and can be used again? /Ken ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12325530286.154.A.ERIC@GSB-HOW.Stanford.EDU] <1987081020000100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: A.Eric@GSB-HOW.STANFORD.EDU (Eric M. Berg) Newsgroups: comp.protocols.tcp-ip Subject: Mailing to DEC Easynet Message-ID: <12325530286.154.A.ERIC@GSB-HOW.Stanford.EDU> Date: Tue, 11-Aug-87 00:00:01 EDT Article-I.D.: GSB-HOW.12325530286.154.A.ERIC Posted: Tue Aug 11 00:00:01 1987 Date-Received: Wed, 12-Aug-87 02:27:29 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 27 [My apologies for posting this to the entire list, but the return-address on the original message (umnd-cs!umn-cs!haque@ucbvax.Berkeley.EDU) didn't work.] DEC's internal network (called "Easynet") is connected to the Internet via host DECWRL.DEC.COM (which is also a UUCP backbone node). The syntax is user%host.dec@decwrl.dec.com You need to get the name of the Easynet host, and the user-name of the person you want. (Often user-names seem to consist of the first two character of the person's first name appended to their last name... so I'd be "BergEr".) It's helpful to know that DEC Easynet nodes seem to have two different names each: a DECnet node name, and an internet-style name. So, for example, most of the Santa Clara office sales people have accounts on "USWRSL.DEC.COM" ("US Western Region SaLes", as close as I can guess), which is also known as "RHEA" (DECnet node name). You can try sending mail to Postmaster@DECWRL.DEC.COM... I've found the people there to be very helpful in sorting this stuff out. Eric M. Berg Computer Facility Graduate School of Business Stanford University ------- ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12325577808.12.JTW@XX.LCS.MIT.EDU] <1987081100210400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JTW@XX.LCS.MIT.EDU (John T. Wroclawski) Newsgroups: comp.protocols.tcp-ip Subject: Re: telnet CR processing, bridge comm servers and TWG telnet Message-ID: <12325577808.12.JTW@XX.LCS.MIT.EDU> Date: Tue, 11-Aug-87 04:21:04 EDT Article-I.D.: XX.12325577808.12.JTW Posted: Tue Aug 11 04:21:04 1987 Date-Received: Wed, 12-Aug-87 05:28:00 EDT References: <7419@think.UUCP> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 37 Summary: Chuck Hedrick's recent letter hit the nail on the head. From: barmar@think.com (Barry Margolin) Subject: Re: telnet CR processing, bridge comm servers and TWG telnet In article <109@quick.UUCP> srg@quick.UUCP (Spencer Garrett) writes: > You hit > The Bridge box sends \r\n You said this twice in your message without justifying it. The key is labeled RETURN, which is generally taken to be a synonym for CR. The TELNET spec says that CR should be represented in NETASCII as CRNUL. Why should the Bridge box assume that CR is NEWLINE? Because it is the character most often sent by the key that most people using terminals likely to be hooked to Bridge boxes use for EOL, and you have to have some way to send a NEWLINE. However, it doesn't really matter -what- the bridge box sends. The only thing that matters is that the terminal<->NETASCII<->machine transformation be invisible. For unix-like systems this is easily achieved by having the server telnet translate incoming CR-LF and CR-NUL to CR, and incoming LF to LF. This result is then stuffed into the PTY, where normal terminal processing (CRMOD) takes care of the rest, including your objection below. (Which -is- a problem if CR-LF translates to LF, as Spencer suggested.) > telnetd converts \r\n to \n and feeds it to the pty > telnet reads \n from its tty (pseudo-tty, but it shouldn't matter) > telnet sends \r\n through its tcp stream to the vax > the vax should convert \r\n to whatever it wants for EOL What if the program on the VAX wants to see the raw characters that the user typed, which happens in programs such as EMACS?... ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708111329.AA25694@ucbvax.Berkeley.EDU] <1987081104560000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: SYSTEM@CRNLNS.BITNET Newsgroups: comp.protocols.tcp-ip Subject: DECnet Ethernet interface addresses (was Re: IBM TCP) Message-ID: <8708111329.AA25694@ucbvax.Berkeley.EDU> Date: Tue, 11-Aug-87 08:56:00 EDT Article-I.D.: ucbvax.8708111329.AA25694 Posted: Tue Aug 11 08:56:00 1987 Date-Received: Thu, 13-Aug-87 01:36:30 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 42 Ken, In message <12325520704.139.SY.KEN@CU20B.COLUMBIA.EDU> you commented: >I'm afraid I fail to see where you get AA-00-03-01-10-E7 from 19.53. >... >or, node 57.784. Well, I'm afraid I didn't get it: DECnet did. I guess it doesn't use your algorithm. Herewith the Ethernet address used by the same node with the same hardware interface after I changed its address to be 43.298 = 44330 decimal (1024*43+298). (We are in the process of vacating area 19 so someone else can use it.) The following report was generated by the command "MCR NCP SHOW KNOWN LINE CHARACTERISTICS" Known Line Volatile Characteristics as of 11-AUG-1987 08:38:42 Line = UNA-0 Receive buffers = 6 Controller = normal Protocol = Ethernet Service timer = 4000 Hardware address = AA-00-03-01-1D-E7 UNA device buffer size = 1498 I hope this helps. Selden E. Ball, Jr. (Wilson Lab's network and system manager) Cornell University NYNEX: +1-607-255-0688 Laboratory of Nuclear Studies BITNET: SYSTEM@CRNLNS Wilson Synchrotron Lab ARPA: SYSTEM%CRNLNS.BITNET@WISCVM.WISC.EDU Judd Falls & Dryden Road PHYSnet/HEPnet/SPAN: Ithaca, NY, USA 14853 LNS61::SYSTEM = 44283::SYSTEM (node 43.251) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987081104560001> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Tue 11 Aug 87 06:13:45-PDT Received: from CRNLNS.BITNET by wiscvm.wisc.edu ; Tue, 11 Aug 87 07:52:58 CDT Date: Tue, 11 Aug 87 08:56 EDT From: Subject: DECnet Ethernet interface addresses (was Re: IBM TCP) To: TCP-IP@SRI-NIC.ARPA X-Original-To: SY.KEN@CU20B.COLUMBIA.EDU,TCP-IP@SRI-NIC.ARPA, SYSTEM Ken, In message <12325520704.139.SY.KEN@CU20B.COLUMBIA.EDU> you commented: >I'm afraid I fail to see where you get AA-00-03-01-10-E7 from 19.53. >... >or, node 57.784. Well, I'm afraid I didn't get it: DECnet did. I guess it doesn't use your algorithm. Herewith the Ethernet address used by the same node with the same hardware interface after I changed its address to be 43.298 = 44330 decimal (1024*43+298). (We are in the process of vacating area 19 so someone else can use it.) The following report was generated by the command "MCR NCP SHOW KNOWN LINE CHARACTERISTICS" Known Line Volatile Characteristics as of 11-AUG-1987 08:38:42 Line = UNA-0 Receive buffers = 6 Controller = normal Protocol = Ethernet Service timer = 4000 Hardware address = AA-00-03-01-1D-E7 UNA device buffer size = 1498 I hope this helps. Selden E. Ball, Jr. (Wilson Lab's network and system manager) Cornell University NYNEX: +1-607-255-0688 Laboratory of Nuclear Studies BITNET: SYSTEM@CRNLNS Wilson Synchrotron Lab ARPA: SYSTEM%CRNLNS.BITNET@WISCVM.WISC.EDU Judd Falls & Dryden Road PHYSnet/HEPnet/SPAN: Ithaca, NY, USA 14853 LNS61::SYSTEM = 44283::SYSTEM (node 43.251) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987081105460000> Received: from acc.arpa by SRI-NIC.ARPA with TCP; Tue 11 Aug 87 13:49:59-PDT Date: 11 Aug 87 13:46:00 PST From: Subject: Ethernet Address Space To: "sy.ken" cc: tcp-ip@sri-nic.arpa,art Reply-To: >It would seem to me that it would be hopelessly difficult to try to >administer a flat global set of ethernet addresses, and that some sort of >mechanism, such as the global/local bits at the beginning would have to >exist. In any case, regardless of how a spec says it SHOULD be, the real >world appears to be allocating blocks of ethernet addresses to vendors to >be used as they (or their customers) see fit. Vendors are ASSIGNED blocks of addresses which they are responsible for assigning to their interface boards. When a block is exhausted, another can be acquired (from Xerox originally, IEEE now). DEC is one of the few I know of that has more than on assigned block (SUN probably does by now). >Along slightly different lines, I fail to see how the global ethernet >addressing scheme, whether managed as a flat address space or in some >hierarchical fashion, hasn't blown up yet. I mean there just aren't that >many addresses available. Just as an isolated example, what happens to >ethernet addresses on failing boards? We've probably had the ethernet >board on one of our -20's replaced three times already. Am I to believe >that DEC Field Service records these hardware addresses, and when bad >boards come back that can't be repaired, they tell some global address >administrator that this particular hardware address has now been freed and >can be used again? I don't think that this is a problem yet. The Ethernet addresses are 48 bits long, minus one or two for format flags. This still leaves roughly 64 TRILLION possibilities. Even if the address space is only 0.01% utilized, that leaves roughly 6 BILLION Ethernet interfaces. Art Berggreen art@acc.arpa ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708111351.AA10668@roundhouse.sunuk.uucp] <1987081105513300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: kluger@roundhouse.UUCP (Larry Kluger Sun Europe) Newsgroups: comp.protocols.tcp-ip Subject: Ethernet addresses Message-ID: <8708111351.AA10668@roundhouse.sunuk.uucp> Date: Tue, 11-Aug-87 09:51:33 EDT Article-I.D.: roundhou.8708111351.AA10668 Posted: Tue Aug 11 09:51:33 1987 Date-Received: Thu, 13-Aug-87 02:12:51 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 133 Hi, I've been watching this discussion go for a couple days now and have found the mis-communications between people of this distribution list (who are all communications 'experts') quite interesting. Let me take a whack at a few points. First, brief personal background: I was in charge of the internetwork routing software for XNS at Xerox Palo Alto from mid '81 through '86. I didn't design the stuff, Yogen Dalal, Hal Murray, Dave Boggs, Larry Garlick, Alan Freier, and others did that. But I had lots of discussions with those folks over the years on the subject of "why it was done that way." ---------- First, addressing uniqueness. Alto's used the 3 MBit Ethernet which had 8 bit addressing at the link level. Everytime you installed an Alto, the tech had to open the machine and futz with the 8 jumpers which set the binary address to be 0-255. Except that it couldn't be either 0 or 255 for various reasons. It was decided that this was a real pain. And so in the Dec/Intel/Xerox Ethernet spec, 48 bits are used for the link level addressing. Let's be clear about the functionality that is desired: the idea is that people would be able to purchase a computer, plug it into the "Information Outlet" and be all set. No jumpers, no configuration, no nothing. Any magic bits can be taken care of by administrators at a central location. Through the power of broadcasting and multicasting, I claim that you NEVER need to type in special numbers at the keyboard of your new computer. All of that can and should be done over the network. What is now known as ARP and RARP play a big part in that of course. Unfortunately, DEC decided to do it their way--you have to tell the DecNet machines their node and area, then they change their Ethernet address as was discussed, etc. Put me down as someone who doesn't like or understand Dec's methodology in this regard. But remember that I work for a competitor of Dec's, namely Sun Microsystems. I'm encouraged by the messages which indicate that Dec may change this in the next release Phase of DecNet. ------------ "Having globally unique addresses can really mess up MAC level bridges." I found that mail message interesting because a) the writer raised a very valid point that I hadn't thought of before and b) the writer then went on to suggest the WRONG (I feel) solution to the problem. I feel that the correct answer is to not use Mac-level bridges. I don't really want to bring back the bridge vs anti-bridge discussions, but I will make the comment that I'm sure that no one in the late 70's and early 80's who was working on the Ethernet spec ever thought that people would actually build boxes that tried to see every packet, do the 'right' thing with it, and then try to make the whole affair invisible to the source and destination machines. Why don't people use internetworking for their internetworks? -------------- Assigning Ethernet addresses. When I left Xerox in March of 1986, all 'magic number' assignments were still be handled by Xerox. This included type numbers at the Ethernet level, 48 bit Ethernet source/destination, XNS network numbers, etc. You can reach those people at "Network Administration Office, Xerox Corp, 3333 Coyote Hill Road, Palo Alto CA 94304, USA" AA-00-04 was assigned to Digital. So were some other blocks. Digital uses the other blocks when burning proms for their machines. Xerox gave itself several blocks also. One interesting block they gave themselves is the 00-00-00 block. This is used with old Dolphins. There's an interesting story there, ask me about it (in person) some time. ---------------------- Someone asked if 48 bits is enough. The short answer is yes. For more information, see the paper by Bob Printis. My copy is at home so I can't give you the full citation. Bob presented it at a conference in Mexico City in the early 80's. The paper explains why 48 bits is enough. With respect to the question about manufacturers 'using up' the numbers through various bad practices, two comments: a) Manufacturers are asked to use the 48 bit numbers that they are assigned 'densely.' They are NOT to use them as serial numbers, etc. Most manufacturers are pretty good about this. If a manufacturer wants, Xerox will even sell them a batch of id proms with the ids burned in the proms in sequential order. (At least that's the idea...) b) It is in manufacturers' interest to swap the id prom with the new and old FRU (Field Replaceable Unit) (usually circuit board) when fixing their computers. Because 1) it's the 'right' thing to do and 2) if the manufacturer has their computer system set up so that *everything* depends on the 48-bit number (remember that this is the 'right' thing to do) then the manufacturer wants to save their customers the pain of changing anything merely because some hardware failed. Somewhere there's even a recommendation that manufacturers put the id prom in a socket rather than soldering it to the board for EXACTLY this reason. By the way, Sun Microsystems instructs its service engineers to swap the ID proms when replacing FRU's that contain ID proms. If Dec doesn't do this than that's their problem (and their customers...). But my guess is that the Dec people really are swapping the proms, it might not have been noticed since it doesn't take much time to do. ------------- Version of the Ethernet spec. The current version is Version 2.0. Dated November, 1982. Copies of version 1 should be treasured, but not referred to. "Local addresses" This is not part of the Ethernet spec, neither version 1 or 2. I believe that it was added by the IEEE 802.2/802.3 committees in their infinite wisdom. I don't know what the rationale is, but in any case I don't agree with it. People who want to have to tamper with every single workstation that is added to a site (rather than changing one or two mapping tables somewhere) should not be allowed out of their computer rooms. Think about a common electric typewriter--the vendor supplies it, it is placed on the user's desk, plugged in, and away you go. The idea of Ethernet was to extend that simple 'plug and play' model to comunicating computers. Regards, Larry Kluger European Data Communications Consultant Sun Microsystems Europe lkluger@sun.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [2828@psuvax1.psu.edu] <1987081106223300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ehrlich@psuvax1.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: Blue Book Message-ID: <2828@psuvax1.psu.edu> Date: Tue, 11-Aug-87 10:22:33 EDT Article-I.D.: psuvax1.2828 Posted: Tue Aug 11 10:22:33 1987 Date-Received: Thu, 13-Aug-87 01:21:45 EDT References: <12323617830.139.SY.KEN@CU20B.COLUMBIA.EDU> <870804093337.8.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> <2837@phri.UUCP> Reply-To: ehrlich@psuvax1.psu.edu (Dan Ehrlich) Distribution: world Organization: Penn State University, University Park, PA Lines: 14 Keywords: ethernet, blue book, DIX In article <2837@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: >I keep seeing references to "The Blue Book". What, exactly, is that? I The "Blue Book" is the ethernet spcefication published by DEC, Intel, and XEROX. It's correct title is "The Ethernet; A Local Area Network, Data Link Layer and Physical Layer Specifications" The latest copy I have is dated November 1982 and reflects version 2.0 of the specification. -- --Dan Ehrlich The Pennsylvania State University, Computer Science Department 333 Whitmore Laboratory, University Park, PA 16802 +1 814 863 1142 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987081106341000> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Tue 11 Aug 87 00:14:18-PDT Received: by ucbvax.Berkeley.EDU (5.58/1.27) id AA20839; Tue, 11 Aug 87 00:05:11 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 Aug 87 06:34:10 GMT From: soliloquy.rutgers.edu!dpz@RUTGERS.EDU (David P. Zimmerman) Organization: Rutgers Univ., New Brunswick, N.J. Subject: Re: RFS vs NFS Message-Id: <934@soliloquy.rutgers.edu> References: <3681e98d.b8ab@apollo.uucp>, <3537@cit-vax.Caltech.Edu>, <929@soliloquy.rutgers.edu> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa In article <929@soliloquy.rutgers.edu> I blurted: > > The claim of statelessness should not be taken too literally. When one > ... > > before the crash. Talk about some confused clients... > > Sun's ND (one of the weirdest beasts around) isn't stateless, you > can't use that as an example in this case. And of course he wasn't using it as an example. Sorry about that. What he was decribing sounded like the typical ND problem of modifying a client's root partition on the server while the client was still up, and I misinterpreted his statement as meaning that. (ND still rots, though. At least we don't have to worry about an ND /pub here anymore...) dpz -- David P. Zimmerman rutgers!dpz dpz@rutgers.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [870811103840.1.DCP@KOYAANISQATSI.S4CC.Symbolics.COM] <1987081106380000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer) Newsgroups: comp.protocols.tcp-ip Subject: Re: IBM TCP. Really DECnet and Ethernet addresses Message-ID: <870811103840.1.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Date: Tue, 11-Aug-87 10:38:00 EDT Article-I.D.: KOYAANIS.870811103840.1.DCP Posted: Tue Aug 11 10:38:00 1987 Date-Received: Thu, 13-Aug-87 02:13:40 EDT References: <12325522493.139.SY.KEN@CU20B.COLUMBIA.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 23 There are a lot more Ethernet addresses than Internet addresses, and I don't hear people screaming (yet) that we're running out of Internet addresses. (I do remember screaming that there weren't enough class A subnets, and later screaming that we had to be careful about doling out class B and C addresses because of fixed-size non-replacable tables in some older gateway implementations. Anyway...) The V1.0 Ethernet allowed for 2^23 vendors. That's 8 million vendors. Each vendor gets 2^24 addresses. That's 16 million addresses. It's conceivable that a vendor could run out of addresses, and my solution would be to give the vendor another (or several more) chunks of 2^24 addresses. Even if every person on the planet (about 2^32 people) had 64 machines (2^6) and got a new address for each machine every year, the Ethernet address space (2^47) allows for 2^(47-32-6) = 2^9 = 512 years of such (farfetched) activity. This is why the addressing hasn't "blown up yet," to use your phrase. There is therefore no need to recycle hardware addresses if a particular board (e.g., your DEC-20's) is unfixable. As for your DEC-20 board, replacing a board and/or changing an Ethernet hardware address for a host works pretty well if you use a dynamic protocol->hardware address translation mechanism such as ARP. The minor problem being the transition time until the hosts learn of the new address, and this problem is discussed in the RFC. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708111543.AA27571@ucbvax.Berkeley.EDU] <1987081107224900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PADLIPSKY@A.ISI.EDU (Michael Padlipsky) Newsgroups: comp.protocols.tcp-ip Subject: Re: No echo from the NIC Message-ID: <8708111543.AA27571@ucbvax.Berkeley.EDU> Date: Tue, 11-Aug-87 11:22:49 EDT Article-I.D.: ucbvax.8708111543.AA27571 Posted: Tue Aug 11 11:22:49 1987 Date-Received: Thu, 13-Aug-87 02:14:49 EDT References: Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 15 OH DEAR!!!!! I'm even more appalled to report on the resolution of yesterday's mystery about the "My NCP Costs $500 a Day" RFC: Through the good offices of Marlyn Johnson at the NIC, I've learned that there was indeed such an RFC (425, actually) but the reason I didn't spot it was that I was looking for ones by me and it (gasp, shudder, eek) wasn't by me after all. Could have sworn if was one of mine, but it turns out to have been by Bob Bressler--and addresses the general problem of too many Hosts having gotten into the habit even then (late '72) of doing "surveys," "probes," and the like. Oh, the forgetfulness of Early Middle Age.... abashed cheers, map ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987081107224901> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Tue 11 Aug 87 08:28:06-PDT Date: 11 Aug 1987 11:22:49 EDT Subject: Re: No echo from the NIC From: Michael Padlipsky To: Ken Pogran cc: "GBURG::ENGER" , "tcp-ip" , enger@BLUTO.SCC.COM In-Reply-To: (Message from "Ken Pogran " of Wed, 5 Aug 87 8:41:40 EDT) OH DEAR!!!!! I'm even more appalled to report on the resolution of yesterday's mystery about the "My NCP Costs $500 a Day" RFC: Through the good offices of Marlyn Johnson at the NIC, I've learned that there was indeed such an RFC (425, actually) but the reason I didn't spot it was that I was looking for ones by me and it (gasp, shudder, eek) wasn't by me after all. Could have sworn if was one of mine, but it turns out to have been by Bob Bressler--and addresses the general problem of too many Hosts having gotten into the habit even then (late '72) of doing "surveys," "probes," and the like. Oh, the forgetfulness of Early Middle Age.... abashed cheers, map ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [555699623.0.KASHTAN@IU.AI.SRI.COM] <1987081109002200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: KASHTAN@IU.AI.SRI.COM (David L. Kashtan) Newsgroups: comp.protocols.tcp-ip Subject: Re: VMS and X.25 Message-ID: <555699623.0.KASHTAN@IU.AI.SRI.COM> Date: Tue, 11-Aug-87 13:00:22 EDT Article-I.D.: IU.555699623.0.KASHTAN Posted: Tue Aug 11 13:00:22 1987 Date-Received: Thu, 13-Aug-87 04:06:50 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 12 > I have been looking at various VMS and microVMS solutions for Tcp/Ip > (Excelan, Interlan-Micom, Wollongong, SRI, Hyperlink, etc.) and all > of them assume an Ethernet.... I cannot speak for the rest of the VMS TCP implementations but I do know that SRI's (and probably Wollongong's) support many more devices than just Ethernet. You can get TCP over X.25 service using the ACC 5250/6250 board, which is supported by SRI's MultiNet. There are other possibilities as well: DMR-11s come to mind. David ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708111728.AA00583@akamai.isi.edu] <1987081109285400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jkrey@AKAMAI.ISI.EDU (Joyce Reynolds) Newsgroups: comp.protocols.tcp-ip Subject: Re: No echo from the NIC Message-ID: <8708111728.AA00583@akamai.isi.edu> Date: Tue, 11-Aug-87 13:28:54 EDT Article-I.D.: akamai.8708111728.AA00583 Posted: Tue Aug 11 13:28:54 1987 Date-Received: Thu, 13-Aug-87 04:41:53 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 10 Dear Interested Onlookers, re: RFC 1012 and the "But my NCP costs $500 a day..." Please see page 28 in RFC 1012 for the RFC... 425 - Bressler, Bob, "But my NCP costs $500 a day..", RFC 425 (NIC 13010), BBN, 19 December 1972. Joyce Reynolds ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708111749.AA05938@gyre.umd.edu] <1987081109494200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: chris@GYRE.UMD.EDU (Chris Torek) Newsgroups: comp.protocols.tcp-ip Subject: Re: telnet CR processing, bridge comm servers and TWG telnet Message-ID: <8708111749.AA05938@gyre.umd.edu> Date: Tue, 11-Aug-87 13:49:42 EDT Article-I.D.: gyre.8708111749.AA05938 Posted: Tue Aug 11 13:49:42 1987 Date-Received: Thu, 13-Aug-87 04:41:41 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 74 Why are things always more complicated than they need to be? Let us see what happens if we break this down carefully. First, telnet seems to assume that there is a User on a Terminal (possibly a Printing Terminal) who is connected, either directly or via modem, to a Host. This Host is connected to another Host via the Internet. Let us name these hosts to avoid confusion: the first will be Tachost, the second Usefulhost. Now as to cases: Usefulhost can try to print a line to User. To do so, it sends characters to Tachost, and then it sends an End Of Line. What is this End Of Line? It seems fairly well agreed that it is a CR plus an LF. To print this, should Usefulhost send or just ? Either should work, but the latter should be preferred. Tachost must arrange for either to produce the appropriate printhead or cursor motion. Usefulhost can also try to do fancy printhead motion (if our User is on a Printing Terminal), namely, `go back to the beginning of the line and get ready to overstrike' or `go down one line'; for these it should send and respectively. It is obvious that will move the printhead to the beginning of a new line, though possibly inefficiently, which is why we say is preferred. Now on the other hand, User may be trying to send a line to Usefulhost. Here the situation is murkier. User pushes keys for characters; upon these we agree: they are just plain ASCII. (Let us not consider binary EBCDIC, please!) But then User pushes a key marked ENTER. Or is it marked RETURN? Maybe LINE FEED? Or perhaps even NEWLINE. Just what key *is* this, anyway? I cannot speak for everyone, but all *my* terminals have a great big key marked RETURN. It sends . They also have an ordinary sized key marked LINE FEED, and it sends . But apparently there is at least one Tachost that has different terminals, with keys marked ENTER that send . The clear, obvious solution is to have Tachost send when a User types RETURN, when a User types LINE FEED, and when a user pushes an ENTER key that sends . Terminals with just one big ENTER key thus cannot send . Well, that is natural since they have no key for it. As long as the terminal has separate keys, though, it should be Tachost's job to send to Usefulhost exactly that key which was typed. Alas, telnet does not use the clear, obvious solution. It imposes on a User the very same protocol used for making a Terminal or Printer work. This is odd, for Users are not at all like Terminals and Printers, but we are stuck with it. At least it is symmetric---or is it? If Tachost can easily tell which key User typed, *I* say it should send that very key to Usefulhost. So (since we have this extra protocol in the way) let us define that Tachost is to send either or (it should not matter which) when User types RETURN, and when User types LINE FEED. If User types ENTER and Tachost cannot tell which was meant, let it again send either or . Note that in the Tachost->Usefulhost path, means RETURN, while on the Usefulhost->Tachost path, means NEW LINE. This is--- alas!---not symmetric, but is clearly necessary since many Tachosts already send when a User hits RETURN. Note also that is useless, since it means the same thing as ; nonetheless, it must be retained for compatibility, since other Tachosts already send when a User hits RETURN. Summary: End host should send for NEW LINE, for cursor-to-beginning-of-line, for cursor-down-without-return. Intermediate host should send or for RETURN, for LINE FEED. Neither host should ever send without immediately sending either or . Chris ----MESSAGE-END---- ----MESSAGE-BEGIN---- [870811154904.7.DCP@KOYAANISQATSI.S4CC.Symbolics.COM] <1987081111490000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer) Newsgroups: comp.protocols.tcp-ip Subject: Blue Book Message-ID: <870811154904.7.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Date: Tue, 11-Aug-87 15:49:00 EDT Article-I.D.: KOYAANIS.870811154904.7.DCP Posted: Tue Aug 11 15:49:00 1987 Date-Received: Thu, 13-Aug-87 05:48:11 EDT References: <2837@phri.UUCP> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 36 Date: 11 Aug 87 02:24:21 GMT From: phri!roy@nyu.arpa (Roy Smith) I keep seeing references to "The Blue Book". What, exactly, is that? I have a small (about the size of the 11/45 hardware manual) blue-covered paperback book that DEC put out a few years back called something like "Introduction to Local Area Networks". Is that "The Blue Book"? -- Roy Smith, {allegra,cmcl2,philabs}!phri!roy System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016 It's The Ethernet A Local Area Network Data Link Layer and Physical Layer Specifications DEC's Intel's Xerox's logo logo logo addresses...... for............ the............ above Version 1.0 September 30, 1980 has a blue cover and is 8.5"x11". I considered it the Ethernet Bible, but I'm apparently in error since there have been changes. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987081112023300> Received: from Xerox.COM by SRI-NIC.ARPA with TCP; Tue 11 Aug 87 19:04:06-PDT Received: from Cabernet.ms by ArpaGateway.ms ; 11 AUG 87 19:02:34 PDT Date: 11 Aug 87 19:02:33 PDT (Tuesday) Subject: Re: IBM TCP. Really DECnet and Ethernet addresses In-reply-to: <12325522493.139.SY.KEN@CU20B.COLUMBIA.EDU> To: Ken Rossman , David C. Plummer cc: Adam Hamilton , tcp-ip@SRI-NIC.ARPA, RMRichardson.PA@Xerox.COM From: Rich Line-fold: no Message-ID: <870811-190234-1391@Xerox> >I guess I'm hopelessly out of date. My copy of the Blue Book is Version >1.0, Sepetmber 30, 1980. In it, in section 6.2.1 on page 21, there is >no mention of this second bit being for local/global administration. In >fact, of the physical address it says > "A station's physical address should be distinct from the > physical address of any other station on @i(any) Ethernet." >The italics are in the book. Time marches on... standards change... I don't have a copy of the blue book, but the relevant section in IEEE 802.3 is 3.2.3 (with Fig 3-2) on pages 24, 25 of the IEEE book (green cover). > Along slightly different lines, I fail to see how the global > ethernet addressing scheme, whether managed as a flat address space > or in some hierarchical fashion, hasn't blown up yet. I mean there > just aren't that many addresses available. Just as an isolated > example, what happens to ethernet addresses on failing boards? > We've probably had the ethernet board on one of our -20's replaced > three times already. Am I to believe that DEC Field Service > records these hardware addresses, and when bad boards come back > that can't be repaired, they tell some global address administrator > that this particular hardware address has now been freed and can be > used again? Given that 2 of the 48 bits are used by the "flags," that leaves 2**46 addresses for ethernet devices. This is a large number that is hard to get hold of until one reduces it to reasonable. Conversion to a power of ten is a start: 7.036874e+13. Even 10**13 is a very large number to get hold of; lets suppose we can produce one thousand devices every second, round the clock, until the space is full. 7.036874e+13, /60 secs/min, /60 min/hour, /24 hours/day, and /365.25 days/year. 2229.851 years! Even the space allowed for a single manufacturer is 2**24 or about 16 million addresses. (And of course if some manufacturer fills out that space, the IEEE can allocate a second block of 16 million. :-) I don't know how DEC Field Service takes care of the problem of bad boards, but when we have to change the relevant board in one of the D-machines around here, we pull the PROM which contains the ethernet ID out of the old board and stick it in the replacement so our machine is as it always was to the ethernet. Only if you break the PROM do you get a new number and go through the pain of re-registering your machine on the net. Rich ----MESSAGE-END---- ----MESSAGE-BEGIN---- [2832@psuvax1.psu.edu] <1987081112243500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ehrlich@psuvax1.psu.edu (Dan Ehrlich) Newsgroups: comp.protocols.tcp-ip,comp.unix.wizards,comp.bugs.4bsd Subject: Trouble speaking SMTP to TOPS 20 (TWENEX) hosts Message-ID: <2832@psuvax1.psu.edu> Date: Tue, 11-Aug-87 16:24:35 EDT Article-I.D.: psuvax1.2832 Posted: Tue Aug 11 16:24:35 1987 Date-Received: Thu, 13-Aug-87 05:46:25 EDT Sender: ehrlich@psuvax1.psu.edu Reply-To: ehrlich@psuvax1.psu.edu (Dan Ehrlich) Distribution: world Organization: Penn State University, University Park, PA Lines: 14 Keywords: TOPS 20, TWENEX, SMTP My memory is fuzzy as to if this problem has been reported before or not. I vaguely remeber seeing something like this but cannot find anything in our old news files, so please excuse me if this is old hat. The VAXen here are running BSD 4.3 UNIX with all of the patches posted to comp.bugs.4bsd.ucb-fixes applied. Most of the time when we try to speak SMTP to a TOPS 20 (TWENEX) host sendmail ends up deffering with a "Bad file number" status. This situation never seems to correct itself and eventually the mail is returned to the originator. If my memory is correct on this and a fix has been posted for it I would appreciate getting a copy from anyone who has it. Thanks in advance. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987081113450200> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Tue 11 Aug 87 09:13:21-PDT Received: by ucbvax.Berkeley.EDU (5.58/1.27) id AA27756; Tue, 11 Aug 87 08:52:09 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 Aug 87 13:45:02 GMT From: super.upenn.edu!operations.dccs.upenn.edu!shaffer@RUTGERS.EDU (Earl Shaffer) Organization: University of Pennsylvania Subject: Wollongong WIN/TCP 3.1? Message-Id: <1736@super.upenn.edu> References: <27@abvax.icd.ab.com>, <109@quick.UUCP>, <1120@rtech.UUCP> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa I have heard rumors about 3.1 coming out. I think there is an address error that was found in 3.0. Does anyone know more about this? ============================================================================== Earl Shaffer - University of Pennsylvania - Data Communications Department "Time was invented so that everything wouldn't happen at once." Steven Wright ============================================================================== ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708112100.AA03752@ucbvax.Berkeley.EDU] <1987081113460000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: art@ACC.ARPA Newsgroups: comp.protocols.tcp-ip Subject: Ethernet Address Space Message-ID: <8708112100.AA03752@ucbvax.Berkeley.EDU> Date: Tue, 11-Aug-87 17:46:00 EDT Article-I.D.: ucbvax.8708112100.AA03752 Posted: Tue Aug 11 17:46:00 1987 Date-Received: Thu, 13-Aug-87 06:05:17 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Distribution: world Organization: The ARPA Internet Lines: 33 >It would seem to me that it would be hopelessly difficult to try to >administer a flat global set of ethernet addresses, and that some sort of >mechanism, such as the global/local bits at the beginning would have to >exist. In any case, regardless of how a spec says it SHOULD be, the real >world appears to be allocating blocks of ethernet addresses to vendors to >be used as they (or their customers) see fit. Vendors are ASSIGNED blocks of addresses which they are responsible for assigning to their interface boards. When a block is exhausted, another can be acquired (from Xerox originally, IEEE now). DEC is one of the few I know of that has more than on assigned block (SUN probably does by now). >Along slightly different lines, I fail to see how the global ethernet >addressing scheme, whether managed as a flat address space or in some >hierarchical fashion, hasn't blown up yet. I mean there just aren't that >many addresses available. Just as an isolated example, what happens to >ethernet addresses on failing boards? We've probably had the ethernet >board on one of our -20's replaced three times already. Am I to believe >that DEC Field Service records these hardware addresses, and when bad >boards come back that can't be repaired, they tell some global address >administrator that this particular hardware address has now been freed and >can be used again? I don't think that this is a problem yet. The Ethernet addresses are 48 bits long, minus one or two for format flags. This still leaves roughly 64 TRILLION possibilities. Even if the address space is only 0.01% utilized, that leaves roughly 6 BILLION Ethernet interfaces. Art Berggreen art@acc.arpa ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708112229.AA00510@apolling.imagen.uucp] <1987081114292100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: geof@apolling.UUCP (Geof Cooper) Newsgroups: comp.protocols.tcp-ip Subject: Re: Blue Book Message-ID: <8708112229.AA00510@apolling.imagen.uucp> Date: Tue, 11-Aug-87 18:29:21 EDT Article-I.D.: apolling.8708112229.AA00510 Posted: Tue Aug 11 18:29:21 1987 Date-Received: Thu, 13-Aug-87 06:53:58 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 31 > I keep seeing references to "The Blue Book". What, exactly, is that? The Ethernet A Local Area Network Data Link Layer and Physical Layer Specifications DEC, Intel, Xerox (all three logo's on the cover) Version 2.0 November, 1982 I got mine from Xerox. The address given for orders is: Xerox Corporation Office Systems Division Ethernet Literature Department 3450 Hillview Avenue Palo Alto, CA 94304 There is a net-mail address that would translate to "OSD-Pubs.pa@Xerox.com" these days. You can try that. The phone number listed is 415 494 5886. I suspect that these days the XNS institute handles such requests. - Geof PS: The cover IS blue on version 2. The cover of version 1 was gray with a blue stripe. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [721@gargoyle.UChicago.EDU] <1987081114553900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: chris@gargoyle.UChicago.EDU (Chris Johnston) Newsgroups: comp.protocols.tcp-ip,comp.unix.wizards,comp.bugs.4bsd Subject: Re: Trouble speaking SMTP to TOPS 20 (TWENEX) hosts Message-ID: <721@gargoyle.UChicago.EDU> Date: Tue, 11-Aug-87 18:55:39 EDT Article-I.D.: gargoyle.721 Posted: Tue Aug 11 18:55:39 1987 Date-Received: Thu, 13-Aug-87 06:29:30 EDT References: <2832@psuvax1.psu.edu> Reply-To: chris@gargoyle.uchicago.edu.UUCP (Chris Johnston) Distribution: world Organization: U of Chicago - Computer Science Lines: 12 Keywords: TOPS 20, TWENEX, SMTP Hi Dan, In order to get sendmail to speak smtp with a Dec-20 you have tell sendmail to use . (use the E flag) From sendmail.cf Mtcp, P=[IPC], F=mDFMueXLC, S=14, R=24, A=IPC $h, E=\r\n Mtcpld, P=[IPC], F=mDFMueXLC, S=17, R=27, A=IPC $h, E=\r\n cj ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708120213.AA09848@ucbvax.Berkeley.EDU] <1987081117505400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jch@OMNIGATE.CLARKSON.EDU (Jeffrey C Honig) Newsgroups: comp.protocols.tcp-ip Subject: Re: DECnet Ethernet interface addresses (was Re: IBM TCP) Message-ID: <8708120213.AA09848@ucbvax.Berkeley.EDU> Date: Tue, 11-Aug-87 21:50:54 EDT Article-I.D.: ucbvax.8708120213.AA09848 Posted: Tue Aug 11 21:50:54 1987 Date-Received: Thu, 13-Aug-87 07:08:54 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 19 >>I'm afraid I fail to see where you get AA-00-03-01-10-E7 from 19.53. >>... >>or, node 57.784. > >Well, I'm afraid I didn't get it: DECnet did. I guess it doesn't >use your algorithm. Actually, it does. >Hardware address = AA-00-03-01-1D-E7 What your 'ncp show line una-0 char' report is showing you is the hardware ethernet address before DECnet changes it. Try looking at an Ethernet monitor. If you are running TCP/IP on that host they try looking in the ARP cache of another host or router on that network for the Ethernet address that is actually being used. Jeff ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987081117505401> Received: from omnigate.clarkson.edu by SRI-NIC.ARPA with TCP; Tue 11 Aug 87 18:53:14-PDT Date: Tue, 11 Aug 87 21:50:54 EDT From: Jeffrey C Honig To: SYSTEM%CRNLNS.BITNET@wiscvm.wisc.edu cc: TCP-IP@sri-nic.arpa Subject: Re: DECnet Ethernet interface addresses (was Re: IBM TCP) >>I'm afraid I fail to see where you get AA-00-03-01-10-E7 from 19.53. >>... >>or, node 57.784. > >Well, I'm afraid I didn't get it: DECnet did. I guess it doesn't >use your algorithm. Actually, it does. >Hardware address = AA-00-03-01-1D-E7 What your 'ncp show line una-0 char' report is showing you is the hardware ethernet address before DECnet changes it. Try looking at an Ethernet monitor. If you are running TCP/IP on that host they try looking in the ARP cache of another host or router on that network for the Ethernet address that is actually being used. Jeff ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708120323.AA29496@okeeffe.Berkeley.EDU] <1987081119234800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: karels%okeeffe@UCBVAX.BERKELEY.EDU (Mike Karels) Newsgroups: comp.protocols.tcp-ip Subject: Re: Telnet, , etc. Message-ID: <8708120323.AA29496@okeeffe.Berkeley.EDU> Date: Tue, 11-Aug-87 23:23:48 EDT Article-I.D.: okeeffe.8708120323.AA29496 Posted: Tue Aug 11 23:23:48 1987 Date-Received: Fri, 14-Aug-87 00:39:21 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 36 Hey, folks, this discussion on telnet has gone much too far, and far astray. Let me summarize the actual problem, which is quite minor, its effect and the proposed modification to mitigate its effect. First, let me remind people that a real problem exists ONLY in the following circumstance: when a user connects by telnet from a host of a certain type (including Bridge terminal servers) to a 4.3BSD host, and THEN runs a program such as telnet that runs in character mode that distinguishes between and . This includes trying to telnet (or tip) from the 4.3BSD host to some other host that distinguishes between and . The problem occurs if the originating host sends when it receives a return from the terminal, and has no option to send instead. With such a combination of hosts and operations, an interoperability problem exists. In all other situations, things work correctly. All of the implementations involved are following the specification. There is a simple, straightforward patch to the 4.3BSD telnet server that mitigates this problem. While I agree with Greg Minshall's excellent summary of the 4.3BSD telnet implementation and rationale, we have both agreed that changing the telnet server in a pragmatic way will avoid this problem. An "official" Berkeley bug fix for 4.3 telnetd will be sent to the tcp-ip list soon and to the Usenet news group set up for official Berkeley fixes (comp.bugs.4bsd.ucb-fixes). I think that the lessons learned are that (1) protocol specifications that allow options for behavior may allow correct implementations that fail to interoperate (no big news here), and (2) the Telnet specification has some problems, especially in the area of character at a time mode versus line at a time mode (see Greg's excellent discussion), and it may need to specify different behavior in the server-to-client and client-to-server directions. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987081119340000> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Tue 11 Aug 87 15:45:23-PDT Received: by ucbvax.Berkeley.EDU (5.58/1.27) id AA05974; Tue, 11 Aug 87 15:42:34 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 Aug 87 19:34:00 GMT From: m2c!ulowell!apollo!rees@bu-cs.bu.edu (Jim Rees) Organization: Apollo Computer, Chelmsford, Mass. Subject: Re: RFS vs NFS Message-Id: <369c1516.b8ab@apollo.uucp> References: <3681e98d.b8ab@apollo.uucp>, <3537@cit-vax.Caltech.Edu>, <929@soliloquy.rutgers.edu> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa Sun's ND (one of the weirdest beasts around) isn't stateless, you can't use that as an example in this case. I don't think he was talking ND. NFS clients will get confused if the server's handles change, which they will if you mkfs and restore. The handles are some combination of inode number, device number, and sequence number. Some of this confusion could be lessened if you could guarantee that handles will never get re-used. This is the approach we took in our NFS server. Instead of inode numbers, objects are named by UID. The UID (Unique ID) is a combination of node number and timestamp, and is guaranteed unique, even if you mkfs and restore. We didn't invent the idea, it's a commonly used technique in more modern (than Unix) operating systems. With UIDs for handles, the clients at least don't mistake new objects for old ones, although they still can't find the ones they want. You could argue that this is correct behavior anyway, since when the files come back in off of tape, they probably aren't the same as they were immediately before the crash. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708120401.AA03055@sluggo.sun.com] <1987081120010300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: melohn@SUN.COM (Bill Melohn) Newsgroups: comp.protocols.tcp-ip Subject: Re: Mailing to DEC Easynet Message-ID: <8708120401.AA03055@sluggo.sun.com> Date: Wed, 12-Aug-87 00:01:03 EDT Article-I.D.: sluggo.8708120401.AA03055 Posted: Wed Aug 12 00:01:03 1987 Date-Received: Fri, 14-Aug-87 01:26:30 EDT References: <12325530286.154.A.ERIC@GSB-HOW.Stanford.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: sun!melohn (Bill Melohn) Distribution: world Organization: Sun Microsystems, Mountain View Lines: 16 In article <12325530286.154.A.ERIC@GSB-HOW.Stanford.EDU> A.Eric@GSB-HOW.STANFORD.EDU (Eric M. Berg) writes: >It's helpful to know that DEC Easynet nodes seem to have two different names >each: a DECnet node name, and an internet-style name. So, for example, most >of the Santa Clara office sales people have accounts on "USWRSL.DEC.COM" >("US Western Region SaLes", as close as I can guess), which is also known >as "RHEA" (DECnet node name). This is done (no suprise) by using the domain name server, which has an MX record defined for all of the valid DECNET node names in the DEC Enet. From the outside, you should be able to get to any DEC Enet node by sending to @.dec.com, assuming you run the nameserver. The node RHEA is merely a forwarding node in the internal chain between DECWRL and the rest of the DEC Enet. Domain names; there not just for IP anymore.. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987081121180000> Received: from Cs.Ucl.AC.UK by SRI-NIC.ARPA with TCP; Tue 11 Aug 87 18:22:08-PDT Received: from rsre.mod.uk by nss.Cs.Ucl.AC.UK via PSS with NIFTP id aa00747; 12 Aug 87 2:20 BST To: Roy Smith <@Cs.Ucl.AC.UK:phri!roy@nyu.arpa> Cc: tcp-ip <@Cs.Ucl.AC.UK:tcp-ip@sri-nic.arpa> From: John Laws (on UK.MOD.RSRE) Date: Wed, 12 Aug 87 02:18 In-reply-to: <2837@phri.UUCP> Message-Id: <12 AUG 1987 02:18:58 LAWS@RSRE> Subject: Re: Blue Book Roy, The Blue Book I know about is 'Network Independent File Transfer Protocol'. This is one of a series of protocols in the Rainbow Book series developed within the UK Joint Academic Network (JANET) more than 10 years ago. Red is Remote Job Entry, Green is Terminal, Grey is Mail. John Laws ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987081200110000> Mail-From: STJOHNS created at 12-Aug-87 07:15:57 Date: 12 Aug 1987 07:11-PDT Sender: STJOHNS@SRI-NIC.ARPA Subject: Re: VMS and X.25 From: STJOHNS@SRI-NIC.ARPA To: heker@JVNCA.CSC.ORG Cc: HANK%TAUNIVM.BITNET@WISCVM.WISC.EDU Cc: KASHTAN@IU.AI.SRI.COM, tcp-ip@SRI-NIC.ARPA Message-ID: <[SRI-NIC.ARPA]12-Aug-87 07:11:44.STJOHNS> In-Reply-To: <8708121248.AA15185@jvnca.csc.org> Sergio, the IETF would like to take you up on your offer of a place to hold an IETF meeting. The schedule we are looking for is to have a meeting at JVNC in late april/early may of 1988. Would this be possible for JVNC? Can you give me some idea of the number/sizes of conference rooms available and how far in advance we have to book them>? Thanks! Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987081200120000> Mail-From: STJOHNS created at 12-Aug-87 07:18:35 Date: 12 Aug 1987 07:12-PDT Sender: STJOHNS@SRI-NIC.ARPA Subject: Re: VMS and X.25 From: STJOHNS@SRI-NIC.ARPA To: heker@JVNCA.CSC.ORG Cc: HANK%TAUNIVM.BITNET@WISCVM.WISC.EDU Cc: KASHTAN@IU.AI.SRI.COM, tcp-ip@SRI-NIC.ARPA Message-ID: <[SRI-NIC.ARPA]12-Aug-87 07:12:55.STJOHNS> In-Reply-To: <8708121248.AA15185@jvnca.csc.org> Apologies, that one got away from me. *sigh* Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12.AUG.1987.02:18:58.LAWS@RSRE] <1987081201180000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: LAWS@rsre.mod.UK (John Laws, on UK.MOD.RSRE) Newsgroups: comp.protocols.tcp-ip Subject: Re: Blue Book Message-ID: <12.AUG.1987.02:18:58.LAWS@RSRE> Date: Wed, 12-Aug-87 05:18:00 EDT Article-I.D.: RSRE.12.AUG.1987.02:18:58.LAWS Posted: Wed Aug 12 05:18:00 1987 Date-Received: Thu, 13-Aug-87 07:09:29 EDT References: <2837@phri.UUCP> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 9 Roy, The Blue Book I know about is 'Network Independent File Transfer Protocol'. This is one of a series of protocols in the Rainbow Book series developed within the UK Joint Academic Network (JANET) more than 10 years ago. Red is Remote Job Entry, Green is Terminal, Grey is Mail. John Laws ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987081204221300> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Wed 12 Aug 87 03:46:20-PDT Received: by ucbvax.Berkeley.EDU (5.58/1.27) id AA16682; Wed, 12 Aug 87 03:41:45 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 12 Aug 87 04:22:13 GMT From: amdahl!unixprt!monkey@ames.arpa (Monkey Face@unixprt) Organization: uni-xperts - Unix System and Networking Consultants Subject: Re: RFS vs NFS Message-Id: <285@unixprt.UUCP> References: <649@houxa.UUCP>, <255@srs.UUCP>, <3537@cit-vax.Caltech.Edu> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa > The claim of statelessness should not be taken too literally. When one > of our disks got trashed (@*#% Xylogics!), we did the "obvious" thing - > we took the server down, created the filesystem afresh, restored all of > the backup tapes, and then let the clients continue where they left off > before the crash. Talk about some confused clients... > "Stateless" only means that the state is kept on disk rather than RAM. Also, NFS is implemented in a stateless manner, but the other network services that are provided are very state-full. Since NFS is really just a 'base' for file system services, extensions via servers et al, are and will continue to be state-full (i.e file locking). Several other network services will be state-full also. The above example is an interesting case when this approach falls a little short, although in general, for short periods of 'failure' it is very appropriate. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708121248.AA15185@jvnca.csc.org] <1987081204484700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: heker@JVNCA.CSC.ORG (Sergio Heker) Newsgroups: comp.protocols.tcp-ip Subject: Re: VMS and X.25 Message-ID: <8708121248.AA15185@jvnca.csc.org> Date: Wed, 12-Aug-87 08:48:47 EDT Article-I.D.: jvnca.8708121248.AA15185 Posted: Wed Aug 12 08:48:47 1987 Date-Received: Fri, 14-Aug-87 05:25:48 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 13 Hank, Wollongong definitely supports DMR11s ( we used to have 4 DMRs and a DEUNA on a VAX8600/VMS/WIMVX ), and I think you can connect an ACC/X.25 board to it as well. -- Sergio ----------------------------------------------------------------------------- Sergio Heker tel: (609) 520-2000 Internet: "heker@jvnca.csc.org" Bitnet: "heker@jvnc" JOHN VON NEUMANN NATIONAL SUPERCOMPUTER CENTER, JVNCnet Network Manager ----------------------------------------------------------------------------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [296@pvab.UUCP] <1987081204585600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: robert@pvab.UUCP (Robert Claeson) Newsgroups: comp.protocols.tcp-ip Subject: NFS for SCO Xenix Message-ID: <296@pvab.UUCP> Date: Wed, 12-Aug-87 08:58:56 EDT Article-I.D.: pvab.296 Posted: Wed Aug 12 08:58:56 1987 Date-Received: Sat, 15-Aug-87 01:20:34 EDT Reply-To: robert@pvab.UUCP (Robert Claeson) Distribution: world Organization: Statskonsult Programvaruhuset AB, Sweden Lines: 8 Is there a NFS implementation for IBM AT's running SCO Xenix System V? I know of Excelan's ethernet card and tcp/ip software, but there is no NFS (what I know, at least). -- SNAIL: Robert Claeson, PVAB, P.O. Box 4040, S-171 04 Solna, Sweden UUCP: {seismo,mcvax,munnari}!enea!pvab!robert ARPA: enea!pvab!robert@seismo.arpa ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708121406.AA04593@topaz.rutgers.edu] <1987081206064600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ron@TOPAZ.RUTGERS.EDU (Ron Natalie) Newsgroups: comp.protocols.tcp-ip Subject: Re: telnet CR processing, bridge comm servers and TWG telnet Message-ID: <8708121406.AA04593@topaz.rutgers.edu> Date: Wed, 12-Aug-87 10:06:46 EDT Article-I.D.: topaz.8708121406.AA04593 Posted: Wed Aug 12 10:06:46 1987 Date-Received: Fri, 14-Aug-87 05:32:30 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 7 The main problem we've found with the blasted BRIDGE boxes is that they insist on negotiating BINARY mode when you open the connection. This screws up all kinds of things. You really want the NVT mapping when dealing with dissimilar machine/terminal types. -Ron ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[SRI-NIC.ARPA]12-Aug-87.07:11:44.STJOHNS] <1987081206110000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: STJOHNS@SRI-NIC.ARPA Newsgroups: comp.protocols.tcp-ip Subject: Re: VMS and X.25 Message-ID: <[SRI-NIC.ARPA]12-Aug-87.07:11:44.STJOHNS> Date: Wed, 12-Aug-87 10:11:00 EDT Article-I.D.: <[SRI-NIC.ARPA]12-Aug-87.07:11:44.STJOHNS> Posted: Wed Aug 12 10:11:00 1987 Date-Received: Fri, 14-Aug-87 06:09:56 EDT References: <8708121248.AA15185@jvnca.csc.org> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 6 Sergio, the IETF would like to take you up on your offer of a place to hold an IETF meeting. The schedule we are looking for is to have a meeting at JVNC in late april/early may of 1988. Would this be possible for JVNC? Can you give me some idea of the number/sizes of conference rooms available and how far in advance we have to book them>? Thanks! Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[SRI-NIC.ARPA]12-Aug-87.07:12:55.STJOHNS] <1987081206120000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: STJOHNS@SRI-NIC.ARPA Newsgroups: comp.protocols.tcp-ip Subject: Re: VMS and X.25 Message-ID: <[SRI-NIC.ARPA]12-Aug-87.07:12:55.STJOHNS> Date: Wed, 12-Aug-87 10:12:00 EDT Article-I.D.: <[SRI-NIC.ARPA]12-Aug-87.07:12:55.STJOHNS> Posted: Wed Aug 12 10:12:00 1987 Date-Received: Fri, 14-Aug-87 06:12:07 EDT References: <8708121248.AA15185@jvnca.csc.org> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 1 Apologies, that one got away from me. *sigh* Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987081209270000> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Wed 12 Aug 87 16:28:54-PDT Received: from YMIR.BITNET by wiscvm.wisc.edu ; Wed, 12 Aug 87 18:28:56 CDT Received: from ENGVAX.SCG.HAC.COM by YMIR.BITNET; Wed, 12 Aug 87 16:26 PDT Date: Wed, 12 Aug 87 16:27 PDT From: Kevin Carosso <@YMIR.BITNET:KVC@ENGVAX.SCG.HAC.COM> Subject: DEC Ethernet addresses To: tcp-ip@sri-nic.ARPA X-VMS-To: IN%"tcp-ip@sri-nic.arpa" For VMS DECnet (using NCP): to show the ethernet controller's hardware address: --------------------------------------------------------------------- NCP> SHOW LINE UNA-0 CHARACTERISTICS Line Volatile Characteristics as of 12-AUG-1987 16:06:40 Line = UNA-0 Receive buffers = 6 Controller = normal Protocol = Ethernet Service timer = 4000 Hardware address = 08-00-2B-05-D3-E3 Device buffer size = 1498 --------------------------------------------------------------------- to show the ethernet controller's current address as set by DECNet: --------------------------------------------------------------------- NCP> SHOW EXECUTOR STATUS Node Volatile Status as of 12-AUG-1987 16:06:10 Executor node = 45.9 (ENGVAX) State = on Physical address = AA-00-04-00-09-B4 --------------------------------------------------------------------- This is the one generated by DECnet from the node number via the scheme: (area * 1024) + node = last_two_bytes There seems to have been some confusion on these issues. Also, I've noted that my DELUA controller and the DESVA controller in a VAXstation-2000 have hardware addresses assigned in the group 08-00-2B. I guess DEC got more than the AA-00-00 through AA-00-04 range. /Kevin Carosso kvc@engvax.scg.hac.com Hughes Aircraft Co. kvc%engvax@oberon.usc.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12325952786.48.ROODE@BIONET-20.ARPA] <1987081210405300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ROODE@BIONET-20.ARPA (David Roode) Newsgroups: comp.protocols.tcp-ip Subject: Re: SMTP question Message-ID: <12325952786.48.ROODE@BIONET-20.ARPA> Date: Wed, 12-Aug-87 14:40:53 EDT Article-I.D.: BIONET-2.12325952786.48.ROODE Posted: Wed Aug 12 14:40:53 1987 Date-Received: Sat, 15-Aug-87 01:32:11 EDT References: Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 18 One reason not to expand SMTP to provide for 8 bit ASCII is that there are a goodly number of obscure computer made by a company called IBM that are probably already internally converting 7 bit ASCII into 8 bit EBCDIC. Who knows what would happen to information encoded into the ASCII parity bit when transmission to one of these guys were attempted. Some of them are still sending mail messages to each other by pretending to punch cards on each others' virtual card punch. Not to poke fun, this is just an example of the sort of baggage that accumulates when one is in business for 40 years or more, give or take a few years, in a field beset by technological advances. It's a miracle that ASCII itself is acceptable in the international community, and I am sure there are some problems with that--going through international mail gateways to other countries' research mail networks would engender problems for 8 bit ASCII, I suspect. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708130054.AA01595@ucbvax.Berkeley.EDU] <1987081215270000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: KVC@ENGVAX.SCG.HAC.COM (Kevin Carosso) Newsgroups: comp.protocols.tcp-ip Subject: DEC Ethernet addresses Message-ID: <8708130054.AA01595@ucbvax.Berkeley.EDU> Date: Wed, 12-Aug-87 19:27:00 EDT Article-I.D.: ucbvax.8708130054.AA01595 Posted: Wed Aug 12 19:27:00 1987 Date-Received: Sat, 15-Aug-87 04:43:24 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 42 For VMS DECnet (using NCP): to show the ethernet controller's hardware address: --------------------------------------------------------------------- NCP> SHOW LINE UNA-0 CHARACTERISTICS Line Volatile Characteristics as of 12-AUG-1987 16:06:40 Line = UNA-0 Receive buffers = 6 Controller = normal Protocol = Ethernet Service timer = 4000 Hardware address = 08-00-2B-05-D3-E3 Device buffer size = 1498 --------------------------------------------------------------------- to show the ethernet controller's current address as set by DECNet: --------------------------------------------------------------------- NCP> SHOW EXECUTOR STATUS Node Volatile Status as of 12-AUG-1987 16:06:10 Executor node = 45.9 (ENGVAX) State = on Physical address = AA-00-04-00-09-B4 --------------------------------------------------------------------- This is the one generated by DECnet from the node number via the scheme: (area * 1024) + node = last_two_bytes There seems to have been some confusion on these issues. Also, I've noted that my DELUA controller and the DESVA controller in a VAXstation-2000 have hardware addresses assigned in the group 08-00-2B. I guess DEC got more than the AA-00-00 through AA-00-04 range. /Kevin Carosso kvc@engvax.scg.hac.com Hughes Aircraft Co. kvc%engvax@oberon.usc.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [870812-174234-1321@Xerox] <1987081216422500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jlarson.pa@XEROX.COM Newsgroups: comp.protocols.tcp-ip Subject: Re: Ethernet addresses Message-ID: <870812-174234-1321@Xerox> Date: Wed, 12-Aug-87 20:42:25 EDT Article-I.D.: Xerox.870812-174234-1321 Posted: Wed Aug 12 20:42:25 1987 Date-Received: Sat, 15-Aug-87 04:52:04 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 11 " Assigning Ethernet addresses. When I left Xerox in March of 1986, all 'magic number' assignments were still be handled by Xerox..." Ethernet 48-bit address blocks (IEEE 802 "48-bit Globally/Universal Assigned Addresses") are now assigned by the IEEE Standards Office rather than Xerox. Contact the IEEE Standards Office, (212) 705-7092, for more information. John ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12326048551.140.SY.KEN@CU20B.COLUMBIA.EDU] <1987081219265600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: sy.Ken@CU20B.COLUMBIA.EDU (Ken Rossman) Newsgroups: comp.protocols.tcp-ip Subject: Re: Ethernet Address Space Message-ID: <12326048551.140.SY.KEN@CU20B.COLUMBIA.EDU> Date: Wed, 12-Aug-87 23:26:56 EDT Article-I.D.: CU20B.12326048551.140.SY.KEN Posted: Wed Aug 12 23:26:56 1987 Date-Received: Sat, 15-Aug-87 05:53:10 EDT References: <8708130005.AA29193@columbia.edu> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 7 OK, I said a really stupid thing, I admit it. Now you guys can quit beating me to death about how many available ethernet addresses there are. I guess, without thinking about it at all, glancing at a 6 field hex number, it just doesn't look all that large... Put it to rest already. /Ken ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12326118244.14.ROODE@BIONET-20.ARPA] <1987081301494600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ROODE@BIONET-20.ARPA (David Roode) Newsgroups: comp.protocols.tcp-ip Subject: Re: TAC "noise" Message-ID: <12326118244.14.ROODE@BIONET-20.ARPA> Date: Thu, 13-Aug-87 05:49:46 EDT Article-I.D.: BIONET-2.12326118244.14.ROODE Posted: Thu Aug 13 05:49:46 1987 Date-Received: Sat, 15-Aug-87 07:53:06 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 6 The CompuServe Network added an option to their 'TAC' to vary the timing of bits or number of stop bits, apparently just to address the type of problem you hypothesize might be what Frank is seeing on TAC's. I believe it was just to send an extra stop bit. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708131534.AA14351@ucbvax.Berkeley.EDU] <1987081306312600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: cain@EDN-UNIX.ARPA (Edward A. Cain) Newsgroups: comp.protocols.tcp-ip Subject: ethernet multicast Message-ID: <8708131534.AA14351@ucbvax.Berkeley.EDU> Date: Thu, 13-Aug-87 10:31:26 EDT Article-I.D.: ucbvax.8708131534.AA14351 Posted: Thu Aug 13 10:31:26 1987 Date-Received: Sat, 15-Aug-87 09:08:47 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 5 Is there a commercial product (gateway) which supports ethernet multicast? Needs to take an IP datagram from Arpanet, recongize that the IP address is really a group address, and multicast it onto an ethernet. Ed Cain ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987081306312601> Received: from EDN-UNIX.ARPA by SRI-NIC.ARPA with TCP; Thu 13 Aug 87 07:57:54-PDT Date: 13 Aug 1987 10:31:26 EDT From: Edward A. Cain Subject: ethernet multicast To: tcp-ip@sri-nic.arpa Cc: Leiden@mit-multics.arpa Is there a commercial product (gateway) which supports ethernet multicast? Needs to take an IP datagram from Arpanet, recongize that the IP address is really a group address, and multicast it onto an ethernet. Ed Cain ----MESSAGE-END---- ----MESSAGE-BEGIN---- [CECOM-WRK-BZ9GD@CECOM-1] <1987081310060000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: WRK.CECOM@CECOM-1.ARPA (Bill.King@SRI-NIC.ARPA, Directorate of Information Management) Newsgroups: comp.protocols.tcp-ip Subject: DDN Node Location Message-ID: Date: Thu, 13-Aug-87 14:06:00 EDT Article-I.D.: CECOM-1.CECOM-WRK-BZ9GD Posted: Thu Aug 13 14:06:00 1987 Date-Received: Sat, 15-Aug-87 10:34:11 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 12 I have what perhaps is a rather dumb question for this forum, but would sincerely like some opinions. We are about to relocate our computer room and at the same time, relocate and upgrade our PSN. Given the choice (which we do have) of locating the PSN adjacent to the telephone switching center (and all incoming trunks) or adjacent to the host computers (eventually a gateway) connected to it, which is preferable and why? Your assistance appreciated. Bill King Ft. Monmouth, NJ KING@CECOM-1.ARPA ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987081312520000> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Thu 13 Aug 87 08:14:47-PDT Received: by ucbvax.Berkeley.EDU (5.58/1.27) id AA13440; Thu, 13 Aug 87 07:40:26 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 13 Aug 87 12:52:00 GMT From: apollo!rees@eddie.mit.edu (Jim Rees) Organization: Apollo Computer, Chelmsford, Mass. Subject: Re: RFS vs NFS Message-Id: <36a4bce2.b8ab@apollo.uucp> References: <255@srs.UUCP>, <3681e98d.b8ab@apollo.uucp>, <4993@felix.UUCP> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa Actually, I like to think of it as RFS using volatile state, and NFS using permanent state (i.e., disk). In order to permit the simple recovery that NFS aspires to, you have to store data on disk that will survive a failure so that a client can do correct cache invalidation. This NFS does, and it completes all writes prior to acknowledging a write to a client. In view of these requirements, I feel that the term "stateless" without qualification is incorrect. Well... I guess so, but if you take that interpretation, you could also argue that no server is ever stateless, because the data in the files represents state, too. In this context, when I say "server state," I mean some information held by the server about connections with the clients. The server "knows" that node X has file "foo" open for reading. NFS does not keep this kind of information around, not even on disk, except maybe as an optimization. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987081314391300> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Thu 13 Aug 87 16:45:37-PDT Received: by ucbvax.Berkeley.EDU (5.58/1.27) id AA23450; Thu, 13 Aug 87 16:26:01 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 13 Aug 87 14:39:13 GMT From: nsc!unixprt!monkey@decwrl.dec.com (Monkey Face@unixprt) Organization: uni-xperts - Unix System and Networking Consultants Subject: Re: RFS vs NFS Message-Id: <287@unixprt.UUCP> References: <649@houxa.UUCP>, <255@srs.UUCP>, <4993@felix.UUCP> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa In article <4993@felix.UUCP>, martin@felix.UUCP (Martin McKendry) writes: > Actually, I like to think of it as RFS using volatile state, and NFS > using permanent state (i.e., disk). In order to permit the simple > recovery that NFS aspires to, you have to store data on disk that > will survive a failure so that a client can do correct cache > invalidation. This NFS does, and it completes all writes prior to > acknowledging a write to a client. In view of these requirements, > I feel that the term "stateless" without qualification is incorrect. > -- > Martin S. McKendry > {hplabs,trwrb}!felix!martin The "stateless" term does not really refer to the 'write through' characteristic of NFS, but to the fact that the 'server' does not maintain 'state' related to currently opened files by 'clients'. The client has a 'handle' for a file that can always be recognized by the server and maintains local state as to 'offset', etc. The server may have to 're-open' that file (if all local users are not using it) each time a request to access that file from a client arrives. This allows the server to go down and come back up whilst the client can use the same 'handle' and local state information to continue to access the file as if the server had not gone down. RFS on the other hand does keep state at the server and client, therefore if the server dies, so does current 'access' to any of its files. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987081401181100> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Thu 13 Aug 87 19:14:58-PDT Received: by ucbvax.Berkeley.EDU (5.58/1.27) id AA26004; Thu, 13 Aug 87 18:59:10 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Aug 87 01:18:11 GMT From: topaz.rutgers.edu!ron@RUTGERS.EDU (Ron Natalie) Organization: Rutgers Univ., New Brunswick, N.J. Subject: Re: RFS vs NFS Message-Id: <13967@topaz.rutgers.edu> References: <255@srs.UUCP>, <4993@felix.UUCP>, <287@unixprt.UUCP> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa The one major piece of statelessness that Sun did that I wish they hadn't is that they do not keep track of the fact that the server they were referencing is down. It would seem to be a trivial modification to notice when the server dies, and then invalidate requests for the mounted disk until they get some indication (periodic pinging or whatever) that the dead machine has come back to life. -Ron ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987081404000000> Received: from twg.arpa by SRI-NIC.ARPA with TCP; Fri 14 Aug 87 11:02:32-PDT Date: 14 Aug 87 11:00:00 PDT From: "Jerry Scott" Subject: RE: Ethernet problems induced by bogus ICMP Address Mask Reply To: "tcp-ip" cc: Reply-To: "Jerry Scott" On date, 8 Aug 87, Preston Mullen wrote: >>==> Potential users of Wollongong 3.0 software should get a fix from >>Wollongong before running 3.0 on a network where a machine might >>broadcast an ICMP address mask request. A fix may be obtained for this problem by using anonymous ftp to host twg.arpa (26.5.0.73) and obtaining image ip_icmp.o. The file is in binary/record format and should be transferred from a Wollongong host running either release 2.3 or 3.0. Also, image named472.sav, can be obtained at this time. This is the new version of the bind name server from D. Kingston, et al. The image is in VMS Backup format and should be obtained using binary/record mode from a Wollongong host. Regards, Jerry Scott ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708141829.AA09490@ucbvax.Berkeley.EDU] <1987081410000000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jerry@twg.arpa ("Jerry Scott") Newsgroups: comp.protocols.tcp-ip Subject: RE: Ethernet problems induced by bogus ICMP Address Mask Reply Message-ID: <8708141829.AA09490@ucbvax.Berkeley.EDU> Date: Fri, 14-Aug-87 14:00:00 EDT Article-I.D.: ucbvax.8708141829.AA09490 Posted: Fri Aug 14 14:00:00 1987 Date-Received: Sun, 16-Aug-87 02:31:49 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: "Jerry Scott" Distribution: world Organization: The ARPA Internet Lines: 21 On date, 8 Aug 87, Preston Mullen wrote: >>==> Potential users of Wollongong 3.0 software should get a fix from >>Wollongong before running 3.0 on a network where a machine might >>broadcast an ICMP address mask request. A fix may be obtained for this problem by using anonymous ftp to host twg.arpa (26.5.0.73) and obtaining image ip_icmp.o. The file is in binary/record format and should be transferred from a Wollongong host running either release 2.3 or 3.0. Also, image named472.sav, can be obtained at this time. This is the new version of the bind name server from D. Kingston, et al. The image is in VMS Backup format and should be obtained using binary/record mode from a Wollongong host. Regards, Jerry Scott ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [862@mcgill-vision.UUCP] <1987081421095300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mouse@mcgill-vision.UUCP (der Mouse) Newsgroups: comp.protocols.tcp-ip Subject: Re: ethernet interface perversity Message-ID: <862@mcgill-vision.UUCP> Date: Sat, 15-Aug-87 01:09:53 EDT Article-I.D.: mcgill-v.862 Posted: Sat Aug 15 01:09:53 1987 Date-Received: Wed, 26-Aug-87 06:17:48 EDT References: <8708050046.AA07011@ucbvax.Berkeley.EDU> Organization: McGill University, Montreal Lines: 22 In article <8708050046.AA07011@ucbvax.Berkeley.EDU>, JOHNSON@NUHUB.ACS.NORTHEASTERN.EDU ("I am only an egg.") writes: > We did some experimentation with our various ethernet interfaces and > discovered that something which was hinted at in many of the > responses seems to be true. The ethernet interfaces we have will > each respond to only one internet number at a time. If this is so it is a software problem. I can see no reason why UNIX (say) couldn't be set up to respond to ARP requests for more than one IP address per interface. The reason you need a gateway node is that the software is not currently set up to do this, and thus you need either a gateway or some serious low-level network code hacking to allow multiple IP addresses per interface, or alternatively multiple pseudo-interfaces which all send their packets out on the same physical interface. In other words - yes, it will work to have multiple IP networks on the same cable. However, you need either a gateway or some currently-nonexistent software. der Mouse (mouse@mcgill-vision.uucp) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987081421542200> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Sat 15 Aug 87 08:44:46-PDT Received: by ucbvax.Berkeley.EDU (5.58/1.27) id AA02901; Sat, 15 Aug 87 08:41:23 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Aug 87 21:54:22 GMT From: amdcad!amd!intelca!oliveb!felix!martin@ucbvax.Berkeley.EDU (Martin McKendry) Organization: FileNet Corp., Costa Mesa, CA Subject: Re: RFS vs NFS Message-Id: <5502@felix.UUCP> References: <3681e98d.b8ab@apollo.uucp>, <4993@felix.UUCP>, <36a4bce2.b8ab@apollo.uucp> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa I wrote > > Actually, I like to think of it as RFS using volatile state, and NFS > using permanent state (i.e., disk). In order to permit the simple > recovery that NFS aspires to, you have to store data on disk that > will survive a failure so that a client can do correct cache > invalidation. This NFS does, and it completes all writes prior to > acknowledging a write to a client. In view of these requirements, > I feel that the term "stateless" without qualification is incorrect. > Jim Rees (rees@apollo.uucp) responded: >Well... I guess so, but if you take that interpretation, you could also >argue that no server is ever stateless, because the data in the files >represents state, too. My comments were probably less than precise. I'm actually getting at terminology and commonly drawn inferences. I would be happy to go with the position that no server is ever stateless. After all, state is what consistency is all about, and consistency is a (if not _the_) major problem in a distributed file system. I just object to the terminology: a "stateless" file system sounds like one that doesn't store anything! I also object to the common perception that "stateless" is somehow "better". Consider what you can do if you are not "stateless": Our FileNet filesystem is "stateful"; we maintain a list with each inode of who is using it. This allowed us to implement a fairly sophisticated caching mechanism. The mechanism allows us to cache both data blocks and inodes -- opens, closes, reads, and some writes can happen without any communication between a client and the server storing a file. Basically, the site that stores a file notifies clients if it changes. If a file changes a lot, (relative to the number of read accesses) we switch modes (all sites using the file notified) so that clients take responsibility for asking the server if there have been changes. Our experience so far (we are currently in quality assurance) is that it is very rare that this pays off. On our basic applications we are seeing hit ratios on the inode cache of 75-85% for opens. Only closes that change a file have to contact the server -- over 98% don't. Total message traffic due to the file system is down over 50% in many cases. I'd rather use a standard filesystem protocol and mechanism (I have spent considerable time trying to do this). However, we build a tightly-coupled system with a very centralized view. Sophisticated caching is essential to supporting large numbers of workstations. You can't do that if you don't maintain some kind of "connection state" that tells a server who has a file cached. So "statelessness" is not a universal panacea. Nonetheless, there are many people around (FileNet included) who believe that there is something inherently 'better' about being stateless (as defined by Sun). But there is no free lunch. The price of Sun's stateless approach is that preservation of consistency of the file system requires that clients interrogate the server to confirm currency of cached entries, *whether or not those entries have changed*. This slows down the client and it loads the server, thus contributing to the limits on its capacity. It may not worry you now, but when you have much larger workstation memories, and you have all the data you need locally, you are not going to be pleased at constantly having to interrogate a server before you can use the data. I'd like to see more understanding of these issues. There are many advantages to Sun's approach. There are also limitations. Like not being able to implement exclusive locking in the file system. (Of course, the v-node mechanism reduces this need, but that moves work to the server, which is already overloaded...etc...) Jim Rees (rees@apollo.uucp) also said: > In this context, when I say "server state," I >mean some information held by the server about connections with the >clients. The server "knows" that node X has file "foo" open for reading. >NFS does not keep this kind of information around, not even on disk, >except maybe as an optimization. The main reasons we keep this data at the server are a) for cache invalidation, and b) to manage exclusive locking. Sun let the client worry about invalidation, and they don't do exclusive locking. Given that the semantics of NFS don't require it to be "stateful", I don't see why being "stateless" gets such a billing as a wonderful feature. I don't know if RFS supports exclusive locking. Their caching is pretty disgusting, but it does require that the server contact clients. Mr/Ms Face [monkey@unixprt.UUCP (Monkey Face@unixprt)] also responded: >The "stateless" term does not really refer to the 'write through' >characteristic of NFS, but to the fact that the 'server' does not >maintain 'state' related to currently opened files by 'clients'. From the Usenix (86?) paper on NFS: "Because the NFS is stateless,, when servicing an NFS request it must commit any modified data to stable storage before returning results." Here, they are including as one of the properties of statelessness the ease with which a client can recover from a server failure. If you don't feel that this is a required property (e.g., the client could detect it and do clean up), then your comment is correct. This property and the lack of per-client data stored at the server do seem to be separable issues. We don't do write-through on our system, but conceivably we could do it to simplify client recovery even though we are not "stateless". These issues are complex, and the tradeoffs are too. I'm not claiming that there are any universal answers. But I'm interested in discussing the tradeoffs. -- Martin S. McKendry; FileNet Corp {hplabs,trwrb}!felix!martin Get in on the ground floor: Buy FileNet stock now! ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1311@bloom-beacon.MIT.EDU] <1987081515411800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: martillo@athena.mit.edu (Yakim Martillo) Newsgroups: comp.protocols.tcp-ip Subject: Re: ethernet multicast Message-ID: <1311@bloom-beacon.MIT.EDU> Date: Sat, 15-Aug-87 19:41:18 EDT Article-I.D.: bloom-be.1311 Posted: Sat Aug 15 19:41:18 1987 Date-Received: Sun, 16-Aug-87 11:51:52 EDT References: <8708131534.AA14351@ucbvax.Berkeley.EDU> Sender: daemon@bloom-beacon.MIT.EDU Reply-To: martillo@hector.UUCP (Yakim Martillo) Distribution: world Organization: Massachusetts Institute of Technology Lines: 35 In article <8708131534.AA14351@ucbvax.Berkeley.EDU> cain@EDN-UNIX.ARPA (Edward A. Cain) writes: >Is there a commercial product (gateway) which supports ethernet multicast? >Needs to take an IP datagram from Arpanet, recongize that the IP address >is really a group address, and multicast it onto an ethernet. >Ed Cain I believe that for hosts directly connected to an IMP via 1822 IP addresses uniquely identified the IMP interface to which a host is connected. The unique mapping of hardware interface to IP address is quite natural in this case. When TCP/IP moved onto ethernet, the mapping of IP address to physical interface was maintained though for a multihomed host with a separated IP address on each network (of any type of communications subnet) there should be no problem with handling an IP packet on any interface with any IP address as long as IP processing is done in the host or as long as the communications controllers can communicate with one another over the backplane as is possible with DEC machines. Also when people began putting PCs onto ethernets, dynamically assigning IP addresses to PCs seems to be quite reasonable. Further when ISDN interfaces become available, dynamically assigning IP addresses to sets of switched physical or virtual circuits will probably make sense (especially for certain cases of security). Thus my questions are: Is there such a thing as an IP *group* address and if there is what is it used for? Next if there are IP group addresses how do they work in an internetting environment. If there are IP group addresses, does it make any sense to map them to ethernet multicast addresses (which I guess would be assigned to groups of hosts dynamically) and if it does how would one go about handling multinetwork IP group addresses for which multicasting would be clearly insufficient. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[A.ISI.EDU]15-Aug-87.21:29:39.CERF] <1987081517290000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: CERF@A.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: ethernet multicast Message-ID: <[A.ISI.EDU]15-Aug-87.21:29:39.CERF> Date: Sat, 15-Aug-87 21:29:00 EDT Article-I.D.: <[A.ISI.EDU]15-Aug-87.21:29:39.CERF> Posted: Sat Aug 15 21:29:00 1987 Date-Received: Sun, 16-Aug-87 12:10:28 EDT References: <1311@bloom-beacon.MIT.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 4 You should look into host group multicast - see Bob Braden or the RFCs for details. Vint Cerf ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708160414.AA00319@bel.isi.edu] <1987081520145200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: postel@ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: ethernet multicast Message-ID: <8708160414.AA00319@bel.isi.edu> Date: Sun, 16-Aug-87 00:14:52 EDT Article-I.D.: bel.8708160414.AA00319 Posted: Sun Aug 16 00:14:52 1987 Date-Received: Sun, 16-Aug-87 12:58:10 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 5 See RFCs 966 and 988. --jon. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [378@swivax.UUCP] <1987081606150200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jan@swivax.UUCP (Jan Wielemaker) Newsgroups: comp.protocols.tcp-ip Subject: bridge on sun (cr/lf) Message-ID: <378@swivax.UUCP> Date: Sun, 16-Aug-87 10:15:02 EDT Article-I.D.: swivax.378 Posted: Sun Aug 16 10:15:02 1987 Date-Received: Tue, 18-Aug-87 03:46:25 EDT Reply-To: jan@swivax.UUCP (Jan Wielemaker) Distribution: world Organization: SWI, UvA, Amsterdam Lines: 7 We have a Bridge CS/100 terminal multiplexer and a SUN Unix network running SunUnix 3.2. When I connect via the Bridge all CR's are mapped on LF's, even with the driver in 'nl' mode. Probably the telnet daemon is doing this, but it is very anoying with Emacs editors! Who knows a fix for this? Thanks --- Jan ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987081609011000> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Sun 16 Aug 87 08:45:15-PDT Received: by ucbvax.Berkeley.EDU (5.58/1.27) id AA18620; Sun, 16 Aug 87 08:39:49 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Aug 87 09:01:10 GMT From: gorodish!guy@sun.com (Guy Harris) Subject: Re: RFS vs NFS Message-Id: <25738@sun.uucp> References: <649@houxa.UUCP>, <255@srs.UUCP>, <5502@felix.UUCP> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa > The price of Sun's stateless approach is that preservation of consistency > of the file system requires that clients interrogate the server to confirm > currency of cached entries, *whether or not those entries have changed*. Or that you have timeouts on the cached data, which is the way SunOS does it (and the way NFS implementations derived from the Sun implementation, which probably includes most UNIX NFS implementations, would most likely do it). Also, (on SunOS, at least) if you do byte-span locking on a file, the caching on data for that file is turned off, so that it goes back to the server on every "read". > The main reasons we keep this data at the server are a) for cache > invalidation, and b) to manage exclusive locking. Sun let the > client worry about invalidation, and they don't do exclusive locking. If by "locking" you are referring either to BSD-style file locking or Bass/POSIX/S5-style byte-span locking, we most definitely *do* have exclusive locking (Bass/POSIX/S5-style), we just don't do it using the NFS protocol! There is no reason to tie all of your file-system operations to the NFS protocol. RFS also supports Bass/POSIX/S5-style locking. Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987081609113300> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Sun 16 Aug 87 08:45:06-PDT Received: by ucbvax.Berkeley.EDU (5.58/1.27) id AA18633; Sun, 16 Aug 87 08:40:21 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Aug 87 09:11:33 GMT From: gorodish!guy@sun.com (Guy Harris) Subject: Re: RFS vs NFS Message-Id: <25739@sun.uucp> References: <255@srs.UUCP>, <4993@felix.UUCP>, <287@unixprt.UUCP> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa > The client has a 'handle' for a file that can always be recognized > by the server and maintains local state as to 'offset', etc. If by that you mean that a file handle contains the current offset in the file as used for I/O operations, a file handle contains no such thing. In SunOS, the file handle for a UNIX file contains a unique identifier for the file, made out of a file system ID and a file ID containing the i-number and generation count, and that's it. The current I/O offset is maintained by the client for each open instance of a file; if the client crashes, this data is obviously of no interest (since all the processes that have the file open have gone away), so it gets thrown away. Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987081616154200> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Sun 16 Aug 87 18:45:17-PDT Received: by ucbvax.Berkeley.EDU (5.58/1.27) id AA24037; Sun, 16 Aug 87 18:40:24 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Aug 87 16:15:42 GMT From: mtune!whuts!homxb!houxa!mel1@RUTGERS.EDU (M.HAAS) Organization: AT&T Bell Laboratories, Holmdel Subject: Re: RFS vs NFS Message-Id: <750@houxa.UUCP> References: <255@srs.UUCP>, <4993@felix.UUCP>, <287@unixprt.UUCP> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa Would someone please post a note explaining all this? What is statelessness? Is it good or bad? Why would someone care? I think the original posting asked for an explination of the differences between RFS and NFS. A good question, worth answering. But, please in English and please in terms of a user, or administrator, or purchaser, too. (As well as academics.) Thanks, Mel Haas , odyssey!mel P.S. Can someone please expand this discussion to include a user's (and/or administrator's) perspective on NFS vs RFS vs NewCastle vs rcp-rsh-rlogin? Particularly, which can co-exist on the network? Which take up the most resources? the most administration? Which are easiest to use? Which presents the least pain at malfunction time? etc? Thanks. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708170341.AA00962@bu-cs.BU.EDU] <1987081619414800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: bzs@BU-CS.BU.EDU (Barry Shein) Newsgroups: comp.protocols.tcp-ip Subject: Re: NFS vs The World Message-ID: <8708170341.AA00962@bu-cs.BU.EDU> Date: Sun, 16-Aug-87 23:41:48 EDT Article-I.D.: bu-cs.8708170341.AA00962 Posted: Sun Aug 16 23:41:48 1987 Date-Received: Mon, 17-Aug-87 05:11:39 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 42 The technical discussions are interesting in regards to things like statelessness vs statefulness etc. What the casual or more product oriented person needs to know is: 1. NFS has been delivered in production systems for years now, it works. 2. NFS is now widely available from vendors for heterogeneous networks running on many different machines compatibly. 3. NFS uses the Internet protocol suite for its lower layers, by and large your knowledge and current investment in internet hardware and software will help you set up and maintain an NFS network. None of the above is really true about RFS (except that it's probably available on some very small set of machines from one vendor.) By and large it's vaporware in its promises to be a widely available heterogeneous product and its implementation on a non-internet standard makes it harder to see what its potential utility is (you want to become a 3Bnet expert on Starlan twisted pair? why?) Let's put it this way, at Boston University we run a lot of NFS sites in different depts. We've been using it to share single copies of things like font directories, software and source distributions, data bases and network news all over campus and to combine clusters of machines into one single environment where users maintain one home directory wherever they log in. RFS can do all this in theory but you'll have to settle on a very limited (1?) set of machine types, it's the old tail wagging the dog. NFS works, we've had it in production for over a year and the NFS community here just grows and grows. Like I said, technical discussions interest me also, but as far as I can see there is a standard in heterogeneous network file systems: NFS. And about 100 vendors agree with me. RFS may have its pluses but in terms of being a viable product it strikes me as being too little too late. -Barry Shein, Boston University ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708170433.AA28234@topaz.rutgers.edu] <1987081620333600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hedrick@TOPAZ.RUTGERS.EDU.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: RFS vs NFS Message-ID: <8708170433.AA28234@topaz.rutgers.edu> Date: Mon, 17-Aug-87 00:33:36 EDT Article-I.D.: topaz.8708170433.AA28234 Posted: Mon Aug 17 00:33:36 1987 Date-Received: Tue, 18-Aug-87 01:03:16 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 66 The distinction involved in "statelessness" is how much "state information" is kept around by file servers about who is using them. If the protocol requires the server to keep control information about each user, then if the server goes down and is rebooted, the clients will not be able to continue. State information is also needed in order to remember who has what file locked. When it is said that NFS is stateless, what this means is that in principle a given request can be processed without any reference to any previous requests, or any side effects created by such previous requests. The advantage of this approach is that clients and servers can randomly crash and come up, or be rebooted, and no special action is needed to keep the network file system consistent. The previous discussion points out that this distinction is at best a slippery one. What a client sees most certainly does depend upon the state of the file system: that's the whole point of doing a remote access, after all. As somebody mentioned, if you dump and restore a file system, all your files have new inode numbers, and all the clients are going to have to restart whatever they are doing. (This situation will be detected by NFS if you do things correctly. However recovery will require you to kill all the processes that are using the file system remotely, umount it and then mount it again.) However except for things that completely rebuild a file system, NFS in practice does recover from crashes and reboots. The only operational problems we have seen with it are that when a server is down, its clients have a tendency to behave badly in various ways, even when what they are doing does not really require that particular server. This does not seem to have anything to do with the NFS protocol per se, but is an implementation issue. (In general that situation is improving release by release.) People around here have gotten started typing "df &", just to avoid having our jobs hang if any servers are down. (To be fair, this is largely because of machines running out of date NFS implementations. On a Sun, you can eventually get out of df in this situation, though it is still annoying.) File locking is handled by a separate lock daemon, which is not part of NFS, though it is implemented using similar mechanisms. File locking obviously involves state information. The server has to remember that the file is locked across crashes. It also has to have a way to get rid of the lock if the client crashes. Sun uses two daemons, lockd and statd, to keep track of things. Statd seems to be responsible for keeping track of what machines are up, and reestablishing connections after a crash and reload. It uses a set of disk directories that contain hosts that it is to monitor and hosts that it is to notify when it comes up after a crash. Like NFS, there don't seem to be any administrative tools involved in maintaining or restoring consistency to the locking system. However I do recall one time where we had to do some manual cleanup after permanently removing a machine. I suspect statd had been told to keep track of the machine. There was no big damage, just an ocassional console error message we wanted to get rid of. There are no adminstrative issues involved with maintaining NFS per se. However you certainly do want to think carefully about what machines mount what disks, and what attributes you will use (e.g. readonly and whether root access is preserved across the network). Our primary planning problem is setting things up so that we don't have every machine having to mount every other disk in the world. I make no comparisons with other remote file system protocols, since I don't know them. You can imagine protocols that would keep internal state information about every file that is open, and which would leave the world in a horribly inconsistent state after a crash and reload. But whether any such things actually exist, I couldn't say. The only bad examples Sun pointed to back when they introduced NFS had to do with file locking. But locking is a special situation, where even Sun maintains state information. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1307@aramis.rutgers.edu] <1987081707313000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: marantz@aramis.rutgers.edu (Roy Marantz) Newsgroups: comp.protocols.misc,comp.protocols.tcp-ip,comp.dcom.lans Subject: wanted: software to talk to a HP 4972 Message-ID: <1307@aramis.rutgers.edu> Date: Mon, 17-Aug-87 11:31:30 EDT Article-I.D.: aramis.1307 Posted: Mon Aug 17 11:31:30 1987 Date-Received: Tue, 18-Aug-87 04:27:58 EDT Organization: Rutgers Univ., New Brunswick, N.J. Lines: 17 Does anyone have any software that will talk (from a regular computer, say a Sun or a Vax) to a HP 4972 lan protocol analyzer? I have documentation on the protocol, but would like to avoid having to implement it if I can. (I'm just basically lazy :-) I want to be able to get data files from the analyzer and maybe be anble to send a node-ethernet list to it. I'd also really like to the source to the program. I'd also be real interested in any code that will talk DDCMP from a non DEC machine. (i.e. a Sun or Pyramid) That would be a good start for writing this "comm" package. Thanks for any and all assistance and please respond directly to me. I'll summarize and repost if there is interest. Roy ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708171650.AA00676@braden.isi.edu] <1987081708503800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: braden@ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: ethernet multicast Message-ID: <8708171650.AA00676@braden.isi.edu> Date: Mon, 17-Aug-87 12:50:38 EDT Article-I.D.: braden.8708171650.AA00676 Posted: Mon Aug 17 12:50:38 1987 Date-Received: Tue, 18-Aug-87 05:00:39 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 21 Is there such a thing as an IP *group* address and if there is what is it used for? Next if there are IP group addresses how do they work in an internetting environment. If there are IP group addresses, does it make any sense to map them to ethernet multicast addresses (which I guess would be assigned to groups of hosts dynamically) and if it does how would one go about handling multinetwork IP group addresses for which multicasting would be clearly insufficient. Please see RFC988 for the definition of IP group addresses. Although it is not yet an Internet standard, it is likely to become one soon. Experimental implementations for 4.3BSD are available, as previously announced on this list. Bob Braden ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708171853.AA06570@opal.berkeley.edu] <1987081710524000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: minshall@OPAL.BERKELEY.EDU Newsgroups: comp.protocols.tcp-ip Subject: Beta test version of tn3270 available. Message-ID: <8708171853.AA06570@opal.berkeley.edu> Date: Mon, 17-Aug-87 14:52:40 EDT Article-I.D.: opal.8708171853.AA06570 Posted: Mon Aug 17 14:52:40 1987 Date-Received: Tue, 18-Aug-87 05:41:54 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 84 A beta test version of release 3 of tn3270 is now available. Tn3270 is a program which allows users to login from Unix machines or (with this release) MSDOS machines to an IBM mainframe (running VM/CMS or MVS) and interact with the IBM machine in full-screen mode. The beta test version may be acquired via anonymous ftp to host arpa.berkeley.edu (10.0.0.78). The file is in directory pub. This distribution is very large. The file tn3270.tar is a bit over 700Kbytes; there is a compress(1) file tn3270.tar.Z which is a bit over 300Kbytes. For people who cannot access arpa.berkeley.edu via the arpanet, I will be willing to produce a limited number of copies of the distribution on an AT style, 1.2MByte, High Capacity diskette. Send me the diskette, along with what you would like, and I will attempt to create a diskette to send you back. Please note that possibly the result of your sending me a diskette MAY be our sending you a form to fill out (this will happen if our software distribution group takes over the filling of orders; this will also likely involve a small, $50 or $100, distribution fee). Following is a short blurb on what is neat about the new version. However, I should mention who might be interested: 1) Vendors implementing tn3270 (since this version has more features and should be easier to port), 2) People who want a free (and more-or-less unsupported) tn3270 for MSDOS, 3) People who need Yale-style graphics to work correctly. There is follow-on work planned to implement a native X version and, within that version, to do IBM 3179G-style graphics. Because of this follow-on work, I'm not sure (at the moment) whether we will polish up this beta release, or go directly to an enhanced-function release. If you are a beta test site, please let me know of both good and bad experiences. Greg Minshall CFC 275 Evans Hall UC Berkeley, CA 94720 (415)642-0530 minshall@berkeley.edu -------- ps - the telnet.c distributed with this release has some bug fixes for binary mode, and allows the user to decide whether or should be sent over a non-3270 connection when the user types carriage-return. ----------- New versions of the tn3270 and mset commands, used to logon to CMS from unix, are now available. New features are: o Error messages, in English, overlay a portion of the screen when the user types an erroneous entry (invalid control sequence, attempt to enter data in an "input disallowed" field, etc.). o Ability to "escape to shell". This, by itself, is mostly useful in an MS-DOS (or non-BSD) system. o An Application Programming Interface (API). This allows programs, running under Unix or MS-DOS, to read and write the 3270 screen, and to send keystrokes (3270) to tn3270. This makes use of the "escape to shell" feature. Included in the (beta) distribution is a program which uses the API to receive files sent from the IBM host (we don't supply the IBM side at this point, and the rather stupid protocol is likely to change in the future). o Yale ASCII/7171/4994 "transparent" mode should now be fully implemented. SAS-Graph, for example, supports doing graphics to TEK terminals over this interface. Locally, we use the X windowing system terminal emulator (xterm), which provides some TEK emulation, to display SAS-Graph graphics on our workstations. o Mset now prints out program function (PF) keys in numerical order. o Various bugs have been fixed. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708172256.AA01038@jupiter.planets] <1987081714565900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: karn@JUPITER.BELLCORE.COM (Phil R. Karn) Newsgroups: comp.protocols.tcp-ip Subject: (none) Message-ID: <8708172256.AA01038@jupiter.planets> Date: Mon, 17-Aug-87 18:56:59 EDT Article-I.D.: jupiter.8708172256.AA01038 Posted: Mon Aug 17 18:56:59 1987 Date-Received: Wed, 19-Aug-87 01:19:32 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 20 I'm curious to know if any thought has been given to providing subnet broadcasting or multicasting in the ARPANET. By this, I mean allowing a host connected to an ARPANET IMP to send a special 1822 message that is received by some or all of the other hosts on the ARPANET. The feature could be implemented within the PSNs through flooding a la USENET. Such a feature might be very useful to support IP routing algorithms. The gateways could broadcast information to each other much as they do now on Ethernet (though hopefully something better than RIP would be used!) As I understand it, this would make the "Core Gateway" notion unnecessary. It seems to me that if the users of a subnetwork need a broadcast facility, it should be more efficient to implement it within the subnet. The only way the users can simulate it is by sending out "bulk mail", congesting links with multiple identical messages with different destinations. With subnet flooding, however, each link would have to be traversed only once. Comments? Phil ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708180007.AA01148@jupiter.planets] <1987081716075300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: karn@JUPITER.BELLCORE.COM (Phil R. Karn) Newsgroups: comp.protocols.tcp-ip Subject: Generalized Subnetting Message-ID: <8708180007.AA01148@jupiter.planets> Date: Mon, 17-Aug-87 20:07:53 EDT Article-I.D.: jupiter.8708180007.AA01148 Posted: Mon Aug 17 20:07:53 1987 Date-Received: Wed, 19-Aug-87 01:31:34 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 41 The recent discussion about varying subnet sizes was interesting. I have implemented a "generalized subnetting" scheme in my own IP routing code that handles this and many similar problems quite well. Basically, I completely ignore the usual rules that distinguish class A, B and C addresses. Instead I keep an explicit subnet mask with each entry in the routing table. (Actually, I use integers between 0 and 32, but the semantics are the same). When a packet is to be routed, I search the routing table for the "best" match under control of the mask. That is, if my routing table contains target width interface gateway 128.96.33.101 32 sl0 128.96 16 ec0 0 0 ec0 128.96.41.1 and I present the address 128.96.33.101, all three entries match. In this case, I select the entry with the greatest width, i.e., the first one. Note that the last entry always matches every address; it is the default route. The first one is a host-specific entry, matching only one IP address. Note that the routing table points to an INTERFACE name, not a gateway address. The gateway field is optional. It is filled in only if the target is to be reached through a gateway on a multiple access subnet, in which case the gateway field is passed down to the subnet driver for translation into a subnet address. If the gateway field is null, the subnet driver is given the target IP address for translation; this would be done if the target is directly on the same subnet. If the subnet is a point-to-point link, the gateway address field is ignored altogether since the subnet has no need for link level addresses. With this scheme you can construct a completely arbitrary internet out of ad-hoc point-to-point links, incompletely connected broadcast subnets (e.g., amateur packet radio), partitioned networks as well as "real" subnets like Ethernets without filling up your routing table with lots of host-specific entries. You can "bunch up" address groups that begin with a common bit pattern, regardless of whether they are really all hosts on the same subnet, or you can split off one or more hosts that are behind a point-to-point link, for example. It works very well. Phil ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987081722050700> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Tue 18 Aug 87 06:45:52-PDT Received: by ucbvax.Berkeley.EDU (5.58/1.27) id AA24964; Tue, 18 Aug 87 06:39:01 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 17 Aug 87 22:05:07 GMT From: amdcad!amd!intelca!oliveb!felix!martin@ucbvax.Berkeley.EDU (Martin McKendry) Organization: FileNet Corp., Costa Mesa, CA Subject: Re: RFS vs NFS Message-Id: <5724@felix.UUCP> References: <255@srs.UUCP>, <5502@felix.UUCP>, <25738@sun.uucp> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa In article <25738@sun.uucp> guy%gorodish@Sun.COM (Guy Harris) writes: >There is no reason to tie all of your file-system operations to the NFS >protocol. Hang on a minute mate. If all the file system isn't in NFS, what is NFS? A piece of the file system? As in, "part of our file system is stateless". If, in order to implement the entire file system, you have to access components that are not stateless, then isn't it incorrect to say that the file system is stateless? (Asbestos suit on) -- Martin S. McKendry; FileNet Corp {hplabs,trwrb}!felix!martin Get in on the ground floor: Buy FileNet stock now! ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987081806014600> Received: from GUNTER-ADAM.ARPA by SRI-NIC.ARPA with TCP; Tue 18 Aug 87 09:03:49-PDT Date: 18 Aug 1987 11:01:46 CDT Sender: LINK@GUNTER-ADAM.ARPA Subject: Hosts and Gateways From: Link Verstegen@GUNTER-ADAM.ARPA To: tcp-ip@SRI-NIC.ARPA cc: LINK@GUNTER-ADAM.ARPA I'm trying to get some information on the exact process used to get a gateway up on the net. We want to do some testing of a pair of EGP gateways using two ports on loan from another program. What are the steps we need to take to bring the hosts down, bring the gateways up, notify the core gateways that they're alive, and then get the hosts back up and running? It's my understanding that there are some administrative steps missing in the above description of what we want to do, but no one I've talked to has the right answers. Any help you can give me would be greatly appreciated. /| /| ===================/ |=================/ |=================== Link N. Verstegen Link@Gunter-ADAM.ARPA Computer Systems/Network Engineer HQ SSC/PRAIT (205)279-5151 Gunter AFS, AL 36114-6343 AV 446-5151 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708181554.AA05739@topaz.rutgers.edu] <1987081807542600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ron@TOPAZ.RUTGERS.EDU (Ron Natalie) Newsgroups: comp.protocols.tcp-ip Subject: Re: TAC "noise" Message-ID: <8708181554.AA05739@topaz.rutgers.edu> Date: Tue, 18-Aug-87 11:54:26 EDT Article-I.D.: topaz.8708181554.AA05739 Posted: Tue Aug 18 11:54:26 1987 Date-Received: Thu, 20-Aug-87 03:47:52 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 4 Yes, you can send an extra stop bit, and then expect not to receive two and things will work OK, but you can not reliably deal with 7-bit No parity (a 9 bit frame) when you are expecing 8 bit,no-parity or 7-bit,parity (10 bit frames). ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708181616.AA27101@ucbvax.Berkeley.EDU] <1987081808014600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Link.Verstegen@GUNTER-ADAM.ARPA Newsgroups: comp.protocols.tcp-ip Subject: Hosts and Gateways Message-ID: <8708181616.AA27101@ucbvax.Berkeley.EDU> Date: Tue, 18-Aug-87 12:01:46 EDT Article-I.D.: ucbvax.8708181616.AA27101 Posted: Tue Aug 18 12:01:46 1987 Date-Received: Thu, 20-Aug-87 03:51:03 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 22 I'm trying to get some information on the exact process used to get a gateway up on the net. We want to do some testing of a pair of EGP gateways using two ports on loan from another program. What are the steps we need to take to bring the hosts down, bring the gateways up, notify the core gateways that they're alive, and then get the hosts back up and running? It's my understanding that there are some administrative steps missing in the above description of what we want to do, but no one I've talked to has the right answers. Any help you can give me would be greatly appreciated. /| /| ===================/ |=================/ |=================== Link N. Verstegen Link@Gunter-ADAM.ARPA Computer Systems/Network Engineer HQ SSC/PRAIT (205)279-5151 Gunter AFS, AL 36114-6343 AV 446-5151 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1988@rosevax.Rosemount.COM] <1987081810433300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: dave@rosevax.Rosemount.COM (David R. Marquardt) Newsgroups: comp.protocols.tcp-ip Subject: Re: bridge on sun (cr/lf) Message-ID: <1988@rosevax.Rosemount.COM> Date: Tue, 18-Aug-87 14:43:33 EDT Article-I.D.: rosevax.1988 Posted: Tue Aug 18 14:43:33 1987 Date-Received: Thu, 20-Aug-87 06:42:36 EDT References: <378@swivax.UUCP> Reply-To: dave@rosevax.Rosemount.COM (David R. Marquardt) Distribution: world Organization: Rosemount Inc., Eden Prairie, MN Lines: 10 In article <378@swivax.UUCP> jan@swivax.UUCP (Jan Wielemaker) writes: >We have a Bridge CS/100 terminal multiplexer and a SUN Unix network >running SunUnix 3.2. When I connect via the Bridge all CR's are mapped >on LF's, even with the driver in 'nl' mode. Probably the telnet daemon >is doing this, but it is very anoying with Emacs editors! Who knows a >fix for this? We just upgraded to SunOS 3.4, and this fixed the problem. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [17950@amdcad.AMD.COM] <1987081812330800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: phil@amdcad.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: Blue Book Message-ID: <17950@amdcad.AMD.COM> Date: Tue, 18-Aug-87 16:33:08 EDT Article-I.D.: amdcad.17950 Posted: Tue Aug 18 16:33:08 1987 Date-Received: Thu, 20-Aug-87 01:58:32 EDT References: <8708112229.AA00510@apolling.imagen.uucp> Reply-To: phil@amdcad.UUCP (Phil Ngai) Distribution: world Organization: Advanced Micro Devices, Inc., Sunnyvale, Ca. Lines: 18 In article <8708112229.AA00510@apolling.imagen.uucp> geof@apolling.UUCP (Geof Cooper) writes: > >PS: The cover IS blue on version 2. The cover of version 1 was gray > with a blue stripe. Hm, my version 1.0 is all blue. So is my 2.0, but a different tint. I got them from the Xerox office in Sunnyvale, which used to be Shugart facilities. But that's not the reason for this article. I heard there was a mistake in the example transceiver cable receiver circuit which was never fixed. I must say I can't understand why the data valid signal is fed back to those two line termination resistors (39 ohms). Any comments? -- I speak for myself, not the company. Phil Ngai, {ucbvax,decwrl,allegra}!amdcad!phil or amdcad!phil@decwrl.dec.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708190020.AA27806@mtxinu.UUCP] <1987081813152100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: chuck@excelan.UUCP (Chuck Kollars, ) Newsgroups: comp.protocols.tcp-ip Subject: posting for moderated news group protocols.tcp-ip Message-ID: <8708190020.AA27806@mtxinu.UUCP> Date: Tue, 18-Aug-87 17:15:21 EDT Article-I.D.: mtxinu.8708190020.AA27806 Posted: Tue Aug 18 17:15:21 1987 Date-Received: Thu, 20-Aug-87 06:27:51 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 31 Subject: 2 IP's on 1 LAN Keywords: TCP-IP Vitalink MAC-Bridge Ethernet The need to have 2 logically separate IP networks on a single datalink (specifically, an Ethernet LAN) for administrative reasons has arisen. [Examples: a) Some nodes on a LAN have officially assigned IP addresses because they sometimes interoperate with another network. To conserve IP addresses, other nodes on the same LAN are assigned IP addresses from a separate address space. b) Two networks which are geographically separated, and which have been administered separately, are now being connected by a Vitalink datalink-level MAC-bridge.] Based on experience with similar situations, is the best course of action to: 1) Modify the IP routing algorithm in each node to understand the notion of a "direct" route. 2) Reassign IP addresses so that all nodes have the same IP network number. 3) Install separate devices which act as fake gateways. 4) Other -------------------------------------------------------------------- Chuck Kollars - address for direct mail responses: arpa: mtxinu!excelan!chuck@ucbvax.berkeley.edu uucp: ...ucbvax!mtxinu!excelan!chuck ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708181940.aa03922@Huey.UDEL.EDU] <1987081815401400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Generalized Subnetting Message-ID: <8708181940.aa03922@Huey.UDEL.EDU> Date: Tue, 18-Aug-87 19:40:14 EDT Article-I.D.: Huey.8708181940.aa03922 Posted: Tue Aug 18 19:40:14 1987 Date-Received: Thu, 20-Aug-87 06:22:38 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 14 Phil, You have described the scheme used in the intrepid fuzzballs, although those animals use a full 32-bit mask to allow arbitrary field geometries. The problem is that the scheme is not particularly fast and is hard to hash. The solution may be an algorithm that quickly turns a description such as yours into a partition of the 32-bit space which can be hashed and used in a match-once fashion. The fuzzscheme, now indigenous to the NSFNET Backbone, provides a hand way to build ARPANET tunnels through other nets, which has been found a handy feature during times when routing is otherwise broken. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987081818355200> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Tue 18 Aug 87 15:46:01-PDT Received: by ucbvax.Berkeley.EDU (5.58/1.27) id AA04719; Tue, 18 Aug 87 15:40:14 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 18 Aug 87 18:35:52 GMT From: gorodish!guy@sun.com (Guy Harris) Subject: Re: RFS vs NFS Message-Id: <25915@sun.uucp> References: <255@srs.UUCP>, <5502@felix.UUCP>, <5724@felix.UUCP> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa > Hang on a minute mate. If all the file system isn't in NFS, what is NFS? > A piece of the file system? As in, "part of our file system is stateless". > If, in order to implement the entire file system, you have to access > components that are not stateless, then isn't it incorrect to say that > the file system is stateless? It depends on your definition of "file system". All the functions necessary for opening, reading, writing, getting the status of, ... files are in NFS. None of the functions necessary for locking regions of files are in NFS. NFS isn't a file system; it's an RPC-based mechanism for performing certain operations on remote file systems. Its semantics match the UNIX file system better than they match those of other file systems, but it is used for other file system types, e.g. MS-DOS. Applications running on a machine with NFS generally don't use NFS, they use the native OS's file manipulation operations. Some of those map to NFS operations, or to sets of NFS operations, some don't. For example, a UNIX "open" will map to a series of NFS "lookup" operations, and some other operations; a "read" will map to one or more NFS "read" operations, if the data to be read isn't in the buffer cache. However, an "fcntl" call to lock a file will map to a lock manager RPC call, not to any NFS RPC calls. If you are using file or record locking, then no, the file system that the application sees is not stateless, since that file system is implemented both by the NFS and by the lock manager. If you are not using file or record locking, then the file system the the application sees is stateless. Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708190304.AA04309@faline.bellcore.com] <1987081819041400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: karn@FALINE.BELLCORE.COM.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: Generalized Subnetting Message-ID: <8708190304.AA04309@faline.bellcore.com> Date: Tue, 18-Aug-87 23:04:14 EDT Article-I.D.: faline.8708190304.AA04309 Posted: Tue Aug 18 23:04:14 1987 Date-Received: Fri, 21-Aug-87 04:38:06 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 16 I thought this probably wasn't original, but I'm glad to see somebody else considers it worthwhile. I too was concerned about the speed of the algorithm. I originally implemented it in a totally brute-force fashion. A "for" loop searches the hash table 32 times starting with the widest possible mask and working down until it hits a match. I assumed I would have to place a cache on top of this to get decent performance. To my delight, however, I discovered that going all the way down to the default entry still took only 6 milliseconds -- on a Taiwanese PC/XT turbo clone! Given the channel speeds involved in the environment I wrote my software for, I didn't consider further optimization to be a high priority task. Sometimes brute force is good enough... Phil ----MESSAGE-END---- ----MESSAGE-BEGIN---- [526@cernvax.UUCP] <1987081902071100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ben@cernvax.UUCP (ben) Newsgroups: comp.protocols.tcp-ip Subject: TCP/IP for Motorola RMS68K O/S ?? Message-ID: <526@cernvax.UUCP> Date: Wed, 19-Aug-87 06:07:11 EDT Article-I.D.: cernvax.526 Posted: Wed Aug 19 06:07:11 1987 Date-Received: Sat, 22-Aug-87 18:16:30 EDT Reply-To: ben@cernvax.UUCP (via mcvax) / ben@cernvax.bitnet Distribution: world Organization: CERN European Laboratory for Particle Physics, CH-1211 Geneva, Switzerland Lines: 9 Keywords: TCP/IP RMS68K NFS I'm not sure this went out correctly last week, so am resending: forgive me if it did..... We are looking for possible TCP/IP implementations for 68K systems running the Motorola RMS68k operating system. We are interested both in the case where all of the protocols and utilities run on the 68K, or where an intelligent board is used, e.g. Excelan, CMC, etc. (for VME-based systems). A big bonus would be the additional availability of (at least client) NFS. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708191010.aa11019@Huey.UDEL.EDU] <1987081906100500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Generalized Subnetting Message-ID: <8708191010.aa11019@Huey.UDEL.EDU> Date: Wed, 19-Aug-87 10:10:05 EDT Article-I.D.: Huey.8708191010.aa11019 Posted: Wed Aug 19 10:10:05 1987 Date-Received: Sat, 22-Aug-87 00:47:44 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 16 Phil, Well, brute force is not enough when there are 270 vanilla IP entries in the table, not to mention subnets, tunnels and crooked passageways. A gateway popping 6 ms per packet (133 packet/s) is probably too slow for any trunkline use. In my experience the depth of search is seldom more than three, one for the martian filter, one for the subnet and one for the net. Tunnels and defaults add another one each, but these are seldom used. With fuzzballs type-of-service adds another level for each TOS combination and an alternate-routing feature (fallback) adds another. With these last the tables get so intricate and delicate that I hesitate to use them outside the lab. This is where we need some clever algorithmic translation between the handy descriptions you and I are using and the actual table structure/cache that drives the routing function. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [599@ms3.UUCP] <1987081910095200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: isns01@ms3.UUCP (Jim Chappell) Newsgroups: comp.sources.wanted,comp.protocols.tcp-ip Subject: Wanted -- 4.2 BSD Exterior Gateway Protocol Message-ID: <599@ms3.UUCP> Date: Wed, 19-Aug-87 14:09:52 EDT Article-I.D.: ms3.599 Posted: Wed Aug 19 14:09:52 1987 Date-Received: Sat, 22-Aug-87 04:29:08 EDT Organization: ISN HIOS Project, Arlington, VA Lines: 10 Keywords: EGP We need the source to EGP. We can't upgrade to 4.3 BSD because our Office System Vendor, CCI, says they won't support their product under 4.3. We have a 4.2 BSD license. Thanks, -- Jim Chappell UUCP: ...!umd5!vrdxhq!ms3!jrc ISN Corp. (703) 979-8900 ARPA: jrc@hios-pent 1235A Jeff Davis Hwy, Suite 220 Arlington, Va 22202 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708191816.AA09774@topaz.rutgers.edu] <1987081910161600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ron@TOPAZ.RUTGERS.EDU (Ron Natalie) Newsgroups: comp.protocols.tcp-ip Subject: Re: DDN Node Location Message-ID: <8708191816.AA09774@topaz.rutgers.edu> Date: Wed, 19-Aug-87 14:16:16 EDT Article-I.D.: topaz.8708191816.AA09774 Posted: Wed Aug 19 14:16:16 1987 Date-Received: Sat, 22-Aug-87 02:38:07 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 13 It's best to have the node closer to the computer that it serves. The lines are cheaper to run (just plain ol' telephone wire) to the node than it is to extend the cables between the hosts and the node. Since the trunks are already on modems, rerouting the wire is not a big effort. Extending the cables to the hosts would require running larger cables for short distances or the purchase of modems (for X.25 and HDH) or ECU's and Modems (for LH/DH) that would not ordinarily be necessary. The idea of a distributed packet switch network is to put the switches near the end points not to centrally locate them. -Ron ----MESSAGE-END---- ----MESSAGE-BEGIN---- [20176@ucbvax.BERKELEY.EDU] <1987081912154300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: spp@zion.berkeley.edu (Steve Pope) Newsgroups: comp.protocols.tcp-ip Subject: SLIP Message-ID: <20176@ucbvax.BERKELEY.EDU> Date: Wed, 19-Aug-87 16:15:43 EDT Article-I.D.: ucbvax.20176 Posted: Wed Aug 19 16:15:43 1987 Date-Received: Sat, 22-Aug-87 04:08:00 EDT Sender: usenet@ucbvax.BERKELEY.EDU Reply-To: spp@zion (Steve Pope) Distribution: world Organization: Experimental Computing Facility, U.C. Berkeley Lines: 8 I've seen references here and there to "SLIP", which I believe stands for "Serial Link Internet Protocol". It is used, I understand, to run IP links over duplex serial lines or modems. Can anyone tell me a little more about SLIP? Thanks in advance. steve pope ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1672@ho95e.ATT.COM] <1987081917475100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: wcs@ho95e.ATT.COM (Bill.Stewart) Newsgroups: news.groups,comp.protocols.tcp-ip Subject: Does comp.protocols.iso exist? Message-ID: <1672@ho95e.ATT.COM> Date: Wed, 19-Aug-87 21:47:51 EDT Article-I.D.: ho95e.1672 Posted: Wed Aug 19 21:47:51 1987 Date-Received: Sat, 22-Aug-87 06:30:57 EDT References: <1510@hou2d.UUCP> Reply-To: wcs@ho95e.UUCP (46133-Bill.Stewart,2G218,x0705,) Distribution: na Organization: AT&T Bell Labs 46133, Holmdel, NJ Lines: 9 Original-Subject: Re: Is there anybody out there ? In article <1510@hou2d.UUCP> n2dsy@hou2d.UUCP (J.BEATTIE) writes: :I guess this is a relatively new newsgroup...my system :doesn't seem to have any items listed. I never got a newgroup message, but I remember some discussion a couple months ago. Was the group ever approved? Is it part of inet? -- # Thanks; # Bill Stewart, AT&T Bell Labs 2G218, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708201334.AA17184@ACC-SB-UNIX.ARPA] <1987082005343200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: kzm@ACC-SB-UNIX.ARPA (Keith McCloghrie) Newsgroups: comp.protocols.tcp-ip Subject: Re: Broadcast/Multicast on ARPANET Message-ID: <8708201334.AA17184@ACC-SB-UNIX.ARPA> Date: Thu, 20-Aug-87 09:34:32 EDT Article-I.D.: ACC-SB-U.8708201334.AA17184 Posted: Thu Aug 20 09:34:32 1987 Date-Received: Sat, 22-Aug-87 10:06:15 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 19 Phil, You point out a number of the ways in which the capability of providing subnet broadcasting or multicasting in the ARPANET could be very useful. I agree. However, I suggest that there would need to be some safeguards installed to prevent the ARPANET from becoming susceptible to the kind of meltdowns which occur in LANs when this capability is abused. The absence of this capability in the wide-area currently provides a firebreak between LAN-subnet clusters, to prevent a meltdown from encompassing the whole internet. Possible safeguards could include : only administratively-authorized Host-ports should have this capability and even the Hosts connected to those should be required to prove that abuse will not occur; restrictions on the types of packets/destination-addresses which are to be forwarded by gateways using this capability. Maybe, only multicasting should be supported (not broadcasting) ? Keith. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708201947.AA11834@sneezy.lanl.gov] <1987082011471400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: cpw%sneezy@LANL.GOV (C. Philip Wood) Newsgroups: comp.protocols.tcp-ip Subject: DELUA interface driver needed Message-ID: <8708201947.AA11834@sneezy.lanl.gov> Date: Thu, 20-Aug-87 15:47:14 EDT Article-I.D.: sneezy.8708201947.AA11834 Posted: Thu Aug 20 15:47:14 1987 Date-Received: Sat, 22-Aug-87 16:13:39 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 5 I need a 4.3BSD DELUA driver. The DEUNA we use currently wedges. As I understand it, there is no software in the world which will make it work any better. So its time to trade up. -Phil Wood, (cpw@lanl.gov) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [301@ablnc.ATT.COM] <1987082012232300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: gil@ablnc.ATT.COM (Gil Widdowson) Newsgroups: comp.protocols.tcp-ip,comp.protocols.misc Subject: Using sockets select(3) function Message-ID: <301@ablnc.ATT.COM> Date: Thu, 20-Aug-87 16:23:23 EDT Article-I.D.: ablnc.301 Posted: Thu Aug 20 16:23:23 1987 Date-Received: Sat, 22-Aug-87 12:49:35 EDT Organization: AT&T, Maitland, Florida Lines: 26 Keywords: sockets select C I have been trying to use the select(3w) function to handle I/O on multiple datagram and virtual circuit fds. This is on a UTS system running Wollongong's TCP/IP. The general application I am trying to upgrade has been running under sockets on this machine for about a year using alarms to do polling. All fds were set to O_NDELAY after they were created. What I wanted to do was set up my fd masks and count and call select() with the time struct pointer set to NULL so it would pend until data came it. Well it just pended forever. So I figured that I misread the intent, and tried setting the time structure so it returned once a second. When it returned it always returned zero, and the masks were all zero. Stepping through in sdb() and forcing the code out of my pend loop, I always found the data that I knew was there. Am I doing something fundamentally wrong? ( I get same results on AT&T 3Bs which also run Wollongong port). A working scrap of code would be greatly appreciated. Thanks, Gil Widdowson AT&T DP&CT Maitland FL (305) 660-6123 {ihnp4, moss} abfli!utiprod!gil ----MESSAGE-END---- ----MESSAGE-BEGIN---- [3447@venera.isi.edu] <1987082022333900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: cracraft@venera.isi.edu (Stuart Cracraft) Newsgroups: comp.protocols.tcp-ip,comp.unix.wizards Subject: looping telnetd bug Message-ID: <3447@venera.isi.edu> Date: Fri, 21-Aug-87 02:33:39 EDT Article-I.D.: venera.3447 Posted: Fri Aug 21 02:33:39 1987 Date-Received: Sun, 23-Aug-87 02:31:27 EDT Organization: USC-Information Sciences Institute Lines: 7 Has anyone out there in netland encountered the mysterious looping telnetd bug? (the /etc/telnetd daemon). The first sign seems to be a telnetd process chewing up hours of cpu. Just wondered if someone else noticed it too. Stuart ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12:baard@vax.elab.unit.uninett] <1987082101343300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: baard%vax.elab.unit.uninett@TOR.NTA.NO (baard w torustad) Newsgroups: comp.protocols.tcp-ip Subject: tcp-ip for xenix on sperry pc Message-ID: <12:baard@vax.elab.unit.uninett> Date: Fri, 21-Aug-87 05:34:33 EDT Article-I.D.: vax.12:baard Posted: Fri Aug 21 05:34:33 1987 Date-Received: Sun, 23-Aug-87 00:42:49 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 7 i am looking for tcp-ip software for xenix on sperry personal computer. to which i can add my own link-layer protocol. (... for the B-channels on an ISDNetwork.) public domain or commercial. Baard Torustad, (baard%vax.elab.unit.uninett@nta-vax.arlook ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987082103090000> Received: from acc.arpa by SRI-NIC.ARPA with TCP; Fri 21 Aug 87 11:34:49-PDT Date: 21 Aug 87 11:09:00 PST From: Subject: TCP SRTT To: "tcp-ip" cc: ietf@gateway.mitre.org,art Reply-To: I implemented the SRTT algoritm posted by Van Jacobsen a while back. This is the one that accumulates both a smoothed round trip time estimate (SRTT) and also a smoothed variance estimate (which I call SRTV). The retransmit timer is set to: (SRTT + 2*SRTV)*rxmt_backoff_factor. This has greatly improved the behavior of TCP over low speed links (4800-9600 baud), while showing no noticable effect over Ethernet. Using the standard SRTT algorithm, I was seeing as low as 10% link utilization because of spurious retransmissions. The new algorithm is giving over 90% link utilization. I would recommend others consider using this algoritm if there TCP ever uses a path with large delay variance (such as low speed lines or Arpa Internet). Art Berggreen art@acc.arpa ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708211505.AA13694@decvax.dec.com] <1987082107053200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: templin@DECVAX.DEC.COM (Fred Templin) Newsgroups: comp.protocols.tcp-ip Subject: Re: DELUA interface driver needed Message-ID: <8708211505.AA13694@decvax.dec.com> Date: Fri, 21-Aug-87 11:05:32 EDT Article-I.D.: decvax.8708211505.AA13694 Posted: Fri Aug 21 11:05:32 1987 Date-Received: Sun, 23-Aug-87 01:23:12 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 13 Hi! The DELUA should be plug-compatible with the 4.3BSD if_de.c driver. I work with the ULTRIX network drivers, and the only change we've made for DELUA's is a check in the "deprobe" routine to make sure the board has passed power- up self test before forcing an interrupt. I don't believe this is done in the 4.3BSD driver, but I really don't see this as being a problem. I'd suggest just having field service install the DELUA and reboot (but, of course, I can't be held responsible!) Fred L. Templin ( templin@decvax.dec.com ) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708211856.AA09676@ucbvax.Berkeley.EDU] <1987082111090000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: art@ACC.ARPA Newsgroups: comp.protocols.tcp-ip Subject: TCP SRTT Message-ID: <8708211856.AA09676@ucbvax.Berkeley.EDU> Date: Fri, 21-Aug-87 15:09:00 EDT Article-I.D.: ucbvax.8708211856.AA09676 Posted: Fri Aug 21 15:09:00 1987 Date-Received: Sun, 23-Aug-87 02:43:25 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Distribution: world Organization: The ARPA Internet Lines: 19 I implemented the SRTT algoritm posted by Van Jacobsen a while back. This is the one that accumulates both a smoothed round trip time estimate (SRTT) and also a smoothed variance estimate (which I call SRTV). The retransmit timer is set to: (SRTT + 2*SRTV)*rxmt_backoff_factor. This has greatly improved the behavior of TCP over low speed links (4800-9600 baud), while showing no noticable effect over Ethernet. Using the standard SRTT algorithm, I was seeing as low as 10% link utilization because of spurious retransmissions. The new algorithm is giving over 90% link utilization. I would recommend others consider using this algoritm if there TCP ever uses a path with large delay variance (such as low speed lines or Arpa Internet). Art Berggreen art@acc.arpa ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708211920.AA05016@okeeffe.Berkeley.EDU] <1987082111201700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: karels%okeeffe@UCBVAX.BERKELEY.EDU (Mike Karels) Newsgroups: comp.protocols.tcp-ip Subject: Re: DELUA interface driver needed Message-ID: <8708211920.AA05016@okeeffe.Berkeley.EDU> Date: Fri, 21-Aug-87 15:20:17 EDT Article-I.D.: okeeffe.8708211920.AA05016 Posted: Fri Aug 21 15:20:17 1987 Date-Received: Sun, 23-Aug-87 02:46:59 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 97 Here are the changes Donn Seeley put into the 4.3 driver to wait for self test to complete on DELUA's. As Fred Templin says, there really shouldn't be any change required to the DEUNA driver for use with the DELUA, but the self-test may take longer than the 4.3 driver will wait. Mike *** /nbsd/sys/vaxif/if_de.c Thu Jun 5 17:02:59 1986 --- if_de.c Fri Jul 18 17:48:29 1986 *************** *** 5,7 **** * ! * @(#)if_de.c 7.1 (Berkeley) 6/5/86 */ --- 5,7 ---- * ! * @(#)if_de.c 7.2 (Berkeley) 7/18/86 */ *************** *** 125,126 **** --- 125,142 ---- + /* + * Make sure self-test is finished before we screw with the board. + * Self-test on a DELUA can take 15 seconds (argh). + */ + for (i = 0; + i < 160 && + (addr->pcsr0 & PCSR0_FATI) == 0 && + (addr->pcsr1 & PCSR1_STMASK) == STAT_RESET; + ++i) + DELAY(100000); + if ((addr->pcsr0 & PCSR0_FATI) != 0 || + (addr->pcsr1 & PCSR1_STMASK) != STAT_READY) + return(0); + + addr->pcsr0 = 0; + DELAY(100); addr->pcsr0 = PCSR0_RSET; *************** *** 148,149 **** --- 164,166 ---- register struct dedevice *addr = (struct dedevice *)ui->ui_addr; + int csr1; *************** *** 155,156 **** --- 172,186 ---- /* + * What kind of a board is this? + * The error bits 4-6 in pcsr1 are a device id as long as + * the high byte is zero. + */ + csr1 = addr->pcsr1; + if (csr1 & 0xff60) + printf("de%d: broken\n", ui->ui_unit); + else if (csr1 & 0x10) + printf("de%d: delua\n", ui->ui_unit); + else + printf("de%d: deuna\n", ui->ui_unit); + + /* * Reset the board and temporarily map *************** *** 158,159 **** --- 188,191 ---- */ + addr->pcsr0 = 0; /* reset INTE */ + DELAY(100); addr->pcsr0 = PCSR0_RSET; *************** *** 247,248 **** --- 279,282 ---- addr->pcsr3 = (incaddr >> 16) & 0x3; + addr->pclow = 0; /* reset INTE */ + DELAY(100); addr->pclow = CMD_GETPCBB; *************** *** 298,301 **** ds->ds_if.if_flags |= IFF_RUNNING; - destart(unit); /* queue output packets */ addr->pclow = PCSR0_INTE; /* avoid interlock */ ds->ds_flags |= DSF_RUNNING; /* need before de_setaddr */ --- 332,335 ---- ds->ds_if.if_flags |= IFF_RUNNING; addr->pclow = PCSR0_INTE; /* avoid interlock */ + destart(unit); /* queue output packets */ ds->ds_flags |= DSF_RUNNING; /* need before de_setaddr */ *************** *** 741,742 **** --- 775,779 ---- ds->ds_flags & DSF_RUNNING) { + ((struct dedevice *) + (deinfo[ifp->if_unit]->ui_addr))->pclow = 0; + DELAY(100); ((struct dedevice *) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [303@pvab.UUCP] <1987082208542200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: robert@pvab.UUCP (Robert Claeson) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: NFS for PC's Message-ID: <303@pvab.UUCP> Date: Sat, 22-Aug-87 12:54:22 EDT Article-I.D.: pvab.303 Posted: Sat Aug 22 12:54:22 1987 Date-Received: Sun, 23-Aug-87 21:42:36 EDT Organization: Statskonsult Programvaruhuset AB, Sweden Lines: 21 We're about to incorporate most of our PC's into the Ethernet w/TCP-IP we use for our UNIX machines. Since we use NFS on most computers, we think it would be a good idea to use NFS on the PC's as well. Now there's PC/NFS from Sun. Version 1.x is the one I've seen, but 2.x is released now. Rumours has it that Pyramid also has a NFS implementation for PC's. Which one should I use? The telnet in Sun's PC/NFS was almost useless. We need support for national characters, ie we need to be able to remap the keyboard in about the same way as SmarTerm 240. But maybe version 2.x is better? Or maybe I should continue to use ST240 for terminal communication, connected to a terminal server? By the way, is it possible to use another telnet together with Sun's PC/NFS and 3Com's EtherLink card? And is there only plain vt100 telnets for PC's? I could have use for vt240 emulation. Please respond me by e-mail, and I'll summarize the responses. -- SNAIL: Robert Claeson, PVAB, P.O. Box 4040, S-171 04 Solna, Sweden UUCP: {seismo,mcvax,munnari}!enea!pvab!robert ARPA: enea!pvab!robert@seismo.arpa ----MESSAGE-END---- ----MESSAGE-BEGIN---- [704@ucdavis.UUCP] <1987082213412900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mccall@iris.ucdavis.edu (Sam McCall) Newsgroups: comp.protocols.tcp-ip Subject: in.named on SunOS3.4 and its friends Message-ID: <704@ucdavis.UUCP> Date: Sat, 22-Aug-87 17:41:29 EDT Article-I.D.: ucdavis.704 Posted: Sat Aug 22 17:41:29 1987 Date-Received: Sun, 23-Aug-87 13:38:19 EDT Sender: uucp@ucdavis.UUCP Reply-To: mccall@iris.ucdavis.edu (Sam McCall) Distribution: world Organization: University of California, Davis Lines: 7 Keywords: SunOS3.4 ftp rlogin nameserver blech Has anyone had any success in getting things like telnet, ftp, rlogin, and so forth to work with the nameserver under SunOS 3.4? I've tried taking 4.2BSD source and compiling it on the suns with the resolver library, but it just doesn't seem to work. -sam ----MESSAGE-END---- ----MESSAGE-BEGIN---- [18020@amdcad.AMD.COM] <1987082311313000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: percy@amdcad.AMD.COM (Percy Irani) Newsgroups: comp.protocols.tcp-ip Subject: Sun routers... Message-ID: <18020@amdcad.AMD.COM> Date: Sun, 23-Aug-87 15:31:30 EDT Article-I.D.: amdcad.18020 Posted: Sun Aug 23 15:31:30 1987 Date-Received: Sun, 23-Aug-87 23:49:07 EDT Organization: Advanced Micro Devices, Inc., Sunnyvale, Ca. Lines: 24 Keywords: routers, Sun We are seriously considering evaluation of Sun based IP routers for our Ethernet. Does any one out (in the world) uses Sun routers for connecting their Ethernet (TCP/IP)? [ I know Sun does!! ] What about using them with DECNET sharing the same (leased phone) line? Any other problems people have encountered using the Sun product (ala reliability, routing updates, size constraints etc.) Does any one uses their software for network monitoring? What does the rest of the world use for network monitoring * - for monitoring their TCP/IP based Ethernet (for the main backbone) - for monitoring lease line(s) for other internet connections (lets assume all TCP/IP type connections). - Any public domain stuff? * monitoring = BIG WORD!! Like to know what other people do. There have been intresting articles in IEEE Network issues about them. Lets see whats being done in the world! -- Ignorance is bliss but can be embarassing at times! ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987082401562700> Received: from NNSC.NSF.NET (WS6.NNSC.NSF.NET) by SRI-NIC.ARPA with TCP; Mon 24 Aug 87 05:34:24-PDT To: amdcad!percy@ucbvax.berkeley.edu cc: tcp-ip@sri-nic.ARPA Subject: network monitoring etc. Date: Mon, 24 Aug 87 08:36:27 -0400 From: Craig Partridge Percy, Yes, monitoring is a BIG WORD. Network management (of which monitoring is only a part) is even bigger. If you are interested in these problems, I suggest you join the GWMON mailing list where most discussion of network management on IP networks is held. (Regarding the name, it started as GateWay MONitoring, and grew up). Send requests to gwmon-request@sh.cs.net. You might also keep an eye out for next spring's issue of IEEE Network which is devoted to Internetwork Management Protocols (and systems). Craig ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708241238.AA24418@ucbvax.Berkeley.EDU] <1987082404394300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: craig@NNSC.NSF.NET (Craig Partridge) Newsgroups: comp.protocols.tcp-ip Subject: network monitoring etc. Message-ID: <8708241238.AA24418@ucbvax.Berkeley.EDU> Date: Mon, 24-Aug-87 08:39:43 EDT Article-I.D.: ucbvax.8708241238.AA24418 Posted: Mon Aug 24 08:39:43 1987 Date-Received: Tue, 25-Aug-87 02:05:50 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 15 Percy, Yes, monitoring is a BIG WORD. Network management (of which monitoring is only a part) is even bigger. If you are interested in these problems, I suggest you join the GWMON mailing list where most discussion of network management on IP networks is held. (Regarding the name, it started as GateWay MONitoring, and grew up). Send requests to gwmon-request@sh.cs.net. You might also keep an eye out for next spring's issue of IEEE Network which is devoted to Internetwork Management Protocols (and systems). Craig ----MESSAGE-END---- ----MESSAGE-BEGIN---- [14003@hi.UUCP] <1987082409061300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: kurt@hi.UUCP (Kurt Zeilenga) Newsgroups: comp.protocols.tcp-ip Subject: Re: in.named on SunOS3.4 and its friends Message-ID: <14003@hi.UUCP> Date: Mon, 24-Aug-87 13:06:13 EDT Article-I.D.: hi.14003 Posted: Mon Aug 24 13:06:13 1987 Date-Received: Tue, 25-Aug-87 04:27:44 EDT References: <704@ucdavis.UUCP> Reply-To: kurt@hi.UUCP (Kurt Zeilenga) Organization: U. of New Mexico, Albuquerque Lines: 15 Keywords: SunOS3.4 ftp rlogin nameserver blech In article <704@ucdavis.UUCP> mccall@iris.ucdavis.edu (Sam McCall) writes: >Has anyone had any success in getting things like telnet, >ftp, rlogin, and so forth to work with the nameserver under >SunOS 3.4? I've tried taking 4.2BSD source and compiling >it on the suns with the resolver library, but it just doesn't >seem to work. > >-sam Assuming you got the named(8) running on your SUNs, and use YP, just start up ypserv with a -i flag. The YP server will then use the named(8) to resolve any unknown request. Your client will not use named(8) directly, but via the YP server. Good Luck. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987082412204300> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Mon 24 Aug 87 17:19:34-PDT Received: by ucbvax.Berkeley.EDU (5.58/1.27) id AA08369; Mon, 24 Aug 87 16:59:56 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 Aug 87 12:20:43 GMT From: mcvax!enea!tut!utacs!jaj@seismo.css.gov (Jari J{ntti) Organization: University of Tampere, Dept. of Computer Science, Finland Subject: NETBIOS over TCP/IP Message-Id: <497@utacs.UTA.FI> References: <8707291543.a017776@Louie.UDEL.EDU>, <8707292031.AA13932@columbia.edu> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa Is there a free source for NETBIOS over TCP/IP -implementation? There are two vendors (of which I know) who offer commercial versions -- Ungermann-Bass and Excelan. Anybody know the origin of these two? Jari Jantti University of Tampere Computing Center FINLAND JJANTTI@BITNET ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12237@bu-cs.BU.EDU] <1987082414150700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: tower@bu-cs.BU.EDU (Leonard H. Tower Jr.) Newsgroups: news.groups,comp.protocols.tcp-ip Subject: Re: Does comp.protocols.iso exist? Message-ID: <12237@bu-cs.BU.EDU> Date: Mon, 24-Aug-87 18:15:07 EDT Article-I.D.: bu-cs.12237 Posted: Mon Aug 24 18:15:07 1987 Date-Received: Tue, 25-Aug-87 05:34:49 EDT References: <1510@hou2d.UUCP> <1672@ho95e.ATT.COM> Reply-To: tower@bu-cs.bu.edu Followup-To: news.groups Distribution: na Organization: Distributed Systems Group, Boston University, 111 Cummington Street, Boston, MA 02215, USA +1 (617) 353-2780 Lines: 40 Home: 36 Porter Street, Somerville, MA 02143, USA +1 (617) 623-7739 In article <1672@ho95e.ATT.COM> wcs@ho95e.UUCP (46133-Bill.Stewart,2G218,x0705,) writes: > In article <1510@hou2d.UUCP> n2dsy@hou2d.UUCP (J.BEATTIE) writes: > :I guess this is a relatively new newsgroup...my system > :doesn't seem to have any items listed. > > I never got a newgroup message, but I remember some discussion a couple > months ago. Was the group ever approved? Is it part of inet? > -- > # Thanks; > # Bill Stewart, AT&T Bell Labs 2G218, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs comp.protocols.iso is an inet distribution newsgroup. If all of USENET wants it, just ask Eric Fair . Note that I am *NOT* conducting such a news group poll. (Perhaps Bill wants to?) Followups directed to news.groups. enjoy -len PS: comp.protocols.iso is gated with the Internet mailing list (this description is from ZELLICH's list-of-lists): ISO@NRTC.NORTHROP.COM Discussion group focusing on the ISO protocol stack. The list naturally has some overlap with the ISODE list; contributors are urged to use the appropriate list based on their topic of discussion. Archives are kept on the host NRTC-GREMLIN.NORTHROP.COM (128.99.0.17). Use "anonymous" ftp to retrieve file "archive/iso.mbox" which represents the current archives. All requests to be added to or deleted from this list, problems, questions, etc., should be sent to ISO-Request@NRTC.NORTHROP.COM. Coordinator: Marshall T. Rose -- Len Tower, Distributed Systems Group, Boston University, 111 Cummington Street, Boston, MA 02215, USA +1 (617) 353-2780 Home: 36 Porter Street, Somerville, MA 02143, USA +1 (617) 623-7739 UUCP: {}!harvard!bu-cs!tower INTERNET: tower@bu-cs.bu.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987082510223400> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Wed 26 Aug 87 02:49:30-PDT Received: by ucbvax.Berkeley.EDU (5.58/1.27) id AA11303; Wed, 26 Aug 87 02:39:58 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 25 Aug 87 10:22:34 GMT From: mcvax!cernvax!jmg@seismo.css.gov (jmg) Organization: CERN European Laboratory for Particle Physics, CH-1211 Geneva, Switzerland Subject: Re: NETBIOS over TCP/IP Message-Id: <528@cernvax.UUCP> References: <8707291543.a017776@Louie.UDEL.EDU>, <8707292031.AA13932@columbia.edu>, <497@utacs.UTA.FI> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa In article <497@utacs.UTA.FI> jaj@utacs.UUCP (Jari J{ntti) writes: >Is there a free source for NETBIOS over TCP/IP -implementation? >There are two vendors (of which I know) who offer commercial versions -- >Ungermann-Bass and Excelan. Anybody know the origin of these two? I don't know about U-B, but I am told that the Excelan product is not yet conforming with RFC 1001/2. Given the large number of mutually incompatible implementations of NETBIOS already available, I hope that people wanting NETBIOS on TCP/IP will wait for implementations matching these RFCs. I certainly am going to wait. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708251939.AA26971@ucbvax.Berkeley.EDU] <1987082511194200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mckenzie@J.BBN.COM (Alex McKenzie) Newsgroups: comp.protocols.tcp-ip Subject: "But my NCP costs $500 a day..." Message-ID: <8708251939.AA26971@ucbvax.Berkeley.EDU> Date: Tue, 25-Aug-87 15:19:42 EDT Article-I.D.: ucbvax.8708251939.AA26971 Posted: Tue Aug 25 15:19:42 1987 Date-Received: Thu, 27-Aug-87 00:49:07 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 10 I've been on vacation, or I would have provided the reference sooner. The author was BBN employee Bob Bressler, not Mike. The RFC number is 425. Regards, Alex ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987082511194201> Received: from J.BBN.COM by SRI-NIC.ARPA with TCP; Tue 25 Aug 87 12:34:39-PDT Date: Tue, 25 Aug 87 15:19:42 EDT From: Alex McKenzie To: Michael Padlipsky , pogran@J.BBN.COM cc: tcp-ip@SRI-NIC.ARPA Subject: "But my NCP costs $500 a day..." I've been on vacation, or I would have provided the reference sooner. The author was BBN employee Bob Bressler, not Mike. The RFC number is 425. Regards, Alex ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1261@spice.cs.cmu.edu] <1987082512442700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ecc@spice.cs.cmu.edu (Eric Cooper) Newsgroups: comp.protocols.tcp-ip Subject: Are simultaneous TCP opens useful? Message-ID: <1261@spice.cs.cmu.edu> Date: Tue, 25-Aug-87 16:44:27 EDT Article-I.D.: spice.1261 Posted: Tue Aug 25 16:44:27 1987 Date-Received: Thu, 27-Aug-87 02:04:16 EDT Organization: Carnegie-Mellon University, CS/RI Lines: 15 Can anyone defend the usefulness of allowing simultaneous active OPENs to result in a single connection? It seems to me that a pair of would-be communicants cannot rely on this to succeed, since it would depend on the relative time at which they give the OPEN command. Suppose an implementation rejected incoming SYNs when in the SYN-SENT state, instead of entering SYN-RECEIVED. How could you ever observe that this implementation is really nonconforming, and not just faster or slower? Am I wrong? Does anyone have examples of applications that depend on this feature? Eric Cooper (ecc@spice.cs.cmu.edu) Computer Science Department Carnegie Mellon University ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708252304.AA04887@gyre.umd.edu] <1987082515041000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: chris@GYRE.UMD.EDU (Chris Torek) Newsgroups: comp.protocols.tcp-ip Subject: Re: ethernet interface perversity Message-ID: <8708252304.AA04887@gyre.umd.edu> Date: Tue, 25-Aug-87 19:04:10 EDT Article-I.D.: gyre.8708252304.AA04887 Posted: Tue Aug 25 19:04:10 1987 Date-Received: Thu, 27-Aug-87 02:56:08 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 22 (Apparently, someone wants a single Ethernet interface to respond to ARP requests for several different Internet addresses.) Jim O'Toole did something like this under 4.2BSD, with an `IP magic' hook whereby all IP packets for one IP address were forwarded to a user-level program. It takes about 15 minutes to figure out where and what to write; we then had a user program that provided echo service a la goonhilly-echo.arpa. If all you want is for a 4.3 host to respond to multiple IP addresses, this is even easier. Configure some unused interface with the alternate address: # ifconfig lo1 a.b.c.d # or ifconfig sl1 a.b.c.d Add it to your arp table: # arp -s a.b.c.d pub You should be set once the router picks up the address a.b.c.d from interface sl0, or immediately if a.b.c.d is on the same `network' as the 4.3 host as far as the sender is concerned. I tested this, and gyre (128.8.128.77) did respond to packets for 128.8.128.200. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [2878@phri.UUCP] <1987082518504200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: roy@phri.UUCP (Roy Smith) Newsgroups: comp.protocols.tcp-ip Subject: Re: ethernet interface perversity Message-ID: <2878@phri.UUCP> Date: Tue, 25-Aug-87 22:50:42 EDT Article-I.D.: phri.2878 Posted: Tue Aug 25 22:50:42 1987 Date-Received: Fri, 28-Aug-87 02:09:14 EDT References: <8708050046.AA07011@ucbvax.Berkeley.EDU> <862@mcgill-vision.UUCP> Reply-To: roy@phri.UUCP (Roy Smith) Organization: Public Health Research Inst. (NY, NY) Lines: 13 In <862@mcgill-vision.UUCP> mouse@mcgill-vision.UUCP (der Mouse) writes: # If this is so it is a software problem. I can see no reason why UNIX (say) # couldn't be set up to respond to ARP requests for more than one IP address # per interface. The Kinetics KFPS Ethernet-to-AppleTalk bridge box (at least when loaded with the Stanford KIP gateway code) is quite capable of responding to multiple IP addresses using a single ethernet address. If KIP can do it, I don't see any reason why a UNIX kernel can't. -- Roy Smith, {allegra,cmcl2,philabs}!phri!roy System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1615@briar.Philips.Com] <1987082607070700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jmr@philabs.Philips.Com (Joanne Mannarino) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: SUN 3.4 problems Message-ID: <1615@briar.Philips.Com> Date: Wed, 26-Aug-87 11:07:07 EDT Article-I.D.: briar.1615 Posted: Wed Aug 26 11:07:07 1987 Date-Received: Sat, 29-Aug-87 09:02:31 EDT Organization: Philips Laboratories, Briarcliff Manor, NY. Lines: 66 In trying to upgrade our SUN 3/180 fileserver (named condor) to SUN UNIX version 3.4 along with 11 diskless clients, I ran into some problems. The upgrade procedure on condor went fine. I reconfigured the kernel for 3.4, rebooted condor and still no problem. Then I tried booting up all of the diskless clients (one at a time) and then the headaches began. The booting process began with "requesting internet address" with the host responding with the correct information (thus there is communication via our Ethernet). The problem began when the booting process got to the point for: starting rpc and net services: portmap router biod The boot process then halts with the following error messages: server not responding RPC: program not registered mount retrying /usr /usr/condor This will remain at this point until you either manually abort or power down the unit. At this point, any active workstation on the network (ie, SUNs either connected to our other fileserver (which still runs 3.2) or diskful SUNs sitting on the net) displays a screenful of "ie0: no carrier" and "Ethernet jammed" error messages. I contacted SUN support immediately and after running tests to see if all of the daemons that should be running were running, the conclusion was made by SUN that the problem is somewhere within our Ethernet structure. SUN said that 3.4 includes major changes in the Ethernet drivers that don't correct for possible problems in the network. At this point SUN support referred me to someone in their Data Communications support department. After running some net stats and sending them the data, I was told "your network looks ok". BUT still we are having problems. We've tried some different things to see if we could isolate the problem (actually this was done before the fileserver upgrade, but we wrote it off as being a network problem isolated to a particular laboratory). We tried running a diskful 3/160 as a server for a diskless 3/160 both running 3.4 and we ran across the same problems. It was suggested that we take both units off of our main net and hook them up directly to their own mini net. When this was done, the problem went away, ie, the client came up running 3.4. We have also tried changing the /etc/fstab on a client and "backgrounding" the mount process. This results in the client coming up in single user mode. Then after trying to manually mount a filesystem, I get the above errors of "server not responding" and "mount retrying". As an interim solution, we have kept the 3.4 enhancements (I didn't back out of the upgrade) and are running a 3.2 kernel. Everything seems fine, but this still doesn't solve our problem. Some SUN reps claim that the problem is definitely with our network, others say it's in the 3.4 software. Anyone else experienced these symptoms when upgrading to 3.4? Any suggestions on what we should do now? thanks in advance, Joanne Mannarino -- joanne mannarino seismo!philabs!jmr philips laboratories or (914)945-6008 jmr@philabs.philips.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708261808.AA16444@sneezy.lanl.gov] <1987082610081600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: cpw%sneezy@LANL.GOV (C. Philip Wood) Newsgroups: comp.protocols.tcp-ip Subject: Suns, Symbolics, Celerities and Reverse ARP Message-ID: <8708261808.AA16444@sneezy.lanl.gov> Date: Wed, 26-Aug-87 14:08:16 EDT Article-I.D.: sneezy.8708261808.AA16444 Posted: Wed Aug 26 14:08:16 1987 Date-Received: Fri, 28-Aug-87 06:17:59 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 18 Excuse if you already know about this problem. But, a recent release of software for the Celerity OS caused a big headache here at LANL. The symptom was Suns and Symbolics machines could not boot or communicate because they could not find out their internet addresses via RARP. Or, rather, they found out a wrong address, namely 0.0.0.0. This tidbit of information was provided by the Celerity RARP handler. I give credit to Celerity for finding out about the problem and fixing it. However, it took some sluthing with etherfind to figure out who the culprit was on our part. And, then finding the offending piece of hardware, and then finding someone who would take responsibility for it, and then calling up Celerity support. Once we got that far the fix was easy. Run ifconfig with the -arp option, and wait for the patch tapes in the mail. The came the next day. Phil Wood (cpw@lanl.gov) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708261820.AA16452@sneezy.lanl.gov] <1987082610202800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: cpw%sneezy@LANL.GOV (C. Philip Wood) Newsgroups: comp.protocols.tcp-ip Subject: Broadcast Storms Message-ID: <8708261820.AA16452@sneezy.lanl.gov> Date: Wed, 26-Aug-87 14:20:28 EDT Article-I.D.: sneezy.8708261820.AA16452 Posted: Wed Aug 26 14:20:28 1987 Date-Received: Fri, 28-Aug-87 06:19:09 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 17 This subject may have been discussed before. But, LANL was experiencing broadcast storms on an ethernet. About 100 hosts on the ether would send a message back to a lone Ultrix V2.0-1 (Microvax) system running the rwho daemon every few minutes. It was broadcasting to 128.165.255.255 and all these hosts were sending back some kind of arp to find out who the guy was so they could probably send him some kind of response (Connection refused?). Anyhow, as in the problem with reverse arp responses of zero (a previous missive) I spent some time tracking down the culprit. Once I found him, the fix was to terminate the rwho daemon (and remove entry from the startup file). Network management in a heterogeneous environment, anyone? Phil Wood (cpw@lanl.gov ----MESSAGE-END---- ----MESSAGE-BEGIN---- [870826171713.7.DCP@KOYAANISQATSI.S4CC.Symbolics.COM] <1987082613170000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: DCP@QUABBIN.SCRC.Symbolics.COM (David C. Plummer) Newsgroups: comp.protocols.tcp-ip Subject: Suns, Symbolics, Celerities and Reverse ARP Message-ID: <870826171713.7.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Date: Wed, 26-Aug-87 17:17:00 EDT Article-I.D.: KOYAANIS.870826171713.7.DCP Posted: Wed Aug 26 17:17:00 1987 Date-Received: Fri, 28-Aug-87 07:25:46 EDT References: <8708261808.AA16444@sneezy.lanl.gov> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 30 Date: Wed, 26 Aug 87 12:08:16 MDT From: cpw%sneezy@LANL.GOV (C. Philip Wood) Excuse if you already know about this problem. But, a recent release of software for the Celerity OS caused a big headache here at LANL. The symptom was Suns and Symbolics machines could not boot or communicate because they could not find out their internet addresses via RARP. Point of information: The released Symbolics system does not use RARP at all. (It normally gets it's Internet address from the namespace object for the host, which it finds from the chaos address, which is specified in the boot file.) I suspect the Symbolics systems couldn't boot for some other reason, such as failing to get valid ARP responses from the servers. Or, rather, they found out a wrong address, namely 0.0.0.0. This tidbit of information was provided by the Celerity RARP handler. I give credit to Celerity for finding out about the problem and fixing it. However, it took some sluthing with etherfind to figure out who the culprit was on our part. And, then finding the offending piece of hardware, and then finding someone who would take responsibility for it, and then calling up Celerity support. Once we got that far the fix was easy. Run ifconfig with the -arp option, and wait for the patch tapes in the mail. The came the next day. Phil Wood (cpw@lanl.gov) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708270241.AA17670@topaz.rutgers.edu] <1987082618410500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hedrick@topaz.rutgers.EDU (Charles Hedrick) Newsgroups: comp.protocols.tcp-ip Subject: Re: Sun routers... Message-ID: <8708270241.AA17670@topaz.rutgers.edu> Date: Wed, 26-Aug-87 22:41:05 EDT Article-I.D.: topaz.8708270241.AA17670 Posted: Wed Aug 26 22:41:05 1987 Date-Received: Sat, 29-Aug-87 06:23:19 EDT References: <18020@amdcad.AMD.COM> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 47 Sun's Ethernet hardware is quite good. There's no reason in principle why a Sun couldn't be a very good IP gateway. However there are some practical things that make this less than optimal. The versions of SunOS we have seen are based on 4.2. In order to avoid stability problems, gateways have to have much more careful validation of packets than 4.2 does. E.g. they have to recognize every possible broadcast address format, and also refuse to forward packets for invalid addresses (as opposed for example to sending ARP requests for Martian addresses). This is somewhat better in 4.3 than 4.2, but even 4.3 does not recognize all possible old and new style broadcast addresses, nor as far as I can tell does it have a complete Martian filter. We expect our gateways to do proxy ARP (for hosts that can't handle subnets, and a few that can't even deal with routing). This is not present in 4.2, and as far as I know is not in 4.3 either. We expect our gateways to be up all the time. Normal timesharing systems are taken down periodically for PM, software installation, etc. Our gateways (cisco) download software from a server. Going to a new release requires downtime of about 30 seconds. Suns typically require a good deal longer than this to bring up new releases. Some sites also take them down for backups, and now and then they crash (though in honesty I'd have to say that our Suns are very stable). I believe that the operational requirements of a gateway are at least slightly inconsistent with those of a host. If you are building a large or complex network, the vendors whose business is making routers are likely to have better routing technology than routed, to support a wider variety of media, (As an example, we tried to interface our Sun to the Arpanet and found that although 1822 interfaces existed, we couldn't find anyone who knew how to get them.), and to be more aggressive about supporting new network monitoring standards. In the long run, there are going to be performance advantages. At the moment, Suns probably perform at least as well at connecting Ethernets as the typical dedicated routers. We have used Suns as gateways between major Ethernets and restricted Ethernets containing only diskless Suns. They perform very well at this. I'm sure we will continue to use Suns as gateways to one extent or another. However for large networks, those with complex topologies, and those serving machines from many vendors (and with buggy TCP implementations), I would recommend using a gateway from a vendor that specializes in such things. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12329710967.136.SY.KEN@CU20B.COLUMBIA.EDU] <1987082618451100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: sy.Ken@CU20B.COLUMBIA.EDU (Ken Rossman) Newsgroups: comp.protocols.tcp-ip Subject: Re: Broadcast Storms Message-ID: <12329710967.136.SY.KEN@CU20B.COLUMBIA.EDU> Date: Wed, 26-Aug-87 22:45:11 EDT Article-I.D.: CU20B.12329710967.136.SY.KEN Posted: Wed Aug 26 22:45:11 1987 Date-Received: Sat, 29-Aug-87 06:22:59 EDT Sender: uucp@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 Please forgive my ignorance in these matters (I'm still pretty new to a lot of this), but shouldn't the decision as to whether to address broadcasts using an IP address like X.Y.255.255, as opposed to X.Y.0.0 be done by the kernal and not some daemon (rwho)? Again, I'm not clear on this, as I only got part of an explanation of this awhile back, but isn't the X.Y.255.255 format an old style (obsolete?) broadcast format, and X.Y.0.0 the current way to broadcast? Or are they both valid but used differently? /Ken ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708270339.AA20547@topaz.rutgers.edu] <1987082619390900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick) Newsgroups: comp.protocols.tcp-ip Subject: Re: Broadcast Storms Message-ID: <8708270339.AA20547@topaz.rutgers.edu> Date: Wed, 26-Aug-87 23:39:09 EDT Article-I.D.: topaz.8708270339.AA20547 Posted: Wed Aug 26 23:39:09 1987 Date-Received: Sun, 30-Aug-87 01:11:43 EDT References: <8708261820.AA16452@sneezy.lanl.gov> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 45 Maybe we need to keep a collection of known causes of broadcast storms, and send them to the list once a month. Almost certainly what is going on is that most of your machines are configured to expect 128.165.0.0 as a broadcast address (this would be the default for 4.2), and they have ipforwarding turned on. Thus the 128.165.255.255 looks to them like an attempt to send a message to a host with this address. Since ipforwarding is on, they try to be nice and forward the message. Thus they ARP 128.165.255.255. The real fix is to make sure that every one of your machines has the stormproofing code in it that I have posted several times. (In brief, 1) in ipintr, make sure that all possible broadcast addresses are recognized. 2) in udp_input, fix the code that sends unreachables so that its test for broadcast addresses includes all possible addresses 3) in ip_forward, when ipforwarding is off, discard the packet in all cases with no error message. [4.3 has fixed this already, but not 4.2.] Leave ipforwarding off except on actual gateways, and if you use Unix hosts as gateways, make sure that proper Martian filtering, etc., is done. ) However it is often impossible to modify the code on every one of your machines. In that case, a reasonable approach is to make sure that every one of your machines agrees about the broadcast address. 4.2 systems will use net.0.0. 4.3 systems and Ultrix will default to net.255.255, but allow an option -broadcast in ifconfig to set a different address. I suggest that you set your Ultrix machine to use 128.165.0.0 as its broadcast address. This is a violation of the standards, but it's better to have everyone on your network agree than to have one lone machine be right. I do not recommend rwho on big networks in any case. But it should not cause storms. There are enough other uses of broadcasts that you should make sure they are safe. I would set the broadcast address to 128.165.0.0 and turn rwho back on. Now use Etherfind on a Sun (or netwatch on a PC, but if you have 100 machines on an Ethernet, it is worth buying a Sun just to run Etherfind) and verify that you are not seeing any ARP's for 128.165.0.0, nor any ICMP unreachables. If you see either of these, start tracking down the hosts one by one and fixing them. If you are using level 2 Bridges, you are asking for this sort of thing. In that case, you should do this sort of test periodically to make sure no new problems have crept into your network. If there are any hosts that insist on sending garbage in response to broadcasts, isolate them from the rest of your network with a gateway. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[A.ISI.EDU]27-Aug-87.00:42:03.CERF] <1987082620420000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: CERF@A.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Are simultaneous TCP opens useful? Message-ID: <[A.ISI.EDU]27-Aug-87.00:42:03.CERF> Date: Thu, 27-Aug-87 00:42:00 EDT Article-I.D.: <[A.ISI.EDU]27-Aug-87.00:42:03.CERF> Posted: Thu Aug 27 00:42:00 1987 Date-Received: Sun, 30-Aug-87 01:01:30 EDT References: <1261@spice.cs.cmu.edu> Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 Distributed systems with symmetric processes that automatically seek to link to each other (no master/slave relationship) would use the simul-OPEN style. It was designed into TCP for that purpose; I do not know, however, whether any actual applications have made use of this feature. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987082701070000> Received: from acc.arpa by SRI-NIC.ARPA with TCP; Thu 27 Aug 87 09:10:59-PDT Date: 27 Aug 87 09:07:00 PST From: Subject: Symetric TCP opens To: "cerf" cc: tcp-ip@sri-nic.arpa Reply-To: >Distributed systems with symmetric processes that automatically seek >to link to each other (no master/slave relationship) would use the >simul-OPEN style. It was designed into TCP for that purpose; I do not >know, however, whether any actual applications have made use of this >feature. > >Vint Vint, We have developed systems that live on TCP/IP networks and communicate with each other in a symetric peer fashion. When one of these boxes starts up, it attempts to open TCP connections with its peers. The connection attempt starts actively by sending SYNs. If the remote end doesn't respond, the TCP port goes into LISTEN, assuming that the other end will eventually initiate the connection. Art Berggreen art@acc.arpa ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708270922.AA06419@topaz.rutgers.edu] <1987082701222100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick) Newsgroups: comp.protocols.tcp-ip Subject: Re: Broadcast Storms Message-ID: <8708270922.AA06419@topaz.rutgers.edu> Date: Thu, 27-Aug-87 05:22:21 EDT Article-I.D.: topaz.8708270922.AA06419 Posted: Thu Aug 27 05:22:21 1987 Date-Received: Sat, 29-Aug-87 11:53:56 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 7 X.Y.255.255 is the new form. X.Y.0.0 is the old form. Unfortunately it is easier to convince new software to use the old than old software to use the new. So until everybody updates, it may be easiest to stick with the old format. The decision is in fact made in the kernel, not rwho. You use ifconfig to choose the broadcast address. Ifconfig is a program that primarily does system calls to set up various options in the kernel. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987082703033800> Received: from PARK-STREET.BBN.COM by SRI-NIC.ARPA with TCP; Thu 27 Aug 87 07:27:25-PDT To: CERF@A.ISI.EDU cc: ecc@SPICE.CS.CMU.EDU, tcp-ip@SRI-NIC.ARPA, hinden@PARK-STREET.BBN.COM Subject: Re: Are simultaneous TCP opens useful? In-reply-to: Your message of 27 Aug 87 00:42:00 -0400. <[A.ISI.EDU]27-Aug-87 00:42:03.CERF> Date: Thu, 27 Aug 87 09:43:38 -0400 From: Robert Hinden Vint, The only example I can think of is the Automated Network Management (ANM) system. It uses TCP as the base for its interprocess communication which allows it processes to be easily distributed. Bob ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708271439.AA05573@ucbvax.Berkeley.EDU] <1987082707042600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hinden@PARK-STREET.BBN.COM.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: Are simultaneous TCP opens useful? Message-ID: <8708271439.AA05573@ucbvax.Berkeley.EDU> Date: Thu, 27-Aug-87 11:04:26 EDT Article-I.D.: ucbvax.8708271439.AA05573 Posted: Thu Aug 27 11:04:26 1987 Date-Received: Sat, 29-Aug-87 17:03:44 EDT References: <[A.ISI.EDU]27-Aug-87.00:42:03.CERF> Sender: usenet@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 7 Vint, The only example I can think of is the Automated Network Management (ANM) system. It uses TCP as the base for its interprocess communication which allows it processes to be easily distributed. Bob ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12329849264.136.SY.KEN@CU20B.COLUMBIA.EDU] <1987082707245200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: sy.Ken@CU20B.COLUMBIA.EDU (Ken Rossman) Newsgroups: comp.protocols.tcp-ip Subject: Re: Broadcast Storms Message-ID: <12329849264.136.SY.KEN@CU20B.COLUMBIA.EDU> Date: Thu, 27-Aug-87 11:24:52 EDT Article-I.D.: CU20B.12329849264.136.SY.KEN Posted: Thu Aug 27 11:24:52 1987 Date-Received: Sat, 29-Aug-87 12:11:34 EDT References: <8708270922.AA06419@topaz.rutgers.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 16 X.Y.255.255 is the new form. X.Y.0.0 is the old form. Unfortunately it is easier to convince new software to use the old than old software to use the new. So until everybody updates, it may be easiest to stick with the old format. The decision is in fact made in the kernel, not rwho. You use ifconfig to choose the broadcast address. Ifconfig is a program that primarily does system calls to set up various options in the kernel. I guess the reason I asked about this was because we've seen those broadcast storms here a number of times, and so apparently have other sites, yet in answer to this problem, folks keep saying the "fix" is to kill the rwho daemon, as though rwho was directly responsible for net storms. Rwho is doing its job properly -- it's the kernal that's goofing up. Rwho ain't the only thing around that's gonna cause ARP broadcast anyway, is it? /Ken ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708271602.AA08523@mitre-bedford.ARPA] <1987082708021900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: sra@mitre-bedford.ARPA.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: NETBIOS over TCP/IP Message-ID: <8708271602.AA08523@mitre-bedford.ARPA> Date: Thu, 27-Aug-87 12:02:19 EDT Article-I.D.: mitre-be.8708271602.AA08523 Posted: Thu Aug 27 12:02:19 1987 Date-Received: Sat, 29-Aug-87 17:07:15 EDT References: <528@cernvax.UUCP> Sender: usenet@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 5 I am under the impression that the new Bridge products implement RFCs 1001 and 1002. Of course they do not interoperate with other netbios implementations yet as they are the first to announce it. Stan Ames ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708272358.AA14612@ucbvax.Berkeley.EDU] <1987082709070000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: art@ACC.ARPA Newsgroups: comp.protocols.tcp-ip Subject: Symetric TCP opens Message-ID: <8708272358.AA14612@ucbvax.Berkeley.EDU> Date: Thu, 27-Aug-87 13:07:00 EDT Article-I.D.: ucbvax.8708272358.AA14612 Posted: Thu Aug 27 13:07:00 1987 Date-Received: Sat, 29-Aug-87 14:14:52 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Organization: The ARPA Internet Lines: 22 >Distributed systems with symmetric processes that automatically seek >to link to each other (no master/slave relationship) would use the >simul-OPEN style. It was designed into TCP for that purpose; I do not >know, however, whether any actual applications have made use of this >feature. > >Vint Vint, We have developed systems that live on TCP/IP networks and communicate with each other in a symetric peer fashion. When one of these boxes starts up, it attempts to open TCP connections with its peers. The connection attempt starts actively by sending SYNs. If the remote end doesn't respond, the TCP port goes into LISTEN, assuming that the other end will eventually initiate the connection. Art Berggreen art@acc.arpa ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [4355@elroy.Jpl.Nasa.Gov] <1987082710492200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: earle@jplopto.uucp (Greg Earle) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: SUN 3.4 problems Message-ID: <4355@elroy.Jpl.Nasa.Gov> Date: Thu, 27-Aug-87 14:49:22 EDT Article-I.D.: elroy.4355 Posted: Thu Aug 27 14:49:22 1987 Date-Received: Sun, 30-Aug-87 06:14:58 EDT References: <1615@briar.Philips.Com> Sender: news@elroy.Jpl.Nasa.Gov Reply-To: earle@jplopto.JPL.NASA.GOV (Greg Earle) Followup-To: poster Organization: Jet Propulsion Laboratory, Pasadena, CA Lines: 23 Keywords: /etc/servers YP Summary: Another possibility Joanne, Are you running YP? Your boots are dying when it tries to do NFS mounts; in order to do this there has to be an entry for the rpc.mountd daemon in /etc/servers, so the program can be registered. Trouble is, when you install diskless clients, either /etc/servers or /etc/services (or both) *do not get installed* on diskless clients. If it is /etc/servers and (I think) you do not run Yellow Pages, then the portmapper will not be able to get the entry for the server, and it will emit the messages you describe. I suggest you halt all your diskless clients, retry the 3.4 kernel on `condor', then successively mount /dev/ndl[0-9?] onto /mnt, and do a cp /etc/servers /mnt/etc/servers (and do /etc/services just to make sure). Then unmount /mnt. After you're all done, reboot the server with the 3.4 kernel, then try the client reboots again. See what happens. Just a thought, - Greg Greg Earle earle@jplopto.JPL.NASA.GOV Sun Consulting earle%jplopto@jpl-elroy.ARPA [aka:] (Freelance - earle%jplopto@elroy.JPL.NASA.GOV write me) ...!cit-vax!elroy!smeagol!jplopto!earle ----MESSAGE-END---- ----MESSAGE-BEGIN---- [14266@topaz.rutgers.edu] <1987082711215800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hedrick@topaz.rutgers.edu (Charles Hedrick) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: SUN 3.4 problems Message-ID: <14266@topaz.rutgers.edu> Date: Thu, 27-Aug-87 15:21:58 EDT Article-I.D.: topaz.14266 Posted: Thu Aug 27 15:21:58 1987 Date-Received: Sat, 29-Aug-87 10:07:18 EDT References: <1615@briar.Philips.Com> Organization: Rutgers Univ., New Brunswick, N.J. Lines: 70 I claim no expertise in SunOS 3.4. We are using 3.2 with locally-added networking enhancements that put it somewhere between 3.3 and 3.4 in terms of functionality. However from your results, it sounds like Sun's diagnosis is right. The fact that your hosts all get "ie0: no carrier" or "Ethernet jammed" strongly indicates a broadcast storm. The fact that things work when you use a separate Ethernet suggests that there is no error in your software or setup. However it's not quite right to say that the problem is with your "network". The problem is not with the network itself, but with the hosts on that network. If all of the hosts on it are Suns, then Sun can't entirely avoid blame. 3.4 is based on 4.3BSD's version of IP. 3.2 is based on 4.2BSD's version of IP. Between 4.2 and 4.3, the broadcast address was changed. (The people who changed the standard should be shot. The amount of damage done to networks and the reputation of IP due to inconsistent broadcast addresses is enormous. By the way, this is not Berkeley's fault. The standard actually changed.) Unfortunately, there are various bugs in 4.2 (and presumably Sun 3.2), such that any disagreement over the broadcast address can cause such a flurry of ICMP unreachables and ARP's that the network becomes unusable. The solution is going to depend upon the particular set of machines on your network. You have two choices: find some broadcast address on which everyone can agree, or split the network. 4.3-based systems allow you to set the broadcast address. So do some 4.2-based systems that contain "4.3 enhancements". This includes Ultrix and Pyramid. Unmodified 4.2 systems use net.0 as the broadcast address. E.g. if your network number is 128.6, your broadcast address is 128.6.0.0. The new standard allows either 128.6.255.255 or 255.255.255.255. If you are using subnets, things get more complex. 4.2 didn't support subnets, but if you patched your 4.2 to do so, you will probably have ended up with a broadcast address of net.subnet.0. E.g. for us a typical one would be 128.6.4.0. The new standard, and 4.3, say that the correct broadcast address for a subnetted network is 128.6.4.255. One approach would be to tell your 4.3-based systems (i.e. your Sun 3.4 systems) to use the old broadcast address. There should be an option to ifconfig to do this. What bothers me is that this option may not take effect during the early stages of booting. However the simplest thing to try would be to change the ifconfig commands, normally present in /etc/rc or /etc/rc.boot to contain the appropriate option. Assuming you don't use subnets, this would be something like ifconfig ie0 `/bin/hostname` up -trailers broadcast 128.6.0.0 Everything up to "broadcast" should be whatever your ifconfig command is now. It may be that the option is -broadcast. You should use your own net number in place of 128.6.0.0. You must make this change to /etc/rc.boot for every individual client partition. This means you'll have to bring up the clients one by one single-user or just mount the partitions on the server, using /dev/ndlx (making sure that the clients are not running at the time). You might try this for a few clients to see whether it fixes your problem, before doing it on all of them. In retrospect, Sun would probably have been better off distributing 3.4 with the old broadcast address as a default. Once everyone had upgraded to 3.4, the next release could safely move to the new address, since 3.4 should (if it is properly implemented) accept either. At the very least the setup program should provide this as an option. (Of course I haven't seen 3.4 yet -- maybe it does.) Other approaches to this problem are to fix all your existing systems to accept the new address (which may be the best solution if you have source to them -- we can give you the changes), or to put a gateway between your 3.4 systems and everything else. If you don't have any other kind of gateway, you could add a second Ethernet board to one of your servers and use it as a gateway. Finally, if all of your systems are Suns, the simplest thing to do is simply to upgrade them all at once. Bring them all down, and then bring them up one by one on 3.4. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [280@nrc-ut.UUCP] <1987082713482600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: andre@nrc-ut.UUCP (Andre' Hut) Newsgroups: comp.protocols.tcp-ip Subject: Re: Are simultaneous TCP opens useful? Message-ID: <280@nrc-ut.UUCP> Date: Thu, 27-Aug-87 17:48:26 EDT Article-I.D.: nrc-ut.280 Posted: Thu Aug 27 17:48:26 1987 Date-Received: Sun, 30-Aug-87 06:23:15 EDT References: <1261@spice.cs.cmu.edu> Reply-To: andre@nrc-ut.UUCP (Andre' Hut) Organization: Network Research Corp. Salt Lake City, UT Lines: 28 In article <1261@spice.cs.cmu.edu> ecc@spice.cs.cmu.edu (Eric Cooper) writes: >Can anyone defend the usefulness of allowing simultaneous active OPENs to >result in a single connection? It seems to me that a pair of would-be >communicants cannot rely on this to succeed, since it would depend on the >relative time at which they give the OPEN command. > >Suppose an implementation rejected incoming SYNs when in the SYN-SENT state, >instead of entering SYN-RECEIVED. How could you ever observe that this >implementation is really nonconforming, and not just faster or slower? > >Am I wrong? Does anyone have examples of applications that depend on this >feature? yeah.. A pipe. A TCP connection can be used as a pipe if it connects to itself. This sounds wierd, but it works, and its a guaranteed simultaneous open. -- ----------------------------------------------------------------------------- sdcsvax-\ ihnp4-\ \ \ Andre' Hut sdcrdcf!psivax!nrcvax!nrc-ut!andre / / / hplabs--/ ucbvax!calma-/ / utah-gr!uplherc/ Network Research Corporation 923 Executive Park Dr. Suite C Salt Lake City, Utah 84117 ----------------------------------------------------------------------------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708272207.AA02104@sluggo.sun.com] <1987082714071200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: melohn@SUN.COM.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: Sun routers... Message-ID: <8708272207.AA02104@sluggo.sun.com> Date: Thu, 27-Aug-87 18:07:12 EDT Article-I.D.: sluggo.8708272207.AA02104 Posted: Thu Aug 27 18:07:12 1987 Date-Received: Sat, 29-Aug-87 16:04:39 EDT References: <8708270241.AA17670@topaz.rutgers.edu> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 77 >The versions of SunOS we have seen are based on 4.2. In order to >avoid stability problems, gateways have to have much more careful >validation of packets than 4.2 does. E.g. they have to recognize >every possible broadcast address format, and also refuse to forward >packets for invalid addresses (as opposed for example to sending ARP >requests for Martian addresses). This is somewhat better in 4.3 than >4.2, but even 4.3 does not recognize all possible old and new style >broadcast addresses, nor as far as I can tell does it have a complete >Martian filter. We have gradually introduced many 4.3 networking features into various release of SunOS, beginning with SunOS 3.3. We plan to have all of 4.3 features in the next major release of SunOS. > >We expect our gateways to do proxy ARP (for hosts that can't handle >subnets, and a few that can't even deal with routing). This is not >present in 4.2, and as far as I know is not in 4.3 either. > Proxy ARP exists for Sun machines. If it is generally felt that this is a hinderance to using Suns as internet gateways, we will look into making it a supported part of the product. >We expect our gateways to be up all the time. Normal timesharing >systems are taken down periodically for PM, software installation, >etc. Our gateways (cisco) download software from a server. Going to >a new release requires downtime of about 30 seconds. Suns typically >require a good deal longer than this to bring up new releases. Some >sites also take them down for backups, and now and then they crash >(though in honesty I'd have to say that our Suns are very stable). >I believe that the operational requirements of a gateway are at least >slightly inconsistent with those of a host. This is historically a reasonable arguement, especially when dealing with large host systems that support timesharing or other loads. Within our own internal network we have many dedicated gateway machines with no local file system to backup whose uptime is regularly measured in weeks. Our network is built mostly out of file server machines with two ethernet interfaces; these are maintained by a central support staff, and support both diskless clients and internetworking connectivity. Having several gateways between each network distributes the load and increases the redundancy if any particular node fails. A diskless Sun running as a dedicated network server offers much the same network-loadable gateway capability as a cisco box at approximetly the same cost, albeit both the client and its server must be reliable. > >If you are building a large or complex network, the vendors whose >business is making routers are likely to have better routing >technology than routed, to support a wider variety of media, (As an >example, we tried to interface our Sun to the Arpanet and found that >although 1822 interfaces existed, we couldn't find anyone who knew how >to get them.), and to be more aggressive about supporting new network >monitoring standards. Here, I take strong exception to your statements! Pardon the commercial, but I don't know of any gateway box vendor who supports the range of media AND protocols that Sun currently supports. We run IP over Ethernet, Token bus, and load-shared sync connections; we offer gateways to DECnet, OSI, SNA, etc. We have had an DDN gateway product for almost a year, supporting both 1822 and X.25. We are actively involved in both Internet and OSI protocol committees, and as standards emerge that replace routed, EGP, and friends, we will have products that implement those standards. > >In the long run, there are going to be performance advantages. At >the moment, Suns probably perform at least as well at connecting >Ethernets as the typical dedicated routers. > Sun continues to be very agressive in delivering multiple MIPS at the lowest cost per MIP in the business. The technology that brings forth low cost high powered workstations can also be used just as effectively for high speed internet gateways. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708272316.AA02140@sluggo.sun.com] <1987082715164600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: melohn@SUN.COM (Bill Melohn) Newsgroups: comp.protocols.tcp-ip Subject: Re: Sun routers... Message-ID: <8708272316.AA02140@sluggo.sun.com> Date: Thu, 27-Aug-87 19:16:46 EDT Article-I.D.: sluggo.8708272316.AA02140 Posted: Thu Aug 27 19:16:46 1987 Date-Received: Sat, 29-Aug-87 14:15:13 EDT References: <8708270241.AA17670@topaz.rutgers.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 53 >We expect our gateways to be up all the time. Normal timesharing >systems are taken down periodically for PM, software installation, >etc. Our gateways (cisco) download software from a server. Going to >a new release requires downtime of about 30 seconds. Suns typically >require a good deal longer than this to bring up new releases. Some >sites also take them down for backups, and now and then they crash >(though in honesty I'd have to say that our Suns are very stable). >I believe that the operational requirements of a gateway are at least >slightly inconsistent with those of a host. This is historically a reasonable arguement, especially when dealing with large host systems that support timesharing or other loads. Within our own internal network we have many dedicated gateway machines with no local file system to backup whose uptime is regularly measured in weeks. Our network is built mostly out of file server machines with two ethernet interfaces; these are maintained by a central support staff, and support both diskless clients and internetworking connectivity. Having several gateways between each network distributes the load and increases the redundancy if any particular node fails. A diskless Sun running as a dedicated network server offers much the same network-loadable gateway capability as a cisco box at approximetly the same cost, albeit both the client and its server must be reliable. > >If you are building a large or complex network, the vendors whose >business is making routers are likely to have better routing >technology than routed, to support a wider variety of media, (As an >example, we tried to interface our Sun to the Arpanet and found that >although 1822 interfaces existed, we couldn't find anyone who knew how >to get them.), and to be more aggressive about supporting new network >monitoring standards. Here, I take strong exception to your statements! Pardon the commercial, but I don't know of any gateway box vendor who supports the range of media AND protocols that Sun currently supports. We run IP over Ethernet, Token bus, and load-shared sync connections; we offer gateways to DECnet, OSI, SNA, etc. We have had an DDN gateway product for almost a year, supporting both 1822 and X.25. We are actively involved in both Internet and OSI protocol committees, and as standards emerge that replace routed, EGP, and friends, we will have products that implement those standards. > >In the long run, there are going to be performance advantages. At >the moment, Suns probably perform at least as well at connecting >Ethernets as the typical dedicated routers. > Sun continues to be very agressive in delivering multiple MIPS at the lowest cost per MIP in the business. The technology that brings forth low cost high powered workstations can also be used just as effectively for high speed internet gateways. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708272338.aa04715@Huey.UDEL.EDU] <1987082719380200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: Are simultaneous TCP opens useful? Message-ID: <8708272338.aa04715@Huey.UDEL.EDU> Date: Thu, 27-Aug-87 23:38:02 EDT Article-I.D.: Huey.8708272338.aa04715 Posted: Thu Aug 27 23:38:02 1987 Date-Received: Sat, 29-Aug-87 15:58:33 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 9 Vint, The vintage Internet Message Protocol (RFC-759) uses, at least in some implementations, port 45 for both source and destination. The result is that it is readily possible that simultaneous connection attempts can result in a single synchronized connection. This was considered a feature. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [4358@elroy.Jpl.Nasa.Gov] <1987082720540100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: david@elroy.Jpl.Nasa.Gov (David Robinson) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: SUN 3.4 problems Message-ID: <4358@elroy.Jpl.Nasa.Gov> Date: Fri, 28-Aug-87 00:54:01 EDT Article-I.D.: elroy.4358 Posted: Fri Aug 28 00:54:01 1987 Date-Received: Sun, 30-Aug-87 06:18:03 EDT References: <1615@briar.Philips.Com> <14266@topaz.rutgers.edu> Organization: Image Analysis Systems Grp, JPL Lines: 13 Summary: WIN 3.0? It has been noted before by someone that SunOS 3.4 does not check to see if the value of the ICMP mask request is valid. Supposedly Wollengong Win 3.0 for VMS returns back a subnet address of 0x0000FFFF which then causes the Suns to go into a broadcast storm. You then must disconnect the VMS Vaxen and reboot all Suns. -- David Robinson elroy!david@csvax.caltech.edu ARPA david@elroy.jpl.nasa.gov (new) seismo!cit-vax!elroy!david UUCP Disclaimer: No one listens to me anyway! ----MESSAGE-END---- ----MESSAGE-BEGIN---- [4359@elroy.Jpl.Nasa.Gov] <1987082721060500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: david@elroy.Jpl.Nasa.Gov (David Robinson) Newsgroups: comp.protocols.tcp-ip Subject: Re: Broadcast Storms Message-ID: <4359@elroy.Jpl.Nasa.Gov> Date: Fri, 28-Aug-87 01:06:05 EDT Article-I.D.: elroy.4359 Posted: Fri Aug 28 01:06:05 1987 Date-Received: Sun, 30-Aug-87 06:18:16 EDT References: <8708270922.AA06419@topaz.rutgers.edu> Organization: Image Analysis Systems Grp, JPL Lines: 26 Summary: WRONG! In article <8708270922.AA06419@topaz.rutgers.edu>, hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick) writes: > X.Y.255.255 is the new form. X.Y.0.0 is the old form. Unfortunately > it is easier to convince new software to use the old than old software > to use the new. So until everybody updates, it may be easiest to > stick with the old format. Agreed, until you have a net where 100% can understand new style broadcasts you should leave it as the old style. > The decision is in fact made in the > kernel, not rwho. You use ifconfig to choose the broadcast address. > Ifconfig is a program that primarily does system calls to set up > various options in the kernel. WRONG! All of the programs in the 4.3bsd distribution that broadcast make an ioctl call to get the kernel broadcast address which is set via /etc/ifconfig. SunOS 3.[3-4] suffers from the fact that none of their programs that broadcast check the kernel broadcast address and insist on using old style 4.2bsd broadcasts. -- David Robinson elroy!david@csvax.caltech.edu ARPA david@elroy.jpl.nasa.gov (new) seismo!cit-vax!elroy!david UUCP Disclaimer: No one listens to me anyway! ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987082805470000> Mail-From: STJOHNS created at 28-Aug-87 12:52:05 Date: 28 Aug 1987 12:47-PDT Sender: STJOHNS@SRI-NIC.ARPA Subject: Where can I find SLIP server for 4.2/3? From: Mike StJohns To: tcp-ip@SRI-NIC.ARPA Message-ID: <[SRI-NIC.ARPA]28-Aug-87 12:47:01.STJOHNS> The subject says it all. Is there a public domain SLIP server for a 4.2 based system available anywhere? I've got a bunch of IBM PCs I want to run over something called a CO-LAN (wire replacement system). Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987082807084900> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Sat 29 Aug 87 08:51:20-PDT Received: by ucbvax.Berkeley.EDU (5.58/1.27) id AA05980; Sat, 29 Aug 87 08:44:42 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 28 Aug 87 07:08:49 GMT From: bpa!sjuvax!bbanerje@burdvax.prc.unisys.com (B. Banerjee) Organization: St. Joseph's University, Phila. PA. Subject: How do I turn on RARP handling. Message-Id: <841@sjuvax.UUCP> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa Hi, I've been adding a bunch of PC's with various network boards/software to our little local net. I'd like to turn on RARP (if possible) on one of our Unix systems. Most of the users of these PC's will be regular users. I would like to be able to give them a diskette and have them insert and run it (Just like wordstar or something). At any rate, I figured that I could centralise the management by letting them get their internet addresses via RARP. Unfortunately I can't seem to find out how to turn it on with our Vax. We're running BSD 4.3. In case it makes a difference, we also have a Microvax running Ultrix 2.0 and a Sun 2 running 3.4 on the same network (Well, actually the Sun is waiting for the Ethernet-2 board). So, turning it on for one of these is also a possibility. I grepped through the sources, the documentation, and the manual pages. The only match I found was in trek(6), which gave me ``w\fRarp drive''. Though it sounds like fun, I don't think that's what I want :-( Thanks (in anticipation), Binayak Banerjee {allegra | astrovax | bpa | burdvax}!sjuvax!bbanerje bbanerje%sjuvax.sju.edu@relay.cs.net ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708281527.AA03523@topaz.rutgers.edu] <1987082807273100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ron@TOPAZ.RUTGERS.EDU (Ron Natalie) Newsgroups: comp.protocols.tcp-ip Subject: Re: Broadcast Storms Message-ID: <8708281527.AA03523@topaz.rutgers.edu> Date: Fri, 28-Aug-87 11:27:31 EDT Article-I.D.: topaz.8708281527.AA03523 Posted: Fri Aug 28 11:27:31 1987 Date-Received: Sun, 30-Aug-87 01:12:22 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 4 More than likely they were arping because they were attempting to forward the datagram. -Ron ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708281633.AA00133@apolling.imagen.uucp] <1987082808334500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: geof@imagen.UUCP (Geof Cooper) Newsgroups: comp.protocols.tcp-ip Subject: Re: Re: Sun routers... Message-ID: <8708281633.AA00133@apolling.imagen.uucp> Date: Fri, 28-Aug-87 12:33:45 EDT Article-I.D.: apolling.8708281633.AA00133 Posted: Fri Aug 28 12:33:45 1987 Date-Received: Sun, 30-Aug-87 02:49:28 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: imagen!geof@decwrl.dec.com Organization: The ARPA Internet Lines: 15 Interdispersed with much stuff with which I have no problem, you write: > ..... Having several gateways between each > network distributes the load and increases the redundancy if any > particular node fails..... "Distributes the load"? I know of no network standard that allows this to happen. It is a major failing of the Internet protocol suite that redundant gateways improve the reliability of an internet, but don't increase its capacity to handle traffic (not that other protocols such as XNS or DECNET been more successful). If you have accomplished this, can you let us all know how? - Geof ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12330130206.13.SATZ@MATHOM.CISCO.COM] <1987082809080800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: SATZ@MATHOM.CISCO.COM (Greg Satz) Newsgroups: comp.protocols.tcp-ip Subject: Re: Sun routers... Message-ID: <12330130206.13.SATZ@MATHOM.CISCO.COM> Date: Fri, 28-Aug-87 13:08:08 EDT Article-I.D.: MATHOM.12330130206.13.SATZ Posted: Fri Aug 28 13:08:08 1987 Date-Received: Sun, 30-Aug-87 01:39:48 EDT References: <8708272207.AA02104@sluggo.sun.com> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 12 It seems the internet gateway market is heating (or flaming) up. Instead of vendors showing off their features in a public forum like TCP-IP, maybe an interested member of the community would be willing to chase down the features and capabilities of the latest off-the-shelf products from the gateway vendors and make them available. This may be more beneficial to more people. As an aside, it seems that the europeans have a show called "CeBIT MultiNET, the new dimension in communication" where many vendors with TCP-IP products get together and do what they do best -- interoperate. Seems like a good idea to me. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [2006@bcsaic.UUCP] <1987082809131600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: randy@bcsaic.UUCP (Randy Groves) Newsgroups: comp.protocols.tcp-ip Subject: Pointer to latest SLIP Message-ID: <2006@bcsaic.UUCP> Date: Fri, 28-Aug-87 13:13:16 EDT Article-I.D.: bcsaic.2006 Posted: Fri Aug 28 13:13:16 1987 Date-Received: Sun, 30-Aug-87 08:48:01 EDT Organization: Boeing Computer Services ATC, Seattle Lines: 15 Could somebody give me a pointer to the latest implementation of SLIP that exists?? If there's a version for Ultrix 1.2 or 2.0 that would be the best, but anything that will work with the fairly current 4.2/3 would be fine. Email only please. If I get a lot of responses, I'll summarize to this group. Thanks much. -- -randy groves - Boeing Advanced Technology Center UUCP: ..!uw-beaver!uw-june!bcsaic!randy USNail: Boeing Computer Services CSNET: randy@boeing.com PO Box 24346 M/S 7L-68 VOICE: (206)865-3424 Seattle, WA 98124 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987082810510000> Received: from twg.arpa by SRI-NIC.ARPA with TCP; Fri 28 Aug 87 17:54:08-PDT Date: 28 Aug 87 17:51:00 PDT From: "Jerry Scott" Subject: RE: SUN 3.4 problems To: "tcp-ip" cc: Reply-To: "Jerry Scott" I think your problem has to do with ICMP Mask Requests from your Sun 3.4. In release 3.3 and 3.4, diskless suns starting asking the net for network masks. This is all well and good, but when you have hosts on your net giving you the wrong answer... There is a bug in 4.3BSD and (sorry to say) Wollongong's VAX/VMS release 3.0 networks that causes them to respond to ICMP Mask Requests with the wrong answer (actually the answer is right but is not byte swapped into network order before sent out onto the cable). Anyway the fix for 4.3BSD is to modify the file netinet/ip_icmp.c in routine icmp_input as follows: CHANGE: case ICMP_MASKREQ: if (icmplen < ICMP_MASKLEN || (ia = ifptoia(ifp)) == 0) break; icp->icmp_type = ICMP_MASKREPLY; icp->icmp_mask = ia->ia_netmask; TO: case ICMP_MASKREQ: if (icmplen < ICMP_MASKLEN || (ia = ifptoia(ifp)) == 0) break; icp->icmp_type = ICMP_MASKREPLY; icp->icmp_mask = htonl(ia->ia_netmask); To fix your Wollongong host, use anonymous ftp from another Wollongong VMS machine, set ftp transfer type to BINARY and transfer structure to RECORD, and get file ip_icmp.o. By the way, there is another work-around if you are familiar with dealing with disk partitions for client hosts on your sun servers. Get into the root partitions for the diskless hosts and modify the /etc/rc.boot files to issue the "ifconfig" command properly, for example: ifconfig ie0 192.5.36.4 ... netmask 255.255.255.0 Hope this helps, I think this was discussed earlier but your message shows the symptom from the sun's point of view. I hope Sun support is taking note of this. Jerry Scott ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[SRI-NIC.ARPA]28-Aug-87.12:47:01.STJOHNS] <1987082811470000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: StJohns@SRI-NIC.ARPA (Mike StJohns) Newsgroups: comp.protocols.tcp-ip Subject: Where can I find SLIP server for 4.2/3? Message-ID: <[SRI-NIC.ARPA]28-Aug-87.12:47:01.STJOHNS> Date: Fri, 28-Aug-87 15:47:00 EDT Article-I.D.: <[SRI-NIC.ARPA]28-Aug-87.12:47:01.STJOHNS> Posted: Fri Aug 28 15:47:00 1987 Date-Received: Sun, 30-Aug-87 04:09:19 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 4 The subject says it all. Is there a public domain SLIP server for a 4.2 based system available anywhere? I've got a bunch of IBM PCs I want to run over something called a CO-LAN (wire replacement system). Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708282256.AA11117@ucbvax.Berkeley.EDU] <1987082814350000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: LYNCH@A.ISI.EDU (Dan Lynch) Newsgroups: comp.protocols.tcp-ip Subject: Re: Sun routers... Message-ID: <8708282256.AA11117@ucbvax.Berkeley.EDU> Date: Fri, 28-Aug-87 18:35:00 EDT Article-I.D.: ucbvax.8708282256.AA11117 Posted: Fri Aug 28 18:35:00 1987 Date-Received: Sun, 30-Aug-87 04:44:07 EDT References: <12330130206.13.SATZ@MATHOM.CISCO.COM> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 16 Greg, The "good idea" you refer to (Europeans putting on a TCP/IP interoperability show) is something that we are working on here in the USA. We are working with many dozens of vendors to construct a permanent facility for demonstrating TCP/IP interoperability to the public. It will be open daily and we have scheduled the opening for January, 1988. It will live at Techmart, next to the Santa Clara Convention Center and should be an impressive activity. It is called the Connectivity Showcase and will be paid for by the vendors who want to clearly demonstrate that their products run harmoniously together. Users will be able to come in and run demos between any machines they wish to find out about. If it really catches on we wil be opening up additional sites in other US locations. Dan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987082814350001> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Fri 28 Aug 87 15:40:35-PDT Date: 28 Aug 1987 18:35:00 EDT Subject: Re: Sun routers... From: Dan Lynch To: Greg Satz cc: tcp-ip@SRI-NIC.ARPA, LYNCH@A.ISI.EDU In-Reply-To: <12330130206.13.SATZ@MATHOM.CISCO.COM> Greg, The "good idea" you refer to (Europeans putting on a TCP/IP interoperability show) is something that we are working on here in the USA. We are working with many dozens of vendors to construct a permanent facility for demonstrating TCP/IP interoperability to the public. It will be open daily and we have scheduled the opening for January, 1988. It will live at Techmart, next to the Santa Clara Convention Center and should be an impressive activity. It is called the Connectivity Showcase and will be paid for by the vendors who want to clearly demonstrate that their products run harmoniously together. Users will be able to come in and run demos between any machines they wish to find out about. If it really catches on we wil be opening up additional sites in other US locations. Dan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708290110.AA13873@ucbvax.Berkeley.EDU] <1987082816510000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jerry@TWG.ARPA ("Jerry Scott") Newsgroups: comp.protocols.tcp-ip Subject: RE: SUN 3.4 problems Message-ID: <8708290110.AA13873@ucbvax.Berkeley.EDU> Date: Fri, 28-Aug-87 20:51:00 EDT Article-I.D.: ucbvax.8708290110.AA13873 Posted: Fri Aug 28 20:51:00 1987 Date-Received: Sun, 30-Aug-87 06:20:03 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: "Jerry Scott" Organization: The ARPA Internet Lines: 45 I think your problem has to do with ICMP Mask Requests from your Sun 3.4. In release 3.3 and 3.4, diskless suns starting asking the net for network masks. This is all well and good, but when you have hosts on your net giving you the wrong answer... There is a bug in 4.3BSD and (sorry to say) Wollongong's VAX/VMS release 3.0 networks that causes them to respond to ICMP Mask Requests with the wrong answer (actually the answer is right but is not byte swapped into network order before sent out onto the cable). Anyway the fix for 4.3BSD is to modify the file netinet/ip_icmp.c in routine icmp_input as follows: CHANGE: case ICMP_MASKREQ: if (icmplen < ICMP_MASKLEN || (ia = ifptoia(ifp)) == 0) break; icp->icmp_type = ICMP_MASKREPLY; icp->icmp_mask = ia->ia_netmask; TO: case ICMP_MASKREQ: if (icmplen < ICMP_MASKLEN || (ia = ifptoia(ifp)) == 0) break; icp->icmp_type = ICMP_MASKREPLY; icp->icmp_mask = htonl(ia->ia_netmask); To fix your Wollongong host, use anonymous ftp from another Wollongong VMS machine, set ftp transfer type to BINARY and transfer structure to RECORD, and get file ip_icmp.o. By the way, there is another work-around if you are familiar with dealing with disk partitions for client hosts on your sun servers. Get into the root partitions for the diskless hosts and modify the /etc/rc.boot files to issue the "ifconfig" command properly, for example: ifconfig ie0 192.5.36.4 ... netmask 255.255.255.0 Hope this helps, I think this was discussed earlier but your message shows the symptom from the sun's point of view. I hope Sun support is taking note of this. Jerry Scott ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [18120@amdcad.AMD.COM] <1987082818485300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: percy@amdcad.AMD.COM (Percy Irani) Newsgroups: comp.protocols.tcp-ip Subject: IBM's TCP-IP announcement.. Message-ID: <18120@amdcad.AMD.COM> Date: Fri, 28-Aug-87 22:48:53 EDT Article-I.D.: amdcad.18120 Posted: Fri Aug 28 22:48:53 1987 Date-Received: Sun, 30-Aug-87 06:30:04 EDT Organization: Advanced Micro Devices, Inc., Sunnyvale, Ca. Lines: 22 Keywords: TCP-IP, IBM Is there any one out there who has experience with the recent (!) announcements by IBM regarding TCP-IP for VM/CMS, IBM-PC (using 8232). Any real users already? I attended a satellite presentation by IBM. It looks like Columbia University uses that. Any one from Columbia can comment? Im specially intrested in things like - speed - how close are they to standards :-) - how well does the product interface to things like the batch monitor to do remote batch submissions? etc... - Any monitoring capability (problem isolation?) - Can Sun make use of that for NFS etc... i.e. can other products like NFS, Apollo's NCS etc run with that? (may be this is a repeat of the standards question I had earlier!) Forum.... any comments? -- Ignorance is bliss but can be embarassing at times! ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708290144.aa19625@Huey.UDEL.EDU] <1987082821444300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: What are martian filters? Message-ID: <8708290144.aa19625@Huey.UDEL.EDU> Date: Sat, 29-Aug-87 01:44:43 EDT Article-I.D.: Huey.8708290144.aa19625 Posted: Sat Aug 29 01:44:43 1987 Date-Received: Sun, 30-Aug-87 06:55:55 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 9 Doug, A martian filter is designed to delete certain kinds of packet trash at gateway interfaces between networks. Specifically, the trash consists of "loopback" addresses 127.0.0.1 from malconfigured Unix hosts, "local use" addresses (see latest Assigned Numbers RFCs) and broadcasts. See RFC-1009 for further information. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987082823230000> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Fri 28 Aug 87 19:49:24-PDT Received: by ucbvax.Berkeley.EDU (5.58/1.27) id AA15398; Fri, 28 Aug 87 19:40:19 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 28 Aug 87 23:23:00 GMT From: uwmcsd1!marque!doug@unix.macc.wisc.edu (harris) Organization: Marquette University, Milwaukee, WI Subject: What are martian filters? Message-Id: <1750@marque.UUCP> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa I like hitech talk such as "swamp" and "fuzzball" as much as the next Ph. D., but I would appreciate a little explanation of "martian filter". Is there an RFC to peruse? or would some kind soul send mail, or post an explanation? I'm in the middle of writing code and setting up some local gateways, and believe the notion is something I need to be familiar with. Thanks in advance. uwvax!marque!doug doug@mu.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[A.ISI.EDU]29-Aug-87.06:37:11.CERF] <1987082902370000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: CERF@A.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Sun routers... Message-ID: <[A.ISI.EDU]29-Aug-87.06:37:11.CERF> Date: Sat, 29-Aug-87 06:37:00 EDT Article-I.D.: <[A.ISI.EDU]29-Aug-87.06:37:11.CERF> Posted: Sat Aug 29 06:37:00 1987 Date-Received: Sun, 30-Aug-87 08:35:43 EDT References: <12330130206.13.SATZ@MATHOM.CISCO.COM> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 11 I had always hoped that the initiative taken by Dan Lynch with his conferences, seminars and Tech Mart would lead to the kind of joint demonstrations you suggest and which I agree are generally more productive than indiscriminate flaming. However, when there is real reason to flame, I am always glad to find a few souls willing to brave the heckling of their peers to holler about things that need fixing. Vint Cerf ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[A.ISI.EDU]29-Aug-87.07:06:34.CERF] <1987082903060000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: CERF@A.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Are simultaneous TCP opens useful? Message-ID: <[A.ISI.EDU]29-Aug-87.07:06:34.CERF> Date: Sat, 29-Aug-87 07:06:00 EDT Article-I.D.: <[A.ISI.EDU]29-Aug-87.07:06:34.CERF> Posted: Sat Aug 29 07:06:00 1987 Date-Received: Sun, 30-Aug-87 08:49:04 EDT References: <280@nrc-ut.UUCP> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 15 A bit of history: In the earliest days of TCP design (1973-1974), we worked very hard to make sure that self-simul-syn would work (sounds vaguely self-abusive, doesn't it?). Richard Karp (not the one at Berkeley, but the one now running Reliable systems in Palo Alto) was a graduate student working on one of the first TCP programs (in BCPL). We assured him that the design really was intended to work on a self-connect but I recall his astonishment when we tried it and it, indeed, worked just as advertised. Vint Cerf ----MESSAGE-END---- ----MESSAGE-BEGIN---- [14304@hi.UUCP] <1987082909393100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: cyrus@hi.UUCP (Tait Cyrus) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: SUN 3.4 problems Message-ID: <14304@hi.UUCP> Date: Sat, 29-Aug-87 13:39:31 EDT Article-I.D.: hi.14304 Posted: Sat Aug 29 13:39:31 1987 Date-Received: Sun, 30-Aug-87 09:14:20 EDT References: <1615@briar.Philips.Com> Reply-To: cyrus@hc.dspo.gov (Tait Cyrus) Organization: U. of New Mexico, Albuquerque Lines: 39 In article <1615@briar.Philips.Com> jmr@philabs.Philips.Com (Joanne Mannarino) writes: > > >In trying to upgrade our SUN 3/180 fileserver (named condor) to SUN UNIX >version 3.4 along with 11 diskless clients, I ran into some problems. The > ... >Ethernet). The problem began when the booting process got to the point for: > > starting rpc and net services: portmap router biod > >The boot process then halts with the following error messages: > > server not responding > RPC: program not registered > mount retrying Something that ?might? be causing some problems is that when a SUN client boots, it determines its netmask from an ICMP (rfc 950) 'netmask request'. At one point, here at the University of New Mexico, one of our SUN's was configured with the WRONG netmask. When we tried to boot our diskless clients, they got the wrong netmask and were unable to talk with the server. Rebooting the server did not fix the problem because it got the netmask from the partially booted clients. We ended up halting ALL of our SUN's, booting the servers with the correct netmask, and THEN booting our clients. I don't know if this is your problem or not, but you might look into it. -- @__________@ W. Tait Cyrus (505) 277-0806 /| /| University of New Mexico / | / | Dept of EECE - Hypercube Project @__|_______@ | Albuquerque, New Mexico 87131 | | | | | | hc | | e-mail: | @.......|..@ cyrus@hc.dspo.gov or | / | / seismo!unmvax!hi!cyrus @/_________@/ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987082911370000> Mail-From: STJOHNS created at 29-Aug-87 18:38:50 Date: 29 Aug 1987 18:37-PDT Sender: STJOHNS@SRI-NIC.ARPA Subject: Re: Where can I find SLIP server for 4.2/3? From: STJOHNS@SRI-NIC.ARPA To: karels%okeeffe@UCBVAX.BERKELEY.EDU Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[SRI-NIC.ARPA]29-Aug-87 18:37:56.STJOHNS> In-Reply-To: <8708300016.AA04771@okeeffe.Berkeley.EDU> Thanks for all the responses. To summarize: SLIP comes embedded in 4.3. A version for 4.2 is available from seismo.css.gov or from mimsy.umd.edu. (BTW, seismo didn't seem to have any public access ftp files when I checked last night!) PC SLIP is available from SIMTEL20 or from MIT. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987082915450000> Received: from twg.arpa by SRI-NIC.ARPA with TCP; Sat 29 Aug 87 22:51:31-PDT Date: 29 Aug 87 22:45:00 PDT From: "Jerry Scott" Subject: RE: SUN 3.4 problems To: "karels%okeeffe" cc: Reply-To: "Jerry Scott" Mike, I am told that I missed the posting of this latest 4.3 ICMP mask reply bug by minutes before I posted my errant bug fix to the net. Anyway, I hope this solves the issue with the sun that caused this trading of code changes. I have included this latst fix and made it available via anonymous ftp to host twg.arpa (26.5.0.73). If you don't have arpa access call Wollongong support for the fix. I think this fix is really only needed by those sites with diskless suns running os 3.3 or 3.4. Is this true or are there other implementations using the ICMP MASKREQ broadcast? Thanks, Jerry ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708300016.AA04771@okeeffe.Berkeley.EDU] <1987082916164800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: karels%okeeffe@UCBVAX.BERKELEY.EDU (Mike Karels) Newsgroups: comp.protocols.tcp-ip Subject: Re: Where can I find SLIP server for 4.2/3? Message-ID: <8708300016.AA04771@okeeffe.Berkeley.EDU> Date: Sat, 29-Aug-87 20:16:48 EDT Article-I.D.: okeeffe.8708300016.AA04771 Posted: Sat Aug 29 20:16:48 1987 Date-Received: Sun, 30-Aug-87 10:05:36 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 17 I'm not sure what you mean by a SLIP server; the SLIP protocol for the 4BSD side of a connection is included in 4.3 as if_sl.c. It is configured into a kernel with a line like pseudo-device sl 4 in the system config file, where the number is the number of lines to support. The lines are then set up with the programs slattach and ifconfig, each of which have manual entries. These programs are designed for more-or-less static configurations, as they don't allow dialup use (very easily) and don't do dynamic address assignment. The original versions of slip and slattach were written for 4.2BSD, and they are probably still available somewhere. Of course, you'll need a corresponding protocol module for the PC end, along with IP/TCP support; if that's what you're asking for, I don't know where to find it. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708300024.AA04790@okeeffe.Berkeley.EDU] <1987082916240200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: karels%okeeffe@UCBVAX.BERKELEY.EDU (Mike Karels) Newsgroups: comp.protocols.tcp-ip Subject: Re: Sun routers... Message-ID: <8708300024.AA04790@okeeffe.Berkeley.EDU> Date: Sat, 29-Aug-87 20:24:02 EDT Article-I.D.: okeeffe.8708300024.AA04790 Posted: Sat Aug 29 20:24:02 1987 Date-Received: Sun, 30-Aug-87 10:12:08 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 10 Geof, the Berkeley/UNIX "routed" router (and other similar routing protocols) choose among equal-cost routes semi-randomly. Different hosts and gateways may then choose different gateways for the same destination. The same is true for hosts that use one of several default gateways and then process redirects from them; they'll either choose a suitable gateway, or be redirected to that particular gateway's choice of next-hop router. None of this manages carefully-equalized load balancing, but does tend to spread out the load among multiple gateways. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708300031.AA04819@okeeffe.Berkeley.EDU] <1987082916311500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: karels%okeeffe@UCBVAX.BERKELEY.EDU (Mike Karels) Newsgroups: comp.protocols.tcp-ip Subject: Re: SUN 3.4 problems Message-ID: <8708300031.AA04819@okeeffe.Berkeley.EDU> Date: Sat, 29-Aug-87 20:31:15 EDT Article-I.D.: okeeffe.8708300031.AA04819 Posted: Sat Aug 29 20:31:15 1987 Date-Received: Sun, 30-Aug-87 10:12:30 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 11 Jerry, sorry to say this, but your fix for ICMP MASK request handling for 4.3 was incomplete; it was recently pointed out to me that wrong mask was being returned. Make that icp->icmp_mask = htonl(ia->ia_subnetmask); The error was originally mine, of course. (Watch out for those woodpeckers; that makes three errors in two lines of code! I guess that demonstrates that 4.3 doesn't use mask requests when booting). Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[SRI-NIC.ARPA]29-Aug-87.18:37:56.STJOHNS] <1987082917370000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: STJOHNS@SRI-NIC.ARPA Newsgroups: comp.protocols.tcp-ip Subject: Re: Where can I find SLIP server for 4.2/3? Message-ID: <[SRI-NIC.ARPA]29-Aug-87.18:37:56.STJOHNS> Date: Sat, 29-Aug-87 21:37:00 EDT Article-I.D.: <[SRI-NIC.ARPA]29-Aug-87.18:37:56.STJOHNS> Posted: Sat Aug 29 21:37:00 1987 Date-Received: Sun, 30-Aug-87 10:15:50 EDT References: <8708300016.AA04771@okeeffe.Berkeley.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 5 Thanks for all the responses. To summarize: SLIP comes embedded in 4.3. A version for 4.2 is available from seismo.css.gov or from mimsy.umd.edu. (BTW, seismo didn't seem to have any public access ftp files when I checked last night!) PC SLIP is available from SIMTEL20 or from MIT. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708300436.AA03739@beno.CSS.GOV] <1987082920363100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: rick@SEISMO.CSS.GOV (Rick Adams) Newsgroups: comp.protocols.tcp-ip Subject: Re: Where can I find SLIP server for 4.2/3? Message-ID: <8708300436.AA03739@beno.CSS.GOV> Date: Sun, 30-Aug-87 00:36:31 EDT Article-I.D.: beno.8708300436.AA03739 Posted: Sun Aug 30 00:36:31 1987 Date-Received: Fri, 4-Sep-87 00:38:59 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 18 You can ftp the source code for SLIP from uunet.uu.net as the file ~ftp/pub/sl.shar.Z This file contains the code for 4.2bsd systems and Sun 3.X. If you have 4.3bsd, you already have SLIP (it is surprising how many people ask this). It is known to run on vaxes and suns. It may run on other systems depending on how much the vendor "fixed" that wasn't broken. Note: SLIP is ONLY a device driver. You have to come up with your own IP, TCP, ICMP, ETC To answer the other popular question, no there is no RFC describing the "protocol" (I hesitate to call it a protocol. Its a simple framing scheme.) ---rick f ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708300609.AA22444@ucbvax.Berkeley.EDU] <1987082921450000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jerry@TWG.ARPA.UUCP Newsgroups: comp.protocols.tcp-ip Subject: RE: SUN 3.4 problems Message-ID: <8708300609.AA22444@ucbvax.Berkeley.EDU> Date: Sun, 30-Aug-87 01:45:00 EDT Article-I.D.: ucbvax.8708300609.AA22444 Posted: Sun Aug 30 01:45:00 1987 Date-Received: Sun, 30-Aug-87 18:35:55 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: "Jerry Scott" Distribution: world Organization: The ARPA Internet Lines: 16 Mike, I am told that I missed the posting of this latest 4.3 ICMP mask reply bug by minutes before I posted my errant bug fix to the net. Anyway, I hope this solves the issue with the sun that caused this trading of code changes. I have included this latst fix and made it available via anonymous ftp to host twg.arpa (26.5.0.73). If you don't have arpa access call Wollongong support for the fix. I think this fix is really only needed by those sites with diskless suns running os 3.3 or 3.4. Is this true or are there other implementations using the ICMP MASKREQ broadcast? Thanks, Jerry ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [18137@amdcad.AMD.COM] <1987082922340500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: phil@amdcad.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: Where can I find SLIP server for 4.2/3? Message-ID: <18137@amdcad.AMD.COM> Date: Sun, 30-Aug-87 02:34:05 EDT Article-I.D.: amdcad.18137 Posted: Sun Aug 30 02:34:05 1987 Date-Received: Sun, 30-Aug-87 18:43:02 EDT References: <8708300016.AA04771@okeeffe.Berkeley.EDU> Reply-To: phil@amdcad.UUCP (Phil Ngai) Distribution: world Organization: Advanced Micro Devices Lines: 27 In article <8708300016.AA04771@okeeffe.Berkeley.EDU> karels%okeeffe@UCBVAX.BERKELEY.EDU (Mike Karels) writes: >I'm not sure what you mean by a SLIP server; the SLIP protocol for >the 4BSD side of a connection is included in 4.3 as if_sl.c. It is >configured into a kernel with a line like > pseudo-device sl 4 >in the system config file, where the number is the number of lines to support. >The lines are then set up with the programs slattach and ifconfig, each >of which have manual entries. This brings up a question I had. I hope it's not too stupid. Consider a network with machines A, B, and C. B talks to A and C. A does not talk to C except through B. B's /dev/ttyh0 goes to A. B's /dev/ttyh1 goes to C. I slattach ttyh0 and ttyh1. Now I want to ifconfig sl0 and sl1. How do I know which dstaddr to associate with sl0 and which with sl1? Does it matter? If not, how does the kernel know which tty line to send the packets down? The thing that confuses me is I would expect slattach to take a sl0 or sl1 argument as well as a tty argument. But it doesn't. Also, do I have to do anything special to B to get it to forward packets from A to C? -- I speak for myself, not the company. Phil Ngai, {ucbvax,decwrl,allegra}!amdcad!phil or amdcad!phil@decwrl.dec.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1800@munnari.oz] <1987083010453700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: kre@munnari.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: Where can I find SLIP server for 4.2/3? Message-ID: <1800@munnari.oz> Date: Sun, 30-Aug-87 14:45:37 EDT Article-I.D.: munnari.1800 Posted: Sun Aug 30 14:45:37 1987 Date-Received: Sun, 30-Aug-87 23:43:29 EDT References: <8708300016.AA04771@okeeffe.Berkeley.EDU> <18137@amdcad.AMD.COM> Organization: Comp Sci, Melbourne Uni, Australia Lines: 26 In article <18137@amdcad.AMD.COM>, phil@amdcad.AMD.COM (Phil Ngai) writes: > Now I want to ifconfig sl0 and sl1. How do I know which dstaddr to > associate with sl0 and which with sl1? Does it matter? If not, how > does the kernel know which tty line to send the packets down? It matters, and this has been bugging me too. The only way to solve this currently is to run all the slattach's serially, which means that if there's no carrier on the first (the remote end is down when you're booting) the second doesn't happen until carrier appears (who knows how long). It happens that its trivial to fix this, with no major changes to anything. Rather than tell slattach which slN it should use, we can just have it tell us which one it was assigned, then /etc/rc.local can look like UNIT=`slattach ttyh0 9600` dstaddr $UNIT ... # if needed ifconfig $UNIT ... All the support needed for slattach to do this is there already, I'm going to add the few lines needed (there will probably be a flag to cause this behaviour for backward compatability) sometime very soon now. I'll post the diffs. kre ----MESSAGE-END---- ----MESSAGE-BEGIN---- [cVCAGRy00UoJy0A2wR@andrew.cmu.edu] <1987083016343700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ddp+@ANDREW.CMU.EDU.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: Where can I find SLIP server for 4.2/3? Message-ID: Date: Sun, 30-Aug-87 20:34:37 EDT Article-I.D.: andrew.cVCAGRy00UoJy0A2wR Posted: Sun Aug 30 20:34:37 1987 Date-Received: Mon, 31-Aug-87 04:02:25 EDT References: <[SRI-NIC.ARPA]29-Aug-87.18:37:56.STJOHNS> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 8 >PC SLIP is available from SIMTEL20 or from MIT. Sorry Mike, but PC "SLIP" is not available from MIT. The "slip" which MIT distributes does not support the same framing scheme as the "slip" (SLIP) available with 4.3bsd. However, both the MIT slip and "SLIP" are included with CMU-PCIP, available from me. It is also supported by the KA9Q (Phil Karn) PC IP package. Drew ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708311459.AA25432@oswego] <1987083106591700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: beadel@oswego.UUCP (Edward F. Beadel, Jr.) Newsgroups: comp.protocols.tcp-ip Subject: Re: Where can I find SLIP server for 4.2/3? Message-ID: <8708311459.AA25432@oswego> Date: Mon, 31-Aug-87 10:59:17 EDT Article-I.D.: oswego.8708311459.AA25432 Posted: Mon Aug 31 10:59:17 1987 Date-Received: Fri, 4-Sep-87 05:46:38 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 26 Mike Karels writes (among other things regarding SLIP): > >of which have manual entries. These programs are designed for more-or-less >static configurations, as they don't allow dialup use (very easily) >and don't do dynamic address assignment. The original versions of slip Does anybody know of a 4.3( or 4.2)bsd version that has been hacked to allow dialup use? We are having "campus political problems" getting a dedicated 9600 baud line to another building that will connect through the SUNY InterCampus Data Network to NYSERNet and thus to the INTERNET. However we can buy a pair of 9600baud modems and dial up a phone that is right next to our on campus SICDN port. Of course the 9600baud modems are more expensive, however they seem to be the only way for now (sigh .......) We'd *LOVE* any help at this point since we don't have the time to hack it ourselves at this point in time. (Most of our Systems Programming effort is in beta 2.10 at present). Thanks, Ed ****************************************************************** Edward F. Beadel, Jr., Manager {seismo|decvax}!rochester\ Instructional Computing Center allegra !rocksvax!oswego!beadel SUNY College at Oswego {ihnp4|research|allegra}!warrior/ Oswego, NY 13126 (315)-341-3055 {allegra|watmath}!sunybcs/ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [6715@eddie.MIT.EDU] <1987083107241000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: tung@mit-eddie.UUCP Newsgroups: comp.os.vms,comp.protocols.tcp-ip Subject: Using CMU-TEK TCP-IP with NI1010A Message-ID: <6715@eddie.MIT.EDU> Date: Mon, 31-Aug-87 11:24:10 EDT Article-I.D.: eddie.6715 Posted: Mon Aug 31 11:24:10 1987 Date-Received: Tue, 1-Sep-87 04:26:08 EDT Reply-To: tung@eddie.MIT.EDU (Thye-Lai Tung) Distribution: world Organization: MIT, EE/CS Computer Facilities, Cambridge, MA Lines: 9 Keywords: VAX/VMS, TCP-IP, Interlan Has anyone been able to make the CMU-TEK VMS TCP-IP (version 6.0 or higher) to work with the NI1010A controller ? I understand the original Tektronix software supports the Interlan NI1010A Unibus controller. But Carnegie-Mellon University told me that they did not check their enhanced codes on any Interlan boards. A local site has tried it without success. Thank you for any information that you can provide. - Thye-Lai Tung ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708311733.AA00238@apolling.imagen.uucp] <1987083109335800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: geof@apolling.UUCP (Geof Cooper) Newsgroups: comp.protocols.tcp-ip Subject: Re: Re: Re: Sun routers... Message-ID: <8708311733.AA00238@apolling.imagen.uucp> Date: Mon, 31-Aug-87 13:33:58 EDT Article-I.D.: apolling.8708311733.AA00238 Posted: Mon Aug 31 13:33:58 1987 Date-Received: Sat, 5-Sep-87 00:42:21 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: imagen!geof@decwrl.dec.com Organization: The ARPA Internet Lines: 31 > This isn't exactly a failing of the standards, except maybe by > omission..... Actually, I think it IS a failing of the standards (by the way, some people misread my message -- I'm in favor of load sharing. I want EVERYONE to do it). Clearly, implementors have found ad hoc ways of achieving load sharing. We've seen three here (random choice, round robin, choose the first response ("load-biased random"?)). What are the implications of each to network congestion? Network reliability? One implementor points out that the load-sharing decision must not be made every packet. How frequently is right? How do the different schemes interact? Are there some combinations that make network congestion worse? There are non-trivial issues of network congestion and performance at stake. A standard is supposed to address these by causing even the most naive implementor to use a "good" technique. The standard also ensures that everyone addresses the problem. There are certainly gateways out there today (we have some) that don't support ANY ad-hoc load sharing system. So if we think that load-sharing is important (I do), and we know that it is tricky (cf above questions) then this is exactly the sort of thing the standards should address. - Geof ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987083110090000> Mail-From: STJOHNS created at 31-Aug-87 17:11:30 Date: 31 Aug 1987 17:09-PDT Sender: STJOHNS@SRI-NIC.ARPA Subject: Re: IP network numbers for networks not on the Internet From: STJOHNS@SRI-NIC.ARPA To: hedrick@TOPAZ.RUTGERS.EDU Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[SRI-NIC.ARPA]31-Aug-87 17:09:27.STJOHNS> In-Reply-To: <8708311907.AA04714@topaz.rutgers.edu> Umm... sponsorship is needed if you are going to connect to the DOD internet, whether you say so or not! Attaching without the proper blessings counts as theft of services. Since this is stealing from Uncle Sam, this tends to get the attention of the FBI and the Secret Service (suprise, they have jurisdiction!) Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708311907.AA04714@topaz.rutgers.edu] <1987083111070500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick) Newsgroups: comp.protocols.tcp-ip Subject: IP network numbers for networks not on the Internet Message-ID: <8708311907.AA04714@topaz.rutgers.edu> Date: Mon, 31-Aug-87 15:07:05 EDT Article-I.D.: topaz.8708311907.AA04714 Posted: Mon Aug 31 15:07:05 1987 Date-Received: Fri, 4-Sep-87 06:42:17 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 A couple of people indicated that they had had trouble getting network numbers for networks that are not attached to the Internet. I just checked with the NIC. Sue@sri-nic.arpa verified that they will give out a network number to anyone who needs it. Sponsorship is needed only if you say that your network is to be connected to the DDN-internet. If you have had trouble in the past getting a number, you might want to try again. The NIC's mail address is hostmaster@sri-nic.arpa. Their phone number is 415-859-5539. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8708312048.AA08185@opal.berkeley.edu] <1987083112482900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: minshall@OPAL.BERKELEY.EDU.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: tn3270 beta version bug Message-ID: <8708312048.AA08185@opal.berkeley.edu> Date: Mon, 31-Aug-87 16:48:29 EDT Article-I.D.: opal.8708312048.AA08185 Posted: Mon Aug 31 16:48:29 1987 Date-Received: Wed, 2-Sep-87 01:21:26 EDT References: <8708262049.AA18050@america.BRC.com> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 29 Tom, You reported a problem with the beta test version of tn3270, which makes it fail using the CMS "note" command (in "input" mode). The CMS "note" command uses "fullread". This is, by the way, a bad use of your network (since it transfers the entire 3270 screen buffer to the host everytime an AID- generating key is hit). However, tn3270 was designed to support this mode. So, here is the fix. The file is tn3270/api/ebc_disp.c. The structure being changed is the "disp_ebc" table (for translating display codes to ebcdic. The problem is that NULLs are being translated into 0xff's; NULLs should be translated into NULLs. 6c6 < static char sccsid[] = "%W% (Berkeley) %G%"; --- > static char sccsid[] = "@(#)ebc_disp.c 3.2 (Berkeley) 8/31/87"; 49c49 < /*00*/ 0xff, 0xce, 0xcf, 0xdd, 0xde, 0xdf, 0xed, 0xee, --- > /*00*/ 0x00, 0xce, 0xcf, 0xdd, 0xde, 0xdf, 0xed, 0xee, ^^ Note that the tar files on arpa.berkeley.edu have been changed. Thanks again for the bug report. Greg Minshall ----MESSAGE-END---- ----MESSAGE-BEGIN---- [14442@hi.UUCP] <1987083114470000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: zeilenga@hc.dspo.gov (Kurt Zeilenga) Newsgroups: comp.protocols.tcp-ip Subject: IP assigned protocol numbers Message-ID: <14442@hi.UUCP> Date: Mon, 31-Aug-87 18:47:00 EDT Article-I.D.: hi.14442 Posted: Mon Aug 31 18:47:00 1987 Date-Received: Fri, 4-Sep-87 07:30:12 EDT Organization: U. of New Mexico, Albuquerque Lines: 8 Keywords: goof According to "Assigned Protocol Numbers," available from the NIC, The gateway-to-gateway protocol, GGP, should be protocol 3. When looking thru the .h files on our system (SUN UNIX) I noticed that GGP was using protocol number 2. I checked other systems (other BSD based systems), and they too were using protocol 2 for GGP. Mmmm. Comments? Kurt Zeilenga (zeilenga@hc.dspo.gov) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[SRI-NIC.ARPA]31-Aug-87.17:09:27.STJOHNS] <1987083116090000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: STJOHNS@SRI-NIC.ARPA.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: IP network numbers for networks not on the Internet Message-ID: <[SRI-NIC.ARPA]31-Aug-87.17:09:27.STJOHNS> Date: Mon, 31-Aug-87 20:09:00 EDT Article-I.D.: <[SRI-NIC.ARPA]31-Aug-87.17:09:27.STJOHNS> Posted: Mon Aug 31 20:09:00 1987 Date-Received: Tue, 1-Sep-87 05:46:56 EDT References: <8708311907.AA04714@topaz.rutgers.edu> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 9 Umm... sponsorship is needed if you are going to connect to the DOD internet, whether you say so or not! Attaching without the proper blessings counts as theft of services. Since this is stealing from Uncle Sam, this tends to get the attention of the FBI and the Secret Service (suprise, they have jurisdiction!) Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8709010032.AA11406@topaz.rutgers.edu] <1987083116321800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick) Newsgroups: comp.protocols.tcp-ip Subject: Re: IP network numbers for networks not on the Internet Message-ID: <8709010032.AA11406@topaz.rutgers.edu> Date: Mon, 31-Aug-87 20:32:18 EDT Article-I.D.: topaz.8709010032.AA11406 Posted: Mon Aug 31 20:32:18 1987 Date-Received: Sat, 5-Sep-87 00:36:16 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 I certainly wasn't implying that people should attach to the Internet without permission. Rather, I was pointing out that whether your application needs to get "blessed" depends upon what you say to the question about whether you are going to connect to the DoD Internet. One theory as to why people may have had trouble getting numbers is that they inappropriately said that they intended to connect to the Internet, for example because they didn't understand exactly what the question meant. ----MESSAGE-END----