----MESSAGE-BEGIN---- [401@jc3b21.UUCP] <1988060103013500> From: jra@jc3b21.UUCP (Jay R. Ashworth) Newsgroups: rec.ham-radio.packet,comp.protocols.tcp-ip Subject: SLIP Info please? Message-ID: <401@jc3b21.UUCP> Date: 1 Jun 88 03:01:35 GMT Organization: The Great Ashworth & Petrillo Production Co. Lines: 25 Can anybody email me more details about SLIP (Serial Link Internet Protocol)? I am interested in the possibility of supporting multiple telnet type login sessions on one physical radio channel, using a standard, albeit high speed (38.4Kb?) serial line between TNC and computer. Does KA9Q do this? Are other possible sources PD? I need to have source code available. I (read: my employer) would be interested in discussing commercial licensing at some future point. For now, though, folks, I'd just like to know what I'm talking about. Can you help? Email ONLY, please. The .sig path should work just fine. Tnx, -- jra KA1FJX -- Jay R. Ashworth ---+-- Suncoast Television Productions--+ ...!uunet!codas! 10974 111th St. N. | producers of Suncoast Magazine | !usfvax2!jc3b21!jra Seminole FL 34648 +------------------------------------------------+--------- (813) 397-1859 ----+-- Premiering on Vision Cable Ch. 24 in July ---+ :-) !$ Robert Heinlein, 1901-1988, alas, not as long-lived as Lazarus Long. R. I. P. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1624@erix.UUCP] <1988060106543600> From: per@erix.UUCP (Per Hedeland) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Subnetting Message-ID: <1624@erix.UUCP> Date: 1 Jun 88 06:54:36 GMT References: <1607@erix.UUCP> Reply-To: per@erix.ericsson.se (Per Hedeland) Organization: Ericsson Telecom, Stockholm, Sweden Lines: 26 While it may be a bit late, I thought I should post a short summary of the information I got in response to my query a few weeks back - it did generate some discussion, after all. If you recall, the issue was how to use subnetting on a network structure with a big backbone net and many small ones hanging off of it. I think the below is the essence of what I found out; I also have a pile of mail for those particularly interested. - Unequal-sized subnets, whether or not a Good Thing, is not currently implemented in any generally accepted way (and thus of little interest to us). - Partitioned subnets (i.e. subnets of a given net interconnected only by some other net) are out. - One can have several logical subnets on the same wire (i.e. the backbone in our case), thus effectively increasing the address space, at the expense of some manual "routing" (i.e. gateways have to be explicitly told that the different subnets can be accessed via the same interface - hosts on such a wire can be "fooled" into believing that it's all one (bigger) subnet). We will probably go for the latter method, with a long-term goal of splitting our backbone by using dedicated routers. Thanks to all who offered help and advice! ---Per Hedeland ----MESSAGE-END---- ----MESSAGE-BEGIN---- [25.UUL1.3#935@aocgl.UUCP] <1988060107091400> From: tmanos@aocgl.UUCP (Theodore W. Manos) Newsgroups: comp.protocols.tcp-ip Subject: Re: non-*NIX implementations Message-ID: <25.UUL1.3#935@aocgl.UUCP> Date: 1 Jun 88 07:09:14 GMT References: <714@lakesys.UUCP> Organization: Alpha Omega Consulting Group, LTD, Roselle, IL Lines: 6 Ya Mike, what are you looking for? VM/CMS? VMS? MS/DOS? Macintosh? MPE? There's stuff all over the place. -Ted --------- Ted Manos tmanos@aocgl.{COM,UUCP,UU.NET} or ...!{uunet,mcdchg}!aocgl!tmanos ----MESSAGE-END---- ----MESSAGE-BEGIN---- [3665@uikku.tut.fi] <1988060107444900> From: jh@tut.fi (Juha Hein{nen) Newsgroups: comp.protocols.misc,comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Linking LAN's via Public X.25 Message-ID: <3665@uikku.tut.fi> Date: 1 Jun 88 07:44:49 GMT References: <13652@comp.vuw.ac.nz> Organization: Tampere University of Technology, Finland Lines: 7 SunLink X.25 indeed allows connecting two IP networks over X.25 but it requires a PVC and cannot dynamically open and close the connection. You may want to check the Cisco router product that also has the later capability. -- Juha Heinanen, Tampere Univ. of Technology, Finland jh@tut.fi (Internet), tut!jh (UUCP), jh@tut (Bitnet) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988060109060000> Received: from Venus.YCC.Yale.Edu by SRI-NIC.ARPA with TCP; Wed, 1 Jun 88 11:17:47 PDT Date: Wed, 1 Jun 88 14:06 EST From: AIVANO@Venus.YCC.Yale.Edu Subject: Moderated Newsgroup Posting To: tcp-ip@sri-nic.arpa X-VMS-To: VENUS::IN%"tcp-ip@sri-nic.arpa",AIVANO Path: venus!aivano From: aivano@venus.ycc.yale.edu Newsgroups: mail.tcp-ip Subject: Public Domain TN3270 Message-ID: <27@venus.ycc.yale.edu> Date: 1 Jun 88 14:05:48 GMT Organisation: VMS NEWS V4.0 Lines: 11 Is there a public domain TN3270 program that runs under VMS and can interface with Wollongong's TCP/IP? We would prefer to have source code so that we could write our own interface, but could live with a documented executable that includes an interface to the Wollongong TCP/IP. Please send replies directly to me, Sandy Aivano Yale Computer Center AIVANO@YALEVMS (BITNET) AIVANO@YALEVMS.YCC.YALE.EDU (ARPA) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988060114450000> Received: from CUNYVM.CUNY.EDU by SRI-NIC.ARPA with TCP; Wed, 1 Jun 88 21:26:44 PDT Received: from BKNLVMS.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 7783; Wed, 01 Jun 88 18:46:10 EDT Date: Wed, 1 Jun 88 18:45 EDT From: PMDF Mail Server Subject: Undeliverable mail To: TCP-IP@SRI-NIC.ARPA The message could not be delivered to: Addressee: DAVIS Reason: %MAIL-E-NOSUCHUSR, no such user DAVIS at node ---------------------------------------- Received: from JNET-DAEMON by BKNLVMS.BITNET; Wed, 1 Jun 88 18:40 EDT Received: From OHSTVMA(MAILER) by BKNLVMS with Jnet id 6415 for DAVIS@BKNLVMS; Wed, 1 Jun 88 18:39 EDT Received: by OHSTVMA (Mailer X1.25) id 6412; Wed, 01 Jun 88 18:36:57 EDT Date: Wed, 1 Jun 88 07:09:14 GMT From: "Theodore W. Manos" Subject: Re: non-*NIX implementations Sender: ARPA TCP-IP Discussion Redistribution To: jeff davis , 'Ralph Droms' , JERRY MEAD , "CARL I. NEWMAN" , CHRIS RILEY , "TIMOTHY M. SCHREYER" Reply-to: TCP-IP@SRI-NIC.ARPA Comments: Warning -- original Sender: tag was tcp-ip-request@sri-nic.arpa X-To: tcp-ip@sri-nic.arpa Ya Mike, what are you looking for? VM/CMS? VMS? MS/DOS? Macintosh? MPE? There's stuff all over the place. -Ted --------- Ted Manos tmanos@aocgl.{COM,UUCP,UU.NET} or ...!{uunet,mcdchg}!aocgl!tmanos ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988060114500000> Received: from CUNYVM.CUNY.EDU by SRI-NIC.ARPA with TCP; Wed, 1 Jun 88 21:27:38 PDT Received: from BKNLVMS.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 8229; Wed, 01 Jun 88 18:51:09 EDT Date: Wed, 1 Jun 88 18:50 EDT From: PMDF Mail Server Subject: Undeliverable mail To: TCP-IP@SRI-NIC.ARPA The message could not be delivered to: Addressee: SCHREYER Reason: %MAIL-E-NOSUCHUSR, no such user SCHREYER at node ---------------------------------------- Received: from JNET-DAEMON by BKNLVMS.BITNET; Wed, 1 Jun 88 18:46 EDT Received: From OHSTVMA(MAILER) by BKNLVMS with Jnet id 6421 for SCHREYER@BKNLVMS; Wed, 1 Jun 88 18:41 EDT Received: by OHSTVMA (Mailer X1.25) id 6412; Wed, 01 Jun 88 18:36:58 EDT Date: Wed, 1 Jun 88 07:09:14 GMT From: "Theodore W. Manos" Subject: Re: non-*NIX implementations Sender: ARPA TCP-IP Discussion Redistribution To: jeff davis , 'Ralph Droms' , JERRY MEAD , "CARL I. NEWMAN" , CHRIS RILEY , "TIMOTHY M. SCHREYER" Reply-to: TCP-IP@SRI-NIC.ARPA Comments: Warning -- original Sender: tag was tcp-ip-request@sri-nic.arpa X-To: tcp-ip@sri-nic.arpa Ya Mike, what are you looking for? VM/CMS? VMS? MS/DOS? Macintosh? MPE? There's stuff all over the place. -Ted --------- Ted Manos tmanos@aocgl.{COM,UUCP,UU.NET} or ...!{uunet,mcdchg}!aocgl!tmanos ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988060114550000> Received: from CUNYVM.CUNY.EDU by SRI-NIC.ARPA with TCP; Wed, 1 Jun 88 21:28:35 PDT Received: from BKNLVMS.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 8682; Wed, 01 Jun 88 18:56:28 EDT Date: Wed, 1 Jun 88 18:55 EDT From: PMDF Mail Server Subject: Undeliverable mail To: TCP-IP@SRI-NIC.ARPA The message could not be delivered to: Addressee: SCHREYER Reason: %MAIL-E-NOSUCHUSR, no such user SCHREYER at node ---------------------------------------- Received: from JNET-DAEMON by BKNLVMS.BITNET; Wed, 1 Jun 88 18:51 EDT Received: From OHSTVMA(MAILER) by BKNLVMS with Jnet id 6556 for SCHREYER@BKNLVMS; Wed, 1 Jun 88 18:46 EDT Received: by OHSTVMA (Mailer X1.25) id 6547; Wed, 01 Jun 88 18:38:26 EDT Date: Wed, 1 Jun 88 03:01:35 GMT From: "Jay R. Ashworth" Subject: SLIP Info please? Sender: ARPA TCP-IP Discussion Redistribution To: jeff davis , 'Ralph Droms' , JERRY MEAD , "CARL I. NEWMAN" , CHRIS RILEY , "TIMOTHY M. SCHREYER" Reply-to: TCP-IP@SRI-NIC.ARPA Comments: Warning -- original Sender: tag was tcp-ip-request@sri-nic.arpa X-To: tcp-ip@sri-nic.arpa Can anybody email me more details about SLIP (Serial Link Internet Protocol)? I am interested in the possibility of supporting multiple telnet type login sessions on one physical radio channel, using a standard, albeit high speed (38.4Kb?) serial line between TNC and computer. Does KA9Q do this? Are other possible sources PD? I need to have source code available. I (read: my employer) would be interested in discussing commercial licensing at some future point. For now, though, folks, I'd just like to know what I'm talking about. Can you help? Email ONLY, please. The .sig path should work just fine. Tnx, -- jra KA1FJX -- Jay R. Ashworth ---+-- Suncoast Television Productions--+ ...!uunet!codas! 10974 111th St. N. | producers of Suncoast Magazine | !usfvax2!jc3b21!jra Seminole FL 34648 +------------------------------------------------+--------- (813) 397-1859 ----+-- Premiering on Vision Cable Ch. 24 in July ---+ :-) !$ Robert Heinlein, 1901-1988, alas, not as long-lived as Lazarus Long. R. I. P. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988060115000000> Received: from CUNYVM.CUNY.EDU by SRI-NIC.ARPA with TCP; Wed, 1 Jun 88 21:30:08 PDT Received: from BKNLVMS.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 9003; Wed, 01 Jun 88 19:01:33 EDT Date: Wed, 1 Jun 88 19:00 EDT From: PMDF Mail Server Subject: Undeliverable mail To: TCP-IP@SRI-NIC.ARPA The message could not be delivered to: Addressee: RILEY Reason: %MAIL-E-NOSUCHUSR, no such user RILEY at node ---------------------------------------- Received: from JNET-DAEMON by BKNLVMS.BITNET; Wed, 1 Jun 88 18:56 EDT Received: From OHSTVMA(MAILER) by BKNLVMS with Jnet id 6555 for RILEY@BKNLVMS; Wed, 1 Jun 88 18:46 EDT Received: by OHSTVMA (Mailer X1.25) id 6547; Wed, 01 Jun 88 18:38:25 EDT Date: Wed, 1 Jun 88 03:01:35 GMT From: "Jay R. Ashworth" Subject: SLIP Info please? Sender: ARPA TCP-IP Discussion Redistribution To: jeff davis , 'Ralph Droms' , JERRY MEAD , "CARL I. NEWMAN" , CHRIS RILEY , "TIMOTHY M. SCHREYER" Reply-to: TCP-IP@SRI-NIC.ARPA Comments: Warning -- original Sender: tag was tcp-ip-request@sri-nic.arpa X-To: tcp-ip@sri-nic.arpa Can anybody email me more details about SLIP (Serial Link Internet Protocol)? I am interested in the possibility of supporting multiple telnet type login sessions on one physical radio channel, using a standard, albeit high speed (38.4Kb?) serial line between TNC and computer. Does KA9Q do this? Are other possible sources PD? I need to have source code available. I (read: my employer) would be interested in discussing commercial licensing at some future point. For now, though, folks, I'd just like to know what I'm talking about. Can you help? Email ONLY, please. The .sig path should work just fine. Tnx, -- jra KA1FJX -- Jay R. Ashworth ---+-- Suncoast Television Productions--+ ...!uunet!codas! 10974 111th St. N. | producers of Suncoast Magazine | !usfvax2!jc3b21!jra Seminole FL 34648 +------------------------------------------------+--------- (813) 397-1859 ----+-- Premiering on Vision Cable Ch. 24 in July ---+ :-) !$ Robert Heinlein, 1901-1988, alas, not as long-lived as Lazarus Long. R. I. P. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988060115050000> Received: from CUNYVM.CUNY.EDU by SRI-NIC.ARPA with TCP; Wed, 1 Jun 88 21:45:06 PDT Received: from BKNLVMS.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 9481; Wed, 01 Jun 88 19:05:47 EDT Date: Wed, 1 Jun 88 19:05 EDT From: PMDF Mail Server Subject: Undeliverable mail To: TCP-IP@SRI-NIC.ARPA The message could not be delivered to: Addressee: NEWMAN Reason: %MAIL-E-NOSUCHUSR, no such user NEWMAN at node ---------------------------------------- Received: from JNET-DAEMON by BKNLVMS.BITNET; Wed, 1 Jun 88 19:01 EDT Received: From OHSTVMA(MAILER) by BKNLVMS with Jnet id 6554 for NEWMAN@BKNLVMS; Wed, 1 Jun 88 18:46 EDT Received: by OHSTVMA (Mailer X1.25) id 6547; Wed, 01 Jun 88 18:38:25 EDT Date: Wed, 1 Jun 88 03:01:35 GMT From: "Jay R. Ashworth" Subject: SLIP Info please? Sender: ARPA TCP-IP Discussion Redistribution To: jeff davis , 'Ralph Droms' , JERRY MEAD , "CARL I. NEWMAN" , CHRIS RILEY , "TIMOTHY M. SCHREYER" Reply-to: TCP-IP@SRI-NIC.ARPA Comments: Warning -- original Sender: tag was tcp-ip-request@sri-nic.arpa X-To: tcp-ip@sri-nic.arpa Can anybody email me more details about SLIP (Serial Link Internet Protocol)? I am interested in the possibility of supporting multiple telnet type login sessions on one physical radio channel, using a standard, albeit high speed (38.4Kb?) serial line between TNC and computer. Does KA9Q do this? Are other possible sources PD? I need to have source code available. I (read: my employer) would be interested in discussing commercial licensing at some future point. For now, though, folks, I'd just like to know what I'm talking about. Can you help? Email ONLY, please. The .sig path should work just fine. Tnx, -- jra KA1FJX -- Jay R. Ashworth ---+-- Suncoast Television Productions--+ ...!uunet!codas! 10974 111th St. N. | producers of Suncoast Magazine | !usfvax2!jc3b21!jra Seminole FL 34648 +------------------------------------------------+--------- (813) 397-1859 ----+-- Premiering on Vision Cable Ch. 24 in July ---+ :-) !$ Robert Heinlein, 1901-1988, alas, not as long-lived as Lazarus Long. R. I. P. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988060115200000> Received: from CUNYVM.CUNY.EDU by SRI-NIC.ARPA with TCP; Wed, 1 Jun 88 21:47:31 PDT Received: from BKNLVMS.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 1077; Wed, 01 Jun 88 19:20:29 EDT Date: Wed, 1 Jun 88 19:20 EDT From: PMDF Mail Server Subject: Undeliverable mail To: TCP-IP@SRI-NIC.ARPA The message could not be delivered to: Addressee: DAVIS Reason: %MAIL-E-NOSUCHUSR, no such user DAVIS at node ---------------------------------------- Received: from JNET-DAEMON by BKNLVMS.BITNET; Wed, 1 Jun 88 19:16 EDT Received: From OHSTVMA(MAILER) by BKNLVMS with Jnet id 6550 for DAVIS@BKNLVMS; Wed, 1 Jun 88 18:45 EDT Received: by OHSTVMA (Mailer X1.25) id 6547; Wed, 01 Jun 88 18:38:24 EDT Date: Wed, 1 Jun 88 03:01:35 GMT From: "Jay R. Ashworth" Subject: SLIP Info please? Sender: ARPA TCP-IP Discussion Redistribution To: jeff davis , 'Ralph Droms' , JERRY MEAD , "CARL I. NEWMAN" , CHRIS RILEY , "TIMOTHY M. SCHREYER" Reply-to: TCP-IP@SRI-NIC.ARPA Comments: Warning -- original Sender: tag was tcp-ip-request@sri-nic.arpa X-To: tcp-ip@sri-nic.arpa Can anybody email me more details about SLIP (Serial Link Internet Protocol)? I am interested in the possibility of supporting multiple telnet type login sessions on one physical radio channel, using a standard, albeit high speed (38.4Kb?) serial line between TNC and computer. Does KA9Q do this? Are other possible sources PD? I need to have source code available. I (read: my employer) would be interested in discussing commercial licensing at some future point. For now, though, folks, I'd just like to know what I'm talking about. Can you help? Email ONLY, please. The .sig path should work just fine. Tnx, -- jra KA1FJX -- Jay R. Ashworth ---+-- Suncoast Television Productions--+ ...!uunet!codas! 10974 111th St. N. | producers of Suncoast Magazine | !usfvax2!jc3b21!jra Seminole FL 34648 +------------------------------------------------+--------- (813) 397-1859 ----+-- Premiering on Vision Cable Ch. 24 in July ---+ :-) !$ Robert Heinlein, 1901-1988, alas, not as long-lived as Lazarus Long. R. I. P. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988060115250000> Received: from CUNYVM.CUNY.EDU by SRI-NIC.ARPA with TCP; Wed, 1 Jun 88 21:48:39 PDT Received: from BKNLVMS.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 1447; Wed, 01 Jun 88 19:25:30 EDT Date: Wed, 1 Jun 88 19:25 EDT From: PMDF Mail Server Subject: Undeliverable mail To: TCP-IP@SRI-NIC.ARPA The message could not be delivered to: Addressee: RILEY Reason: %MAIL-E-NOSUCHUSR, no such user RILEY at node ---------------------------------------- Received: from JNET-DAEMON by BKNLVMS.BITNET; Wed, 1 Jun 88 19:21 EDT Received: From OHSTVMA(MAILER) by BKNLVMS with Jnet id 6420 for RILEY@BKNLVMS; Wed, 1 Jun 88 18:40 EDT Received: by OHSTVMA (Mailer X1.25) id 6412; Wed, 01 Jun 88 18:36:58 EDT Date: Wed, 1 Jun 88 07:09:14 GMT From: "Theodore W. Manos" Subject: Re: non-*NIX implementations Sender: ARPA TCP-IP Discussion Redistribution To: jeff davis , 'Ralph Droms' , JERRY MEAD , "CARL I. NEWMAN" , CHRIS RILEY , "TIMOTHY M. SCHREYER" Reply-to: TCP-IP@SRI-NIC.ARPA Comments: Warning -- original Sender: tag was tcp-ip-request@sri-nic.arpa X-To: tcp-ip@sri-nic.arpa Ya Mike, what are you looking for? VM/CMS? VMS? MS/DOS? Macintosh? MPE? There's stuff all over the place. -Ted --------- Ted Manos tmanos@aocgl.{COM,UUCP,UU.NET} or ...!{uunet,mcdchg}!aocgl!tmanos ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988060115300000> Received: from CUNYVM.CUNY.EDU by SRI-NIC.ARPA with TCP; Wed, 1 Jun 88 21:50:09 PDT Received: from BKNLVMS.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 1825; Wed, 01 Jun 88 19:30:48 EDT Date: Wed, 1 Jun 88 19:30 EDT From: PMDF Mail Server Subject: Undeliverable mail To: TCP-IP@SRI-NIC.ARPA The message could not be delivered to: Addressee: NEWMAN Reason: %MAIL-E-NOSUCHUSR, no such user NEWMAN at node ---------------------------------------- Received: from JNET-DAEMON by BKNLVMS.BITNET; Wed, 1 Jun 88 19:26 EDT Received: From OHSTVMA(MAILER) by BKNLVMS with Jnet id 6419 for NEWMAN@BKNLVMS; Wed, 1 Jun 88 18:40 EDT Received: by OHSTVMA (Mailer X1.25) id 6412; Wed, 01 Jun 88 18:36:57 EDT Date: Wed, 1 Jun 88 07:09:14 GMT From: "Theodore W. Manos" Subject: Re: non-*NIX implementations Sender: ARPA TCP-IP Discussion Redistribution To: jeff davis , 'Ralph Droms' , JERRY MEAD , "CARL I. NEWMAN" , CHRIS RILEY , "TIMOTHY M. SCHREYER" Reply-to: TCP-IP@SRI-NIC.ARPA Comments: Warning -- original Sender: tag was tcp-ip-request@sri-nic.arpa X-To: tcp-ip@sri-nic.arpa Ya Mike, what are you looking for? VM/CMS? VMS? MS/DOS? Macintosh? MPE? There's stuff all over the place. -Ted --------- Ted Manos tmanos@aocgl.{COM,UUCP,UU.NET} or ...!{uunet,mcdchg}!aocgl!tmanos ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988060115450000> Received: from CUNYVM.CUNY.EDU by SRI-NIC.ARPA with TCP; Wed, 1 Jun 88 21:51:02 PDT Received: from BKNLVMS.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 2899; Wed, 01 Jun 88 19:46:47 EDT Date: Wed, 1 Jun 88 19:45 EDT From: PMDF Mail Server Subject: Undeliverable mail To: TCP-IP@SRI-NIC.ARPA The message could not be delivered to: Addressee: SCHREYER Reason: %MAIL-E-NOSUCHUSR, no such user SCHREYER at node ---------------------------------------- Received: from JNET-DAEMON by BKNLVMS.BITNET; Wed, 1 Jun 88 19:40 EDT Received: From OHSTVMA(MAILER) by BKNLVMS with Jnet id 8645 for SCHREYER@BKNLVMS; Wed, 1 Jun 88 19:36 EDT Received: by OHSTVMA (Mailer X1.25) id 8634; Wed, 01 Jun 88 19:31:40 EDT Date: Wed, 1 Jun 88 12:42:55 CDT From: John Lee Subject: WHOIS prog. for 5000/80 Sender: ARPA TCP-IP Discussion Redistribution To: jeff davis , 'Ralph Droms' , JERRY MEAD , "CARL I. NEWMAN" , CHRIS RILEY , "TIMOTHY M. SCHREYER" Reply-to: TCP-IP@SRI-NIC.ARPA X-To: tcp-ip@SRI-NIC.ARPA Ladies and Gentlemen: I am the host administrator of an Unisys (Sperry) 5000/80 running release 5.2 of UNIX with release 2.0 of the DDN software. I am looking for someone who has a version of "WHOIS" running on their 5000/80. I would greatly appreciate getting the source code of that program. Can anyone help? Thanks for your time. John lee Information Systems Command 4300 Goodfellow St. Louis, Mo. 63120 mailbox: jlee@AVSCOM.ARPA phone: (314) 263-3137 autovon: 693-3137 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988060115530000> Received: from CUNYVM.CUNY.EDU by SRI-NIC.ARPA with TCP; Wed, 1 Jun 88 21:53:05 PDT Received: from BKNLVMS.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 3457; Wed, 01 Jun 88 19:53:59 EDT Date: Wed, 1 Jun 88 19:53 EDT From: PMDF Mail Server Subject: Undeliverable mail To: TCP-IP@SRI-NIC.ARPA The message could not be delivered to: Addressee: RILEY Reason: %MAIL-E-NOSUCHUSR, no such user RILEY at node ---------------------------------------- Received: from JNET-DAEMON by BKNLVMS.BITNET; Wed, 1 Jun 88 19:49 EDT Received: From OHSTVMA(MAILER) by BKNLVMS with Jnet id 8640 for RILEY@BKNLVMS; Wed, 1 Jun 88 19:36 EDT Received: by OHSTVMA (Mailer X1.25) id 8634; Wed, 01 Jun 88 19:31:40 EDT Date: Wed, 1 Jun 88 12:42:55 CDT From: John Lee Subject: WHOIS prog. for 5000/80 Sender: ARPA TCP-IP Discussion Redistribution To: jeff davis , 'Ralph Droms' , JERRY MEAD , "CARL I. NEWMAN" , CHRIS RILEY , "TIMOTHY M. SCHREYER" Reply-to: TCP-IP@SRI-NIC.ARPA X-To: tcp-ip@SRI-NIC.ARPA Ladies and Gentlemen: I am the host administrator of an Unisys (Sperry) 5000/80 running release 5.2 of UNIX with release 2.0 of the DDN software. I am looking for someone who has a version of "WHOIS" running on their 5000/80. I would greatly appreciate getting the source code of that program. Can anyone help? Thanks for your time. John lee Information Systems Command 4300 Goodfellow St. Louis, Mo. 63120 mailbox: jlee@AVSCOM.ARPA phone: (314) 263-3137 autovon: 693-3137 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988060115590000> Received: from CUNYVM.CUNY.EDU by SRI-NIC.ARPA with TCP; Wed, 1 Jun 88 21:54:12 PDT Received: from BKNLVMS.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 4208; Wed, 01 Jun 88 20:00:10 EDT Date: Wed, 1 Jun 88 19:59 EDT From: PMDF Mail Server Subject: Undeliverable mail To: TCP-IP@SRI-NIC.ARPA The message could not be delivered to: Addressee: NEWMAN Reason: %MAIL-E-NOSUCHUSR, no such user NEWMAN at node ---------------------------------------- Received: from JNET-DAEMON by BKNLVMS.BITNET; Wed, 1 Jun 88 19:54 EDT Received: From OHSTVMA(MAILER) by BKNLVMS with Jnet id 8639 for NEWMAN@BKNLVMS; Wed, 1 Jun 88 19:36 EDT Received: by OHSTVMA (Mailer X1.25) id 8634; Wed, 01 Jun 88 19:31:40 EDT Date: Wed, 1 Jun 88 12:42:55 CDT From: John Lee Subject: WHOIS prog. for 5000/80 Sender: ARPA TCP-IP Discussion Redistribution To: jeff davis , 'Ralph Droms' , JERRY MEAD , "CARL I. NEWMAN" , CHRIS RILEY , "TIMOTHY M. SCHREYER" Reply-to: TCP-IP@SRI-NIC.ARPA X-To: tcp-ip@SRI-NIC.ARPA Ladies and Gentlemen: I am the host administrator of an Unisys (Sperry) 5000/80 running release 5.2 of UNIX with release 2.0 of the DDN software. I am looking for someone who has a version of "WHOIS" running on their 5000/80. I would greatly appreciate getting the source code of that program. Can anyone help? Thanks for your time. John lee Information Systems Command 4300 Goodfellow St. Louis, Mo. 63120 mailbox: jlee@AVSCOM.ARPA phone: (314) 263-3137 autovon: 693-3137 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12403011487.32.JLEE@STL-HOST1.ARPA] <1988060117365800> From: JLEE@STL-HOST1.ARPA (John Lee) Newsgroups: comp.protocols.tcp-ip Subject: whois prog. for 5000/80 Message-ID: <12403011487.32.JLEE@STL-HOST1.ARPA> Date: 1 Jun 88 17:36:58 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 16 Ladies/Gentlemen: I am the host administrator of an Unisys (Sperry) 5000/80 running UNIX 5.2. We are running release 2.0 of DDN software. I am looking for someone who has the "whois" program running on their 5000/80. If so, I would like to get the program (source if possible). Is there anyone who can help? My mailbox is jlee@AVSCOM.ARPA. Thanks for you time. John Lee Information Systems Command 4300 Goodfellow St. Louis, Mo. 63120 mailbox address : jlee@AVSCOM.ARPA ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12403012570.12.JLEE@STL-HOST1.ARPA] <1988060117425500> From: JLEE@STL-HOST1.ARPA (John Lee) Newsgroups: comp.protocols.tcp-ip Subject: WHOIS prog. for 5000/80 Message-ID: <12403012570.12.JLEE@STL-HOST1.ARPA> Date: 1 Jun 88 17:42:55 GMT Article-I.D.: STL-HOST.12403012570.12.JLEE Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 15 Ladies and Gentlemen: I am the host administrator of an Unisys (Sperry) 5000/80 running release 5.2 of UNIX with release 2.0 of the DDN software. I am looking for someone who has a version of "WHOIS" running on their 5000/80. I would greatly appreciate getting the source code of that program. Can anyone help? Thanks for your time. John lee Information Systems Command 4300 Goodfellow St. Louis, Mo. 63120 mailbox: jlee@AVSCOM.ARPA phone: (314) 263-3137 autovon: 693-3137 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [360@lalk.excelan.UUCP] <1988060119004800> From: chuck@excelan.UUCP (Chuck Kollars) Newsgroups: comp.protocols.tcp-ip Subject: Re: Third TCP-IP Book? Message-ID: <360@lalk.excelan.UUCP> Date: 1 Jun 88 19:00:48 GMT References: <8805170601.AA21125@Larry.McRCIM.McGill.EDU> <12399598897.40.LYNCH@A.ISI.EDU> <925@actnyc.UUCP> Reply-To: chuck@lalk.UUCP (Chuck Kollars) Organization: Excelan Inc., San Jose, CA Lines: 22 In article <925@actnyc.UUCP> gcf@actnyc.UUCP (Gordon Fitch) writes: >I'd like to get the full titles, etc., of the [TCP/IP] books ... An Introduction to TCP/IP by John Davidson Springer-Verlag, 1988 - ISBN# 0-387-96651-X (also 3-540-96651-X) paperback, over 100 pages - suggested retail price $24.95 Handbook of Computer Communications Standards Volume 3, Department of Defense (DOD) Protocol Standards by William Stallings Macmillan, 1988 - ISBN# 0-02-948072-8 hardbound, over 200 pages - suggested retail price $34.95 Internetworking With TCP/IP Principles, Protocols, and Architecture by Douglas Comer Prentice Hall, 1988 - ISBN# 0-13-470154-2 hardbound, almost 400 pages - suggested retail price $36.00 -- Chuck Kollars, Excelan, Inc. mtxinu!excelan!chuck@ucbvax.Berkeley.COM (chuck@excelan.UUCP) ...!{mtxinu,leadsv,cae780}!excelan!chuck ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806020322.AA06334@ucbvax.Berkeley.EDU] <1988060119060000> From: AIVANO@VENUS.YCC.YALE.EDU Newsgroups: comp.protocols.tcp-ip Subject: Moderated Newsgroup Posting Message-ID: <8806020322.AA06334@ucbvax.Berkeley.EDU> Date: 1 Jun 88 19:06:00 GMT Article-I.D.: ucbvax.8806020322.AA06334 Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 20 Path: venus!aivano From: aivano@venus.ycc.yale.edu Newsgroups: mail.tcp-ip Subject: Public Domain TN3270 Message-ID: <27@venus.ycc.yale.edu> Date: 1 Jun 88 14:05:48 GMT Organisation: VMS NEWS V4.0 Lines: 11 Is there a public domain TN3270 program that runs under VMS and can interface with Wollongong's TCP/IP? We would prefer to have source code so that we could write our own interface, but could live with a documented executable that includes an interface to the Wollongong TCP/IP. Please send replies directly to me, Sandy Aivano Yale Computer Center AIVANO@YALEVMS (BITNET) AIVANO@YALEVMS.YCC.YALE.EDU (ARPA) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1115@thumper.bellcore.com] <1988060119553400> From: karn@thumper.bellcore.com (Phil R. Karn) Newsgroups: rec.ham-radio.packet,comp.protocols.tcp-ip Subject: Re: SLIP Info please? Summary: SLIP definition Message-ID: <1115@thumper.bellcore.com> Date: 1 Jun 88 19:55:34 GMT References: <401@jc3b21.UUCP> Organization: Bell Communications Research, Inc Lines: 63 I don't think I've seen a formal description of SLIP, but it is very simple. It is just a framing technique suitable for carrying IP datagrams (or whatever you want) on asynchronous links. Four special characters are defined. They are as follows: C0 hex DB DC DD Transmitter Operation The transmitter sends the frame a byte at a time, ending it with the character. If a character occurs in the body of the frame, it is replaced by the two character sequence , . Similarly, if a character occurs in the body of the frame, it is replaced by the two byte sequence , . Receiver Operation The receiver appends incoming bytes to a reassembly buffer, passing whatever has been accumulated up to the next layer when it sees a character. (The itself is not added to the buffer). The receiver maintains a one-bit "escaped" flag that is set whenever it sees a character. (The character itself is NOT added to the reassembly buffer). If the receiver then sees either a or a while in "escaped" mode, it is translated to a or a , respectively, and adds it to the reassembly buffer. Regardless of the character received while in escaped mode, the "escaped" flag is cleared. If the or characters are received while NOT in "escaped" mode, no special action is necessary; they are added to the reassembly buffer unchanged. Note that the character is *never* sent over the line except as an actual end-of-frame indication. The original SLIP put characters only at the end of each frame. I.e., a series of back-to-back frames would be separated by only a single . I have made a minor, backward compatible change to the protocol that puts a in front of each frame as well. This adds a very small bit of overhead (back-to-back frames are now separated by two characters) but it improves performance over noisy links by forcing the receiver into a known state at the beginning of each new frame. When used to send IP datagrams over phone lines, the datagrams are encapsulated directly in frames formatted as described here; no additional header is carried. There has been considerable discussion about the need for such a header, but nothing has actually come into use, as far as I know. I use SLIP in a different way between a system running my TCP/IP software and a KISS TNC. There I use SLIP style framing to carry AX.25 frames and control messages between the TNC and host, and there is a one-byte "type" field at the beginning of each frame. For details, see the paper by K3MC and myself in last year's ARRL Computer Networking Conference proceedings. (The same article also described SLIP in detail). Phil ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8851162341.21a0028a.HEILNER_K] <1988060121234000> From: HEILNER_K@VAXC.STEVENS-TECH.EDU Newsgroups: comp.protocols.tcp-ip Subject: ISO Documents Message-ID: <8851162341.21a0028a.HEILNER_K> Date: 1 Jun 88 21:23:40 GMT Article-I.D.: <8851162341.21a0028a.HEILNER_K> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 16 Hi Does anyone have the address for purchasing documents like ISO 8348. I am particularly interested in finding documents that explain the structure of the network address as defined by ISO. Thanks Keith Heilner Stevens Institute Network Coordinator Heilner_k@sitvxc Heilner_k@vaxc.stevens-tech.edu ------------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988060122011000> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Wed, 1 Jun 88 17:06:46 PDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA02627; Wed, 1 Jun 88 16:22:20 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: 1 Jun 88 22:01:10 GMT From: amdahl!pacbell!david@ames.arc.nasa.gov (David St.Pierre) Organization: Pacific * Bell, San Ramon, CA Subject: TCP/IP in MVS? Message-Id: <353@pacbell.PacBell.COM> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa I'm trying to determine whether or not there are any commercial products which support TCP/IP on MVS, specifically for the purposes of FTP. We need to transfer a lot of files around and sneaker-net just isn't cutting it. I've talked to one vendor who may have a product out this summer. Other than that, I'm completely at a loss as to what's available. What kind of hardware is needed? What's required on the MVS side? How is security handled (RACF, ACF2)? Any leads would be appreciated. Please E-mail them to me. Thanks. -- David St. Pierre 415/823-6800 {att,bellcore,sun,ames,pyramid}!pacbell!david ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1683@lll-lcc.aRpA] <1988060200255700> From: wiltzius@lll-lcc.aRpA (Dave P. Wiltzius) Newsgroups: comp.protocols.tcp-ip Subject: UDP reserved ports Message-ID: <1683@lll-lcc.aRpA> Date: 2 Jun 88 00:25:57 GMT Article-I.D.: lll-lcc.1683 Reply-To: wiltzius@lll-crg.UUCP (Dave P. Wiltzius) Organization: CRG, Lawrence Livermore Labs Lines: 14 I believe this was discussed here a while back, but I would like to know how daemons (such as TFTPD or FTPD) get their reserved UDP or TCP port (as specified in RFC 1010 if I recall correctly). That is, the port for TFTP is 69 (dex) as per RFC 1010. The TFTP client therefore sends packets to the destination host with UDP port number 69 - which the TFTP daemon on that host should subsequently receive since it listens on UDP port 69. How does it acquire UDP port 69? Directions to appropriate BSD code would be most welcome. Thank you. Dave (wiltzius@lll-lcc.llnl.gov) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [23053@bu-cs.BU.EDU] <1988060202364800> From: bzs@bu-cs.BU.EDU (Barry Shein) Newsgroups: comp.protocols.tcp-ip Subject: Re: UDP reserved ports Message-ID: <23053@bu-cs.BU.EDU> Date: 2 Jun 88 02:36:48 GMT Article-I.D.: bu-cs.23053 References: <1683@lll-lcc.aRpA> Organization: Boston U. Comp. Sci. Lines: 10 In-reply-to: wiltzius@lll-lcc.aRpA's message of 2 Jun 88 00:25:57 GMT >How does it acquire UDP port 69? Directions to appropriate >BSD code would be most welcome. > >Thank you. > Dave (wiltzius@lll-lcc.llnl.gov) See the bind and recvfrom manual pages. -Barry Shein, Boston University ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988060205530000> Mail-From: MKL created at 2-Jun-88 17:28:16 Received: from CUNYVM.CUNY.EDU by SRI-NIC.ARPA with TCP; Thu, 2 Jun 88 16:55:41 PDT Received: from BAYLOR.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 4767; Thu, 02 Jun 88 13:12:13 EDT Date: Thu, 2 Jun 88 11:53 CST From: Michael Califf Subject: RE: TCP/IP in MVS? To: TCP-IP@SRI-NIC.ARPA X-VMS-To: IN%"TCP-IP@SRI-NIC.ARPA" ReSent-Date: Thu, 2 Jun 88 17:27:20 PDT ReSent-From: Mark Lottor ReSent-To: tcp-ip-rebroadcast@SRI-NIC.ARPA ReSent-Message-ID: <12403348335.42.MKL@SRI-NIC.ARPA> Here at Baylor we are using a product from Advintech inc. on our MVS 4381. It is a combined hardware/software product which uses a custom channel-attach box to interface to the ether/DDN and includes SMTP (with a mailer) FTP and TELNET (nvt). This is a new company and a new product so there are still a few bugs, but they are working on them. If you want an address/phone number please send me a note or call. Mike Califf Communications Programming Coordinator Baylor University CALIFFM@BAYLOR.BITNET (817) 755-2711 I have no connection with ACVINTECH other than being an employee of a moderately satisfied customer. My opinions are my own and rarely reflect those of my employers. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12403151619.23.MKL@SRI-NIC.ARPA] <1988060206264400> From: MKL@SRI-NIC.ARPA (Mark Lottor) Newsgroups: comp.protocols.tcp-ip Subject: Mail Loop Message-ID: <12403151619.23.MKL@SRI-NIC.ARPA> Date: 2 Jun 88 06:26:44 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 7 Submissions to the TCP-IP list will now be manually redistributed until the person responsible for the mail loop sends me a personal letter explaining that it is fixed. The bogus mail is from: From: PMDF Mail Server ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [3348@pdn.UUCP] <1988060212102200> From: steve@pdn.UUCP (Steve Fowler) Newsgroups: comp.protocols.tcp-ip Subject: Re: ISO Documents Message-ID: <3348@pdn.UUCP> Date: 2 Jun 88 12:10:22 GMT Article-I.D.: pdn.3348 References: <8851162341.21a0028a.HEILNER_K> Reply-To: steve@pdn.UUCP (0000-Steve Fowler) Organization: Paradyne Corporation, Largo, Florida Lines: 45 In article <8851162341.21a0028a.HEILNER_K> you write: >Does anyone have the address for purchasing documents like ISO 8348. I am >particularly interested in finding documents that explain the structure of >the network address as defined by ISO. > >Keith Heilner >Stevens Institute >Network Coordinator >Heilner_k@sitvxc >Heilner_k@vaxc.stevens-tech.edu Keith, The document you are looking for can be purchased from the following company: OMNICOM, INC. 115 Park Street, S.E. Vienna, VA 22180 TEL: (703) 281-1135 FAX: (703) 281-1505 TLX: 279678 OMNI UR ORDER#: 1-800-OMNICOM (666-4266) I quote from their order form: "The American National Standards Institute (ANSI) has granted to Omnicom the right to distribute ISO/IEC JTC 1 (Information Processing Systems) working papers, draft proposals, draft international standards, and internmational standards currently available for Open Systems Interconnection and Data Commuinications. Topics of interest ionclude the seven layers of OSI, OSI Management, Formal Description Languages, Conformance Testing, Database Languages, Computer Graphics, Text and Office Systems, The Directory, and Remote Database Operations." Omnicom also distributes the CCITT "red" and "green" books. I hope that this information helps you. -- Steve Fowler W(813) 530-8708 Paradyne Corporation | \ _ / "I can't even be held responsible for Mail Stop LF-207 | ~o.O~ my own opinions much less my employer's" 8550 Ulmerton Rd., | (_|_) ..!uunet!pdn!steve Largo, FL 34641 | / U ----MESSAGE-END---- ----MESSAGE-BEGIN---- [21877@amdcad.AMD.COM] <1988060217065200> From: indra@amdcad.AMD.COM (Indra K. Singhal) Newsgroups: comp.protocols.tcp-ip Subject: Convert /etc/hosts to RR format pgm anyone? Message-ID: <21877@amdcad.AMD.COM> Date: 2 Jun 88 17:06:52 GMT Article-I.D.: amdcad.21877 Organization: Advanced Micro Devices, Inc., Sunnyvale, Ca. Lines: 11 Has anyone put together a program/shell script that converts /etc/hosts to the standard RR format as specified in the RFCs listed? Thought I'd ask before I get a coleague to spend time reinventing it. Thanks !! -- Indra K. Singhal | | {ucbvax,decwrl,allegra}!amdcad!indra | This space for rent ! | amdcad!indra@decwrl.dec.com | | (408) 749-5445(w) | | ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988060219523100> Mail-From: MKL created at 2-Jun-88 19:26:30 Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Thu, 2 Jun 88 18:59:38 PDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA22589; Thu, 2 Jun 88 13:33: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: 2 Jun 88 19:52:31 GMT From: zu!kurt@hc.dspo.gov (Kurt Zeilenga) Organization: U. of New Mexico, Albuquerque Subject: TCP/IP for PDP-11 running TSX (RT11) Message-Id: <23595@zu.unm.edu> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa ReSent-Date: Thu, 2 Jun 88 19:26:06 PDT ReSent-From: Mark Lottor ReSent-To: tcp-ip-rebroadcast@SRI-NIC.ARPA ReSent-Message-ID: <12403369957.20.MKL@SRI-NIC.ARPA> We have a system here in need of a cheap, basic TCP/IP implementation. It should support at least telnet and FTP. Here is the description I was given of the system: >My machine is a PDP-11/23. The Ethernet card is a DEQNA. My operating >system is TSX-Plus Version 5.1B, which is written by S&H Enterprises. >TSX is based on DEC's RT11, inc this case Version 5. TSX uses all of the >RT11 filesystem and I/O handlers, but replaces the kernel with a >multitasking multiuser real-time kernel. Any pointers, etc., would be greatly appreciated. -- Kurt ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12403312072.42.MKL@SRI-NIC.ARPA] <1988060221080800> From: MKL@SRI-NIC.ARPA (Mark Lottor) Newsgroups: comp.protocols.tcp-ip Subject: a bunch of messages Message-ID: <12403312072.42.MKL@SRI-NIC.ARPA> Date: 2 Jun 88 21:08:08 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 190 Received: from DOCKMASTER.ARPA by SRI-NIC.ARPA with TCP; Thu, 2 Jun 88 05:47:11 PDT Date: Thu, 2 Jun 88 08:45 EDT From: Fitch@DOCKMASTER.ARPA Subject: UDP Example Sources To: tcp-ip@SRI-NIC.ARPA Message-ID: <880602124550.014174@DOCKMASTER.ARPA> I am looking for a suite of examples using UDP, ranging from something simple (say an echo server) to something more complex (say TFTP). Can someone point me to public domain, anonymous FTP-able, sources? In particular, I am looking for examples using the Berkeley socket interface to UDP. --Jack Fitch (Fitch@dockmaster.arpa) include ---------------------------------------------------------------------- Received: from uxc.cso.uiuc.edu by SRI-NIC.ARPA with TCP; Thu, 2 Jun 88 09:13:15 PDT Received: by uxc.cso.uiuc.edu (5.51/9.7) id AA23522; Thu, 2 Jun 88 10:28:59 CDT Date: Thu, 2 Jun 88 10:28:59 CDT From: kline@uxc.cso.uiuc.edu (Charley Kline) Message-Id: <8806021528.AA23522@uxc.cso.uiuc.edu> To: tcp-ip@sri-nic.arpa Subject: Re: non-*NIX implementations We run TCP implementations on Unix systems as well as VMS, Macintosh, MSDOS, Cray CTSS, and VM/SP. What did you want to know? ----- Charley Kline, University of Illinois Computing Services kline@tuna.cso.uiuc.edu {ihnp4,uunet,pur-ee,convex}!uiucuxc!kline "Birth. School. Work. Death." ---------------------------------------------------------------------- Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Thu, 2 Jun 88 09:41:24 PDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA16608; Thu, 2 Jun 88 08:32: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: 1 Jun 88 06:54:36 GMT From: mcvax!enea!erix!per@uunet.uu.net (Per Hedeland) Organization: Ericsson Telecom, Stockholm, Sweden Subject: Re: Subnetting Message-Id: <1624@erix.UUCP> References: <1607@erix.UUCP> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa While it may be a bit late, I thought I should post a short summary of the information I got in response to my query a few weeks back - it did generate some discussion, after all. If you recall, the issue was how to use subnetting on a network structure with a big backbone net and many small ones hanging off of it. I think the below is the essence of what I found out; I also have a pile of mail for those particularly interested. - Unequal-sized subnets, whether or not a Good Thing, is not currently implemented in any generally accepted way (and thus of little interest to us). - Partitioned subnets (i.e. subnets of a given net interconnected only by some other net) are out. - One can have several logical subnets on the same wire (i.e. the backbone in our case), thus effectively increasing the address space, at the expense of some manual "routing" (i.e. gateways have to be explicitly told that the different subnets can be accessed via the same interface - hosts on such a wire can be "fooled" into believing that it's all one (bigger) subnet). We will probably go for the latter method, with a long-term goal of splitting our backbone by using dedicated routers. Thanks to all who offered help and advice! ---Per Hedeland ---------------------------------------------------------------------- Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Thu, 2 Jun 88 10:28:56 PDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA18222; Thu, 2 Jun 88 10:04: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: 1 Jun 88 19:00:48 GMT From: amdahl!pyramid!leadsv!excelan!chuck@ames.arc.nasa.gov (Chuck Kollars) Organization: Excelan Inc., San Jose, CA Subject: Re: Third TCP-IP Book? Message-Id: <360@lalk.excelan.UUCP> References: <8805170601.AA21125@Larry.McRCIM.McGill.EDU>, <12399598897.40.LYNCH@A.ISI.EDU>, <925@actnyc.UUCP> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa In article <925@actnyc.UUCP> gcf@actnyc.UUCP (Gordon Fitch) writes: >I'd like to get the full titles, etc., of the [TCP/IP] books ... An Introduction to TCP/IP by John Davidson Springer-Verlag, 1988 - ISBN# 0-387-96651-X (also 3-540-96651-X) paperback, over 100 pages - suggested retail price $24.95 Handbook of Computer Communications Standards Volume 3, Department of Defense (DOD) Protocol Standards by William Stallings Macmillan, 1988 - ISBN# 0-02-948072-8 hardbound, over 200 pages - suggested retail price $34.95 Internetworking With TCP/IP Principles, Protocols, and Architecture by Douglas Comer Prentice Hall, 1988 - ISBN# 0-13-470154-2 hardbound, almost 400 pages - suggested retail price $36.00 -- Chuck Kollars, Excelan, Inc. mtxinu!excelan!chuck@ucbvax.Berkeley.COM (chuck@excelan.UUCP) ...!{mtxinu,leadsv,cae780}!excelan!chuck ---------------------------------------------------------------------- Received: from acc.arpa by SRI-NIC.ARPA with TCP; Thu, 2 Jun 88 10:47:19 PDT Date: 2 Jun 88 10:31:00 PST From: Subject: RE: ISO Documents To: "heilner_k" cc: tcp-ip@sri-nic.arpa Reply-To: >Does anyone have the address for purchasing documents like ISO 8348. I am >particularly interested in finding documents that explain the structure of >the network address as defined by ISO. Two places that we use are: OMNICOM, Inc. 115 Park Street S.E. Vienna, VA 22180 (703) 281-1135 AlphaGraphics 10215 N. 35th Ave. Phoenix, AZ 85051 (602) 863-0999 Both try to obtain up-to-date copies of the standards documents and offer document duplication services. I believe both will take phone orders on major credit cards. OMNICOM also provides seminars on ISO protocols, etc. Art Berggreen art@acc.arpa ------ ---------------------------------------------------------------------- Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Thu, 2 Jun 88 12:25:12 PDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA19084; Thu, 2 Jun 88 10:44:07 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: 2 Jun 88 17:06:52 GMT From: amdcad!indra@ucbvax.Berkeley.EDU (Indra K. Singhal) Organization: Advanced Micro Devices, Inc., Sunnyvale, Ca. Subject: Convert /etc/hosts to RR format pgm anyone? Message-Id: <21877@amdcad.AMD.COM> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa Has anyone put together a program/shell script that converts /etc/hosts to the standard RR format as specified in the RFCs listed? Thought I'd ask before I get a coleague to spend time reinventing it. Thanks !! -- Indra K. Singhal | | {ucbvax,decwrl,allegra}!amdcad!indra | This space for rent ! | amdcad!indra@decwrl.dec.com | | (408) 749-5445(w) | | ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806022259.AA25446@skl-crc.arpa] <1988060222594300> From: symchych@SKL-CRC.ARPA (Tim Symchych) Newsgroups: comp.protocols.tcp-ip Subject: Re: Linking LAN's via Public X.25 Message-ID: <8806022259.AA25446@skl-crc.arpa> Date: 2 Jun 88 22:59:43 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 81 Perhaps another view of IP over X.25 might help. While the original question was asked about Sun X.25, there are a number of networks within the ARPA/Internet that use IP over X.25. The experience that Phil Karn described at Bellcore does not describe our experience in establishing the DRENET and XDRENET here in Canada. There is no doubt in my mind that some implementations of packet switching using CCITT X.25 are poor. We did some testing of various networks about two years ago including ARPANET (1822 Links), Telenet in the USA, SATNET, and the public packet switching networks in the UK and Canada (Datapac). Packets were timed in some great loops, and by network segment to allow us to determine level of service over the various segments. Generally, the packets through Telenet and SATNET suffered the most delay. The X.75 gateways didn't seem to work all that well then either. I'm not sure that X.25 was designed for slow speed terminal multiplexing. NO packet switching network works well at that task. In our own case, use of TCP/IP over X.25 has been shown effective from both points of view: cost and throughput. In Canada, we have at least one first rate X.25 packet switching network. Through eight years of using Datapac for applications, including five years of TCP/IP over X.25, we have found no problems in service or reliability. By the way, I don't work for any of the Bell franchises, nor do I own any of their stock. I just pay the phone bill. We have several hosts and gateways that connect LANs using X.25. I don't agree that X.25 is overly complex, or managing virtual circuits is a big problem. Our gateways and hosts usually do the work in software on board level products. We did some preliminary testing with SunLink using our hosts and one of their software implementations. Everything worked but the Sun stuff has some minor rough edges. For instance, the Sun would only allow one virtual circuit between two hosts even thought our side would allow one per user process. Imagine sharing your TELNET session with an FTP with each IP packet waiting it turn in in the X.25 queue. TELNET over X.25 is bad, but Sun made it worse. I hope they worked on that "kludge". Our tariff structure for communication services is almost the reverse to that in the U.S. Our leased lines cost us dearly, but out packet switching cost much less. If you look at our telco infrastructure, its easy to see why. Our population is spread across the country, and leased lines are nearly always new services. In the way of cost and performance, we have this kind of experience: Rental of 9600 bps X.25 modem with 20 virtual circuits is $390.00 U.S. per month. Traffic charges range from $35.00 to $300.00 U.S. per month per X.25 interface depending on usage and distance. The later is for about 50MB per month to a site 1500 miles away using the Datapac cost formula. On most of our X.25 legs, we get between 50 and 75 per cent of the of the 9600 bps. But this does depend a great deal on the HOST implementation of TCP/IP. In contrast, our 9600 bps HDH line gives us about 80 to 85 per cent of the line speed. Our 56 kbps line gives about 20 to 30 percent of the line speed, but we are not sure that we have hosts at either end to drive it faster. To send a 10 MB file across the country, it would cost about $75.00 U.S.. Thats about the same as it would cost to run the data on to a mag new tape and send it FEDEX. Some of our sites will be running 19.2 bps X.25 service which will double the monthly modem cost, and increase throughput but will be limited by the TCP/IP on the hosts. We expect that these 19.2 links will get us about 12000 bps or just about what we get out of our very expensive 56k bps line between our core gateway and the U. of Rochester. When our core gateway was replaced in Feb/88 with a Butterfly, the measured throughput went up slightly even though the HDH interface was replaced with an X.25 interface. I've tried to figure that one out. I will be the first to agree that our needs and network structure is different than Bellcore. However, I view X.25 packet switches as a low cost backbone that will allow us to operate until we have sufficient traffic levels to support leased lines. If there is a target needing a thumper, it sounds like the implementation of X.25 in Telenet will do. When it comes to bad implementations of TCP/IP, the cry is "burn them at the stake". There are good and bad X.25 implementations, and I recommend burning where it is due. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988060304310000> Mail-From: MKL created at 3-Jun-88 12:17:30 Received: from jessica.Stanford.EDU by SRI-NIC.ARPA with TCP; Fri, 3 Jun 88 11:33:13 PDT Received: by jessica.Stanford.EDU; Fri, 3 Jun 88 11:31:42 PDT Date: 3 Jun 1988 1131-PDT (Friday) From: Charles Spurgeon To: tcp-ip@sri-nic.arpa Cc: Subject: Network books, TCP/IP and Ethernet ReSent-Date: Fri, 3 Jun 88 12:17:19 PDT ReSent-From: Mark Lottor ReSent-To: tcp-ip-rebroadcast@SRI-NIC.ARPA ReSent-Message-ID: <12403554042.37.MKL@SRI-NIC.ARPA> The following is an annotated list of books that I've found useful while designing, building, and operating networks at Stanford University over the last several years. The list reflects the experience of building networks primarily based on TCP/IP protocols and Ethernet technology. This message is long. I just set out to list some useful books with complete access information, and it got longer and longer... -Charles Spurgeon (spurgeon@jessica.stanford.edu) Networking and Communications Systems, Stanford University. June 3, 1988 -- Introductory -- 1. "Local Area Networks", by John E. McNamara, 1985, 165pps with index and glossary. $29.00 Published by Digital Press, ISBN 0-932376-79-7. Digital Press part number for ordering is EY-00051-DP. Digital Press phone is 1-800-343-8321. This is a good general introduction to the concepts and technologies of LANs. As stated in the preface: " This book is intended for students, computer system managers, telecommunications managers, and others who want to become more familiar with local area networks. Since product offerings in this area are constantly changing, a deliberate attempt has been made to emphasize the general principles, operating characteristics, and problem areas of local area network hardware, rather than cite specific product examples." Of special note is the chapter on "Administrative considerations for large networks" which is largely taken from David Clark's 1983 "M.I.T. Campus Network Implementation Planning Document". This chapter mentions many of the problems of supporting large campus area networks with special reference to the issue of multiple protocol support on campus backbone networks. -- Two books by Douglas Comer -- Douglas Comer has written two books of special interest to the networker. His books are comprehensive and he has an excellent writing style, making these the best books I've seen on the TCP/IP protocols. 2. "Internetworking With TCP/IP, Principles, Protocols, and Architecture". By Douglas E. Comer. 1988, 382pps with index and glossary. Prentice-Hall, Inc., New Jersey, ISBN 0-13-470154-2. $36.00. (Stanford Bookstore price.) As stated in the preface: "For professionals, the book provides a comprehensive introduction to TCP/IP technology and the architecture of the Internet. Although it is not intended to replace protocol standards, the book is a good starting point for learning about internetworking because it gives a uniform overview that emphasizes principles. Moreover, it gives the reader perspective that can be extremely difficult to obtain from individual protocol documents." "The book is organized into four main parts. Chapters 1 and 2 form an introduction that provides an overview and discusses existing technologies. In particular, Chapter 2 reviews physical network hardware. The intention is to provide basic intuition about what is possible, not to spend inordinate time on hardware details. Chapters 3-12 describe the TCP/IP Internet from the viewpoint of a single host, showing the basic services available and the protocols a host uses to access them. They cover the basics of Internet addressing and routing as well as the notion of protocol layering. Chapters 13-16 describe the architecture of the Internet when viewed globally. They explore the core gateway system and the protocols gateways use to exchange routing information. Finally, Chapters 17-19 discuss application level services available in the Internet. They present the client-server model of interaction and give several examples of how one can organize client and server software. The last section discusses electronic mail and the domain name system, two topics that are extremely popular." I particularly like the real-world orientation of this book. For instance, there is an appendix on "4.3 BSD UNIX Interface to Internet Protocols" that describes Berkeley sockets and presents example client and server programs for a network whois service. There's another appendix on "Hints And Suggestions For Implementors" full of useful tips for network programmers. And there's a nice appendix called "A Guide To RFCs" which explains the Requests For Comments completely and with due regard for the early folklore and development of the ARPAnet. A guide to the first one thousand RFCs, extracted from RFC1000, is presented as well as electronic and snail mail addresses for getting your own copies of the RFCs. 3. "Operating System Design - Volume II, Internetworking with Xinu". By Douglas Comer. 1987, 5667pps with index. Published by Prentice-Hall, Inc., New Jersey, ISBN 0-13-637414-X. $39.33. (Stanford Bookstore price.) As stated in the preface: "Chapters 1-11 comprise a self-contained unit that covers the basics of internet communication. Each of the eleven chapters explores one component of internet protocol software, motivating and explaining how that component fits into the overall system design. The unit starts with a detailed examination of one network technology, the Ethernet, and moves on to consider the internet concept, address resolution, internet datagrams, routing, control messages, user datagrams, and datagram demultiplexing. Later chapters build on the basic communication system, examining client-server interaction, and remote file access, as well as a user interface and commands that manipulate both local and remote files." "Written as a continuation of 'Operating System Design - The XINU Approach' (Comer [1984]), this text starts where the earlier one ends. The two volumes were written to support a two-semester course in systems design that encompasses operating systems and networks... ." This book is based on the XINU operating system software which is available from Purdue University as described in the book. XINU was written to give students the experience of studying a UNIX-like operating system whose source code was available for modification. Lots of software examples in every chapter make this an especially useful text for aspiring network programmers. It's also good resource for those just curious as to what network software looks like and how it fits together. -- Three books by William Stallings -- William Stallings has published a series of three books that can be helpful in hacking one's way through the jargon laden jungles of network standards - especially the OSI and IEEE standards. 4. "Volume 1. Handbook of Computer Communications Standards, The Open Systems Interconnection (OSI) Model and OSI-Related Standards". By William Stallings. 1987, 322pps with index. Macmillan Publishing Co., NY, ISBN 0-02-948071-X. $34.95. The first volume sets the stage by explaining the OSI standards effort and the organization of the OSI standards process. The OSI reference model is then presented, and each layer is discussed in depth with lots of detail. OSI is a moving target, and some of the material here is no doubt already dated, but it's still a good explanation of the whole OSI world. 5. "Volume 2. Handbook of Computer Communications Standards, Local Network Standards". By William Stallings. 1987, 244pps with index. Macmillan Publishing Co,, NY, ISBN 0-02-948070-1. $34.95. This book covers the IEEE 802 series of standards and the emerging FDDI standard. The material described here makes it possible to decipher the 802.3 standard. After a brief introduction covering network topologies and media, Stallings explains the standardization efforts, including the structure of the standards committees and how the various standards agencies interact. Next the IEEE 802 standards structure is described, with the various subsets explained. Chapter 4 describes the 802.3 standard including variants such as 10BASE2. Also included is a brief description of the major differences between 802.3 and DIX Ethernet. An appendix provides a short introduction to the OSI reference model, so that you don't need volume 1 to figure out volume 2. 6. "Volume 3. Handbook of Computer Communications Standards, Department of Defense (DOD) Protocol Standards". By William Stallings, Paul Mockapetris, Sue McLeod and Tony Michel, 1988, 206pps with index. Macmillan Publishing Co., NY, ISBN 0-02-948072-8. $34.95. This volume is a guide to the TCP/IP protocol suite. As stated in the preface: "...Volume 3, covers the five military standard protocols that have been issued by the DOD. The book begins by introducing the four layer communications architecture that is the framework within which these standards fit. Following the introduction of this architecture, a chapter is devoted to each of the standards." "In contrast with the other books in this series, several of the chapters of this book were written by contributors. Each contributor is intimately familiar with the topic under discussion: biographies of the main author and the contributing authors are found at the end of the book." The chapters on IP and TCP appear to have been written by Stallings. The chapter on FTP is by Tony Michel, the SMTP chapter by Paul Mockapetris and the Telnet chapter by Sue McLeod. The chapters are good descriptions of the various protocols. On the other hand, I prefer Douglas Comer's book, for reasons given above. -- Ethernet Standards -- The next several items deal with the various Ethernet standards in use today. 7. "Ethernet Local Area Network Specification Version 2.0. November, 1982". 103pps, $32.00. DEC Part Number: AA-K759B-TK. Available from DEC-Direct by calling 1-800-344-4825. This is version 2 of the original ten megabit Ethernet specification. The newer 802.3 standard supersedes the DEC-Intel-Xerox (DIX) spec listed here, but most TCP/IP implementations are still based on this DIX specification. Since this specification is not based on the OSI model it is relatively jargon free and reads like something close to English, making it a much more approachable document than the IEEE standards. 8. "Carrier Sense Multiple Access with Collision Detection, ANSI/IEEE Std 802.3, 1985, ISO/DIS 8802/3". ISBN 0-471-82749-5. Available from, IEEE Service Center, 445 Hoes Lane, Piscataway, New Jersey 08854, or by calling 1-201-981-0060, or from technical bookstores (see below). The new Ethernet specifications. Much has changed. Much stayed the same. Vendors like to gloss over the differences (it's a lot easier than trying to describe them!) and you're on your own trying to figure out how it all works. This standard was written to comply with the OSI model. As a result, it contains much more jargon and can be much less understandable at first. An explanatory guide like Stalling's volume 2 is a requirement to help the newcomer to OSI make any sense of it all. 9. "Supplements to Carrier Sense Multiple Access with Collision Detection, ANSI/IEEE Std 802.3a,b,c,and e-1988". ISBN 0-471-61153-0 Same access as above. A set of additions to the 1985 802.3 standard, including the thin Ethernet standard (Type 10BASE2). Also included is the broadband standard (Type 10BROAD36) and a revision of section 9 of the 1985 standard on repeaters. -- Ethernet hardware information -- None of the Ethernet standards docs are very useful when it comes to actually building, testing, and operating an Ethernet. For that you need information about what topologies are allowed, how Ethernet equipment is configured, how to attach connectors and all the rest. While there isn't a good general book available on Ethernet design and construction, the following manual can help. 10. "LAN Cable and Accessories Installation Manual", January 1986, published by Hewlett-Packard Co.. HP Part No. 5955-7680. $45.00. Order from H.P. Direct at 1-800-538-8787. This manual is somewhat dated and contains instructions for installing thick cable transceivers that are obsolete, for instance. On the other hand, the network configuration information is useful and the guidelines for routing cables and grounding issues are informative. My major disagreement with H.P.'s grounding instructions is that they allow metallic cable between building frames if H.P.'s surge arrestors are installed. Given the ease of using fiber optic repeaters, and the dangers inherent in metallic network cables that travel between building frames, there seems little excuse for not using fiber in these situations. In any event, the manual really shines when it comes to complete descriptions of thick cable and thin cable wire strippers and connector crimpers. The H.P. manual has diagrams showing how to strip each kind of cable and how to crimp on N connectors and BNC connectors. There's a short section on verifying the cables you've built, and a longer section on how to use a Time Domain Reflectometer to test networks. Another useful section is the one on how to open up a crimp tool that has been closed on something you didn't want to crimp (like your finger!). Don't laugh - this section came in handy the other day when a student used a crimp tool with a 75 ohm UHF crimp die in it to crimp a 50 ohm N connector. The instructions in the H.P. manual allowed us to get the mauled N connector out without dismantling the whole tool and ruining the precision adjustments. -- Access -- Aside from various phone numbers listed above, the following book stores can be of service: Computer Literacy Bookshop, 2590 North First St., San Jose, CA 95131. Phone 408-435-1118 for mail orders. A good source for computer and electronics books of all kinds. They carry the IEEE network standards, and can probably supply most of the books listed above. Jim Joyce's UNIX Bookstore, 47 Potomac St., San Francisco, CA 94117. Phone 415-626-7581 for mail orders. A handy resource for UNIX-related books of all kinds, including the Douglas Comer books. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988060310530900> Mail-From: MKL created at 3-Jun-88 12:17:59 Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Fri, 3 Jun 88 12:02:00 PDT Date: Fri 3 Jun 88 14:53:09-EDT From: Dan Lynch Subject: Re: Linking LAN's via Public X.25 To: symchych@skl-crc.arpa cc: thumper!karn@faline.bellcore.com, tcp-ip@sri-nic.arpa, lynch@A.ISI.EDU In-Reply-To: <8806022259.AA25446@skl-crc.arpa> Message-ID: <12403549643.58.LYNCH@A.ISI.EDU> ReSent-Date: Fri, 3 Jun 88 12:17:35 PDT ReSent-From: Mark Lottor ReSent-To: tcp-ip-rebroadcast@SRI-NIC.ARPA ReSent-Message-ID: <12403554092.37.MKL@SRI-NIC.ARPA> Tim, Thanks for the explanation of how X.25 works in Canada. Different "administrations" charge differently for the "same services" for their local reasons. That's just the way the world works. Doesn't seem to be a way to optomize an architecture to account for all possible larcenies or charities. But, I was amazed to see you describe the low throughput on some of your slow links (anything under T1 is "slow" in my book). How can there be implementation sout there that cannot keep a 9600 baud link running full tilt??? Reason I ask is that your wording left me feeling that the host implementations were somehow anemic. I would hop that they just had poor data link drivers that can be fixed rapidly. Or are they mainly suffering from the lack of Van Jacobson's fixes? Dan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806031317.AA07162@msc2.TN.CORNELL.EDU] <1988060313172300> From: doug@MSC2.TN.CORNELL.EDU.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: TCP/IP for PDP-11 running TSX (RT11) Message-ID: <8806031317.AA07162@msc2.TN.CORNELL.EDU> Date: 3 Jun 88 13:17:23 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 18 Posted: Fri Jun 3 09:17:23 1988 Process Software in in Mass. has FTP for RT and TSX, TELNET for RT, and I believe they are working on TELNET for TSX. Their product is NOT a general TCP/IP implementation, but a series of applications. The FTP is a very basic vanilla FTP, but the TSX version uses DEC command-line syntax instead of interactive Unix-style syntax. The result of this is that they open and close the connection for EACH file that gets transferred. Also missing is wildcarding (MPUT/MGET), CWD, and DIR functionality. I have written to them requesting that they add the above. It is, however, a basic implementation that works. They can be reached at: Process Software 35 Montague Road PO Box 746 Amherst, MA 01004 (413) 549-6994 - Doug Neuhauser, Materials Science Center, Cornell University (doug@msc2.tn.cornell.edu) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806031332.AA07398@work1.icase] <1988060313320400> From: doug@ICASE.ARPA.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Sun File server Message-ID: <8806031332.AA07398@work1.icase> Date: 3 Jun 88 13:32:04 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 28 Posted: Fri Jun 3 09:32:04 1988 My apologies if this is posted to the wrong discussion group. We have just upgraded our server from a 3/180 to a 3/280, and have seen a DECREASE in performance. We run Sun OS 3.5. The number of diskless clients in both cases is the same. The e-net collision rate is much higher with the new server, which may account for some of the decrease. But I just received my copy of the May Sun STB, which has an article describing how the cache works on a Sun 3/200 series machine. On page 826, there is a statement to the effect that if the cache hit rate is effectively zero, then performance of a 3/280 system will be less than a 3/280. As a server, handling lots of random client requests, I would think that the cache hit rate would be very low. Has anyone observed similar phenomenon? I will summarize to the net. Doug Peterson Systems Manager ICASE Mail Stop 132C NASA Langley Research Center Hampton, VA 23665-5225 (804) 865-4090 ----- End Forwarded Message ----- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806040206.AA21662@ucbvax.Berkeley.EDU] <1988060314404900> From: jon@CS.UCL.AC.UK (Jon Crowcroft) Newsgroups: comp.protocols.tcp-ip Subject: Re: Linking LAN's via Public X.25 Message-ID: <8806040206.AA21662@ucbvax.Berkeley.EDU> Date: 3 Jun 88 14:40:49 GMT Article-I.D.: ucbvax.8806040206.AA21662 References: <8806022259.AA25446@skl-crc.arpa> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 27 >Perhaps another view of IP over X.25 might help. While the original >question was asked about Sun X.25, there are a number of networks within the >ARPA/Internet that use IP over X.25. another e.g. of IP over X.25 is the UK Academic link to the US, which has run over IPSS for some years, as leased lines were rather expensive for the amount of traffic we used to have, and since the SATNET was mainly reserved for research use. A lot of interesting work was done on accounting and access control so that we could forward bills for the IPSS usage to the UK source of any IP packets on a sensible basis. Useful reading... %A R. H. Cole %T User Experience and Evaluation of International X.25 Services %J Proc. Telecoms Today Conf. %I Online %C London %D March 1984 %P 107-118 %K X.25 performance jon ----MESSAGE-END---- ----MESSAGE-BEGIN---- [880603154946.2060094f@elde.epfl.ch] <1988060314494600> From: virchaux@CLSEPF51.BITNET (J.Virchaux EPFL-SIG) Newsgroups: comp.protocols.tcp-ip Subject: Query : TCP/IP on TSX+ Message-ID: <880603154946.2060094f@elde.epfl.ch> Date: 3 Jun 88 14:49:46 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 11 I'm looking for an implementation of TCP/IP on TSX+. We should like to FTP files from a PDP running TSX+ operating system to a VAX through an Ethernet link. Is such software (and hardware if not DEQNA) available ? Please, do not answer to the list as I'm not a member. Reply to : VIRCHAUX@CLSEPF51.BITNET Virchaux@Eldp.Epfl.CH (Arpa, Cs.Net, X.400) PSI%022846911008::ELDP::VIRCHAUX (PSI-Mail) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988060317204900> Mail-From: MKL created at 3-Jun-88 12:15:10 Received: from Cs.Ucl.AC.UK by SRI-NIC.ARPA with TCP; Fri, 3 Jun 88 07:53:20 PDT To: tcp-ip@sri-nic.arpa Subject: Re: Linking LAN's via Public X.25 In-reply-to: Your message of Thu, 02 Jun 88 18:59:43 -0400. <8806022259.AA25446@skl-crc.arpa> Date: Fri, 03 Jun 88 15:40:49 +0100 From: Jon Crowcroft ReSent-Date: Fri, 3 Jun 88 12:14:50 PDT ReSent-From: Mark Lottor ReSent-To: tcp-ip-rebroadcast@SRI-NIC.ARPA ReSent-Message-ID: <12403553592.37.MKL@SRI-NIC.ARPA> >Perhaps another view of IP over X.25 might help. While the original >question was asked about Sun X.25, there are a number of networks within the >ARPA/Internet that use IP over X.25. another e.g. of IP over X.25 is the UK Academic link to the US, which has run over IPSS for some years, as leased lines were rather expensive for the amount of traffic we used to have, and since the SATNET was mainly reserved for research use. A lot of interesting work was done on accounting and access control so that we could forward bills for the IPSS usage to the UK source of any IP packets on a sensible basis. Useful reading... %A R. H. Cole %T User Experience and Evaluation of International X.25 Services %J Proc. Telecoms Today Conf. %I Online %C London %D March 1984 %P 107-118 %K X.25 performance jon ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806040534.AA24486@ucbvax.Berkeley.EDU] <1988060318310000> From: spurgeon@JESSICA.STANFORD.EDU (Charles Spurgeon) Newsgroups: comp.protocols.tcp-ip Subject: Network books, TCP/IP and Ethernet Message-ID: <8806040534.AA24486@ucbvax.Berkeley.EDU> Date: 3 Jun 88 18:31:00 GMT Article-I.D.: ucbvax.8806040534.AA24486 Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 267 The following is an annotated list of books that I've found useful while designing, building, and operating networks at Stanford University over the last several years. The list reflects the experience of building networks primarily based on TCP/IP protocols and Ethernet technology. This message is long. I just set out to list some useful books with complete access information, and it got longer and longer... -Charles Spurgeon (spurgeon@jessica.stanford.edu) Networking and Communications Systems, Stanford University. June 3, 1988 -- Introductory -- 1. "Local Area Networks", by John E. McNamara, 1985, 165pps with index and glossary. $29.00 Published by Digital Press, ISBN 0-932376-79-7. Digital Press part number for ordering is EY-00051-DP. Digital Press phone is 1-800-343-8321. This is a good general introduction to the concepts and technologies of LANs. As stated in the preface: " This book is intended for students, computer system managers, telecommunications managers, and others who want to become more familiar with local area networks. Since product offerings in this area are constantly changing, a deliberate attempt has been made to emphasize the general principles, operating characteristics, and problem areas of local area network hardware, rather than cite specific product examples." Of special note is the chapter on "Administrative considerations for large networks" which is largely taken from David Clark's 1983 "M.I.T. Campus Network Implementation Planning Document". This chapter mentions many of the problems of supporting large campus area networks with special reference to the issue of multiple protocol support on campus backbone networks. -- Two books by Douglas Comer -- Douglas Comer has written two books of special interest to the networker. His books are comprehensive and he has an excellent writing style, making these the best books I've seen on the TCP/IP protocols. 2. "Internetworking With TCP/IP, Principles, Protocols, and Architecture". By Douglas E. Comer. 1988, 382pps with index and glossary. Prentice-Hall, Inc., New Jersey, ISBN 0-13-470154-2. $36.00. (Stanford Bookstore price.) As stated in the preface: "For professionals, the book provides a comprehensive introduction to TCP/IP technology and the architecture of the Internet. Although it is not intended to replace protocol standards, the book is a good starting point for learning about internetworking because it gives a uniform overview that emphasizes principles. Moreover, it gives the reader perspective that can be extremely difficult to obtain from individual protocol documents." "The book is organized into four main parts. Chapters 1 and 2 form an introduction that provides an overview and discusses existing technologies. In particular, Chapter 2 reviews physical network hardware. The intention is to provide basic intuition about what is possible, not to spend inordinate time on hardware details. Chapters 3-12 describe the TCP/IP Internet from the viewpoint of a single host, showing the basic services available and the protocols a host uses to access them. They cover the basics of Internet addressing and routing as well as the notion of protocol layering. Chapters 13-16 describe the architecture of the Internet when viewed globally. They explore the core gateway system and the protocols gateways use to exchange routing information. Finally, Chapters 17-19 discuss application level services available in the Internet. They present the client-server model of interaction and give several examples of how one can organize client and server software. The last section discusses electronic mail and the domain name system, two topics that are extremely popular." I particularly like the real-world orientation of this book. For instance, there is an appendix on "4.3 BSD UNIX Interface to Internet Protocols" that describes Berkeley sockets and presents example client and server programs for a network whois service. There's another appendix on "Hints And Suggestions For Implementors" full of useful tips for network programmers. And there's a nice appendix called "A Guide To RFCs" which explains the Requests For Comments completely and with due regard for the early folklore and development of the ARPAnet. A guide to the first one thousand RFCs, extracted from RFC1000, is presented as well as electronic and snail mail addresses for getting your own copies of the RFCs. 3. "Operating System Design - Volume II, Internetworking with Xinu". By Douglas Comer. 1987, 5667pps with index. Published by Prentice-Hall, Inc., New Jersey, ISBN 0-13-637414-X. $39.33. (Stanford Bookstore price.) As stated in the preface: "Chapters 1-11 comprise a self-contained unit that covers the basics of internet communication. Each of the eleven chapters explores one component of internet protocol software, motivating and explaining how that component fits into the overall system design. The unit starts with a detailed examination of one network technology, the Ethernet, and moves on to consider the internet concept, address resolution, internet datagrams, routing, control messages, user datagrams, and datagram demultiplexing. Later chapters build on the basic communication system, examining client-server interaction, and remote file access, as well as a user interface and commands that manipulate both local and remote files." "Written as a continuation of 'Operating System Design - The XINU Approach' (Comer [1984]), this text starts where the earlier one ends. The two volumes were written to support a two-semester course in systems design that encompasses operating systems and networks... ." This book is based on the XINU operating system software which is available from Purdue University as described in the book. XINU was written to give students the experience of studying a UNIX-like operating system whose source code was available for modification. Lots of software examples in every chapter make this an especially useful text for aspiring network programmers. It's also good resource for those just curious as to what network software looks like and how it fits together. -- Three books by William Stallings -- William Stallings has published a series of three books that can be helpful in hacking one's way through the jargon laden jungles of network standards - especially the OSI and IEEE standards. 4. "Volume 1. Handbook of Computer Communications Standards, The Open Systems Interconnection (OSI) Model and OSI-Related Standards". By William Stallings. 1987, 322pps with index. Macmillan Publishing Co., NY, ISBN 0-02-948071-X. $34.95. The first volume sets the stage by explaining the OSI standards effort and the organization of the OSI standards process. The OSI reference model is then presented, and each layer is discussed in depth with lots of detail. OSI is a moving target, and some of the material here is no doubt already dated, but it's still a good explanation of the whole OSI world. 5. "Volume 2. Handbook of Computer Communications Standards, Local Network Standards". By William Stallings. 1987, 244pps with index. Macmillan Publishing Co,, NY, ISBN 0-02-948070-1. $34.95. This book covers the IEEE 802 series of standards and the emerging FDDI standard. The material described here makes it possible to decipher the 802.3 standard. After a brief introduction covering network topologies and media, Stallings explains the standardization efforts, including the structure of the standards committees and how the various standards agencies interact. Next the IEEE 802 standards structure is described, with the various subsets explained. Chapter 4 describes the 802.3 standard including variants such as 10BASE2. Also included is a brief description of the major differences between 802.3 and DIX Ethernet. An appendix provides a short introduction to the OSI reference model, so that you don't need volume 1 to figure out volume 2. 6. "Volume 3. Handbook of Computer Communications Standards, Department of Defense (DOD) Protocol Standards". By William Stallings, Paul Mockapetris, Sue McLeod and Tony Michel, 1988, 206pps with index. Macmillan Publishing Co., NY, ISBN 0-02-948072-8. $34.95. This volume is a guide to the TCP/IP protocol suite. As stated in the preface: "...Volume 3, covers the five military standard protocols that have been issued by the DOD. The book begins by introducing the four layer communications architecture that is the framework within which these standards fit. Following the introduction of this architecture, a chapter is devoted to each of the standards." "In contrast with the other books in this series, several of the chapters of this book were written by contributors. Each contributor is intimately familiar with the topic under discussion: biographies of the main author and the contributing authors are found at the end of the book." The chapters on IP and TCP appear to have been written by Stallings. The chapter on FTP is by Tony Michel, the SMTP chapter by Paul Mockapetris and the Telnet chapter by Sue McLeod. The chapters are good descriptions of the various protocols. On the other hand, I prefer Douglas Comer's book, for reasons given above. -- Ethernet Standards -- The next several items deal with the various Ethernet standards in use today. 7. "Ethernet Local Area Network Specification Version 2.0. November, 1982". 103pps, $32.00. DEC Part Number: AA-K759B-TK. Available from DEC-Direct by calling 1-800-344-4825. This is version 2 of the original ten megabit Ethernet specification. The newer 802.3 standard supersedes the DEC-Intel-Xerox (DIX) spec listed here, but most TCP/IP implementations are still based on this DIX specification. Since this specification is not based on the OSI model it is relatively jargon free and reads like something close to English, making it a much more approachable document than the IEEE standards. 8. "Carrier Sense Multiple Access with Collision Detection, ANSI/IEEE Std 802.3, 1985, ISO/DIS 8802/3". ISBN 0-471-82749-5. Available from, IEEE Service Center, 445 Hoes Lane, Piscataway, New Jersey 08854, or by calling 1-201-981-0060, or from technical bookstores (see below). The new Ethernet specifications. Much has changed. Much stayed the same. Vendors like to gloss over the differences (it's a lot easier than trying to describe them!) and you're on your own trying to figure out how it all works. This standard was written to comply with the OSI model. As a result, it contains much more jargon and can be much less understandable at first. An explanatory guide like Stalling's volume 2 is a requirement to help the newcomer to OSI make any sense of it all. 9. "Supplements to Carrier Sense Multiple Access with Collision Detection, ANSI/IEEE Std 802.3a,b,c,and e-1988". ISBN 0-471-61153-0 Same access as above. A set of additions to the 1985 802.3 standard, including the thin Ethernet standard (Type 10BASE2). Also included is the broadband standard (Type 10BROAD36) and a revision of section 9 of the 1985 standard on repeaters. -- Ethernet hardware information -- None of the Ethernet standards docs are very useful when it comes to actually building, testing, and operating an Ethernet. For that you need information about what topologies are allowed, how Ethernet equipment is configured, how to attach connectors and all the rest. While there isn't a good general book available on Ethernet design and construction, the following manual can help. 10. "LAN Cable and Accessories Installation Manual", January 1986, published by Hewlett-Packard Co.. HP Part No. 5955-7680. $45.00. Order from H.P. Direct at 1-800-538-8787. This manual is somewhat dated and contains instructions for installing thick cable transceivers that are obsolete, for instance. On the other hand, the network configuration information is useful and the guidelines for routing cables and grounding issues are informative. My major disagreement with H.P.'s grounding instructions is that they allow metallic cable between building frames if H.P.'s surge arrestors are installed. Given the ease of using fiber optic repeaters, and the dangers inherent in metallic network cables that travel between building frames, there seems little excuse for not using fiber in these situations. In any event, the manual really shines when it comes to complete descriptions of thick cable and thin cable wire strippers and connector crimpers. The H.P. manual has diagrams showing how to strip each kind of cable and how to crimp on N connectors and BNC connectors. There's a short section on verifying the cables you've built, and a longer section on how to use a Time Domain Reflectometer to test networks. Another useful section is the one on how to open up a crimp tool that has been closed on something you didn't want to crimp (like your finger!). Don't laugh - this section came in handy the other day when a student used a crimp tool with a 75 ohm UHF crimp die in it to crimp a 50 ohm N connector. The instructions in the H.P. manual allowed us to get the mauled N connector out without dismantling the whole tool and ruining the precision adjustments. -- Access -- Aside from various phone numbers listed above, the following book stores can be of service: Computer Literacy Bookshop, 2590 North First St., San Jose, CA 95131. Phone 408-435-1118 for mail orders. A good source for computer and electronics books of all kinds. They carry the IEEE network standards, and can probably supply most of the books listed above. Jim Joyce's UNIX Bookstore, 47 Potomac St., San Francisco, CA 94117. Phone 415-626-7581 for mail orders. A handy resource for UNIX-related books of all kinds, including the Douglas Comer books. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988060319300000> Received: from GRAD.CIS.TEMPLE.EDU by SRI-NIC.ARPA with TCP; Fri, 3 Jun 88 21:32:14 PDT Date: Sat, 4 Jun 88 00:30 EST From: PMDF Mail Server Subject: Undeliverable mail To: TCP-IP@SRI-NIC.ARPA Your message could not be delivered to: STAFFORD Your message has been enqueued and undeliverable for 6 days. The mail system will continue to try to deliver your message for an additional 6 days. The beginning of your message follows: ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806031954.AA28270@skl-crc.arpa] <1988060319545900> From: symchych@SKL-CRC.ARPA (Tim Symchych) Newsgroups: comp.protocols.tcp-ip Subject: Re: Linking LAN's via Public X.25 Message-ID: <8806031954.AA28270@skl-crc.arpa> Date: 3 Jun 88 19:54:59 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 21 Dan: Yes, there are still versions of IP around in hosts that do not perform well. Regardless of some of the fine work that has been done in end-to-end performance, we still use what comes off the shelf, and if the vendors don't put it out in the product, then we don't have it. Most of our sites have no interest in "patch and run" systems for their users. Many people on this mailing list have covered this problem, including the problems of mixing speeds on segments of the path that traverse ethernet, leased lines and non-IP packet switched nets. Except for ethernet LANS, all our links between hosts use combinations of different link types. I guess that in our case, X.25 is the least of our problems. Something I forgot to mention is that in our PDN connections at 9600, we use 256 byte packets with a window size of up to 7 packets. I also received some hints on the 56 kbps X.25 line to our Butterfly from Dave Capshaw at Lockheed. Seems that some tuning may be possible between the PSN and the Butterfly. regards tim ----MESSAGE-END---- ----MESSAGE-BEGIN---- [728@naucse.UUCP] <1988060323330800> From: jdc@naucse.UUCP (John Campbell) Newsgroups: comp.misc,comp.protocols.tcp-ip,comp.os.vms Subject: cmu tcp-ip Message-ID: <728@naucse.UUCP> Date: 3 Jun 88 23:33:08 GMT Article-I.D.: naucse.728 Organization: Northern Arizona University, Flagstaff, AZ Lines: 18 I know that CMU's TCP/IP has been out for a while. I would like to hear from anyone who has used this implementation. In particular, I am interested in sites that have used TCP/IP terminal servers with CMU TCP/IP on VMS. I would like to say that this is a cost-effective way to get out of LAT and away from DECServers. Any comments? Please mail directly to me. Some of these groups I don't follow. I will summarize responses if there is any interest. Also--if you know other VMS TCP/IP vendors and cost/quality information send it along as well. I'll include anything I get that pretains to the above in my summary. Thanks. -- John Campbell ...!arizona!naucse!jdc unix? Sure send me a dozen, all different colors. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988060402014200> Received: from parmesan.cs.wisc.edu by SRI-NIC.ARPA with TCP; Sat, 4 Jun 88 05:02:01 PDT Date: Sat, 4 Jun 88 07:01:42 CDT From: lhl@cs.wisc.edu (L.H. Landweber) Message-Id: <8806041201.AA10337@parmesan.cs.wisc.edu> Received: by parmesan.cs.wisc.edu; Sat, 4 Jun 88 07:01:42 CDT To: tcp-ip@sri-nic.arpa Subject: SIGCOMM '88 Program All, Enclosed is the advance program and registration form for the 1988 ACM SIGCOMM symposium. SIGCOMM is THE ACM symposium on computer communications. This year we have a very strong technical program, consisting of three days of conference papers, plus one tutorial day. For more information about hotels and on-campus accommodations, please contact Stanford University directly (415/723-3126). Please note that VERY limited on-campus accommodations are available. To expedite the registration process, you can send print outs of the attached forms with payment. Sincerely, JJ Garcia-Luna General Chair, SIGCOMM 88 ----------------------------------------------------------------------- ACM SIGCOMM 88 SYMPOSIUM ADVANCE PROGRAM Communications Architectures and Protocols August 16-19, 1988 Stanford University, Stanford, California SYMPOSIUM August 17-19, 1988 August 17, 1988 9:00 - 10:00 Session 1: Keynote Session General Chair: J.J. Garcia-Luna-Aceves, SRI International, USA Program Chair: L. Landweber, University of Wisconsin, USA Student Paper Award: J.J. Garcia-Luna-Aceves, SRI International, USA Keynote Address: Donald Nielson, SRI International, USA 10:30 - 12:00 Session 2: Local/Metropolitan Area Internets Chair: D. Anderson, Unviversity of California, Berkeley, USA Topological Analysis of Local-Area Internetworks (G. Trewitt, Stanford University) --- Student Paper Dynamic Resource Allocation in a Metropolitan Area Network (K. Maly, C. Overstreet, Old Dominion Univ.; X. Qui, China State Shipbuilding Corporation, Peoples Republic of China; and D. Tang, Chengdu University of Science & Technology, Peoples Republic of China) Optical Interconnection Using ShuffleNet Multihop Networks in Multi-Connected Ring Topologies (M.J. Karol, AT&T Bell Laboratories, USA) 1:15 - 2:45 Session 3: Routing Chair: L. Chapin, Data General Corporation, USA Landmark Routing: Distributed Name-Based Routing for Very Large Networks (P.F. Tsuchiya, Mitre, USA) Pitfalls of a Certain Class of Distributed Routing Algorithms (R. Perlman and G. Varghese, DEC, USA) Multicast Routing in Internetworks and Extended LANs (S.E. Deering, Stanford University, USA) --- Student Paper 3:15 - 5:15 Session 4: Transport Level and Operating System Issues Chair: S. Lam, University of Texas at Austin, USA Design of an x-Kernel (N. Hutchinson and L. Peterson, Univ. of Arizona, USA) Exploiting Recursion to Simplify RPC Communication Architectures (D.R. Cheriton, Stanford University, USA) Service Specification and Protocol Construction for the Transport Layer (S.L. Murphy and A.U. Shankar, Univ. of Maryland at College Park, USA) A Network Management Language for OSI Networks (U. Warrier, A. Relan, Unisys Corporation, USA; O. Berry, IBM Science and Technology, Israel; and J. Bannister, The Aerospace Corporation, USA) 7:00 pm - on Banquet August 18, 1988 8:30 - 10:00 Session 5: Lessons of the Internet Chair: J. Mogul, Digital Equipment Corporation, USA Some thoughts on the DARPA Internet Architecture (David Clark, MIT, USA) The Fuzzball (D.L. Mills, University of Delaware, USA) Development of the Domain Name System (Paul Mockapetris, USC Information Sciences Institute, USA) 10:30 - 12:00 Session 6: Local Area Network Architecture Chair: R. Cheung, Hewlett-Packard, USA Optimizing Bulk Data Transfer Performance: The Packet Train Model (C. Song and L.H. Landweber, University of Wisconsin, USA) --- Student paper A Mesh/Token Ring Hybrid-Architecture LAN (C. Kang, The American University, USA; and J. Herzog, Oregon State University, USA) Tree LANs with Collision Avoidance: Protocol, Switch Architecture, and Simulated Performance (T. Suda, S. Morris, and T. Nguyen, University of California, Irvine, USA) 1:15 - 2:45 Session 7: Very High Speed Networking Chair: D. Farber, University of Pennsylvania, USA An Analysis of Memnet - An Experiment in High Speed Memory Mapped Local Networking (G. Delp, A. Sethi, University of Delaware, USA; and D. Farber, University of Pennsylvania, USA) --- Student paper The VMP Network Adapter Board (NAB): High-Performance Network Communication for Multiprocessors (H. Kanakia and D. Cheriton, Stanford University, USA) --- Student paper Fast Circuit Switching in Fiber Optic Networks (I. Chlamtac, A. Ganz, and G. Karmi, University of Massachusetts, USA) 3:15 - 5:15 Session 8. Measurement and Management Chair: V. Cerf, Corporation for National Research Initiatives, USA A Pseudo-Machine for Packet Monitoring and Statistics (R.T. Braden, USC Information Sciences Institute, USA) Knowledge-Based Monitoring and Control: An Approach to Understanding the Behavior of TCP/IP Network Protocols (B.L. Hitson, Stanford University, USA) --- Student paper Measured Capacity of an Ethernet (D.R. Boggs, J.C. Mogul, and C.A. Kent, DEC, USA) Distributed Testing and Measurement across the Atlantic Packet Satellite Network (SATNET) (K. Seo, BBN, USA; J. Crowcroft, UCL, England; P. Spilling, Norwegian Telecommunications Administration, Norway; J. Laws, Royal Signals and Radar Establishment, Englanand; and C. Topolcic, BBN, USA) 5:30 - 7:00 Reception August 19, 1988 8:30 - 10:00 Session 9: Communication Protocol Design and Testing Chair: D. Mills, University of Delaware, USA A Multicast Transport Protocol (J. Crowcroft and K. Paliwoda, University College London, England) Experience with Test Generation for Real Protocols (D. Sidhu and T. Leung, Iowa State University, USA) Performance Models for Noahnet (G.M. Parulkar, A.S. Sethi, D.J. Farber, University of Pennsylvania, USA) 10:30 - 12:00 Session 10: Broadcast Issues Chair: D. Sidhu, Iowa State University, USA A High Performance Broadcast File Transfer Protocol (J.S.J. Daka, A.G. Waters, University of Essex, England) Specification and Verification of Collision-Free Broadcast Networks (P. Jain and S.S. Lam, University of Texas, Austin, USA)-- Student Paper Delivery and Discrimination: The Seine Protocol (M. Gouda, University of Texas at Austin, USA; N. Maxemchuk, U. Mukherji, and K. Sabnani, AT&T Bell Laboratories, USA) 1:15 - 2:45 Session 11: Congestion and Topology Control Chair: J.J. Garcia-Luna-Aceves, SRI International An Explicit Binary Feedback Scheme for Congestion Avoidance in Computer Networks with a Connectionless Network Layer (K.K. Ramakrishnan and R. Jain, DEC, USA) Congestion Avoidance and Control (Van Jacobson, Lawrence Berkeley Laboratory, USA) A Protocol to Maintain a Minimum Spanning Tree in a Dynamic Topology (C. Cheng, I. Cimet, P. Kumar, Northwestern Univ., USA) 3:00 - 5:00 Session 12: Panel on Internet Engineering Chair: P. Gross, Mitre, USA Panelsists to be announced -------------------------------------------------------------------------- TUTORIALS August 16, 1988 9:00 am - 5:00 pm 1. INTEGRATED SERVICES DATA NETWORKS: NARROWBAND AND BROADBAND (Mario Gerla, UCLA) Abstract ISDN is one of the newest " buzzwords " in the communications arena. The concept is extremely appealing: by integrating various services ( voice, data, video etc.) in a common network we will be able to achieve lower operating costs, higher efficiency, better availability/maintainability and higher flexibility in the introduction of new services.This concept is now becoming a reality, and both users and service providers are taking into account the potential of ISDN's in formulating their plans. This seminar will review the evolution of the ISDN concept during the past few years,will discuss the standard recommendations, will compare implemen- tation alernatives and finally will report on recent field trials. In organizing this seminar , the attempt was to maintain a good balance between design principles, standard recommendations and actual network implementations. Outline - Why integrated services - Narrowband and Broadband ISDN's - Standard recommendations - ISDN backbone implementation alternatives ( Packet/Circuit/Hybrid switching) - ISDN routing and flow control - Service integration in MAN's and LAN's - Field trials - Future trends Biography Professor Mario Gerla received the PhD degree in engineering from the University of California, Los Angeles (UCLA), in 1973. From 1973 to 1976, he was Network Planning Manager at Network Analysis Corporation. >From 1976 to 1977, he was with Tran Telecommunications, Los Angeles, where he participated in the development of integrated packet and circuit networks. In 1977, he joined UCLA and is now a Professor in the Department of Computer Science. His research interests include the design and control of distributed computer communications systems and networks, and the development of high-speed local area networks. 2. MULTI-HOP TOPOLOGIES, BRIDGES AND ROUTERS (Radia Perlman, DEC) Abstract A Local Area Network (LAN) allows direct communication between any stations directly connected to the LAN. Route computation and forwarding nodes are not necessary. However, technology and performance constrains the topology, distance, and number of stations of a single LAN. Thus a network usually needs to grow beyond the limits of a single LAN. One method of interconnecting LANs is through "Bridges". Two different schemes for interconnecting LANs are being standardized by two different subcommittees of the IEEE 802 committee, which is standardizing LANs. These two schemes are "spanning tree/transparent" bridges, and "source routing" bridges. Another method of creating a network with multiple links is through "routers". These too are being standardized by various committees. "Routers" perform the "Network Layer Protocol" as defined by the ISO reference model. This tutorial will briefly review the ISO reference model. It will explain the two bridge schemes, and contrast their functionality and performance. It will explain the functionality of the Network Layer, and explain design alternatives for meeting this functionality. The emphasis will be placed on the design of a "connectionless" style of Network Layer. No background other than intellectual curiosity is required. Emphasis is on protocol concepts rather than specifics of the schemes, or mathematical analysis. Outline o ISO Reference Model Review (20 minutes) o LAN review -- CSMA/CD, token ring, token bus (15 minutes) o Bridges -- Spanning Tree, Source Routing, Comparisons (1 1/2 hours) o Network Layer functionality -- connection oriented vs connectionless, routing, fragmentation and reassembly, autoconfigurability, addressing (45 minutes) o Routing Algorithms -- "Distance Vector" vs "Link State" (2 hours) o Depending on time and interest, remaining time can be spent exploring the design implications of: - interoperability of spanning tree and source routing bridges - Network Layer autoconfigurability - Design implications of hierarchical networks; subnetwork partition problem, subnetwork autonomy Biography Radia Perlman is a consulting engineer at Digital Equipment Corporation. She designed the spanning tree algorithm used by Digital's bridges and adopted for use by both bridge standards (transparent bridges and source routing bridges). She also was responsible for the design and specification of the Network Layer in Digital's Network Architecture, aspects of which have been adopted by ISO for use in the standard connectionless Network Layer. She has taught as adjunct faculty at the graduate schools of Wang Institute and University of Lowell, and at the Wang Summer Institute. She received the B.S. and M.S. degrees in mathematics at MIT, and is currently pursuing a Ph.D. degree in Computer Science at MIT. ----------------------------------------------------------------------- TUTORIAL AND SYMPOSIUM REGISTRATION Please check applicable fees: ADVANCE REGULAR (before 7/25/88) TUTORIAL 1: ____ ACM members $200 $250 ____ Non-members 250 300 ____ Full-time students** 100 150 TUTORIAL 2: ____ ACM members $200 $250 ____ Non-members 250 300 ____ Full-time students** 100 150 SYMPOSIUM*: ____ ACM members $200 $250 ____ Non-members 250 300 ____ Full-time students** 100 150 * Reception and banquet fees will be included in the recidence hall registration package. ** Student registration must be accompanied by a copy of valid full-time student ID. Must be ACM member. TOTAL PAYMENT MUST BE INCLUDED IN US$. $____________. Advance registration payment must be received by July 25, 1988. After that date, please wait to register at the Symposium itself. Make checks payable in US$ to ACM SIGCOMM. There will be a $10.00 Surcharge on foreign banks. Please return tutorial and symposium registration form and complete payment to: Dr. J.J. Garcia-Luna-Aceves, SRI International, 333 Ravenswood Ave., Menlo Park, CA 94025, USA; tel: (415) 859-5647; e-mail: garcia@sri.com. ---------------------------------------------------------------------------- APPLICATION FOR RESIDENCE HALLS Room and meal payments are due upon arrival. DO NOT PAY IN ADVANCE. All payments must be in $US dollars, and made in cash, traveler's checks, or personal checks from a U.S. Bank made payable to Stanford University. A VERY LIMITED number of rooms in Stanford University are available on a first-come, first-served basis. Complete this form and return it, no later than July 25, 1988, to Dr. J.J. Garcia-Luna-Aceves, SRI International, Menlo Park, CA 94035; Tel: (415) 859-5647; e-mail: garcia@sri.com. RATES: PLAN I - Room for 4 nights (Mon., Tue., Wed., and Thurs.) and 10 meals from Tue. breakfast thru Fri. lunch (omitting Wed. Dinner). Single room - $102.00, shared room - $76.00 meals 95.00 meals - $95.50 ------- ------- $197.50 $171.50 per person PLAN II - Room for 3 nights (Tues., Wed., Thurs.) and 7 meals (breakfast and lunch on Wed., Thurs., Fri., and dinner on Thursday. Single room - $76.50, shared room - $57.00 meals 65.00 meals - $65.50 ------- ------- $141.50 $122.50 per person EXTRA NIGHT'S STAY: single room - $25.50, shared room - $19.00 per person. CHILDREN: 10 yrs. old and under are charged half rate for housing and meal package. RESIDENCE HALL REQUIREMENTS: Name: ____________________________________________________________ Last First Middle Address: _________________________________________________________ _________________________________________________________ _________________________________________________________ ____ Plan I, ____ Plan II ____ Single, ____ Double ____ Female, ____ Male ____ Smoking, ____ Nonsmoking Preferred rommate: ________________________________________________ Date and time of arrival: _________________________________________ Date and time of departure: _______________________________________ _________________________________________________________________________ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988060410120000> Received: from relay.MOD.UK by SRI-NIC.ARPA with TCP; Sat, 4 Jun 88 07:17:13 PDT Received: from rsre.mod.uk by relay.MOD.UK via PSS with NIFTP id aa01257; 4 Jun 88 13:42 WET From: John Laws (on UK.MOD.RSRE) To: tcp-ip <@relay.MOD.UK:tcp-ip@sri-nic.arpa> Cc: MMDF-Warning: Parse error in original version of preceding line at .relay.MOD.UK Date: Sat, 4 Jun 88 15:12 Subject: Re: Linking LAN's via Public X.25 Message-Id: <04 JUN 1988 15:12:54 LAWS@RSRE> >Perhaps another view of IP over X.25 might help. While the original >question was asked about Sun X.25, there are a number of networks within the >ARPA/Internet that use IP over X.25. Yet another view. The RSRE Internet Lab connects to two other European Internet sites (one in Holland and one in Germany) and others internal to the UK running IP over X.25. Quality of service is good and at current traffic levels is much cheaper than international/national leased circuits. The software has been developed to pay attention to the fact that real money is being spent e.g. virtual circuits close if IP traffic stops, and of course accounting and access control are well developed. If national X.25 provision by US carriers is seen as less than adequate, by US users, maybe its because they (the carriers) do not see it as a viable commercial market to make a big investment in given the existing 'free' networks like Arpanet, Milnet, NSFnet etc. YES I DO KNOW that they are not really free - that Government, Academic institutions and companies make payments. But in many cases the users at the keyboard are unaware and uncaring of the costs (judged by many of the remarks in this forum some months ago). John ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806041348.AA06264@flora.wustl.edu] <1988060413483500> From: guru@flora.wustl.EDU (Gurudatta Parulkar) Newsgroups: comp.protocols.tcp-ip Subject: A couple of questions Message-ID: <8806041348.AA06264@flora.wustl.edu> Date: 4 Jun 88 13:48:35 GMT Article-I.D.: flora.8806041348.AA06264 Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 18 Has anybody successfully installed Van Jacobson's tcp/ip on a binary only sun 3/50 ? Please let me know. I need some help. Are there any good references on operating large campus networks which talk about administrative as well as technical issues ? I have accumulated a lot of info from this and other bboards, but want to check if there are any comprehensive papers on the subject. Thanks in advance. -guru Dr. Guru Parulkar Asst Professor guru@flora.wustl.edu Dept of Computer Science parulkar@udel.edu Washington University wucs1!guru@uunet.uu.net St. Louis MO 63130 (314) 889-4621 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988060413483501> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Sat, 4 Jun 88 12:55:31 PDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA02936; Sat, 4 Jun 88 11:18:30 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: 4 Jun 88 13:48:35 GMT From: @hplabs.hp.com (Gurudatta Parulkar) Organization: The Internet Subject: A couple of questions Message-Id: <8806041348.AA06264@lora.wustl.edu> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa Has anybody successfully installed Van Jacobson's tcp/ip on a binary only sun 3/50 ? Please let me know. I need some help. Are there any good references on operating large campus networks which talk about administrative as well as technical issues ? I have accumulated a lot of info from this and other bboards, but want to check if there are any comprehensive papers on the subject. Thanks in advance. -guru Dr. Guru Parulkar Asst Professor guru@Dept of Computer Science parulkar@udel.edu Washington University wucs1!guru@uunet.uu.net St. Louis MO 63130 (314) 889-4621 #! rnews 1443e wind th: ucb ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12403803889.8.MRC@PANDA.PANDA.COM] <1988060418094600> From: MRC@PANDA.PANDA.COM.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: Linking LAN's via Public X.25 Message-ID: <12403803889.8.MRC@PANDA.PANDA.COM> Date: 4 Jun 88 18:09:46 GMT References: <12403549643.58.LYNCH@A.ISI.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 27 Dan - I'm responsible for one of the TCP/IP implementations used on a 9600 baud link in Canada. The system is a DEC-2065 running a TOPS-20 with a heavily modified TCP. It has two IP interfaces; a NIA20 to the local Ethernet and an AN20 to a C/30 PSN using 1822. This TCP lacks RFNM counting which is a serious deficiency, but in the case of this link it doesn't really matter all that much since (at least the last I read) there is only one place for the 1822-grams to go to. If you're RFNM blocked to the friendly not-so-local gateway, you can't do anything anyway. What makes the burden worse, this machine is the only path between the local Ethernet (which talks TCP/IP and DECnet) and the rest of the world. It has a rudimentary EGP-speaker that babbles updates to Friend Gateway. I've seen no indication of a bottleneck at the DEC-20. Instead, it seems to be more that the DEC-20 (and the Symbolics Lisp machines behind it on the Ethernet) are communicating almost exclusively with the Internet in the US, across two gateways over a long long wire. There isn't all that much traffic to begin with, so any latency in a connection can easily stop the line...because there is no other traffic! -- Mark -- ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [04.JUN.1988.15:12:54.LAWS@RSRE] <1988060422120000> From: LAWS@rsre.mod.UK (John Laws, on UK.MOD.RSRE) Newsgroups: comp.protocols.tcp-ip Subject: Re: Linking LAN's via Public X.25 Message-ID: <04.JUN.1988.15:12:54.LAWS@RSRE> Date: 4 Jun 88 22:12:00 GMT Article-I.D.: RSRE.04.JUN.1988.15:12:54.LAWS Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 26 >Perhaps another view of IP over X.25 might help. While the original >question was asked about Sun X.25, there are a number of networks within the >ARPA/Internet that use IP over X.25. Yet another view. The RSRE Internet Lab connects to two other European Internet sites (one in Holland and one in Germany) and others internal to the UK running IP over X.25. Quality of service is good and at current traffic levels is much cheaper than international/national leased circuits. The software has been developed to pay attention to the fact that real money is being spent e.g. virtual circuits close if IP traffic stops, and of course accounting and access control are well developed. If national X.25 provision by US carriers is seen as less than adequate, by US users, maybe its because they (the carriers) do not see it as a viable commercial market to make a big investment in given the existing 'free' networks like Arpanet, Milnet, NSFnet etc. YES I DO KNOW that they are not really free - that Government, Academic institutions and companies make payments. But in many cases the users at the keyboard are unaware and uncaring of the costs (judged by many of the remarks in this forum some months ago). John ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806050525.AA00175@orc.olivetti.com] <1988060505251900> From: roode@orc.olivetti.COM (David Roode) Newsgroups: comp.protocols.tcp-ip Subject: Re: Linking LAN's via Public X.25 Message-ID: <8806050525.AA00175@orc.olivetti.com> Date: 5 Jun 88 05:25:19 GMT References: <04.JUN.1988.15:12:54.LAWS@RSRE> Sender: daemon@ucbvax.BERKELEY.EDU Organization: Olivetti Research Center, Menlo Park, CA Lines: 44 There's no question that X.25 packet switching is a service built on top of point-to-point data circuit (leased line) capability. The tariffs in the U.S treat this as a 'value added' service and prohibit the basic operating companies from competing in the national market. The Public Data Networks offering packet services have to pay the same leased line rates as an end-user, both for backbone circuits and for ties between their switch locations and customer premises. At the same time, the charges for leased line service are obviously much cheaper in the U.S. than they are elsewhere. (It calls for a judgement, but it seems likely that much in excess of costs is recovered in the charges for leased line service in Europe.) As a result, it may be illogical to 'blame' the U.S. Public Data Nets for their charges. European PTT's may subsidize their X.25 offerings. U.S. PDN's see reduced usage volume due to reasonable competition from leased lines. The main service a PDN provides is the sharing of data circuits. So, in the U.S. a smaller fraction of uses see an economic incentive to share costs by making use of a PDN. (It takes a smaller volume of usage to cost justify switching to a leased line in the U.S.) The operating efficiency of the U.S. PDN's may be the same or even higher than the European PTT's in providing PDN service. It appears the hierarchy in terms of increasing cost for a 2400 baud data flow is something like: leased lines at U.S. typical rates Public Data nets at European rates Public Data nets at U.S. rates leased lines at European rates For 300 baud data flow, it is something like: Public Data nets at European rates Public Data nets at U.S. rates leased lines at U.S. typical rates leased lines at European rates For 9600 baud data flow, sequence might be: -or- leased lines/ U.S. rates leased lines/ U.S. rates Public Data nets/ U.S. rates Public Data nets/ U.S. rates Public Data nets/ Europe rates leased lines/Europe rates leased lines/Europe rates Public Data nets/ Europe rates ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988060506001000> Received: from NNSC.NSF.NET by SRI-NIC.ARPA with TCP; Sun, 5 Jun 88 11:51:17 PDT To: guru@flora.wustl.edu cc: tcp-ip@sri-nic.ARPA Subject: re: a couple of questions Date: Sun, 05 Jun 88 12:40:10 -0400 From: Craig Partridge Installing Van Jacobson's TCP on a SUN 3/50 is quite simple. There is a special Makefile.sun that makes it easy to generate *.o files you can stick in /sys/OBJ. It also works wonderfully -- my TCP connections have been noticeably happier. Installing the entire Berkeley distribution (with the IP fixes, etc) is quite difficult -- it requires porting the software to the SUN. Craig ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988060513385200> Received: from Sun.COM by SRI-NIC.ARPA with TCP; Mon, 6 Jun 88 18:35:54 PDT Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0) id AA15525; Mon, 6 Jun 88 18:31:04 PDT Received: from speed.sun.com (speed-ebb) by snail.sun.com (4.0/SMI-3.2) id AA24853; Sun, 5 Jun 88 20:34:34 PDT Received: from rose.sun.com by speed.sun.com (4.0/SMI-4.0) id AA28521; Sun, 5 Jun 88 20:38:52 PDT Date: Sun, 5 Jun 88 20:38:52 PDT From: nowicki@Sun.COM (Bill Nowicki) Message-Id: <8806060338.AA28521@speed.sun.com> To: guru@flora.wustl.EDU Subject: Re: A couple of questions Cc: tcp-ip@sri-nic.arpa From: guru@flora.wustl.EDU (Gurudatta Parulkar) Date: 4 Jun 88 13:48:35 GMT Has anybody successfully installed Van Jacobson's tcp/ip on a binary only sun 3/50 ? Yes. Several thousand have. It is in the current software release, SunOS 4.0. - Bill Nowicki Sun Microsystems ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806051955.AA19059@ucbvax.Berkeley.EDU] <1988060516401000> From: craig@NNSC.NSF.NET (Craig Partridge) Newsgroups: comp.protocols.tcp-ip Subject: re: a couple of questions Message-ID: <8806051955.AA19059@ucbvax.Berkeley.EDU> Date: 5 Jun 88 16:40:10 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 10 Installing Van Jacobson's TCP on a SUN 3/50 is quite simple. There is a special Makefile.sun that makes it easy to generate *.o files you can stick in /sys/OBJ. It also works wonderfully -- my TCP connections have been noticeably happier. Installing the entire Berkeley distribution (with the IP fixes, etc) is quite difficult -- it requires porting the software to the SUN. Craig ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806052102.AA13347@sluggo.sun.com] <1988060521024200> From: melohn@SUN.COM (Bill Melohn) Newsgroups: comp.protocols.tcp-ip Subject: Re: A couple of questions Message-ID: <8806052102.AA13347@sluggo.sun.com> Date: 5 Jun 88 21:02:42 GMT References: <8806041348.AA06264@lora.wustl.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: Sun Microsystems, Mountain View Lines: 6 In article <8806041348.AA06264@lora.wustl.edu> guru@wra.wustl.EDU (Gurudatta Parulkar) writes: >Has anybody successfully installed Van Jacobson's tcp/ip on a >binary only sun 3/50 ? Please let me know. I need some help. Van's XTCP work is included in SunOS 4.0, which should be available now at a Sun sales office near you. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988060609135300> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Wed, 8 Jun 88 09:29:43 PDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA09144; Tue, 7 Jun 88 18:18:29 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 Jun 88 09:13:53 GMT From: mcgill-vision!mouse@BLOOM-BEACON.MIT.EDU (der Mouse) Organization: McGill University, Montreal Subject: Re: FTP server question Message-Id: <1136@mcgill-vision.UUCP> References: <8805261929.AA04199@RHEA.CAM.UNISYS.COM> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa In article <8805261929.AA04199@RHEA.CAM.UNISYS.COM>, jonab@CAM.UNISYS.COM (Jonathan P. Biggar) writes: >> The TCP URGENT mechanism uses a pointer; I do not think that there >> is any specification which says that packet boundaries are >> significant with respect to URGENTs. > Not so! RFC 793 states: > If there is urgent data [...]. *****Note that data following > the urgent pointer (non-urgent data) cannot be delivered to the > user in the same buffer with preceeding urgent data unless the > boundary is clearly marked for the user.***** What does this have to do with packet boundaries? Jonab said "packet", not "user buffer". der Mouse uucp: mouse@mcgill-vision.uucp arpa: mouse@larry.mcrcim.mcgill.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988060609374300> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Wed, 8 Jun 88 09:32:49 PDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA09155; Tue, 7 Jun 88 18:19:17 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 Jun 88 09:37:43 GMT From: mcgill-vision!mouse@bloom-beacon.mit.edu (der Mouse) Organization: McGill University, Montreal Subject: Re: Convert /etc/hosts to RR format pgm anyone? Message-Id: <1137@mcgill-vision.UUCP> References: <21877@amdcad.AMD.COM> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa In article <21877@amdcad.AMD.COM>, indra@amdcad.AMD.COM (Indra K. Singhal) writes: > Has anyone put together a program/shell script that converts > /etc/hosts to the standard RR format as specified in the RFCs listed? You probably don't want to do this as simply as you think. Why? - /etc/hosts generally doesn't have domain-style addresses in it - You'll need in-addr.arpa records too - You probably want to put each domain into a file of its own, with SOA and NS records and suchlike.... If you really do want to just convert /etc/hosts to a bunch of A records, it's hardly complicated.... < /etc/hosts sed -e 's/#.*//' \ | awk '{ for (i=2;i<=NF;i++) printf("%s\tin\ta\t%s\n",$i,$1); }' \ > wherever-you-want-the-RRs (The resulting RRs should be loaded with a $ORIGIN of ., of course.) der Mouse uucp: mouse@mcgill-vision.uucp arpa: mouse@larry.mcrcim.mcgill.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [3059@imag.imag.fr] <1988060610224300> From: richier@imag.imag.fr (Jean-Luc Richier) Newsgroups: comp.protocols.tcp-ip Subject: gateways and more-than-one-IP-net on one ethernet Message-ID: <3059@imag.imag.fr> Date: 6 Jun 88 10:22:43 GMT Reply-To: richier@imag.imag.fr (Jean-Luc Richier) Organization: IMAG, University of Grenoble, France Lines: 45 I have a problem with the 4.3 version of TCP-IP, when I use both gateways and multiple nets on one ethernet. Description: I have a ethernet LAN which contains 2 IP networks (In fact, it consists of two ethernet networks, interconnected with Level 2 Bridges). There is also a gateway on the LAN, which provides acess to a third network. The structure is as follows (with arbitrary IP numbers): etherLAN IP-net-A(192.0.0.xx) IP-net-B(192.0.1.yy) --------------------------+--------------------------------- | Gateway (addr 192.0.0.1, dstaddr 192.0.2.1) | | Gateway (addr 192.0.2.2, dstaddr 192.0.0.2) --------------------------+--------------------------------- etherLAN IP-net-C(192.0.2.xx) The machines on IP-net-A use the route commands: route add network IP-net-B 0 route add network IP-net-C 192.0.0.1 1 The machines on IP-net-B use the route command: route add network IP-net-A 0 The problem is that I cannot access the net IP-net-C from machines on the net IP-net-B: The route command route add network IP-net-C 192.0.0.1 1 is refused, with the message "network is unreachable" I have been unable to solve this problem with route, routed, or even by using the "arp -s" command (trying to use proxy arp). About 6 months ago, some persons in netland (in comp.protocols.tcp-ip) suggested the idea of declaring more than one ethernet interface, in order to solve the problem of more than one net on a LAN, each with subnet and non standard broadcast addresses. I have been unable to implement this solution (on Vax or Sun, these interfaces do not configure, and therefore ifconfig does not work). Is there any solution? I can think of many, but they all ask for modifications in the kernel source. I hope that there is simpler solutions. ------------ Jean-Luc Richier richier@imag.imag.fr or richier@imag.UUCP or uunet.uu.net!imag!richier ----MESSAGE-END---- ----MESSAGE-BEGIN---- [3425@ncrcae.Columbia.NCR.COM] <1988060613182900> From: wingo@ncrcae.Columbia.NCR.COM (Dave Wingo) Newsgroups: comp.protocols.tcp-ip Subject: rlogin to self with host name not loopback Keywords: rlogin to self Message-ID: <3425@ncrcae.Columbia.NCR.COM> Date: 6 Jun 88 13:18:29 GMT Distribution: na Organization: NCR Corp., Engineering & Manufacturing - Columbia, SC Lines: 7 I have a question concerning tcp/ip rlogin and/or telnet. If you are trying to rlogin/telnet to yourself using your own host name and not the loopback interface should the traffic generated be kept internal to your host or must it go out on the net. Is there a standard defining this situation or is it just an implementation detail. Thanks in advance..... ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988060613312500> Received: from nisc.nyser.net by SRI-NIC.ARPA with TCP; Mon, 6 Jun 88 17:10:53 PDT Received: by nisc.nyser.net (5.54/2.1-NYSERNet NISC) id AA02565; Mon, 6 Jun 88 20:07:33 EDT Message-Id: <8806070011.AA07012@oswego> Received: from localhost by oswego.Oswego.EDU (1.2/Osw3.8.19) id AA07012; Mon, 6 Jun 88 20:11:30 edt To: tcp-ip@sri-nic.arpa Subject: Re: TCP/IP for PDP-11 running TSX (RT11) Date: Mon, 06 Jun 88 20:11:25 -0400 From: Edward F. Beadel Jr. In regard to Kurt Zeilenga's (kurt@hc.dspo.gov) question about TCP/IP for RT-11. The following message is from the info-pdp11 mailing list. -ed *********************************************************************** Edward F. Beadel, Jr., Assistant Director Instructional Computing Center SUNY College at Oswego beadel@oswego.Oswego.EDU Oswego, NY 13126 (315)-341-3055 *********************************************************************** ------- Forwarded Message >From rna!dan%cmcl2.NYU.EDU@cmcl2.NYU.EDU Fri Jun 3 22:24:41 1988 Date: Fri, 3 Jun 88 20:27:03 EDT >From: rna!dan@cmcl2.NYU.EDU (Dan Ts'o) Message-Id: <8806040027.AA22899@rna> To: cmcl2!oswego.oswego.edu!beadel@cmcl2.NYU.EDU, info-pdp11@sei.cmu.edu Subject: Re: RT-11 question from the TCP-IP mail You can always get the Process Software telnet and ftp for RT-11. I think they want about $1000 for it. Cheers, Dan Ts'o 212-570-7671 Dept. Neurobiology dan@rna.rockefeller.edu Rockefeller Univ. ...cmcl2!rna!dan 1230 York Ave. rna!dan@nyu.edu NY, NY 10021 tso@rockefeller.edu ------- End of Forwarded Message ----MESSAGE-END---- ----MESSAGE-BEGIN---- [3426@ncrcae.Columbia.NCR.COM] <1988060613313500> From: wingo@ncrcae.Columbia.NCR.COM (Dave Wingo) Newsgroups: comp.protocols.tcp-ip Subject: streams based vs character based tcp/ip on UNIX Keywords: streams or character tcp/ip Message-ID: <3426@ncrcae.Columbia.NCR.COM> Date: 6 Jun 88 13:31:35 GMT Distribution: na Organization: NCR Corp., Engineering & Manufacturing - Columbia, SC Lines: 4 Has anyone compared the character based tcp/ip vs the streams based tcp/ip for UNIX. Does one out perform the other? Is one larger than the other? Thanks for your comments and responses in advance. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [21987@amdcad.AMD.COM] <1988060618531100> From: phil@amdcad.AMD.COM (Phil Ngai) Newsgroups: comp.periphs,comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Wanted: Delni Keywords: ethernet, delni, lan, dfs Message-ID: <21987@amdcad.AMD.COM> Date: 6 Jun 88 18:53:11 GMT References: <1138@csustan.UUCP> <5398@coherent.com> Reply-To: phil@amdcad.UUCP (Phil Ngai) Distribution: na Organization: Advanced Micro Devices Lines: 16 In article <5398@coherent.com> celeste@coherent.com (Celeste C. Stokely) writes: >Save yourself a lot of grief and don't buy a Delni. They seems to suffer >from some of the worst quality control problems I've ever seen. If you get >a good one, they're great, but it's hard to get a good Delni. Could you go into more detail on this? How can you tell if your DELNI is bad? We have used a lot of Cabletron equipment and are very happy with them also. Mostly transceivers. We started using DELNIs before Cabletron was around and for lack of any problems directly attributed to them stuck with them. By coincidence, we are seeing problems in a new building and I wonder if the DELNIs are the culprit. -- I speak for myself, not the company. Phil Ngai, {ucbvax,decwrl,allegra}!amdcad!phil or phil@amd.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806061922.AA28776@msr.epm.ornl.gov] <1988060619222400> From: dunigan@MSR.EPM.ORNL.GOV (Tom Dunigan 576-2522) Newsgroups: comp.protocols.tcp-ip Subject: seeking info on security features of tcp/ip Message-ID: <8806061922.AA28776@msr.epm.ornl.gov> Date: 6 Jun 88 19:22:24 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 9 We are gathering information for a CS reading course on aspects of network security supported by TCP/IP -- from the data layer to the application layer. We would very interested in any information on current research, publications, RFC's, etc. relating to network security with respect to TCP/IP. Does anyone use the security options of IP? thanks Tom Dunigan dunigan@msr.epm.ornl.gov ----MESSAGE-END---- ----MESSAGE-BEGIN---- [3c810ce9.13422@apollo.uucp] <1988060620380000> From: mishkin@apollo.uucp (Nathaniel Mishkin) Newsgroups: comp.protocols.tcp-ip Subject: XNS over non-Ethernet Message-ID: <3c810ce9.13422@apollo.uucp> Date: 6 Jun 88 20:38:00 GMT Reply-To: mishkin@apollo.UUCP (Nathaniel Mishkin) Organization: Apollo Computer, Chelmsford, MA Lines: 8 OK, I *know* this isn't an IP questions, but there's no XNS mailing list / news group that I know of and I'm sure some reader of this group must know the answer, so... Has anyone ever run XNS over a data link that was addressed differently from Ethernet? If so, what did they do? ARP? Thanks. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806062159.AA04619@stanford.cray.com] <1988060621592200> From: hunaid@stanford.CRAY.COM (Hunaid Engineer) Newsgroups: comp.protocols.tcp-ip Subject: IP security Message-ID: <8806062159.AA04619@stanford.cray.com> Date: 6 Jun 88 21:59:22 GMT Article-I.D.: stanford.8806062159.AA04619 Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 2 I will working on putting some sort of IP security to our TCP/IP code. Any ideas or examples. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1692@lll-lcc.aRpA] <1988060700190400> From: wiltzius@lll-lcc.aRpA (Dave P. Wiltzius) Newsgroups: comp.protocols.tcp-ip Subject: More IP Security Message-ID: <1692@lll-lcc.aRpA> Date: 7 Jun 88 00:19:04 GMT Reply-To: wiltzius@lll-crg.UUCP (Dave P. Wiltzius) Organization: CRG, Lawrence Livermore Labs Lines: 24 We at LLNL would like to use the IP security option. See the plea for help below. Also talked with people at LANL (sorry, the former is Lawrence Livermore Nat'l Lab and the latter is Los Alamos Nat'l Lab) and Sandia Labs. Apparently all three labs are ready to migrate to TCP/IP to some degree. All three, I think it is safe to say, will need one or both of the IP security options (LLNL apparently will need both). I would recommend getting familiar with RFC 1038 even though it is a draft since (at least a few) vendors are already complying with it. RFC 1038 specifies the use of the IP Basic security option and defines the IP Extended security option. I know of a few vendors of IP routers that intend to comply with RFC 1038 and one vendor of TCP/IP products for hosts (TWG) that intends to comply with it. Anyone know what kind of support for RFC 1038 can be expected from DEC (Ultrix in particular), SUN and others (Ardent, Silicon Graphics, etc)? The local sales folks want to help but . . . Thanks. Dave (wiltzius@lll-lcc.llnl.gov) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988060703525100> Received: from venera.isi.edu by SRI-NIC.ARPA with TCP; Tue, 7 Jun 88 10:58:03 PDT Received: from braden.isi.edu by venera.isi.edu (5.54/5.51) id AA07310; Tue, 7 Jun 88 10:53:05 PDT Date: Tue, 7 Jun 88 10:52:51 PDT From: braden@venera.isi.edu Posted-Date: Tue, 7 Jun 88 10:52:51 PDT Message-Id: <8806071752.AA00280@braden.isi.edu> Received: by braden.isi.edu (5.54/5.51) id AA00280; Tue, 7 Jun 88 10:52:51 PDT To: tcp-ip@sri-nic.arpa Subject: FTP Logical Byte Sizes Cc: braden@venera.isi.edu, ietf-hosts@nnsc.nsf.net Some time ago there was a discussion on this list about the use of the TYPE L command in FTP, but I don't recall the details. I would appreciate hearing from anyone who does remember the discussion; I vaguely remember that a question from Mark Crispin started it off. Any wisdom you can recall or invent will find its way into the "Requirements for Internet Hosts" RFC that is being drafted by an IETF Working Group. Do you have an application that requires some use of TYPE L? Thanks. Bob Braden ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806070434.AA09530@infidel.lanl.gov.ARPA] <1988060704340200> From: peter%infidel@LANL.GOV (Peter Ford) Newsgroups: comp.protocols.tcp-ip Subject: Re: Wanted: Delni Message-ID: <8806070434.AA09530@infidel.lanl.gov.ARPA> Date: 7 Jun 88 04:34:02 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 12 We have a cabletron DELNI clone which is better than the old DELNIs since it is loaded with lights which have helped in network debugging. I have found both DELNIs and Cabletron clones to be equally reliable (haven't seen either fail yet), but I am serious about those lights, I would buy a Cabletron MT-800 every time. Some of us still like those blinking lights on our gear and hope that they come back in style on all equipment. Peter Ford Center for Nonlinear Studies peter@lanl.gov ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988060705322500> Received: from flora.wustl.edu ([128.252.123.41]) by SRI-NIC.ARPA with TCP; Tue, 7 Jun 88 12:39:44 PDT Received: by flora.wustl.edu (3.2/SMI-DDN) id AA10911; Tue, 7 Jun 88 13:52:28 CDT Message-Id: <8806071852.AA10911@flora.wustl.edu> To: nowicki@sun.com (Bill Nowicki) Cc: tcp-ip@sri-nic.arpa Subject: Re: A couple of questions In-Reply-To: Your message of Sun, 05 Jun 88 20:38:52 -0700. <8806060338.AA28521@speed.sun.com> Date: Tue, 07 Jun 88 13:52:25 -0500 From: Gurudatta Parulkar From: guru@flora.wustl.EDU (Gurudatta Parulkar) Date: 4 Jun 88 13:48:35 GMT Has anybody successfully installed Van Jacobson's tcp/ip on a binary only sun 3/50 ? > Yes. Several thousand have. It is in the current software release, > SunOS 4.0. Very true except several thousands like us haven't yet received the SunOS 4.0! And I am interested in having the Van Jacobsen's "source" code for TCP AND IP on my otherwise binary only Sun 3/50. As Craig pointed out TCP is not a problem, but IP part has to be actually ported to sun. I guess the revised question should be has anybody successfully ported the IP part of Van Jacobsen's code to sun 3/50 and is willing to let others use the revised source code ? I hope this makes some sense. -guru guru@flora.wustl.edu or parulkar@udel.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988060710360200> Received: from Score.Stanford.EDU by SRI-NIC.ARPA with TCP; Tue, 7 Jun 88 17:38:47 PDT Date: Tue 7 Jun 88 17:36:02-PDT From: Vince Fuller Subject: Re: FTP Logical Byte Sizes To: braden@VENERA.ISI.EDU cc: tcp-ip@SRI-NIC.ARPA, ietf-hosts@NNSC.NSF.NET In-Reply-To: <8806071752.AA00280@braden.isi.edu> Office: Pine Hall 167 Phone: 415-723-6860 Message-ID: <12404660639.18.VAF@Score.Stanford.EDU> The TOPS-20 FTP software uses TYPE L 36 when transferring files between TOPS-20 machines (and TOPS-10's/TENEX's, for that matter...). I believe the bit-packing is done essentially identically to TYPE I for 36-bit words. The TOPS-20 FTP software also supports other, arbitrary file byte sizes using TYPE L xx and sets the file byte size on the target machine accordingly. Vince Fuller, Stanford Networking Systems (formerly CMU TOPS-20/networking hacker) ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988060711552700> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Wed, 8 Jun 88 09:51:25 PDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA10626; Tue, 7 Jun 88 20:03:51 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 Jun 88 11:55:27 GMT From: osu-cis!att!oucsace!oucs!wright!jsloan@tut.cis.ohio-state.edu (John Sloan) Organization: Wright State University, Dayton OH, 45435 Subject: Experience with Xyplex Terminal Servers? Message-Id: <878@wright.EDU> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa Our main campus computer center is evaluating a terminal server manufactured by Xyplex that speaks both TCP/IP and DECnet. We in Computer Science have never heard of this beast, having settled on Encore Annexen, and are interested in anyone's comments regarding how well the Xyplex works, long term reliability, ease of configuration and management, caveats, etc. Email, and if there's any interest, I'll be glad to summarize and post. Thanks much. -- John Sloan CSNET: jsloan@SPOTS.Wright.Edu -- John Sloan, The SPOTS Group Wright State University Research Building CSNET: jsloan@SPOTS.Wright.Edu 3171 Research Blvd., Kettering, OH 45420 UUCP: ...!wright!jsloan +1-513-259-1384 +1-513-873-2491 Logical Disclaimer: belong(opinions,jsloan). belong(opinions,_):-!,fail. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988060712570300> Received: from CU20B.CC.COLUMBIA.EDU by SRI-NIC.ARPA with TCP; Tue, 7 Jun 88 14:00:28 PDT Date: Tue 7 Jun 88 16:57:03-EDT From: Ken Rossman Subject: Re: Wanted: Delni [blinking lights] To: tcp-ip@SRI-NIC.ARPA Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025 Phone: (212) 280-4876 Message-ID: <12404620776.15.SY.KEN@CU20B.CC.COLUMBIA.EDU> I'll put in a "third" on that one. I miss those little status lights. It's a shame that pricing competition has gotten vendors to a point where they feel they need to shave off a few bucks by tossing out "needless" status lights in favor of some remote "console" (maybe, if that)... ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988060713290000> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Tue, 7 Jun 88 15:11:06 PDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA29204; Tue, 7 Jun 88 08:50:12 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 Jun 88 13:29:00 GMT From: necntc!dandelion!ulowell!apollo!mishkin@ames.arc.nasa.gov (Nathaniel Mishkin) Organization: Apollo Computer, Chelmsford, MA Subject: Point-to-Point links Message-Id: <3c8494c7.13422@apollo.uucp> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa I wonder whether someone would be so kind as to tell me the revealed truth about the assignment of IP network numbers to point-to-point links (like SLIP). From what I can tell from munging around 4.3bsd, it seems that not everyone (e.g. 4.3bsd) assigns a separate IP network number to the link itself. I thought it was always the right thing (if a waste) to assign the link a network number. Can someone tell me how to think about this? Thanks. -- -- Nat Mishkin Apollo Computer Inc., Chelmsford, MA {decvax,mit-eddie,umix}!apollo!mishkin apollo!mishkin@mit-eddie.arpa ----MESSAGE-END---- ----MESSAGE-BEGIN---- [23179@bu-cs.BU.EDU] <1988060713330000> From: kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) Newsgroups: comp.protocols.tcp-ip Subject: Re: Wanted: Delni [blinking lights] Summary: Keep those blinkenlights! Message-ID: <23179@bu-cs.BU.EDU> Date: 7 Jun 88 13:33:00 GMT References: <8806070434.AA09530@infidel.lanl.gov.ARPA> Reply-To: kwe@buit13.bu.edu (Kent England) Followup-To: comp.protocols.tcp-ip Organization: Boston Univ. Information Tech. Dept. Lines: 16 In article <8806070434.AA09530@infidel.lanl.gov.ARPA> peter%infidel@LANL.GOV (Peter Ford) writes: >Some of us still like those blinking lights on our gear and hope >that they come back in style on all equipment. > I heartily second that. One of the interesting things I note on the new unshielded twisted pair Ethernet gear from Cabletron is a "Link OK" status light. I was delighted to hear that Cabletron (and possibly others) are using a 1 MHz idle "tone" on the circuit to indicate "continuity" in the link. This is much better than a simple power light and should help find swapped pairs and dead circuits. I understand that the 802.3 committee is considering standardizing a "Link OK" idle signal (on UTP and fiber[?]). I hope they do. Never underestimate the power of a little LED. Kent England, Boston U ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988060716502300> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Tue, 7 Jun 88 19:49:29 PDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA01394; Tue, 7 Jun 88 11:02: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: 7 Jun 88 16:50:23 GMT From: kwe@bu-cs.bu.edu (kwe@bu-it.bu.edu (Kent W. England)) Organization: Boston Univ. Information Tech. Dept. Subject: Re: Point-to-Point links Message-Id: <23187@bu-cs.BU.EDU> References: <3c8494c7.13422@apollo.uucp> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa In article <3c8494c7.13422@apollo.uucp> mishkin@apollo.UUCP (Nathaniel Mishkin) writes: >I wonder whether someone would be so kind as to tell me the revealed >truth about the assignment of IP network numbers to point-to-point links >(like SLIP). Here's an example from Proteon. Proteon added the feature of NOT using IP subnets on serial links to Rel 7.4 (circa last summer). Prior to 7.4 you HAD to use a subnet. What do you give up? Here's what Proteon said in the 7.4 release notes: o can't ping the interface o cannot run EGP over the interface o cannot boot from that interface (serial line boot added rel 8.0) The problem with omitting an IP subnetted address from a serial interface has to do with identifying that interface. Proteon says that "for routing decisions, such a serial line [no IP addr] is considered to be a part of each subnetted network present in the gateway." Of course, the big lose with IP addresses is "wasting" all those two node subnets. Use addresses for finer control. Don't use them if you don't have subnets to "waste". However, you should design the option in for your customers. Kent England, Boston U ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988060719100500> Received: from VAX.BBN.COM by SRI-NIC.ARPA with TCP; Tue, 7 Jun 88 23:01:25 PDT To: "Frank J. Wancho" cc: braden@VENERA.ISI.EDU, ietf-hosts@NNSC.NSF.NET, tcp-ip@SRI-NIC.ARPA, ado@bbn.com Subject: Re: FTP Logical Byte Sizes In-reply-to: Your message of Tue, 07 Jun 88 16:38:00 -0600. Date: Wed, 08 Jun 88 01:50:05 -0400 From: Buz Owen In addition to being useful with 36 bit pdp10 and related machines, local byte size 8 is useful with the BBN C/70, which has a 20 bit word and a 10 bit byte size. While a discussion of choices of reasonable machine word sizes, and important or unimportant machine architectures would be inappropriate (and boring, or maybe annoying) on this list, type L 8 is useful to tell the C/70 to send just the low 8 bits of each byte, a common type of file on the C/70 -- what you normally get as output from a C program that writes an 8 bit binary file -- or store such a file. Using Image mode instead, you get the unused zero bits sent through the net, wasting network bandwidth and machine cycles, as the C/70 laboriously repacks bits into 8 bit bytes -- and then have to run a program to strip the bits out at the other end. So for both the C/70 and pdp10 type architectures, type L 8 tells the machine to skip over unused bit positions -- the pdp10 put these bits at the end of each word, the C/70 puts them in the high order position of each byte. Thus local byte size is important if you want to assure compatibility with possible "odd" machines in the future, or with existing ones you know you need to communicate with already. User and server FTP's for 8 bit machines sometimes do not initially implement even type L 8 because the author knew that there was no special local interpretation of for it, i.e. that it would be treated the same as image, and therefore deemed it unnecessary. But it eventually has to be added in order to talk to odd machines which do place an interesting -- i.e. different than image -- interpretation on it at the other end. To be general, at least any local byte size that seems equivalent to type image ought to be accepted by the server and settable by the user process, and then treated identically to type Image -- this costs almost nothing in the implementation. As far as I know, only a few cases really seem to be needed. On an 8 bit machine, multiples of 8 seem like they might be equivalent to image, but then since the spec does not say a particular local byte type means, it being a local matter, it is hard to rule out that you might someday need to talk to a machine that needs to be told "type L 5". What should this mean on a an 8 bit machine? The user ftp "quote" command is a reasonable hedge against this unlikely case except that some user ftp processes withhold the type command and send it just before the "stor" or "retr" command. Buz ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988060719311200> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Tue, 7 Jun 88 22:06:37 PDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA03329; Tue, 7 Jun 88 12:42:48 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 Jun 88 19:31:12 GMT From: amdcad!phil@ucbvax.Berkeley.EDU (Phil Ngai) Organization: Advanced Micro Devices Subject: Re: Wanted: Delni [blinking lights] Message-Id: <21998@amdcad.AMD.COM> References: <8806070434.AA09530@infidel.lanl.gov.ARPA>, <23179@bu-cs.BU.EDU> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa In article <23179@bu-cs.BU.EDU> kwe@buit13.bu.edu (Kent England) writes: >understand that the 802.3 committee is considering standardizing a >"Link OK" idle signal (on UTP and fiber[?]). I hope they do. > > Never underestimate the power of a little LED. I asked the DEC salesman about having LEDs like Cabletron does on their transceivers. He thought it was a silly idea. We don't buy H4005s anymore. We buy Cabletron transceivers. Thank goodness for the free market system. -- I speak for myself, not the company. Phil Ngai, {ucbvax,decwrl,allegra}!amdcad!phil or phil@amd.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988060720573600> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Wed, 8 Jun 88 09:10:21 PDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA07464; Tue, 7 Jun 88 16:29:20 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 Jun 88 20:57:36 GMT From: sun.soe.clarkson.edu!nelson@tcgould.tn.cornell.edu (Russ Nelson) Organization: Clarkson University, Potsdam, NY Subject: RIP vs. HELLO Message-Id: <1041@sun.soe.clarkson.edu> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa Reading Comer's book, _Internetworking with TCP/IP_, I get the impression that RIP is a second son of the Internet protocol suite. I also found out why I couldn't find any documentation on the "RIP Protocol". Is there a move to HELLO afoot? *Should* there be a move to HELLO? Also, reading the RFC for BOOTP, I get the impression that RARP is obsoleted by BOOTP. There is no contact address given in the RFC, so I ask here... Also also, Comer's book is very handy for figuring out how a packet gets from host A to host B. Tannenbaum's _Computer Networks_ is a good tutorial on networks in general, but Comer's book gives you a chance to decode Dave Mills' postings :-) -- signed char *reply-to-russ(int network) { /* Why can't BITNET go */ if(network == BITNET) return "NELSON@CLUTX"; /* domainish? */ else return "nelson@clutx.clarkson.edu"; } ----MESSAGE-END---- ----MESSAGE-BEGIN---- [WANCHO.12404639269.BABYL@SIMTEL20.ARPA] <1988060722380000> From: WANCHO@SIMTEL20.ARPA ("Frank J. Wancho") Newsgroups: comp.protocols.tcp-ip Subject: FTP Logical Byte Sizes Message-ID: Date: 7 Jun 88 22:38:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 12 Bob, There still is a definite need for TYPE L , in particular, TYPE L 8, TYPE L 32, and TYPE L 36. Most important is TYPE L 8 because it is the only way to correctly transfer our 8-bit binary files to a non-PDP10 host. It would be short-sighted to assume transfers of 8-bit binary data even between hosts of the same word length would be correct using TYPE IMAGE or TYPE L nn as the byte order within the word may not be the same. Similar cases can be made to be able to specify other possible bytesizes. --Frank ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806072320.AA00636@braden.isi.edu] <1988060723204700> From: braden@VENERA.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: FTP Logical Byte Sizes Message-ID: <8806072320.AA00636@braden.isi.edu> Date: 7 Jun 88 23:20:47 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 7 Frank, I must admit I never thought about byte order. Are there actually any FTP's for little-endian machines that would send "swapped" bytes, ie, not in byte order but in halfword or word order for those machines?? Bob Braden ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988060802264000> Received: from lindy.Stanford.EDU by SRI-NIC.ARPA with TCP; Wed, 8 Jun 88 10:11:17 PDT Received: by lindy.Stanford.EDU (4.0/4.7); Wed, 8 Jun 88 09:26:40 PDT Date: Wed, 8 Jun 88 09:26:40 PDT From: hjs@lindy.Stanford.EDU (Harry Saal) To: tcp-ip@sri-nic.ARPA, urbaniak@g.bbn.com Subject: More Ethertypes Thank you for the list of Ethertypes and manufacturer ids you have accumulated. It is valuable, since Xerox refuses to divulge their list since it is "confidential", and they never chose to ask companies their permission to "disclose" the existence of an assigned Ethertype. Here are several more entries to add to your list: 0200 PUP **** this conflicts with IEEE 802.3/802.2 style network 0201 PUP Address Recog Protocol ***** ditto 0888 Xyplex 0BAD Banyan Systems 8080 Vitalink 8137 Novell 9001 Bridge (bridge management) 9002 Bridge (terminal server) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [5222@ecsvax.UUCP] <1988060802385700> From: tpmsph@ecsvax.UUCP (Thomas P. Morris) Newsgroups: comp.os.vms,comp.protocols.tcp-ip Subject: CMU TCP-IP for VMS 5.0? Keywords: TCP-IP VMS 5.0 Compatible Spinlocks Drivers Message-ID: <5222@ecsvax.UUCP> Date: 8 Jun 88 02:38:57 GMT Organization: UNC Educational Computing Service Lines: 31 Is there or will there be available any time REAL SOON NOW, a version of the CMU TCP-IP package for VMS which will be compatible with VMS 5.0? We're getting ready to install and make available the CMU TCP-IP 6.0/6.2 release on our VAXcluster. We're not particularly thrilled at the prospect of having our user population become dependent upon this package for TELNET and FTP, if the ACP and IPDRIVER code "breaks" under VMS 5.0, which we expect to have in hand and install in the next month and a half. VMS 5.0 changes some of the device driver and system data structure synchronization techniques, so I know that changes will be required to the ACP and the IPDRIVER. We don't have all the tools necessary to rebuild these images on our local systems. So, has anyone tackled this problem yet? Will there be a new release from CMU? Thanx in advance. ----------------------------------------------------------------------------- Tom Morris BITNET: TOM@UNCSPHVX UNC School of Public Health UUCP : ...!mcnc!ecsvax!tpmsph ----------------------------------------------------------------------------- -- ----------------------------------------------------------------------------- Tom Morris BITNET: TOM@UNCSPHVX UNC School of Public Health UUCP : ...!mcnc!ecsvax!tpmsph ----------------------------------------------------------------------------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988060803350000> Received: from twg.com by SRI-NIC.ARPA with TCP; Wed, 8 Jun 88 10:44:03 PDT Received: from TWG.COM by twg.com with SMTP ; Wed, 8 Jun 88 10:38:14 PDT Received: from vax2.twg.com by Gonzo.TWG.COM id aa04915; 8 Jun 88 10:34 PDT Date: 8 Jun 88 10:35:00 PDT From: Mike Anello Subject: RE: streams based vs character based tcp/ip on UNIX To: tcp-ip We have seen a 40% increase in performance on our streams based tcp/ip over our character based tcp/ip. The size I don't have the information about the size of our character product handy, but our streams product kernel is approx 70k. Hope this is useful. Mike Anello Manager, Streams Development Wollongong - Palo Alto ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806091207.AA05785@ucbvax.Berkeley.EDU] <1988060805500500> From: ado@VAX.BBN.COM (Buz Owen) Newsgroups: comp.protocols.tcp-ip Subject: Re: FTP Logical Byte Sizes Message-ID: <8806091207.AA05785@ucbvax.Berkeley.EDU> Date: 8 Jun 88 05:50:05 GMT References: Sender: uucp@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 38 In addition to being useful with 36 bit pdp10 and related machines, local byte size 8 is useful with the BBN C/70, which has a 20 bit word and a 10 bit byte size. While a discussion of choices of reasonable machine word sizes, and important or unimportant machine architectures would be inappropriate (and boring, or maybe annoying) on this list, type L 8 is useful to tell the C/70 to send just the low 8 bits of each byte, a common type of file on the C/70 -- what you normally get as output from a C program that writes an 8 bit binary file -- or store such a file. Using Image mode instead, you get the unused zero bits sent through the net, wasting network bandwidth and machine cycles, as the C/70 laboriously repacks bits into 8 bit bytes -- and then have to run a program to strip the bits out at the other end. So for both the C/70 and pdp10 type architectures, type L 8 tells the machine to skip over unused bit positions -- the pdp10 put these bits at the end of each word, the C/70 puts them in the high order position of each byte. Thus local byte size is important if you want to assure compatibility with possible "odd" machines in the future, or with existing ones you know you need to communicate with already. User and server FTP's for 8 bit machines sometimes do not initially implement even type L 8 because the author knew that there was no special local interpretation of for it, i.e. that it would be treated the same as image, and therefore deemed it unnecessary. But it eventually has to be added in order to talk to odd machines which do place an interesting -- i.e. different than image -- interpretation on it at the other end. To be general, at least any local byte size that seems equivalent to type image ought to be accepted by the server and settable by the user process, and then treated identically to type Image -- this costs almost nothing in the implementation. As far as I know, only a few cases really seem to be needed. On an 8 bit machine, multiples of 8 seem like they might be equivalent to image, but then since the spec does not say a particular local byte type means, it being a local matter, it is hard to rule out that you might someday need to talk to a machine that needs to be told "type L 5". What should this mean on a an 8 bit machine? The user ftp "quote" command is a reasonable hedge against this unlikely case except that some user ftp processes withhold the type command and send it just before the "stor" or "retr" command. Buz ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988060812030000> Received: from TYCHO.ARPA by SRI-NIC.ARPA with TCP; Wed, 8 Jun 88 13:13:59 PDT Date: 8 Jun 1988 1603-EDT Subject: DDN support for CMU-TEK TCP/IP From: hsw@TYCHO.ARPA (Howard Weiss) To: tcp-ip at sri-nic.arpa, info-vax at kl.sri.com cc: hsw Does anyone know of any work that has been done to support a DDN interface in the CMU-TEK TCP/IP package? As delivered, the code supports Ethernet but I would like to know if anyone has support for interfaces such as the ACC LH/DH or the ACC 6250 in order to accomplish a direct connection to a DDN-like network without first going through a gateway. Howard Weiss Internet: hsw@tycho.arpa ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806091403.AA07144@ucbvax.Berkeley.EDU] <1988060816264000> From: hjs@LINDY.STANFORD.EDU (Harry Saal) Newsgroups: comp.protocols.tcp-ip Subject: More Ethertypes Message-ID: <8806091403.AA07144@ucbvax.Berkeley.EDU> Date: 8 Jun 88 16:26:40 GMT Sender: uucp@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 16 Thank you for the list of Ethertypes and manufacturer ids you have accumulated. It is valuable, since Xerox refuses to divulge their list since it is "confidential", and they never chose to ask companies their permission to "disclose" the existence of an assigned Ethertype. Here are several more entries to add to your list: 0200 PUP **** this conflicts with IEEE 802.3/802.2 style network 0201 PUP Address Recog Protocol ***** ditto 0888 Xyplex 0BAD Banyan Systems 8080 Vitalink 8137 Novell 9001 Bridge (bridge management) 9002 Bridge (terminal server) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [2119@tekfdi.TEK.COM] <1988060816591400> From: mhorne@tekfdi.TEK.COM (Michael T. Horne) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: 3c501/503 programming info... Message-ID: <2119@tekfdi.TEK.COM> Date: 8 Jun 88 16:59:14 GMT Reply-To: mhorne@tekfdi.UUCP (Michael T. Horne) Organization: Tektronix, Inc., Beaverton, OR. Lines: 14 I'm trying to locate programming information about the 3COM 3c503 and 3c501 ethernet boards for the PC. Doesn anyone have such information? I'm looking for documentation, schematics, programming info, etc. Apparently the 3c503 info is "available" for $1000 from 3COM (gosh, what a wonderful way to get people to want to support your hardware product). Can anyone fill me in on this? Mike -- Michael Horne - KA7AXD | UUCP: tektronix!tekfdi!honda!mhorne FDI Div, Tektronix, Inc. | INTERNET: mhorne%honda.fdi.tek.com@relay.cs.net Phone: (503) 627-1878 | AMPRNET: ka7axd@tek.ka7axd.ampr.org ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806091430.AA07494@ucbvax.Berkeley.EDU] <1988060817350000> From: mja@TWG.COM (Mike Anello) Newsgroups: comp.protocols.tcp-ip Subject: RE: streams based vs character based tcp/ip on UNIX Message-ID: <8806091430.AA07494@ucbvax.Berkeley.EDU> Date: 8 Jun 88 17:35:00 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 9 We have seen a 40% increase in performance on our streams based tcp/ip over our character based tcp/ip. The size I don't have the information about the size of our character product handy, but our streams product kernel is approx 70k. Hope this is useful. Mike Anello Manager, Streams Development Wollongong - Palo Alto ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806081813.AA10661@skl-crc.arpa] <1988060818132700> From: martinea@SKL-CRC.ARPA (Mike Martineau) Newsgroups: comp.protocols.tcp-ip Subject: PC Network Information Message-ID: <8806081813.AA10661@skl-crc.arpa> Date: 8 Jun 88 18:13:27 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 8 I am looking for technical information on various PC networking schemes (PC-LAN, 3-Com 3+, Novell, etc). Can anyone point me to appropriate articles, books, technical contacts, etc. Thanks in advance. M.P. Martineau Software Kinetics Ltd. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806092103.AA02418@ucbvax.Berkeley.EDU] <1988060820030000> From: hsw@TYCHO.ARPA (Howard Weiss) Newsgroups: comp.protocols.tcp-ip Subject: DDN support for CMU-TEK TCP/IP Message-ID: <8806092103.AA02418@ucbvax.Berkeley.EDU> Date: 8 Jun 88 20:03:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 10 Does anyone know of any work that has been done to support a DDN interface in the CMU-TEK TCP/IP package? As delivered, the code supports Ethernet but I would like to know if anyone has support for interfaces such as the ACC LH/DH or the ACC 6250 in order to accomplish a direct connection to a DDN-like network without first going through a gateway. Howard Weiss Internet: hsw@tycho.arpa ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [733@lakesys.UUCP] <1988060823073100> From: mikep@lakesys.UUCP (Mike Pluta) Newsgroups: comp.protocols.tcp-ip Subject: help, questions Message-ID: <733@lakesys.UUCP> Date: 8 Jun 88 23:07:31 GMT Reply-To: mikep@lakesys.UUCP (Mike Pluta) Organization: Lake Systems - Milwaukee, WI Lines: 21 I'm beginning the process of research into a TCP/IP implementation under the Pick o/s. Pick is primarily a database, and is nowhere near Unix in terms of internal structure; also, 'C' is not available for Pick- all systems coding is done (or rather would be done) in the Pick o/s meta assembler. What I am basically after, are insights into the implementation of TCP/IP under non-Unix like o/s', and without the use of 'C'. Further, what implementation and research references should I gather- I have access to the 'net' and have read through the Comer book. Any insights? suggestions? encouragements? Michael J Pluta Director of New Product Development Tri-Sys Computer Corp, Inc. -- Michael J Pluta (mikep@lakesys.UUCP) c/o | {ihnp4,uwvax}! Tri-Sys Computer Corp., Inc. | uwmcsd1!lakesys! 207 East Buffalo Street, Suite 600 | mikep Milwaukee, WI 53202 | ----MESSAGE-END---- ----MESSAGE-BEGIN---- [23228@bu-cs.BU.EDU] <1988060823181100> From: kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) Newsgroups: comp.protocols.tcp-ip Subject: Re: RIP vs. HELLO Message-ID: <23228@bu-cs.BU.EDU> Date: 8 Jun 88 23:18:11 GMT References: <1041@sun.soe.clarkson.edu> Reply-To: kwe@buit13.bu.edu (Kent England) Followup-To: comp.protocols.tcp-ip Organization: Boston Univ. Information Tech. Dept. Lines: 19 In article <1041@sun.soe.clarkson.edu> nelson@sun.soe.clarkson.edu (Russ Nelson) writes: >Reading Comer's book, _Internetworking with TCP/IP_, I get the >impression that RIP is a second son of the Internet protocol suite. I >also found out why I couldn't find any documentation on the "RIP >Protocol". Is there a move to HELLO afoot? *Should* there be a move >to HELLO? > You can read all about RIP in IDEA0004-01. As soon as Hedrick gets it published as an RFC, we can all take our respective vendors to task for any noncompliance, if there are still any implementations out there that haven't done split horizon, holddowns, etc. HELLO seems to be becoming an orphan with the emergence this summer of the "new NSFnet backbone". Are there any other implementations running, besides the "old NSFnet backbone"? What happens to the fuzzballs? Should we start a networking corner at the Boston Computer Museum? Or do they all revert to Mills' possession? :-) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988060903250000> Received: from twg.com by SRI-NIC.ARPA with TCP; Thu, 9 Jun 88 10:34:09 PDT Received: from TWG.COM by twg.com with SMTP ; Thu, 9 Jun 88 10:28:33 PDT Received: from vax2.twg.com by Gonzo.TWG.COM id aa16483; 9 Jun 88 10:24 PDT Date: 9 Jun 88 10:25:00 PDT From: Mike Anello Subject: RE: streams based tcpip vs character based tcpip To: tcp-ip >Mike - Being unwilling to show my ignorance to the whole tcp-ip list, >I will ask you: what is the difference between streams vs character ? >Does it have to do with System V vs 4.3 bsd ? Regards - Craig The difference is that streams based tcpip is built with stream drivers and modules where character based tcpip is built with UNIX V or BSD character device drivers. Two different technologies. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988060905290100> Received: from clash.cisco.com by SRI-NIC.ARPA with TCP; Thu, 9 Jun 88 13:30:06 PDT Received: from clash.cisco.com by clash.cisco.com with TCP; Thu, 9 Jun 88 12:29:03 PDT To: Frank Kastenholz Cc: der Mouse , tcp-ip@sri-nic.arpa, cire@clash.cisco.com Subject: Re: Convert /etc/hosts to RR format pgm anyone? In-Reply-To: Your message of Thu, 09 Jun 88 09:33:04 -0400. Date: Thu, 09 Jun 88 12:29:01 PDT From: cire@clash.cisco.com >> Date: Thu, 09 Jun 88 09:33:04 EDT >> From: Frank Kastenholz >> Subject: Re: Convert /etc/hosts to RR format pgm anyone? >> To: der Mouse >> Cc: tcp-ip@sri-nic.arpa >> Good start! I've added some corrections to the heirarchy. It strikes me that this kind of info would be reasonable in an intro of some kind to IP. >> This sounds to me like there is some confusion over the meaning of >> some of the terms used (which, to the best of my limited knowledge, >> have never been fully codified - perhaps an addendum to the Assigned >> Numbers RFC is in order - "Assigned Abbreviations and Terms and Their >> Meanings"). >> I'd recommend Douglas Comer's book 'Internetworking with TCP/IP, Principals, Protocols, and Architecture' or Andrew Tanenbaum's book 'Computer Networks'. Both include a glossary at the back with very succinct definitions of most everything you mention below. >> As I understand things the "hierarchy" of terms in use in the Internet >> protocols (among others) are: >> Here is perhaps a better set of definitions: (some of these are essentially pulled from Comer's book). FRAME - The unit of information encapsulated for transmission on physical media or network. FRAGMENT - a unit that the IP layer breaks a DATAGRAM into if necessary for transmission across networks that can not handle the size of the entire DATAGRAM. A FRAGMENT has essentially the same IP header as the original DATAGRAM. DATAGRAM - The basic unit of information dealt with by the IP layer. This is what is sent across the TCP/IP Internet. It may be broken into FRAGMENTS if a network can not handle the DATAGRAM's size. SEGMENT - the basic unit that TCP deals with. A segment consists of a block of bytes that arrive or are sent at one time. These bytes make up part of stream of bytes. Information in the segment identifies where in the stream these bytes exist. A segment will be passed to the IP layer as one or more DATAGRAMS for transmission by that layer. PACKET - the basic unit of information sent across a packet-switching network. It's exact meaning is dependent upon the context. BUFFER - an implementation detail that is used for passing blocks of information including DATAGRAMS to the layers for processing. -c cire|eric Eric B. Decker cisco Systems Menlo Park, California email: cire@cisco.com uSnail: 1360 Willow Rd., Menlo Park, CA 94025 Phone : (415) 326-1941 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988060905330400> Received: from MITVMA.MIT.EDU by SRI-NIC.ARPA with TCP; Thu, 9 Jun 88 06:51:55 PDT Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 4973; Thu, 09 Jun 88 09:51:19 EDT Received: by MITVMA (Mailer X1.25) id 4972; Thu, 09 Jun 88 09:51:17 EDT Date: Thu, 09 Jun 88 09:33:04 EDT From: Frank Kastenholz Subject: Re: Convert /etc/hosts to RR format pgm anyone? To: der Mouse In-Reply-To: Your message of 6 Jun 88 09:37:43 GMT Cc: tcp-ip@sri-nic.arpa In article <8805261929.AA04199@RHEA.CAM.UNISYS.COM>, jonab@CAM.UNISYS.COM (Jonathan P. Biggar) writes: >>> The TCP URGENT mechanism uses a pointer; I do not think that there >>> is any specification which says that packet boundaries are >>> significant with respect to URGENTs. >> Not so! RFC 793 states: >> If there is urgent data [...]. *****Note that data following >> the urgent pointer (non-urgent data) cannot be delivered to the >> user in the same buffer with preceeding urgent data unless the >> boundary is clearly marked for the user.***** > >What does this have to do with packet boundaries? Jonab said "packet", >not "user buffer". This sounds to me like there is some confusion over the meaning of some of the terms used (which, to the best of my limited knowledge, have never been fully codified - perhaps an addendum to the Assigned Numbers RFC is in order - "Assigned Abbreviations and Terms and Their Meanings"). As I understand things the "hierarchy" of terms in use in the Internet protocols (among others) are: FRAME - lowest level of bits/bytes. One speaks of Ethernet Frames, etc A FRAME has ONE data link header (e.g. Ethernet header). FRAGMENT - the thing that IP spits out to the data link driver. Each FRAGMENT has ONE IP header. A FRAGMENT may be split into multiple FRAMES by the lower layers. SEGMENT - the thing that TCP spits into IP. Each SEGMENT has one TCP header. It may be broken into FRAGMENTS by IP. Noe things get a little weird..... DATAGRAM - this is also the 'larger' thing that IP tries to send. A DATAGRAM USUALLY has a one to one relationship with a SEGMENT. It may be broken up (fragmented) into a number of FRAGMENTS by IP before being sent through the data link. A DATAGRAM is ALSO what UDP and other "datagram" oriented protocols may give to IP for transmission. PACKET - a generic term that can mean anything at any time - usually its meaning is derived from the context, other times by a prefix (such as IP PACKET), other times ..... BUFFER - what is passed to TCP/UDP for transmission. Usually. Of course, a device driver reads stuff out of the I/O interface into a buffer.... These are terms that I use, based on "common usage, the literature, etc" Frank Kastenholz. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [10269@ncc.Nexus.CA] <1988060905572900> From: lyndon@ncc.Nexus.CA (Lyndon Nerenberg) Newsgroups: comp.protocols.tcp-ip Subject: Re: Wanted: Delni Message-ID: <10269@ncc.Nexus.CA> Date: 9 Jun 88 05:57:29 GMT References: <8806070434.AA09530@infidel.lanl.gov.ARPA> Reply-To: lyndon@ncc.UUCP (Lyndon Nerenberg) Organization: Nexus Computing Inc. Lines: 17 In article <8806070434.AA09530@infidel.lanl.gov.ARPA> peter%infidel@LANL.GOV (Peter Ford) writes: >We have a cabletron DELNI clone which is better than the old DELNIs >since it is loaded with lights which have helped in network debugging. [ ... ] >Some of us still like those blinking lights on our gear and hope >that they come back in style on all equipment. Great! My question is: Do you have the rack mounting kit for the DELNI? Some of us like the lights mounted in the rack where everyone can see them. [ Yes, this is a serious question. I'm getting sick of tripping over the bundle of cables... ] -- {alberta,utzoo,uunet}!ncc!lyndon lyndon@Nexus.CA ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806100806.AA14313@ucbvax.Berkeley.EDU] <1988060913330400> From: KASTEN@MITVMA.MIT.EDU (Frank Kastenholz) Newsgroups: comp.protocols.tcp-ip Subject: Re: Convert /etc/hosts to RR format pgm anyone? Message-ID: <8806100806.AA14313@ucbvax.Berkeley.EDU> Date: 9 Jun 88 13:33:04 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 57 In article <8805261929.AA04199@RHEA.CAM.UNISYS.COM>, jonab@CAM.UNISYS.COM (Jonathan P. Biggar) writes: >>> The TCP URGENT mechanism uses a pointer; I do not think that there >>> is any specification which says that packet boundaries are >>> significant with respect to URGENTs. >> Not so! RFC 793 states: >> If there is urgent data [...]. *****Note that data following >> the urgent pointer (non-urgent data) cannot be delivered to the >> user in the same buffer with preceeding urgent data unless the >> boundary is clearly marked for the user.***** > >What does this have to do with packet boundaries? Jonab said "packet", >not "user buffer". This sounds to me like there is some confusion over the meaning of some of the terms used (which, to the best of my limited knowledge, have never been fully codified - perhaps an addendum to the Assigned Numbers RFC is in order - "Assigned Abbreviations and Terms and Their Meanings"). As I understand things the "hierarchy" of terms in use in the Internet protocols (among others) are: FRAME - lowest level of bits/bytes. One speaks of Ethernet Frames, etc A FRAME has ONE data link header (e.g. Ethernet header). FRAGMENT - the thing that IP spits out to the data link driver. Each FRAGMENT has ONE IP header. A FRAGMENT may be split into multiple FRAMES by the lower layers. SEGMENT - the thing that TCP spits into IP. Each SEGMENT has one TCP header. It may be broken into FRAGMENTS by IP. Noe things get a little weird..... DATAGRAM - this is also the 'larger' thing that IP tries to send. A DATAGRAM USUALLY has a one to one relationship with a SEGMENT. It may be broken up (fragmented) into a number of FRAGMENTS by IP before being sent through the data link. A DATAGRAM is ALSO what UDP and other "datagram" oriented protocols may give to IP for transmission. PACKET - a generic term that can mean anything at any time - usually its meaning is derived from the context, other times by a prefix (such as IP PACKET), other times ..... BUFFER - what is passed to TCP/UDP for transmission. Usually. Of course, a device driver reads stuff out of the I/O interface into a buffer.... These are terms that I use, based on "common usage, the literature, etc" Frank Kastenholz. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8859102456.20200861.HEILNER_K] <1988060915245500> From: HEILNER_K@VAXC.STEVENS-TECH.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Wanted DELNIs Message-ID: <8859102456.20200861.HEILNER_K> Date: 9 Jun 88 15:24:55 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 13 We have a large(50) DELNI population. It would be nice if DEC would put some LEDs on the DELNI and the DEMPR. As for the reliability of the DELNI, I have had only good experiences with the product. Our experience has been when a DELNI fails it tends to fail a port at a time as opposed to the whole unit going down at one time. Keith Heilner Network Coordinator Stevens Institute Heilner_k@sitvxb Heilner_k@vaxb.stevens-tech.edu ------------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806091540.AA02646@braden.isi.edu] <1988060915405900> From: braden@VENERA.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Point-to-Point links Message-ID: <8806091540.AA02646@braden.isi.edu> Date: 9 Jun 88 15:40:59 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 32 Here's an example from Proteon. Proteon added the feature of NOT using IP subnets on serial links to Rel 7.4 (circa last summer). Prior to 7.4 you HAD to use a subnet. What do you give up? Here's what Proteon said in the 7.4 release notes: o can't ping the interface o cannot run EGP over the interface o cannot boot from that interface (serial line boot added rel 8.0) The problem with omitting an IP subnetted address from a serial interface has to do with identifying that interface. Proteon says that "for routing decisions, such a serial line [no IP addr] is considered to be a part of each subnetted network present in the gateway." Of course, the big lose with IP addresses is "wasting" all those two node subnets. Use addresses for finer control. Don't use them if you don't have subnets to "waste". However, you should design the option in for your customers. Kent England, Boston U I would have thought that the Network Monitoring protocol used to monitor and control the gateway would require, or at least want, an IP address for every gateway interface. What does Proteon do about this problem... or is it just a customer's problem? Bob Braden ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806110819.AA10234@ucbvax.Berkeley.EDU] <1988060917250000> From: mja@TWG.COM (Mike Anello) Newsgroups: comp.protocols.tcp-ip Subject: RE: streams based tcpip vs character based tcpip Message-ID: <8806110819.AA10234@ucbvax.Berkeley.EDU> Date: 9 Jun 88 17:25:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 9 >Mike - Being unwilling to show my ignorance to the whole tcp-ip list, >I will ask you: what is the difference between streams vs character ? >Does it have to do with System V vs 4.3 bsd ? Regards - Craig The difference is that streams based tcpip is built with stream drivers and modules where character based tcpip is built with UNIX V or BSD character device drivers. Two different technologies. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806110829.AA10728@ucbvax.Berkeley.EDU] <1988060919290100> From: cire@CLASH.CISCO.COM Newsgroups: comp.protocols.tcp-ip Subject: Re: Convert /etc/hosts to RR format pgm anyone? Message-ID: <8806110829.AA10728@ucbvax.Berkeley.EDU> Date: 9 Jun 88 19:29:01 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 64 >> Date: Thu, 09 Jun 88 09:33:04 EDT >> From: Frank Kastenholz >> Subject: Re: Convert /etc/hosts to RR format pgm anyone? >> To: der Mouse >> Cc: tcp-ip@sri-nic.arpa >> Good start! I've added some corrections to the heirarchy. It strikes me that this kind of info would be reasonable in an intro of some kind to IP. >> This sounds to me like there is some confusion over the meaning of >> some of the terms used (which, to the best of my limited knowledge, >> have never been fully codified - perhaps an addendum to the Assigned >> Numbers RFC is in order - "Assigned Abbreviations and Terms and Their >> Meanings"). >> I'd recommend Douglas Comer's book 'Internetworking with TCP/IP, Principals, Protocols, and Architecture' or Andrew Tanenbaum's book 'Computer Networks'. Both include a glossary at the back with very succinct definitions of most everything you mention below. >> As I understand things the "hierarchy" of terms in use in the Internet >> protocols (among others) are: >> Here is perhaps a better set of definitions: (some of these are essentially pulled from Comer's book). FRAME - The unit of information encapsulated for transmission on physical media or network. FRAGMENT - a unit that the IP layer breaks a DATAGRAM into if necessary for transmission across networks that can not handle the size of the entire DATAGRAM. A FRAGMENT has essentially the same IP header as the original DATAGRAM. DATAGRAM - The basic unit of information dealt with by the IP layer. This is what is sent across the TCP/IP Internet. It may be broken into FRAGMENTS if a network can not handle the DATAGRAM's size. SEGMENT - the basic unit that TCP deals with. A segment consists of a block of bytes that arrive or are sent at one time. These bytes make up part of stream of bytes. Information in the segment identifies where in the stream these bytes exist. A segment will be passed to the IP layer as one or more DATAGRAMS for transmission by that layer. PACKET - the basic unit of information sent across a packet-switching network. It's exact meaning is dependent upon the context. BUFFER - an implementation detail that is used for passing blocks of information including DATAGRAMS to the layers for processing. -c cire|eric Eric B. Decker cisco Systems Menlo Park, California email: cire@cisco.com uSnail: 1360 Willow Rd., Menlo Park, CA 94025 Phone : (415) 326-1941 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [23399@oliveb.olivetti.com] <1988060920135300> From: jerry@oliveb.olivetti.com (Jerry Aguirre) Newsgroups: comp.protocols.tcp-ip Subject: Re: Wanted: Delni Summary: Cabletron has a rack mount kit Keywords: DELNI DEMPR Cabletron Message-ID: <23399@oliveb.olivetti.com> Date: 9 Jun 88 20:13:53 GMT References: <8806070434.AA09530@infidel.lanl.gov.ARPA> <10269@ncc.Nexus.CA> Reply-To: jerry@oliveb.UUCP (Jerry Aguirre) Organization: Olivetti ATC; Cupertino, Ca Lines: 60 In article <10269@ncc.Nexus.CA> lyndon@ncc.UUCP (Lyndon Nerenberg) writes: >In article <8806070434.AA09530@infidel.lanl.gov.ARPA> peter%infidel@LANL.GOV (Peter Ford) writes: >>We have a cabletron DELNI clone which is better than the old DELNIs >>since it is loaded with lights which have helped in network debugging. > >Great! My question is: Do you have the rack mounting kit for >the DELNI? Some of us like the lights mounted in the rack where >everyone can see them. When our DEC DELNI arrived I tried to mount it in a rack along with the DEC LAT terminal servers. They both come in a plastic case intended for setting on a table or such. To rack mount them you remove the plastic case and inside there is a metal case that will fit into a rack. (We still have those empty plastic cases taking up room on a shelf.) The LAT units installed with no problems but when I went to do the same for the DELNI the brackets didn't line up with anything. A little investigation showed that the brackets included with the DELNI were the ones for a LAT. I thought this was just a fluke but others on the net have complained that this always happens. There is some screwup with the part number so that even if you order the part for the DELNI you get the bracket for the LAT. According to one source the only way to get the right part is to order the DELNI in one of DECs wiring cabinets. Meanwhile our DELNI lays on the bottom of the rack. The Cabletron MT-800 has a rack mount option (RMK-1000) that lists for $75. It is a little bulky for my tastes. It is actually a shelf that the MT-800 bolts to, but it works well and looks nice from the front. (You want to be able to see those blinky lights.) The MT-800 also comes (standard) with a bracket in the back that you can tie-wrap all the cables to, including the power cord. Those of you familiar with transceiver connections and their slide-lock fasteners will understand the importance of strain-relief. The bracket and tie-wrap combination is so effective that you can move the other end of the cable arround and it wont pull out of the MT-800 even if the slide-lock isn't fastened. The Cabletron MR-9000 thin ethernet multiport repeater (DEMPR clone) has the same chassis as the MT-800 and uses the same rack mount kit. The same strain relief bracket is included but I have not found it necessary for BNC connections. It does help for the power cord and transceiver connection. Cabletron has always shiped my orders very fast, usually in a couple of days after we generate the PO. Now for the bad news. I had one of the MR-9000s fail. No big deal, it had been running for 6 months and I expect some failures. (Actually I also had a transceiver on a different floor fail at or about the same time. I suspect some kind of electrical spike.) But I didn't find Cabletron very responsive; it took several days and many phone calls to get me the RMA number and the repair took over a week. To be honest I wasn't really pushing or screaming for immediate help. I had borrowed another unit and my network was working again the same day. Perhaps if I had told them I was off the air they would have arranged a loaner. What was disturbing was that I have written a PO and received a new unit from them in half the time it took to get an in-warranty repair. I finally decided to just order a spare unit. Jerry Aguirre ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12405155411.31.VAF@Score.Stanford.EDU] <1988060921535400> From: VAF@SCORE.STANFORD.EDU (Vince Fuller) Newsgroups: comp.protocols.tcp-ip Subject: Re: DDN support for CMU-TEK TCP/IP Message-ID: <12405155411.31.VAF@Score.Stanford.EDU> Date: 9 Jun 88 21:53:54 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 12 You might want to re-send your query to the CMU-TEK-TCP mailing list, which is reachable as "CMU-TEK-TCP@C.CS.CMU.EDU". This list is mostly made up of users of the CMU-TEK package but is also read by the CMU-TEK maintainers. Vince Fuller, Stanford Networking (former implementor of CMU-TEK-TCP) P.S. To partially answer your question - no such interface was ever written at CMU while I was working on the project and I suspect that it still true today. It is possible, however, that someone outside of CMU has done some work on this (I seem to remember reading something about it, in fact). ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [7080008@eecs.nwu.edu] <1988060922110600> From: morrison@eecs.nwu.edu (Vance Morrison ) Newsgroups: comp.protocols.tcp-ip Subject: SLIP or TCP/X.25 for VMS???? Message-ID: <7080008@eecs.nwu.edu> Date: 9 Jun 88 22:11:06 GMT Organization: Northwestern U, Evanston IL, USA Lines: 15 Hello, I need some help We are trying to connect two VAXes runing VMS to our campus TCP/IP internet. Unfortuately, These computers are not that physically close to each other (> 500 ft) or to the rest of campus (> 3000 ft). Luckily, the data needs of these people are quite modest (mail and a few telnet's and FTP's), so we were thinking about X.25 or SLIP. So my question to you is, does anyone know about TCP/IP software for VMS that will interface to X.25 or a serial port (SLIP). Does CMU make such a thing?? Any help will be greatly appreciated. Vance Morrison Northwestern University morrison@accuvax.nwu.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [3c910032.8a06@apollo.uucp] <1988061000450000> From: brezak@apollo.uucp (John Brezak) Newsgroups: comp.protocols.tcp-ip Subject: Need rfc 877 Message-ID: <3c910032.8a06@apollo.uucp> Date: 10 Jun 88 00:45:00 GMT Organization: Apollo Computer, Chelmsford, Mass. Lines: 9 Could someone email RFC 877 to me. Thanx in advance... -- ============================================================================================ John Brezak UUCP: {mit-erl,yale,uw-beaver}!apollo!brezak Apollo Computer Inc. apollo!brezak@eddie.mit.edu Chelmsford, MA Phone: (617) 256-6600 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806101321.AA00212@zaphod.ncsa.uiuc.edu] <1988061013215000> From: timk@NCSA.UIUC.EDU (Tim Krauskopf) Newsgroups: comp.protocols.tcp-ip Subject: Re: 3c501/503 programming info... Message-ID: <8806101321.AA00212@zaphod.ncsa.uiuc.edu> Date: 10 Jun 88 13:21:50 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 15 As I understand it, the $1000 ($999 actually) is for the 3Com 3L programming library of drivers for all of their boards - forms a common calling interface which is also compatible with NETBIOS and 3+, etc. Needless to say, I didn't come up with the $1000 - if you get past the sales critters there ARE marketing and engineering people at 3Com with the real Engineering reference specs for the hardware that you might get a copy of. I hope someone at 3Com is listening, because not everyone has $1000 to throw at one company when there are so many good competitors out there.... Tim Krauskopf timk@ncsa.uiuc.edu (ARPA) National Center for Supercomputing Applications (NCSA) University of Illinois, Urbana-Champaign ----MESSAGE-END---- ----MESSAGE-BEGIN---- [5667@dcatla.UUCP] <1988061013381400> From: dnwcv@dcatla.UUCP (William C. VerSteeg) Newsgroups: comp.protocols.tcp-ip Subject: Vendor Support of Source Quench Message-ID: <5667@dcatla.UUCP> Date: 10 Jun 88 13:38:14 GMT Reply-To: dnwcv@dcatla.UUCP (William C. VerSteeg) Organization: DCA Inc., Alpharetta, GA Lines: 23 I recently spoke with a vendor of host based TCP/IP software. I was trying to determine the company's support of ICMP Source Quench. The package they sell ignores ICMP Source Quench messages. It doesn't lower offerred traffic when receiving a source quench and doesn't send a source quench when its buffer space is running out. I requested a fix for this problem. We discussed some of the ongoing work in the field of congestion control and its impact on the usability of source quench mechanisms. He informed me that the company had no plans to implement source quench support due to the large number of implementations that also ignore source quench. This brings me to my point. How many of the currently popular packages handle Source Quench in a reasonable fashion? Is it worth my efforts to chase this vendor and force him to conform to specifications or is it a mute point due to a general lack of conformance to the ICMP spec by most of the available packages? We definately require a traffic limiting mechanism. I don't know if the ongoing congestion control work being done obviates the need for source quench support, but I doubt that it does. Bill VerSteeg ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988061014423800> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Sat, 11 Jun 88 21:17:11 PDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA22990; Sat, 11 Jun 88 20:03: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: 10 Jun 88 14:42:38 GMT From: nuchat!texhrc!cml@uunet.uu.net (Chris Lonvick) Organization: Texaco Houston Res. Cntr Hou, Tx Subject: Re: TCP/IP in MVS? Message-Id: <243@texhrc.UUCP> References: <353@pacbell.PacBell.COM> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa In article <353@pacbell.PacBell.COM>, david@pacbell.PacBell.COM (David St.Pierre) writes: > I'm trying to determine whether or not there are any commercial > products which support TCP/IP on MVS, specifically for the purposes of > FTP.... > We looked at many solutions to link things to the MVS computers. At first we were just concerned with our VAXen running VMS. We found FlexLINK, Interlink and FlexComm. Contact IBM if you wish to look at any of these. To actually get TCP/IP from an Ethernet talking to an MVS processor, you will have to either go with some solution that IBM has (bad option) or with one of the third party solutions. The cadillac is the Sparticus products (a division of Fibronics.) It was very expensive last time I looked at it. There is also another startup company (whose name I have forgotten) and Mitek. We will be implementing the Mitek solution in the next few weeks. The telephone number for Fibronics is (617)-778-0700. for Mitek, contact Tim Hogan at (214)-490-4090. It sounds, though, that you just want file transfer. This may be accomplished through several proprietary networks such as Network System's HYPERChannel. This is also a very expensive solution. If you are just transferring text files, I would recommend that you build your own solution. Take one of your old XTs lying around and put an IRMA (or compatable) card in it along with an Ethernet card. Buy an API (Application Programming Interface) to emulate keystrokes through the IRMA software and make sure that your TCP/IP software comes with an API. As far as I know, only Bridge Communications PCS/1 has this capability. Set up user accounts on the MVS system and on some TCP/IP node. Now comes the tricky part: write your program on the PC to first log into the MVS system. Grab any files that are there and pull them down to the PC. Close the connection (or not if you prefer). Open an FTP connecetion to the TCP/IP node and push all the files to the directory there. Pull back any files that you did not put there. Close you FTP connection and reopen the MVS connection. Put files there that you pulled from the TCP node. Go to step one and continue ad infinitum. If you want to get real fancy, you could write front-ends for the MVS and TCp node to put headers on the files and distribute them to final destinations. Now, to transfer files, just put them in one directory on one machine and they will appear on the other machine. Chris Lonvick Texaco EPTD Disclaimer: These opinions are my own and don't reflect the position of the company. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806101444.AA29133@mitre.arpa] <1988061014441300> From: goldstei@MITRE.ARPA (Steve Goldstein) Newsgroups: comp.protocols.tcp-ip Subject: YANB--Yet Another Networking Book Message-ID: <8806101444.AA29133@mitre.arpa> Date: 10 Jun 88 14:44:13 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The MITRE Corp., Washington, D.C. Lines: 18 Folks, I hesitate to speak up among all you august authorities, but in all the chatter back ond forth about references on communications books, I have not noted mention of Stallings' Second Edition "Data and Communications": William Stallings, Ph.D., "Data and Computer Communications--Second Edition" Macmillan Publishing Company, New York, 1988; ISBN 0-02-415451-2; 653 pp.; $51.35 at the Univ of Colorado Book Store in March '88. Seems to do a magnificent job of covering the various protocols in a balanced and comparative fashion. MAY be a condensation of his three-volume set; but as I haven't gone through the set, I really do not know. At any rate, I find this chock-full of the explanations I've been searching for and a most useful extension beyond the world of TCP/IP. Material is presented at an introductory level for the first-time inquirer, and it is quite readily understandable. Still, there's considerable depth. So, if you want a good view of the world beyond Comer and can only have one additional book, I'd vote for Stallings' Second Edition. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806101547.AA00802@gateway.mitre.org] <1988061015471100> From: gomberg@gateway.mitre.ORG (Dave Gomberg) Newsgroups: comp.protocols.tcp-ip Subject: DCA R&D Planning Message-ID: <8806101547.AA00802@gateway.mitre.org> Date: 10 Jun 88 15:47:11 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 43 The MITRE Corporation is assisting the Defense Communications Agency (DCA) in planning for Internet Research and Development (R&D) activities for the FY90-FY92 period (i.e., October 1990-September 1992). Although the focus is more likely to be on D than R for DCA funded projects, there is interest in R projects that might be pursued through other than DCA funding. One of the reasons D will dominate R is that DCA would like to fund projects that will have an operational impact within a year or two of project completion. We are seeking suggestions for R&D activities that can realistically be pursued in the FY90-FY92 period. Suggested activities may or may not be ones in which you or your organization would like to participate. By replying to me directly (not to this list) you may be assured that your ideas will not be revealed outside DCA until the Government issues an RFP and that your unique inputs will be credited/acknowledged to DCA. Although your suggestions may be informally presented, they should address the following to the extent possible: - description of the Internet problem to be addressed and why it is important - suggested approach to solving the problem - estimate of resources required (staff years over some period) Note that the kinds of problems of interest are broad in scope. Not only are "network-centric" problems, such as congestion control of interest, but problems normally thought of as host responsibilities are of interest also. Some of you may recognize an intersection of this request and the IETF Internet Problem/Description Form recently circulated by Phill Gross. If you have already responded to that, you need not duplicate the effort. This request is being sent to a wider audience and is narrower in focus. Apologies in advance to those of you who receive multiple copies of this message. Thanks for your help and cooperation. David A. Gomberg The MITRE Corporation 7525 Colshire Drive McLean, VA 22102 (703)-883-6322 gomberg@gateway.mitre.org ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1988.6.10.16.20.58.Eugene.Hastings@morgul] <1988061016245200> From: Eugene.Hastings@MORGUL.PSC.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Experience with Xyplex Terminal Servers? Message-ID: <1988.6.10.16.20.58.Eugene.Hastings@morgul> Date: 10 Jun 88 16:24:52 GMT References: <878@wright.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 8 We had a demo of a Xyplex Terminal Server. It does IP, but it does not do DECNET, but something similar to, but incompatible with DEC's LAT (Ethernet terminal server transport, which requires physical ethernet connectivity). They swore that they would be doing real LAT Real Soon Now, so we said "Call us back when it does." They do require a host to download from, DEC-style, even for the telnet code. Gene ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806101225.aa19161@Huey.UDEL.EDU] <1988061016255600> From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: RIP vs. HELLO Message-ID: <8806101225.aa19161@Huey.UDEL.EDU> Date: 10 Jun 88 16:25:56 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 30 Kent, So far as I know, the Hellospeak (or whatever else it may be called) routing scheme has been implemented in full only for the fuzzballs, about two dozen of which are skulking about the Internet now. Partial implementations have been done for the cisco router and gated daemon for Unix 4.3bsd. A lot of work went into the design and refinement of Hellospeak in such rugged environments as the present NSFNET Backbone, but as in many other cases like this, the sheer weight of Unix ubiquity and availability of RIP will undoubtably prevail. I would argue and expect many RIP implementors to agree that neither Hellospeak nor RIP are suitable for use on an extended WAN topoplogy and that link-state algorithms such as used in the new NSFNET Backbone are more appropriate. As for enhancements to the traditional Bellman-Ford algorithms, such as hold-down, split-horizon and so forth, there is considerable disagreement within the RIP community as to whether and how to do these things and I suspect agreement will never be reached. These things and some other tricks have in fact been done for Hellospeak, but have not been thoroughly documented and probably will not be replicated. The NSFNET Backbone fuzzbunch belongs to NSF; however, by agreement Merit & Co. is entitled to them should they choose to exercise that option. However, I doubt very much IBM wants to get into the fuzzball maintenance business, to say the least! Present plans are to pull down the serial lines at the end of July, which will leave them isolated on their local Ethers. Personally, I would like to see the fuzzies remain in place for use as remote observation platforms and as time servers for the various regional nets. It is not clear whether the regionals will agree to support this (hardware maintenance) or not. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [3950004@wdl1.UUCP] <1988061017545200> From: holmes@wdl1.UUCP (Randy D. Holmes) Newsgroups: comp.protocols.tcp-ip Subject: Multiple connects to ARPA Message-ID: <3950004@wdl1.UUCP> Date: 10 Jun 88 17:54:52 GMT Lines: 19 I was wondering if someone might be able to inform me of any issues which might arise from having two connections to the arpanet. Our network covers several geographic locations, with our arpa connection being on the east coast. We are looking at the possibility of obtaining a second connection on the west coast. Is this a plan which is generally excepted? are the arpa routers capable of finding the easiest way in to our net? and how hard would be to set up our net to find the easiest way to an outside net. We are using several cisco gateways scattered about, with a direct line connecting our east coast site, and our west coast site. Any insight would be appreciated. Randy D. Holmes holmes1@Ford-wdl1.ARPA Ford Aerospace Corporation 3939 Fabian Way Palo Alto CA 94303 (415) 852-7125 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988061019584900> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Sat, 11 Jun 88 11:11:09 PDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA16197; Sat, 11 Jun 88 10:15: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: 10 Jun 88 19:58:49 GMT From: cca!mirror!rayssd!raybed2!linus!heart-of-gold!jc@husc6.harvard.edu (John M Chambers) Organization: Mitre Corp, Bedford, MA, USA Subject: Re: Getting started Message-Id: <159@heart-of-gold> References: <192@execu.EXECU> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa In article <192@execu.EXECU>, dewey@execu.EXECU (dewey henize) writes: > Ok, I'm obviously the slow one here, but... For some of us, this world of > TCP/IP and networking is a bit tough to pick up. I didn't have a chance > to learn about it in college so its been strictly OJT. Would anyone else > out there who has been in this position be willing to send or post a good > solid intro to mid level reading list? > For a more specific request, I'd like to ask if anyone knows of a set of prototype client/server programs for TCP and UDP. There's no shortage of reading matter on the subject, but I've yet to see anything that tells me how to write the code correctly. You'd think that, since this is something that's supposed to make networking easy and painless for all of us, that there'd be some examples of how it's done. In reality, I (like everyone I talk to) find it all black magic, and my programs just sorta work some of the time, and other times fail in mysterious ways. In particular, it seems very hard to figure out how to pass messages correctly via UDP, though it is supposed to be easy. Note that I'm NOT looking for yet another theoretical explanation of why TCP/UDP/IP are so wonderful. I've got those. I'm looking for examples of correct code. I don't got those. "RTFM" isn't much help. I've read lotsa manuals, and frankly, they're all crummy. (If you have an exception, I'd love to hear about it.) Note also that I haven't said what machine(s) I'm running on. If you really want to know, I'll tell you (and it's a long list). But it seems to me that if these protocols are at all what they are hyped up to be, it shouldn't much matter what sort of machines I have. The protocols are supposed to be very well standardized, aren't they? Well, then, I oughta be able to use them in exactly the same way on, say, a Sun and a MtXinu and a Xenix and a SysV and a ... machine, shouldn't I? Has this all perhaps been posted somewhere that I haven't seen? [Boy, what a dreamer! ;-] -- From: John Chambers From ...!linus!!heart-of-gold!jc (John Chambers) Phone 617/217-7780 [Send flames; they keep it cool in this lab :-] ----MESSAGE-END---- ----MESSAGE-BEGIN---- [10286@ncc.Nexus.CA] <1988061020312600> From: lyndon@ncc.Nexus.CA (Lyndon Nerenberg) Newsgroups: comp.protocols.tcp-ip Subject: DELNI Rack Mount Kits Summary: But, are these kits still available? Message-ID: <10286@ncc.Nexus.CA> Date: 10 Jun 88 20:31:26 GMT References: <8806070434.AA09530@infidel.lanl.gov.ARPA> <10269@ncc.Nexus.CA> <23399@oliveb.olivetti.com> Reply-To: lyndon@ncc.nexus.ca (Lyndon Nerenberg) Organization: Nexus Computing Inc. Lines: 32 In article <23399@oliveb.olivetti.com> jerry@oliveb.UUCP (Jerry Aguirre) writes: >In article <10269@ncc.Nexus.CA> lyndon@ncc.UUCP (Lyndon Nerenberg) writes: >When our DEC DELNI arrived I tried to mount it in a rack along with the >DEC LAT terminal servers. They both come in a plastic case intended for >setting on a table or such. To rack mount them you remove the plastic >case and inside there is a metal case that will fit into a rack. (We >still have those empty plastic cases taking up room on a shelf.) [ ... ] >The LAT units installed with no problems but when I went to do the same >for the DELNI the brackets didn't line up with anything. A little >investigation showed that the brackets included with the DELNI were the >ones for a LAT. I'm not sure if you're trying to imply that the mounting brackets are part of the standard DELNI, or if you ordered them as an accessory with the DELNI. When we ordered our DELNI, a seperate part number was given for the rack mounting kit (in the installation manual). When I called back to order this kit, much confusion resulted. I finally received a phone call from the distributor (about a week later) who said the rack mounting kit was no longer available from DEC. So... If I was to crack the DELNI open would I find the necessary parts inside? If not, does anyone know if DEC still supplies these brackets? -- {alberta,utzoo,uunet}!ncc!lyndon lyndon@Nexus.CA ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1710@lll-lcc.aRpA] <1988061022150700> From: wiltzius@lll-lcc.aRpA (Dave P. Wiltzius) Newsgroups: comp.protocols.tcp-ip Subject: IP Security Message-ID: <1710@lll-lcc.aRpA> Date: 10 Jun 88 22:15:07 GMT Reply-To: wiltzius@lll-crg.UUCP (Dave P. Wiltzius) Organization: CRG, Lawrence Livermore Labs Lines: 12 I posted a similar request to this, but received no replies regarding DEC and SUN. So, can anyone inform me of DEC's and SUN's plans for the IP Security option? Any plans to implement it as specified in RFC 1038? We have lots of Ultrix VAXes and seemly countless SUNs and we would really like to use the IP Security option soon. Thanks much. (PS. Selden, tried to Email summary to you but mailer failed. Any other address to try?) Dave (wiltzius@lll-lcc.llnl.gov) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806110104.aa00736@Huey.UDEL.EDU] <1988061105044000> From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Vendor Support of Source Quench Message-ID: <8806110104.aa00736@Huey.UDEL.EDU> Date: 11 Jun 88 05:04:40 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 11 Bill, At least the new Jacobson/Karels TCP does listen to source-quench and the present NSFNET Backbone system does generate them. According to good-faith info, the new NSFNET Backbone should generate source-quench in a repsonsible way within the next few months. I would suggest you beat on your vendor with this message. I should point out the present system is a far way from optimally tuned and that ongoing research here at UDel shows this tuning may not be easy; however, the handles are there and our experience shows they do work. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12405589788.40.AI.CLIVE@MCC.COM] <1988061113400000> From: AI.CLIVE@MCC.COM (Clive Dawson) Newsgroups: comp.protocols.tcp-ip Subject: Re: DELNI Rack Mount Kits Message-ID: <12405589788.40.AI.CLIVE@MCC.COM> Date: 11 Jun 88 13:40:00 GMT References: <10286@ncc.Nexus.CA> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 5 For years we have obtained our DELNI mounting kits from Radio Shack. They sell some sort of universal car stereo mounting kit which works very well. Clive ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1098@rel.eds.com] <1988061202055400> From: bob@rel.eds.com (Bob Leffler) Newsgroups: comp.protocols.tcp-ip Subject: Re: DELNI Rack Mount Kits Summary: delni's Message-ID: <1098@rel.eds.com> Date: 12 Jun 88 02:05:54 GMT References: <8806070434.AA09530@infidel.lanl.gov.ARPA> <10269@ncc.Nexus.CA> <10286@ncc.Nexus.CA> Organization: Electronic Data Systems, Troy, MI Lines: 32 In article <10286@ncc.Nexus.CA>, lyndon@ncc.Nexus.CA (Lyndon Nerenberg) writes: > In article <23399@oliveb.olivetti.com> jerry@oliveb.UUCP (Jerry Aguirre) writes: > >In article <10269@ncc.Nexus.CA> lyndon@ncc.UUCP (Lyndon Nerenberg) writes: > I'm not sure if you're trying to imply that the mounting brackets are > part of the standard DELNI, or if you ordered them as an accessory > with the DELNI. .... > phone call from the distributor (about a week later) who said the > rack mounting kit was no longer available from DEC. > > So... If I was to crack the DELNI open would I find the necessary > parts inside? If not, does anyone know if DEC still supplies these > brackets? Last fall I installed about a dozen Dec DELNI's at my site. What I was told kinda amazed me. DEC sells the brackets as an option in Europe for the standard 19" rack, but not in the US. In the US, they only come with the DEC cabinet/rack. No, if you take off the plastic case, all you'll see is two holes in the side of the DELNI to mount the missing "ears". Fortunately since my customer site where this equipment is located, happens to be an Engineering Test facility for an Automotive company, it was no big deal for us to fabricate the parts ourselves. I would have still prefered to buy them from DEC. -- Bob Leffler - EDS, GM Truck & Bus Account (313)456-5375 bob@rel.eds.com or {uunet!edsews, rutgers, umix}!rel!bob Opinions expressed may not be those of my employer. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988061204451200> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Sun, 12 Jun 88 02:49:23 PDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA25592; Sun, 12 Jun 88 00:41:29 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 Jun 88 04:45:12 GMT From: mandrill!edguer@tut.cis.ohio-state.edu (Aydin Edguer) Organization: CWRU Dept of Computer Engineering and Science Subject: network unreachable Message-Id: <2512@mandrill.CWRU.Edu> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa I am trying to understand why certain sites are unreachable from my machine. Background: I am currently at mandrill.ces.cwru.edu [129.22.16.1]. CASE.Edu used to be a CSNET site only, hooked up to relay-csnet via a leased line. It has since become a part of the NSFnet with T-1(?) links to Pittsburgh and Columbus. It was renamed CWRU.Edu. Since joining the Internet I have enjoyed using {smtp,nntp,ftp} to obtain information and sources. Recently, however, a number of sites which were reachable now return the message "network unreachable". These sites include such places as purdue.edu, uunet.uu.net, and decwrl.dec.com. Question(s): Why would sites which were reachable become unreachable like this? Is this due (perhaps) to the dismantling of the ARPAnet which I understand is taking place? What can I do to find out why they have become unreachable? What can I do to try to reach them now that my router has given up? Aydin Edguer INTERNET: edguer@mandrill.ces.cwru.edu +1 216 368 3195 (w) UUCP: {att,cbosgd,decvax,sun}!mandrill!edguer ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988061205164100> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Sun, 12 Jun 88 09:14:54 PDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA28481; Sun, 12 Jun 88 06:57:29 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 Jun 88 05:16:41 GMT From: wash08!txr98@uunet.uu.net (Timothy Reed) Organization: American Chemical Society, Washington, DC Subject: TCP-IP and UUCP Message-Id: <134@wash08.UUCP> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa I just started up our tcp-ip net between our 11/785s OK, but uucp bombs out when I try to start it up using the network. My Ultrix doc is *horrible*, and does not touch on using uucp over ethernet. My tcp-ip on our NCR towers comes with a uucp daemon to facilitate this. Is there a similar tool for ultrix, or is there something I else I'm missing? thanks... Timothy Reed ACS ..uunet!wash08!txr98 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806121521.AA27669@vax.ftp.com] <1988061215215200> From: jbvb@VAX.FTP.COM (James Van Bokkelen) Newsgroups: comp.protocols.tcp-ip Subject: Re: APIs for PC TCP/IP packages, TCP/IP for MVS Message-ID: <8806121521.AA27669@vax.ftp.com> Date: 12 Jun 88 15:21:52 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 20 In fact, most commercial TCP/IP packages for DOS can be purchased with an Applications Programming Interface of some sort. Our PC/TCP, Sun's PC/NFS, Excelan's EXOS 8051, and NRC's all have libraries that emulate Berkeley sockets, for Microsoft C. I don't know details of Bridge's offering. I think each product supports all memory models, but I don't think anyone is shipping code for 5.0 or 5.1 yet. In addition, our Developer's Kit comes with libraries that allow access to our native interface (interrupt-based, with fairly rich asynchronous facilities - our NETBIOS was written with it), as well as high-level libraries providing callable FTP, Telnet and Rlogin. Regarding the original question (TCP/IP for MVS), I believe that ACC offers one, in addition to Spartacus. Both provide FTP, Telnet (including TN3270) and SMTP. Both have UCLA MVS ancestry. Both need hardware (a front-end) sold by the vendor to actually provide the network connection. Writing your own FTP gateway on a PC would certainly be possible, particularly if it was batch mode, but I'd be cautious about such a project, because the development would take a while, and then there would be issues of reliability and maintenance... James VanBokkelen FTP Software Inc. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [4330@medusa.cs.purdue.edu] <1988061219314100> From: narten@cs.purdue.EDU (Thomas Narten) Newsgroups: comp.protocols.tcp-ip Subject: Re: network unreachable Message-ID: <4330@medusa.cs.purdue.edu> Date: 12 Jun 88 19:31:41 GMT Sender: news@cs.purdue.EDU Organization: Department of Computer Science, Purdue University Lines: 57 In article <2512@mandrill.CWRU.Edu> edguer@mandrill (Aydin Edguer) writes: >I am trying to understand why certain sites are unreachable from my machine. >Background: [...recently joined NSFnet; prior connection via CSNET..] >Question(s): > Why would sites which were reachable become unreachable like this? > Is this due (perhaps) to the dismantling of the ARPAnet which I understand > is taking place? No. Both Purdue and decwrl are still reachable via the ARPANET. > What can I do to find out why they have become unreachable? The problem is broken routing tables, and I suspect NSFnet (or its regionals). We have been unable to reach net 128.146 (ohio-state) for a week, and the same is apparently the case for 129.22. Both of these nets are reachable from NSFnet sites, but not from us. Moreover, our butterfly core gateway has routes for these nets that point to 10.4.0.14 (psc.psc.edu). Since we can ping psc.psc.edu, I conclude that we are correctly advertising routes to the core. In other words, we (Purdue and ARPANET) are managing routes correctly. By implication, NSFnet is not correctly propagating all of the routes it learns from the ARPANET. (Note that for the most part, we can reach NSFnet sites; only a handful cause trouble.) > What can I do to try to reach them now that my router has given up? Contact your regional NOC (if there is one), and if that doesn't help, call the NSFnet NOC. The following information would be of help: 1) Do you have a route to get to Purdue (either explicit or default)? For that matter, do you have routes to other sites that are on the ARPANET? Can you ping 10.0.0.37 (purdue's arpanet connection)? What about 10.4.0.14? If both of us can ping a common gateway, but not each other....... 2) Do you get ICMP unreachable messages when attempting to reach the networks in question? The best check for this is a 4.3 system with a modified ping that prints the name of the gateway that generated the ICMP message. Alternatively, one can open TCP connection to the host in question. For instance, "ftp 128.10.2.1" will abort with a "network unreachable" error if ICMP unreachables are returned; "connection timed out" on the other hand, indicates that packets are going into a black hole. This works on 4.3 BSD (running the latest tcp/ip code) and Sun OS systems. -- Thomas Narten narten@cs.purdue.edu or {ucbvax,decvax,ihnp4}!purdue!narten ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806122208.AA06949@fermi.cray.com] <1988061222084400> From: hrp@fermi.CRAY.COM (Hal Peterson) Newsgroups: comp.protocols.tcp-ip Subject: Getting started (universal TCP/IP samples) Message-ID: <8806122208.AA06949@fermi.cray.com> Date: 12 Jun 88 22:08:44 GMT References: <159@heart-of-gold> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 14 You ask for a universal sample client/server pair. The trick is the ``universal'' part, in the face of zillions of hardware architectures, implementation languages, and interfaces to the protocols and OS. A change in any ONE of those three parameters can cause enormous porting headaches for any non-trivial program. The best you can do is either a vague and generic description of, say, the sequence of actions an ULP must use to handshake with TCP (which you can find in the RFCs) or a specific example that's reliably good for one kind of box running one flavor of OS/protocol interface and is written on one source language. Neither of those is what you want. Hal Peterson / Cray Research / 1440 Northland Dr. / Mendota Hts, MN 55120 hrp%hall.CRAY.COM@umn-rei-uc.ARPA ihnp4!cray!hrp (612) 681-3145 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806122233.AA02798@Larry.McRCIM.McGill.EDU] <1988061222332600> From: philipp@LARRY.MCRCIM.MCGILL.EDU (Philip A. Prindeville) Newsgroups: comp.protocols.tcp-ip Subject: Re: Convert /etc/hosts to RR format pgm anyone? [unrelated] Message-ID: <8806122233.AA02798@Larry.McRCIM.McGill.EDU> Date: 12 Jun 88 22:33:26 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 26 FRAME - lowest level of bits/bytes. One speaks of Ethernet Frames, etc A FRAME has ONE data link header (e.g. Ethernet header). FRAGMENT - the thing that IP spits out to the data link driver. Each FRAGMENT has ONE IP header. A FRAGMENT may be split into multiple FRAMES by the lower layers. Not quite. A DATAGRAM becomes fragmented (in FRAGMENTS, of course) so that each will fit into a FRAME. The whole purpose of the MTU and fragmentation is to avoid lower level fragmentation and reassembly. The only exception to this is X.25 where you have complete-packet-sequences (but since X.25 is reliable, and in order, this doesn't present a problem). Under LAN technologies (ARCNET, PRONET, Ethernet, Token Ring, etc) 1 FRAGMENT == 1 FRAME. [ ... ] DATAGRAM - this is also the 'larger' thing that IP tries to send. A DATAGRAM USUALLY has a one to one relationship with a SEGMENT It may be broken up (fragmented) into a number of FRAGMENTS by IP before being sent through the data link. Yes. -Philip ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806122243.AA02891@Larry.McRCIM.McGill.EDU] <1988061222431500> From: philipp@LARRY.MCRCIM.MCGILL.EDU (Philip A. Prindeville) Newsgroups: comp.protocols.tcp-ip Subject: RE: streams based tcpip vs character based tcpip Message-ID: <8806122243.AA02891@Larry.McRCIM.McGill.EDU> Date: 12 Jun 88 22:43:15 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 14 The difference is that streams based tcpip is built with stream drivers and modules where character based tcpip is built with UNIX V or BSD character device drivers. Two different technologies. Actually, BSD doesn't use character device drivers in the traditional sense. They use a different approach, with a network interface which provides a dispatch table (somewhat like the character or block device interface). As I remember, the networking code for Version 6 UNIX did the standard device model, but I forget the details. (Their might be an RFC on it.) -Philip ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988061303210000> Received: from RELAY.CS.NET by SRI-NIC.ARPA with TCP; Mon, 13 Jun 88 05:47:55 PDT Received: from helios.northeastern.edu by RELAY.CS.NET id aa04447; 13 Jun 88 8:32 EDT Received: from nuhub.acs.northeastern.edu by helios.northeastern.edu id aa08997; 13 Jun 88 8:28 EDT Date: Mon, 13 Jun 88 08:21 5 From: "I am only an egg." Subject: Cisco terminal servers? To: tcp-ip@SRI-NIC.ARPA X-VMS-To: TCP-IP Hello. I'm looking for information. I'm told Cisco makes TELNET terminal servers. This I didn't know. Is it true? Are they good (I know they make very good routers)? Do they do the WHOLE standard and not just the mandatory parts (i.e. do they do things like Interrupt, Abort etc like UNIX TELNET)? What's the failure rate? What are the common failure modes? Do they diagnose easily? Can their parameters, i.e. port characteristics and IP characteristics, be changed from a central location? Does it burn up what gets plugged into it? What's the software complexity? Is it ROM based, does it load from disk or is it downlined? How is Cisco at repair and support? Anything else you can think of would be helpful. I'll summarize the results for the net if anyone wants it. Thanks much. Chris Johnson Northeastern University. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806150420.AA20750@ucbvax.Berkeley.EDU] <1988061308160000> From: JOHNSON@nuhub.acs.northeastern.EDU ("I am only an egg.") Newsgroups: comp.protocols.tcp-ip Subject: Cisco terminal servers? Message-ID: <8806150420.AA20750@ucbvax.Berkeley.EDU> Date: 13 Jun 88 08:16:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 20 Hello. I'm looking for information. I'm told Cisco makes TELNET terminal servers. This I didn't know. Is it true? Are they good (I know they make very good routers)? Do they do the WHOLE standard and not just the mandatory parts (i.e. do they do things like Interrupt, Abort etc like UNIX TELNET)? What's the failure rate? What are the common failure modes? Do they diagnose easily? Can their parameters, i.e. port characteristics and IP characteristics, be changed from a central location? Does it burn up what gets plugged into it? What's the software complexity? Is it ROM based, does it load from disk or is it downlined? How is Cisco at repair and support? Anything else you can think of would be helpful. I'll summarize the results for the net if anyone wants it. Thanks much. Chris Johnson Northeastern University. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988061309010800> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Mon, 13 Jun 88 20:28:19 PDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA16053; Mon, 13 Jun 88 16:11:31 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 Jun 88 09:01:08 GMT From: chris@mimsy.umd.edu (Chris Torek) Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742 Subject: Re: Getting started Message-Id: <11935@mimsy.UUCP> References: <192@execu.EXECU>, <159@heart-of-gold> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa In article <159@heart-of-gold> jc@heart-of-gold (John M Chambers) writes: >... I'm looking for examples of correct code. >Note also that I haven't said what machine(s) I'm running on. If you really >want to know, I'll tell you (and it's a long list). But it seems to me that >if these protocols are at all what they are hyped up to be, it shouldn't much >matter what sort of machines I have. ... This is sort of like saying, `I want to know how to install the fuel filter, but I will not say what kind of car I have.' One fuel filter may fit quite a few cars, but the location of the appropriate hose is different on each. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988061309330000> Received: from CORNELLC.CCS.CORNELL.EDU by SRI-NIC.ARPA with TCP; Mon, 13 Jun 88 11:52:27 PDT Received: from SSCvax.McMaster.CA by CORNELLC.CCS.CORNELL.EDU ; Mon, 13 Jun 88 14:50:32 EDT Date: Mon, 13 Jun 88 14:33 EST From: BEAME@SSCvax.McMaster.CA Subject: Subnet to Subnet routing To: tcp-ip@sri-nic.arpa X-VMS-To: IN%"tcp-ip@sri-nic.arpa",BEAME After reading the documents regarding subnets, I still have one outstanding question with the specifics of BSD/SUN routing from one subnet to another. Is it possible to use the following numbering scheme and provide complete inter-communication: +-------+---------------- Class B Network -----------+--------+ | | +--+--+ +--+--+ | SUN1| | SUN2| +--+--+ +--+--+ | | | +-----+ +-----+ | +--+ SUN3| | SUN4+---+ (Class C Network) | +-----+ +-----+ | | | . (Class C Network) . . . . . Where SUN1 and SUN2 are on the same Class B network (0 subnet bits) and SUN3 and SUN4 use the same Class C number, but with 4 bits used for subnetting. Will SUN1 route packets, from SUN3 destined to SUN4, to SUN2 when the destination is the same Class C number except that the subnet bits are different ? - Carl Beame Beame@McMaster.CA Beame@McMaster.BitNet ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806131225.AA02582@tut.cis.ohio-state.edu] <1988061312255100> From: tom@TUT.CIS.OHIO-STATE.EDU (Tom Easterday) Newsgroups: comp.protocols.tcp-ip Subject: network unreachable Message-ID: <8806131225.AA02582@tut.cis.ohio-state.edu> Date: 13 Jun 88 12:25:51 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 19 The problem that CWRU and Perdue is experiencing is due to two things. As of 6/7/88 the link between PSN 29 here at Ohio State and PSN 21 at Pittsburgh was deinstalled. We switched over to our NSFnet link to PSC which is a string of Proteon gateways (one here, one in Cleveland, and one in Pittsburgh). These gateways are running Proteon software rev 7.4 which has a known bug when using default routes. PSC is in the process (so I've been told) of installing rev 7.4b on these gateways which will hopefully clear things up a bit. I'm counting on it happening early this week. When the Cleveland POP gateway is upgraded CWRU should see an improvement. Maybe Gene Hastings at PSC would like to clarify things if something I've said here is incorrect. Tom Easterday The Ohio State University Instruction and Research Computer Center (614)292-4843 Email: tom@tut.cis.ohio-state.edu or tom@oscsuna.osc.ohio-state.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [15544@tut.cis.ohio-state.edu] <1988061314150500> From: karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) Newsgroups: comp.protocols.tcp-ip Subject: Re: network unreachable Message-ID: <15544@tut.cis.ohio-state.edu> Date: 13 Jun 88 14:15:05 GMT References: <4330@medusa.cs.purdue.edu> Sender: news@tut.cis.ohio-state.edu Lines: 25 In-reply-to: narten@cs.purdue.EDU's message of 12 Jun 88 19:31:41 GMT narten@cs.purdue.EDU writes: edguer@mandrill writes: >[...Case Western can't get out to the Rest of the World...] > What can I do to find out why they have become unreachable? The problem is broken routing tables, and I suspect NSFnet (or its regionals). We have been unable to reach net 128.146 (ohio-state) for a week, and ... By implication, NSFnet is not correctly propagating all of the routes it learns from the ARPANET. (Note that for the most part, we can reach NSFnet sites; only a handful cause trouble.) Case Western is behind the same gateway as Ohio State... The problem is out-of-date software at the gateways in Columbus, Cleveland, and Pittsburgh, from what the local folks managing the net connections have told me, resulting in routing glitches in large quantities and leaving us unable to find lots of places, e.g., I haven't seen utexas.edu in 8 days. The expectation/hope is that the matter will be cleared up within another day or two - an update from The Vendor is on the way. What a mess, --Karl ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1988.6.13.14.27.28.Eugene.Hastings@morgul] <1988061314402200> From: Eugene.Hastings@MORGUL.PSC.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Networks unreachable Message-ID: <1988.6.13.14.27.28.Eugene.Hastings@morgul> Date: 13 Jun 88 14:40:22 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 21 We have encountered a peculiar situation on a Proteon p4200 that has broken connectivitiy for Ohio State, Case Western Reserve, and the Universith of Michigan. The router in question is located in Cleveland and has T1 lines to those institutions, and also to the routing stub where PSC-GW and companions connect the ARPANET, NSFNET, PSCNET, and SURANET. Explicit RIP routes are propagated, plus translated (from hello) NSFNET routes, plus default. (Let me remind all and sundry that the present gated does not announce routes learned via EGP, but relies on the propagation of default.) So far, so good. Default is propagated successfully to the affected schools, but when data is sent to a net via default, the p4200 in Cleveland returns net unreachable (in fact, if the Proteon console is queried for a route to such a net, like MILNET, the response is "unable to route, reason none". This reouter has been running v7.4 of Proteon's code for some time, and it has only been very recently that it has failed. Proteon's response has been to advise us to use a bugfix, v7.4b, which we have only just received. No explanation of what may have happened to exercise this bug, or precisely what bugs have been fixed has been offered. The new version should be installed today. Gene ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1988.6.13.17.20.22.Eugene.Hastings@morgul] <1988061317254000> From: Eugene.Hastings@MORGUL.PSC.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Networks unreachable Message-ID: <1988.6.13.17.20.22.Eugene.Hastings@morgul> Date: 13 Jun 88 17:25:40 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 26 Yea, verily, and after a restart, the Router In Question passes previously barfed traffic. Thanks, and a tip of the bashed hat. Yet another reminder that confession can be good for one's productivity, let alone one's soul. Thanks again, Gene - - - - Begin forwarded message - - - - Date: Mon, 13 Jun 88 08:25:13 PDT From: dlw@violet.Berkeley.EDU (David Wasley) Message-Id: <8806131525.AA24652@violet.berkeley.edu> To: Eugene.Hastings@morgul.psc.edu Subject: p4200 bug We (actually Milo Medin) found what may be that bug when we installed 7.4 here, and Proteon generated 7.4b for us as a result. Basically, if the box had an explicit route for a net, and it became unreachable (ie 16), the box wouldn't take default but would claim the net was explicitly unreachable. There is a mailing list for p4200 users that Scott Brim started long ago: p4200@devvax.tn.cornell.edu -- some of those folks may have other bug information re 7.4. We've been using 7.4b since January. David Wasley U C Berkeley - - - - End forwarded message - - - - ----MESSAGE-END---- ----MESSAGE-BEGIN---- [5047@videovax.Tek.COM] <1988061318520300> From: dmc@videovax.Tek.COM (Donald M. Craig) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Looking for comments on the 15-pin ethernet connector Message-ID: <5047@videovax.Tek.COM> Date: 13 Jun 88 18:52:03 GMT Reply-To: dmc@videovax.Tek.COM (Donald M. Craig) Organization: Tektronix Television Systems, Beaverton, Oregon Lines: 45 I am looking for feedback on the quality and reliability of the slide latch mechanism used on the DB-15 ethernet connectors. I have used these myself for the past five years, and have discovered a number of problems with them. Additionally, various nasty remarks about these connectors have surfaced on the net from time to time. The Society of Motion Picture and Television Engineers has a standard known as RP-125 which specifies a parallel digital television interface. The connector for that interface is a 25 pin D-type (DB-25) with a slide latch like the ethernet connector. The RP-125 standard is up for revision, and the Tektronix representative submitted a note from me outlining my experience and problems with the ethernet slide latch connector. Sun Microsystems also has a representative on the RP-125 committee. He has asked the component engineer for connectors at Sun if there was any data concerning the mechanical integrity of the slide latch locking mechanism used in the ethernet connector. Here is the response: "I am the Component Engineer for connectors at Sun. In regards to your question concerning the Ethernet DB-15, these are used through out industry by the millions, in many applications. I am not aware of any significant problems with mechanical integrity of the lock, or for that matter with the connector in any aspect. If the connector is properly installed and handled in a semi-reasonable manner you should not have any problems. As far as Sun is concerned, usage of D-Sub connectors in general, that is various sizes and configurations, will probably increase. When all things are considered it often turns out to be the best way to go! Hope this helps!!!" In the face of this informal statement by Sun's component engineer, I now need data about other people's experience with the DB-15 slide latch ethernet connector. Help save another standard from the same fate! Please send your comments email to: dmc@tv.tv.tek.com or tektronix!videovax!dmc Thank you, Don Craig Tektronix Television Systems ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806131854.AA04634@chakra.cs.umd.edu] <1988061318545500> From: dheeraj@CHAKRA.CS.UMD.EDU Newsgroups: comp.protocols.tcp-ip Subject: Pointers to performance studies on TCP/IP... Message-ID: <8806131854.AA04634@chakra.cs.umd.edu> Date: 13 Jun 88 18:54:55 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 14 Hi, I am doing a performance analysis of TCP/IP by instrumenting the code and monitoring the selected connections. I am extremely interested in knowing about the other performance studies done so far. Any pointers to papers/journals/reports etcetera would be greatly appreciated. If somebody is interested, I am working on SUN3.0 modified locally to include 4.3BSD networking code. thanks in advance, -dheeraj Dheeraj Sanghi (301)-454-1516 (off) Systems Design & Analysis Group (301)-345-6024 (home) Dept of CS, U of MD., College Pk. MD -20742 dheeraj@tove.umd.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806142027.AA12732@ucbvax.Berkeley.EDU] <1988061319330000> From: BEAME@SSCvax.McMaster.CA Newsgroups: comp.protocols.tcp-ip Subject: Subnet to Subnet routing Message-ID: <8806142027.AA12732@ucbvax.Berkeley.EDU> Date: 13 Jun 88 19:33:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 32 After reading the documents regarding subnets, I still have one outstanding question with the specifics of BSD/SUN routing from one subnet to another. Is it possible to use the following numbering scheme and provide complete inter-communication: +-------+---------------- Class B Network -----------+--------+ | | +--+--+ +--+--+ | SUN1| | SUN2| +--+--+ +--+--+ | | | +-----+ +-----+ | +--+ SUN3| | SUN4+---+ (Class C Network) | +-----+ +-----+ | | | . (Class C Network) . . . . . Where SUN1 and SUN2 are on the same Class B network (0 subnet bits) and SUN3 and SUN4 use the same Class C number, but with 4 bits used for subnetting. Will SUN1 route packets, from SUN3 destined to SUN4, to SUN2 when the destination is the same Class C number except that the subnet bits are different ? - Carl Beame Beame@McMaster.CA Beame@McMaster.BitNet ----MESSAGE-END---- ----MESSAGE-BEGIN---- [881@wright.EDU] <1988061321533100> From: jsloan@wright.EDU (John Sloan) Newsgroups: comp.protocols.tcp-ip Subject: Re: DELNI Rack Mount Kits Message-ID: <881@wright.EDU> Date: 13 Jun 88 21:53:31 GMT References: <1098@rel.eds.com> Organization: Wright State University, Dayton OH, 45435 Lines: 11 Are we all talking about the same thing? In my DECDirect catalog, Winter/Spring 1988, on the same page as the DELNI (p. 113), P/N H3126-00/FP, Rack Mount Brackets, $42. I've ordered these, installed them on the DELNIs, and rack mounted them. Did one just last week. What's the deal? Am I confused? Are they no longer available? Should I be worried? -- John Sloan, The SPOTS Group Wright State University Research Building CSNET: jsloan@SPOTS.Wright.Edu 3171 Research Blvd., Kettering, OH 45420 UUCP: ...!wright!jsloan +1-513-259-1384 +1-513-873-2491 Logical Disclaimer: belong(opinions,jsloan). belong(opinions,_):-!,fail. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806140116.AA01014@orville.nas.nasa.gov] <1988061401163400> From: lekash@ORVILLE.NAS.NASA.GOV (John Lekashman) Newsgroups: comp.protocols.tcp-ip Subject: HYROUTE(TCP/IP gateway between HYPERchannel and ethernet) Message-ID: <8806140116.AA01014@orville.nas.nasa.gov> Date: 14 Jun 88 01:16:34 GMT References: <8805231553.AA21150@oliver.cray.com> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 30 The bottom line is that any implementation of HYROUTE that limits you to a subset of the IP addresses that the vendor supports is broken. (That is, if the vendor doesn't support subnets, then his HYROUTE program isn't broken because it doesn't work with subnets. But if the vendor does support subnets, as the vendor should, and HYROUTE does not work with subnets, then the vendor's implementation is broken) I bet this problem stems from the fact that the BSD distributed in_lnaof() in the C-library does not return the subnetted net, only the main network number. (At least the version we have. I think I've gotten all bug fixes.) So, the typical clever programmer just calls in_lnaof(addr) in both the hyroute and the kernel, and loses cause they return different things for user and kernel space. I fixed this here some time ago by sticking in a in_mainlnaof() in the hy driver, and calling that. It returns only the class A,B,C network. It would be better to repair the c-library, but it does not seem to be a trivial fix, and I didn't want to worry about breaking other things at this time. I like the idea of hashing on the whole IP address better, but it does mean a more difficult hashing algorithm, or else a really big table. I know those few rotates and adds don't much matter, but they have to happen on every packet. john ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806141426.AA11094@miasma.Stanford.EDU] <1988061414263200> From: trewitt@MIASMA.STANFORD.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: DELNI Rack Mount Kits Message-ID: <8806141426.AA11094@miasma.Stanford.EDU> Date: 14 Jun 88 14:26:32 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 15 > Are we all talking about the same thing? In my DECDirect catalog, > Winter/Spring 1988, on the same page as the DELNI (p. 113), P/N > H3126-00/FP, Rack Mount Brackets, $42. I've ordered these, installed > them on the DELNIs, and rack mounted them. Did one just last week. > What's the deal? Am I confused? Are they no longer available? > Should I be worried? Here's some details on the kit that Clive Dawson mentioned earlier: For a smaller part number (270-023) and a much smaller price ($2.99), I think that the Radio Shack "Universal Mounting Bracket Set" is a much better deal. The only drawback is that you have to provide your own #6-32 screws and washers. Works great! And, you have two other pairs of brackets left over, just in case you need to mount a car stereo. - Glenn ----MESSAGE-END---- ----MESSAGE-BEGIN---- [856@wucs2.UUCP] <1988061414420900> From: jps@wucs2.UUCP (James Sterbenz) Newsgroups: comp.protocols.tcp-ip,comp.protocols.ibm Subject: TCP/IP on mainframes Message-ID: <856@wucs2.UUCP> Date: 14 Jun 88 14:42:09 GMT Reply-To: jps@wucs2.UUCP (James Sterbenz) Organization: Washington U. in St. Louis Lines: 54 I am interested in experiences involving the installation/operation of official internet protocols (especially TCP and IP) on large mainframe systems. I'd like to know how the protocols were installed (division of processes, what code runs priviliged, etc.), how the system architecture is utilized (is the communications link on a communications processor or an IOP), and how the implementation performs. I'm interested in this for the research issues pertaining to high performance network-host architectures, rather than from the standpoint of finding a package to run on my system. Either pointers to existing documentation (papers, tech reports) or private communications would be appreciated. In particular, I am looking for non-Unix, large system implementations, such as on IBM sys/370 (303x, 308x, 3090) machines under MVS or VM, Burroughs 6000/7000/A MCP, Univac 1100 EXEC, NCR 8500/8500 VRX, CDC Cyber 700/800 NOS and NOS/VE, Honeywell DPS 8/80/90 GCOS and MULTICS (yea I know Burroughs and Univac ane now Unisys, but it messes up the "BUNCH"), and ICL 2900 VME. I would guess that there are a number of these installations, especially IBM (due to sheer numbers) and Univac (due to high government usage). For example, in the IBM sys/370 MVS environment: - which parts of the protocols run as seperate tasks, and in what address spaces - how is inter adress space communication handeled: via SRB's or using CMS - what code runs user state, semi-priveleged, or supervisor state (key 0) - how are buffers allocated and passed (GETMAIN vs. GETCELL or CPOOL) - what are performance factors: virtual storage (disk or extended), real storage utilization, SRM parameters (ICS, IPS), etc. - are links handeled as communications devices or I/O devices - if links are I/O devices, was IOS code modified and were new channel programs written - if links are communications devices, was any existing VTAM (or God forbid, TCAM or BTAM :-) code used (actually the effort might be worth the efficiency gained by using BTAM), or was a 'conventional' access method custom written - was existing NCP/SNA code utilized in a 3725 or 3705 box or was a custom control program written - other issues are important, but this gives the flavor of what I'm looking for If responses are e-mailed to me, I will summarize results and post. -- James Sterbenz Computer and Communications Research Center Washington University in St. Louis 314-726-4203 INTERNET: jps@wucs1.wustl.edu UUCP: wucs1!jps@uunet.uu.net ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806141502.AA04498@sonny.proteon.com] <1988061415022300> From: jas@proteon.COM (John A. Shriver) Newsgroups: comp.protocols.tcp-ip Subject: Subnet to Subnet routing Message-ID: <8806141502.AA04498@sonny.proteon.com> Date: 14 Jun 88 15:02:23 GMT References: <8806132340.AA01240@monk.proteon.com> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 20 Subnets of a given subnet must be contiguous. The definition of contiguous is that all subnets of the net are reachable via routes internal to that network. It's in RFC 950 and RFC 1009. The whole point of subnets is to hide the internal structure of a network from all other networks. In your example, the Class C network has been split, and is not contiguous, since traffic between the subnets must cross the Class B network. Since hosts on the Class B network are routing to the Class C network on a network (not subnet) basis, how will they know whether to send traffic for SUN3 via SUN1 or SUN2? Looking at your configuration, subnet your Class B network, using from 4 to 8 subnet bits. Make each Ethernet one subnet. Subnetting Class C networks is not typical. If there are some hosts on the backbone Ethernet that don't know from subnets, you may be able to fake them out using proxy ARP subnet routing. However, they had better age their ARP cache if they do this. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [3352@phri.UUCP] <1988061415280300> From: roy@phri.UUCP (Roy Smith) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Looking for comments on the 15-pin ethernet connector Summary: It sucks! Message-ID: <3352@phri.UUCP> Date: 14 Jun 88 15:28:03 GMT References: <5047@videovax.Tek.COM> Reply-To: roy@phri.UUCP (Roy Smith) Organization: Public Health Research Inst. (NY, NY) Lines: 58 dmc@videovax.Tek.COM (Donald M. Craig) writes: > I am looking for feedback on the quality and reliability of > the slide latch mechanism used on the DB-15 ethernet connectors. In a nutshell, they suck! There is no doubt that the single most common cause of problems in our entire network (19 Suns, a Vax, and maybe a dozen Macintoshes and PCs) is loose ethernet tranciever cables, particularly on the backs of Sun-3/50's which provide no mechanical support for the cable at all. On our rack-mount systems, we support the cables with cable ties to various convenient supports. On our deskside suns, we've constructed assorted mechanical strain reliefs. Some of our 3/50's seem to be OK with just wedging the cable behind a desk but some are a constant cause of trouble. For the worse ones, we install a support bracked we've designed which helps a little (it's just a plexiglass bar notched to fit on the card extractor ears and with cutouts for the various cables and attachment points for cable ties in the appropriate places). > "I am the Component Engineer for connectors at Sun. In regards to your > question concerning the Ethernet DB-15 [...] I am not aware of any > significant problems with mechanical integrity of the lock, or for that > matter with the connector in any aspect. I'm not given to public flamage, but this guy must have his head firmly wedged in a dark place. If he's not aware of any problems, it because he hasn't been listening. I've complained loudly about this on the net before. I've complained to Sun field service. I've complained to Sun tech support. Clearly those complaints havn't gotten back to the right people. The stupid little stamped sheet metal clips are simply not strong enough to secure a connector with a big fat, heavy, and fairly stiff tranciever cable on it. As long as the cable is secured so if can't move if accidentally moved, it's OK. For example, on the tranciever ends, we lash the cable to the main ethernet trunk cable with 2 (or sometimes 3) wire ties a few inches away. But on systems which might move a little (like a deskside Sun on wheels), or in situations where the cable might be disturbed (like hanging off the back of a desk) forget it. What was wrong with good-old RS-232-style screws? Or, if they really wanted a tool-less installation, why not Macintosh-style knurled screws, or maybe even centronics-style wire bails? We recently got a 3-Com 3C503 ethernet card for an IBM-PC. The connector is a bit different, with screw holes instead of binding posts. Unfortunately, to use the screw holes you need a special adaptor bracket which I havn't been able to locate yet (OK, we just got the thing; I havn't had a chance to look very hard). It looks like it might be a bit more secure. Our Interlan ethernet board for the vax has a slight variation on the slide connector which looks like it might be marginally stronger (it has small extra ridges along the sides), but I doubt it would still be strong enough if we weren't able to lash the cable to various places in the vax's rack frame. I really don't know what the DIX guys had in mind when they designed this connector. Administering a network is hard enough without having to worry about which $5 connector is falling out. -- Roy Smith, System Administrator Public Health Research Institute 455 First Avenue, New York, NY 10016 {allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1542@se-sd.sandiego.NCR.COM] <1988061417415000> From: cliff@se-sd.sandiego.NCR.COM (Cliff Bamford) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Looking for comments on the 15-pin ethernet connector Message-ID: <1542@se-sd.sandiego.NCR.COM> Date: 14 Jun 88 17:41:50 GMT References: <5047@videovax.Tek.COM> Reply-To: cliff@se-sd.sandiego.NCR.COM (Cliff Bamford) Organization: NCR Corp. Systems Engineering, San Diego Lines: 12 The problem is that it's impossibly impractical to give that connector "reasonable care" in the field. Regardless of type, connectors always seem to be just-barely-visible and just-barely-out-of-reach. The D-sub requires good visibility (to tell which way the slider is slid) and good tactile access to [un]couple. Since these conditions rarely obtain, THE !#@$%&* CONNECTER DRIVES PEOPLE CRAZY. Which is one of the reasons you see so many of them torn asunder, at which point they become worse than useless. Except as mute testimony to the limits of human patience. -- cliff.bamford@sandiego.ncr.com (619)693-5724 {ucsd,cbosgd}!ncr-sd!se-sd!cliff ----MESSAGE-END---- ----MESSAGE-BEGIN---- [Jun.14.13.58.26.1988.20620@topaz.rutgers.edu] <1988061417582800> From: ron@topaz.rutgers.edu (Ron Natalie) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Looking for comments on the 15-pin ethernet connector Message-ID: Date: 14 Jun 88 17:58:28 GMT References: <5047@videovax.Tek.COM> <3352@phri.UUCP> Organization: Rutgers Univ., New Brunswick, N.J. Lines: 4 Yep, by the way, we've gone and replaced the slide clips with the good old RS-232 screws and threaded inserts on all the Ethernet cables of importance. -Ron ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988061419410000> Received: from G.BBN.COM by SRI-NIC.ARPA with TCP; Tue, 14 Jun 88 20:41:04 PDT Date: 14 Jun 1988 23:41-EDT Sender: KSEO@G.BBN.COM Subject: Re: Pointers to performance studies on TCP/IP... From: KSEO@G.BBN.COM To: dheeraj@TOVE.UMD.EDU, dheeraj@CHAKRA.CS.UMD.EDU Cc: tcp-ip@SRI-NIC.ARPA, satnet-task-force@VAX.BBN.COM Message-ID: <[G.BBN.COM]14-Jun-88 23:41:04.KSEO> Dheeraj, The SATNET (Atlantic Packet Satellite Network) Measurement Taskforce just completed some work analyzing TCP/IP performance over the SATNET. As part of this effort, we developed an instrumented TCP/IP implementation and a separate IP measurement tool. For additional information: a) Our experimental methodology, tools and results are described in a paper to be presented at SIGCOMM 88 in August. Send me your paper address if you'd like a copy. b) There will be 3 additional writeups describing the taskforce's work in more detail. These will probably be done by the end of the summer. Let me know if you'd like copies when they're complete. c) For specific details about the TCP and IP tools, please contact: TCP tool: Jon Crowcroft (jon@cs.ucl.ac.uk) IP tool: Paal Spilling (paal@tor.nta.no) Let me know if you have further questions, Karen ----MESSAGE-END---- ----MESSAGE-BEGIN---- [23340@bu-cs.BU.EDU] <1988061419540900> From: bzs@bu-cs.BU.EDU (Barry Shein) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Looking for comments on the 15-pin ethernet connector Message-ID: <23340@bu-cs.BU.EDU> Date: 14 Jun 88 19:54:09 GMT References: <5047@videovax.Tek.COM> <3352@phri.UUCP> Organization: Boston U. Comp. Sci. Lines: 27 In-reply-to: roy@phri.UUCP's message of 14 Jun 88 15:28:03 GMT I'll second Roy Smith's gripes about those slide-latch ethernet connectors to quote Roy: "In a nutshell, they suck!" Actually, if there were some negative pressure they might work... We have around 100 Suns here and other assorted items (this lousy slide-latch is not unique to Suns by any means, it's ubiquitous) and they're always falling out, the worst catastrophes occur when they fall out of centralized server machines, we've been out for hours and hours while some poor operator tries to figure out what the problem is (they're learning, we're all learning.) Worse, much worse, it falls out of MY SUN all the time, like when I swing my chair around to gulp coffee or some other critical maneuver and brush the deskside tower, to get it to stay back in I have to re-arch the cable at a precarious angle so it provides pressure towards the plug. Now *that's* unacceptable, the public be damned. I'll also add a vote to the Mac-like knurled screws, that would be the ticket. -Barry Shein, Boston University ----MESSAGE-END---- ----MESSAGE-BEGIN---- [23345@bu-cs.BU.EDU] <1988061420411200> From: kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: the 15-pin ethernet connector slide lock Summary: need integral strain relief on host side Message-ID: <23345@bu-cs.BU.EDU> Date: 14 Jun 88 20:41:12 GMT References: <5047@videovax.Tek.COM> <3352@phri.UUCP> <23340@bu-cs.BU.EDU> Reply-To: kwe@buit13.bu.edu (Kent England) Followup-To: comp.dcom.lans Organization: Boston Univ. Information Tech. Dept. Lines: 28 In article <23340@bu-cs.BU.EDU> bzs@bu-cs.BU.EDU (Barry Shein) writes: > >I'll also add a vote to the Mac-like knurled screws, that would be the >ticket. That would just about do it, but there are some little touches that the hardware guys could do if they just thought about how the equipment gets used. Hardware engineers- you listening?? Redesign the host side of the connection for better strain relief. We can handle the xcvr side with ty wraps alright. First, use a 90 degree angle on the cable into the connector. Then provide a ty wrap mount an inch or so away from the connector mounting point so we can tie the cable down and provide strain relief. Barry will also be able to shove his deskside closer to the wall and that will help. If you can't angle the cable put a standoff bar somewhere on the back of the box so that when the unit IS shoved into the wall it won't crush the cable/connector and pop it off. Ideally, put a strain relief point on the standoff bar so we can tie the cable down. (Smart guys will do both.) This would help a great deal even without a major session of 802.3 devoted to rehashing this. Kent England, also BU ----MESSAGE-END---- ----MESSAGE-BEGIN---- [22269@tis.llnl.gov] <1988061421023000> From: bae@ati.tis.llnl.gov (Hwa Jin Bae) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Looking for comments on the 15-pin ethernet connector Message-ID: <22269@tis.llnl.gov> Date: 14 Jun 88 21:02:30 GMT References: <5047@videovax.Tek.COM> <3352@phri.UUCP> Sender: news@tis.llnl.gov Reply-To: bae@ati.tis.llnl.gov (Hwa Jin Bae) Organization: Lawrence Livermore National Laboratory, Livermore CA Lines: 14 In general, I don't like DIX 15 pin adapter without any secure screws. My Symmetric 375 comes with 9 pin output which can be interface to regular transceiver with a 9 pin to 15 pin drop cable. You can use RS-232 like screw attachment with it, and it's so much nicer than SUN's way of doing attachment. But then again you can always use "Crazy Glue" or something... 8-) --- Hwa Jin Bae | Standard excuses...not responsible.../dev/null...etc. Control Data Corp. | (415) 463 - 6865 4234 Hacienda Drive | bae@tis.llnl.gov (Internet) Pleasanton, CA 94566 | {ames,ihnp4,lll-crg}!lll-tis!bae (UUCP) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [206@execu.UUCP] <1988061423133400> From: dewey@execu.UUCP (dewey henize) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Looking for comments on the 15-pin ethernet connector Message-ID: <206@execu.UUCP> Date: 14 Jun 88 23:13:34 GMT References: <5047@videovax.Tek.COM> Reply-To: dewey@execu.UUCP (dewey henize) Organization: Execucom Systems Corp., Austin, Texas Lines: 51 In article <5047@videovax.Tek.COM> dmc@videovax.Tek.COM (Donald M. Craig) writes: >I am looking for feedback on the quality and reliability of >the slide latch mechanism used on the DB-15 ethernet connectors. [ Info on use of the info... } >Sun Microsystems also has a representative on the RP-125 committee. >He has asked the component engineer for connectors at Sun >if there was any data concerning the mechanical integrity of the >slide latch locking mechanism used in the ethernet connector. >Here is the response: > >"I am the Component Engineer for connectors at Sun. In regards to your >question concerning the Ethernet DB-15, these are used through out >industry by the millions, in many applications. I am not aware of any >significant problems with mechanical integrity of the lock, or for that >matter with the connector in any aspect. If the connector is properly >installed and handled in a semi-reasonable manner you should not have >any problems. As far as Sun is concerned, usage of D-Sub connectors in >general, that is various sizes and configurations, will probably >increase. When all things are considered it often turns out to be the >best way to go! Hope this helps!!!" > >In the face of this informal statement by Sun's component engineer, >I now need data about other people's experience with the DB-15 slide >latch ethernet connector. Here at Execucom we have a slightly different term for this 'device'. I won't put it out on the net, however, since this probably isn't the place to put adjectives regarding personal ancestory or public sexual habits. Suffice it to say that if the person who designed the slide latch connector were to come here and visit, his/her employer should only buy a one-way ticket - we'd be able to ship what remains there were back in a shoebox! Seriously, those things are a joke. When each and every part is made to exact and perfect spec, they seem to work ok (at least until you touch them in some fashion). The ones we got with at least 3 of our Suns and the cables that we also got from Sun seem to be made to different specs entirely. We had to do a good bit of reverse engineering to get them to handle the normal vibration of someone merely walking in the office (concrete floors). Junk em. Use screws. Please, since you are protecting this 'Component Engineer', help him/her/it :-) become aware of 'significant problems'. -- =============================================================================== | execu!dewey Dewey Henize @ Execucom Systems Corp 512/346-3008 | | You don't think my employer APPROVES of these ideas, do you?? Sheesh! | =============================================================================== ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1612@iscuva.ISCS.COM] <1988061423145400> From: jimk@iscuva.ISCS.COM (Jim Kendall) Newsgroups: comp.protocols.tcp-ip Subject: Re: Wanted: Delni Keywords: DELNI DEMPR Cabletron Message-ID: <1612@iscuva.ISCS.COM> Date: 14 Jun 88 23:14:54 GMT References: <8806070434.AA09530@infidel.lanl.gov.ARPA> <10269@ncc.Nexus.CA> <23399@oliveb.olivetti.com> Organization: ISC Systems Corporation, Spokane, WA Lines: 40 Jerry Aguirre writes: >Now for the bad news. I had one of the MR-9000s fail.... But I didn't find >Cabletron very responsive; it took several days and many phone calls to >get me the RMA number and the repair took over a week..... Perhaps if >I had told them I was off the air they would have arranged a loaner. >What was disturbing was that I have written a PO and received a new unit >from them in half the time it took to get an in-warranty repair. We detected a malfunction in one of our MR-9000s in that when the cable segment was accidentally opened up a couple of hundred feet down the wire, the fault and collision lights didn't come on........but the jam light flickered rapidly. This indication tells me that the faulty segment did not automatically disconnect and that runt packets were being propagated to all segments (including channel 9, the Ethernet segment). Needless to say, this loaded the network quite heavily. I disconnected the faulty segment and, sure enough, the collision and fault lights lit and the segment disconnected properly. I called Cabletron and told them about it and they indicated that there was a PAL change made to later units (ours was 8 months old, therefore we didn't have the PAL change) to fix a faulty segment disconnect problem, BUT....he said that what I was describing didn't sound like the problem the PAL change was intended to fix. He said that he would air freight me up a new one and that I should get it next Monday (this was last week and Monday has obviously passed) along with an RMA # to ship the old one back under. To date I've gotten neither.....and we need this to fix our problem (we are in a developement situation where we are often opening up segments, and it's imperative that the open segment disconnect properly). So, Jerry, I don't know about the "if I'd only told them I was down" arguement. While I've typically had good response from Cabletron, in this particular instance it hasn't been. Now just watch.......I'll hit the `S'end key and Receiving will call and tell me to come get my MR-9000 ;^) Cheers! -- Jim Kendall ISC Systems Corp. My boss is in full jimk@iscuva.ISCS.COM E. 22425 Appleway agreement with all uunet!iscuva!jimk Liberty Lake, WA 99019 of my opinions.... ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1613@iscuva.ISCS.COM] <1988061423183300> From: jimk@iscuva.ISCS.COM (Jim Kendall) Newsgroups: comp.protocols.tcp-ip Subject: TCP/IP Message-ID: <1613@iscuva.ISCS.COM> Date: 14 Jun 88 23:18:33 GMT Organization: ISC Systems Corporation, Spokane, WA Lines: 12 OHH!!! I forgot to ask.......... Has anyone got TCP/IP working on their eniac yet???? (That's a joke, son....... :-) Cheers! -- Jim Kendall ISC Systems Corp. My boss is in full jimk@iscuva.ISCS.COM E. 22425 Appleway agreement with all uunet!iscuva!jimk Liberty Lake, WA 99019 of my opinions.... ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1333@sbcs.sunysb.edu] <1988061502022900> From: root@sbcs.sunysb.edu (root) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Looking for comments on the 15-pin ethernet connector Summary: He's gotta be joking about the 15 pin connector Message-ID: <1333@sbcs.sunysb.edu> Date: 15 Jun 88 02:02:29 GMT References: <5047@videovax.Tek.COM> <3352@phri.UUCP> Organization: State University of New York at Stony Brook Lines: 29 In article <3352@phri.UUCP>, roy@phri.UUCP (Roy Smith) writes: > dmc@videovax.Tek.COM (Donald M. Craig) writes: > > > "I am the Component Engineer for connectors at Sun. In regards to your > > question concerning the Ethernet DB-15 [...] I am not aware of any > > significant problems with mechanical integrity of the lock, or for that > > matter with the connector in any aspect. > To the "Component Engineer" at Sun: I submit Sir, that you must not use your own product. At Stony Brook we have ~100 Suns of mixed types and I can attest that the metal slide lock causes us NO END of trouble. > What was wrong with good-old RS-232-style screws? Or, if they really > wanted a tool-less installation, why not Macintosh-style knurled screws, or > maybe even centronics-style wire bails? We recently got a 3-Com 3C503 I would like to see a connector like the one used on the uVAX (?) console cable: Long screw posts with a knob on the end that allows finger tightening of the screw. I understand that the slide is somehow a standard, but if it "don't work" then fix the bloody thing. > Roy Smith, System Administrator > Public Health Research Institute > 455 First Avenue, New York, NY 10016 > {allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net Rick Spanbauer SUNY/Stony Brook ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988061502500000> Received: from RELAY.CS.NET by SRI-NIC.ARPA with TCP; Wed, 15 Jun 88 05:42:20 PDT Received: from helios.northeastern.edu by RELAY.CS.NET id aa08679; 15 Jun 88 7:51 EDT Received: from nuhub.acs.northeastern.edu by helios.northeastern.edu id aa00897; 15 Jun 88 7:48 EDT Date: Wed, 15 Jun 88 07:50 5 From: "I am only an egg." Subject: Re: Ethernet slide connectors To: tcp-ip@SRI-NIC.ARPA X-VMS-To: TCP-IP Roy Smith, System Administrator for Public Health Research Institute writes: "In a nutshell, they suck!" While I might have phrased it differently, I fully agree. I have yet to get one of these silly, stupid slide style connectors to work. I much prefer the other kind that are screwed in. We also use the idea of cable ties to secure the cables. Fortunately I can get away with this since all my wires are in very fixed places. I had to scream at the communications people here to tie them up because they were constantly falling out just from fan vibration (and random air currents too I think). In the earily days of our Ethernet this was the cause of many a mysterious problem. One of the things I ask vendors now is what style connector their hardware comes with. Chris Johnson Northeaster University. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988061503091800> Received: from PARK-STREET.BBN.COM by SRI-NIC.ARPA with TCP; Wed, 15 Jun 88 07:20:05 PDT To: "Donald M. Craig" cc: tcp-ip@SRI-NIC.ARPA Subject: Re: Looking for comments on the 15-pin ethernet connector In-reply-to: Your message of 13 Jun 88 18:52:03 +0000. <5047@videovax.Tek.COM> Date: Wed, 15 Jun 88 09:49:18 -0400 From: Mike Brescia > I am looking for feedback on the quality and reliability of > the slide latch mechanism used on the DB-15 ethernet connectors. > The Society of Motion Picture and Television Engineers has a > standard known as RP-125 which specifies a parallel digital > television interface. The connector for that interface is > a 25 pin D-type (DB-25) with a slide latch like the ethernet > connector. The RP-125 standard is up for revision, ... So far, I have seen people flaming the slide latch, but no comment on the Dtype connectors. While using screws to replace the slide latch helps in some cases, the main problem seems to be that the long, narrow connector with 2 rows of pins cannot withstand stress from a heavy or thick or stiff cable. There should be some analysis of why you should not use cable that is an inch in diameter to contain 18 individually shielded twisted pairs for your rs422/rs449 and try to connect it with a DC-37. The slide latch can only handle a little stress on the long dimension, and can handle none on the narrow dimension. The DB15 would be ok with a ribbon cable, because the ribbon is both light and flexible, and a well fitted slide latch would lock it in place, but then you would not even need a lock because the friction of the connector would keep it it. So, if SMPTE is going to do it right, they need to consider the mechanical characteristics of the locking mechanism, as well as the ease of connection and disconnection. Mike disclaimer: My degree is E.E., not M.E., so I am relating experiences, not properly qualified professional opinion. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[G.BBN.COM]14-Jun-88.23:41:04.KSEO] <1988061503410000> From: KSEO@G.BBN.COM Newsgroups: comp.protocols.tcp-ip Subject: Re: Pointers to performance studies on TCP/IP... Message-ID: <[G.BBN.COM]14-Jun-88.23:41:04.KSEO> Date: 15 Jun 88 03:41:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 21 Dheeraj, The SATNET (Atlantic Packet Satellite Network) Measurement Taskforce just completed some work analyzing TCP/IP performance over the SATNET. As part of this effort, we developed an instrumented TCP/IP implementation and a separate IP measurement tool. For additional information: a) Our experimental methodology, tools and results are described in a paper to be presented at SIGCOMM 88 in August. Send me your paper address if you'd like a copy. b) There will be 3 additional writeups describing the taskforce's work in more detail. These will probably be done by the end of the summer. Let me know if you'd like copies when they're complete. c) For specific details about the TCP and IP tools, please contact: TCP tool: Jon Crowcroft (jon@cs.ucl.ac.uk) IP tool: Paal Spilling (paal@tor.nta.no) Let me know if you have further questions, Karen ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988061505324900> Received: from WILMA.BBN.COM by SRI-NIC.ARPA with TCP; Wed, 15 Jun 88 06:38:47 PDT Date: Wed, 15 Jun 88 9:32:49 EDT From: "Benjamin J. Woznick" To: "Donald M. Craig" cc: tcp-ip@SRI-NIC.ARPA Subject: Re: Looking for comments on the 15-pin ethernet connector I would like to second most of the comments that have been made about the slide connector. The problem with the ethernet is compounded by the size and stiffness of the cable. The only quibble I have with the other comments is that *I* can't really tell which way the slide wants to go even when I have it in full view. This has to be the worst human-engineered connector in the history of mankind. Ben Woznick ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806150602.AA11768@atom.hpl.hp.com] <1988061506023100> From: robert@ATOM.HPL.HP.COM (Robert Michaels) Newsgroups: comp.protocols.tcp-ip Subject: Re: Looking for comments on the 15-pin ethernet connector Message-ID: <8806150602.AA11768@atom.hpl.hp.com> Date: 15 Jun 88 06:02:31 GMT References: <3352@phri.UUCP> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 20 > The stupid little stamped sheet metal clips are simply not strong >enough to secure a connector with a big fat, heavy, and fairly stiff >tranciever cable on it. As long as the cable is secured so if can't move if >accidentally moved, it's OK. For example, on the tranciever ends, we lash >the cable to the main ethernet trunk cable with 2 (or sometimes 3) wire ties >a few inches away. But on systems which might move a little (like a deskside >Sun on wheels), or in situations where the cable might be disturbed (like >hanging off the back of a desk) forget it. > > What was wrong with good-old RS-232-style screws? Or, if they really To me the problem is that the little clips are "standard". I would be very surprised if a vendor will have enough courage to promote something more effective. To alleviate your problem you could try using a lighter weight transceiver cable. For us most transceivers are within 5 meters of the host. For short runs you don't need these really big fat cables. I think several vendors build these short lightweight transceiver cables ( yes even HP does). - Robert Michaels HP Labs ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806151535.AA01753@ucbvax.Berkeley.EDU] <1988061507450000> From: JOHNSON@nuhub.acs.northeastern.EDU ("I am only an egg.") Newsgroups: comp.protocols.tcp-ip Subject: Re: Ethernet slide connectors Message-ID: <8806151535.AA01753@ucbvax.Berkeley.EDU> Date: 15 Jun 88 07:45:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 21 Roy Smith, System Administrator for Public Health Research Institute writes: "In a nutshell, they suck!" While I might have phrased it differently, I fully agree. I have yet to get one of these silly, stupid slide style connectors to work. I much prefer the other kind that are screwed in. We also use the idea of cable ties to secure the cables. Fortunately I can get away with this since all my wires are in very fixed places. I had to scream at the communications people here to tie them up because they were constantly falling out just from fan vibration (and random air currents too I think). In the earily days of our Ethernet this was the cause of many a mysterious problem. One of the things I ask vendors now is what style connector their hardware comes with. Chris Johnson Northeaster University. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [244@texhrc.UUCP] <1988061511390400> From: cml@texhrc.UUCP (Chris Lonvick) Newsgroups: comp.protocols.tcp-ip Subject: Re: DELNI Rack Mount Kits Summary: DELNI Rack Mounting Ears Message-ID: <244@texhrc.UUCP> Date: 15 Jun 88 11:39:04 GMT References: <8806070434.AA09530@infidel.lanl.gov.ARPA> <10269@ncc.Nexus.CA> <1098@rel.eds.com> Organization: Texaco Houston Res. Cntr Hou, Tx Lines: 18 >kinda amazed me. DEC sells the brackets as an option in Europe for the > standard 19" rack, but not in the US. In the US, they only come with the [...] > to be an Engineering Test facility for an Automotive company, it was no > big deal for us to fabricate the parts ourselves. I would have still > prefered to buy them from DEC. [???] > I've been buying the ears from DEC for at least two years. If I had a machine shop I would opt to manufacture them in-house since they could then be made from gold and still cost less than what DEC charges. In the current DEC Direct catalog: H3126-00/FP Rack Mounting Brackets (rack 4 DELNI) $42. This gives you 8 ears, some screws and a neat pictorial guide to correct installation. Such a deal. Chris Lonvick Texaco EPTD Usual Disclaimer: These views are mine, mine, all mine and you can't have any. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806151535.AA01779@ucbvax.Berkeley.EDU] <1988061513324900> From: bjw@WILMA.BBN.COM ("Benjamin J. Woznick") Newsgroups: comp.protocols.tcp-ip Subject: Re: Looking for comments on the 15-pin ethernet connector Message-ID: <8806151535.AA01779@ucbvax.Berkeley.EDU> Date: 15 Jun 88 13:32:49 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 6 I would like to second most of the comments that have been made about the slide connector. The problem with the ethernet is compounded by the size and stiffness of the cable. The only quibble I have with the other comments is that *I* can't really tell which way the slide wants to go even when I have it in full view. This has to be the worst human-engineered connector in the history of mankind. Ben Woznick ----MESSAGE-END---- ----MESSAGE-BEGIN---- [152@iravcl.ira.uka.de] <1988061513380600> From: schuetz@iravcl.ira.uka.de Newsgroups: comp.protocols.tcp-ip,comp.os.vms Subject: tcp-connection on vaxen: vms4.7 <-> bsd4.3 (second attempt) Message-ID: <152@iravcl.ira.uka.de> Date: 15 Jun 88 13:38:06 GMT Lines: 20 Organisation: Universitaet Karlsruhe, IRA, F.R. Germany Hello again, 8 days ago I posted a very detailed letter (Reference <146@iravcl.ira.uka.de>. Up to now I got no answers. Maybe there's trouble with BITNET from some sites (delay up to 3 weeks) maybe no one knows the answer ... I now want to know is there anybody who programmed with cmu-tek tcp/ip on VAXen under VMS? Did you make a connection to a machine under bsd4.3 (esp. VAX, too)? Did your program use two ports to communicate? Did you open the 1st port active and the 2nd passive? If you answer all questions with 'yes' please contact me. I want to hear of the functions and parameters you use with '$qio'. FYI: I'm using VAX-cluster (8700/8200 VMS4.7), VAX 11/750 (bsd4.3), IP_ACP(V6.2) Please reply via e-mail to schuetz@ira.uka.de Many thanks in advance Regards, Elmar ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806151700.AA03253@ucbvax.Berkeley.EDU] <1988061513491800> From: brescia@PARK-STREET.BBN.COM (Mike Brescia) Newsgroups: comp.protocols.tcp-ip Subject: Re: Looking for comments on the 15-pin ethernet connector Message-ID: <8806151700.AA03253@ucbvax.Berkeley.EDU> Date: 15 Jun 88 13:49:18 GMT References: <5047@videovax.Tek.COM> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 31 > I am looking for feedback on the quality and reliability of > the slide latch mechanism used on the DB-15 ethernet connectors. > The Society of Motion Picture and Television Engineers has a > standard known as RP-125 which specifies a parallel digital > television interface. The connector for that interface is > a 25 pin D-type (DB-25) with a slide latch like the ethernet > connector. The RP-125 standard is up for revision, ... So far, I have seen people flaming the slide latch, but no comment on the Dtype connectors. While using screws to replace the slide latch helps in some cases, the main problem seems to be that the long, narrow connector with 2 rows of pins cannot withstand stress from a heavy or thick or stiff cable. There should be some analysis of why you should not use cable that is an inch in diameter to contain 18 individually shielded twisted pairs for your rs422/rs449 and try to connect it with a DC-37. The slide latch can only handle a little stress on the long dimension, and can handle none on the narrow dimension. The DB15 would be ok with a ribbon cable, because the ribbon is both light and flexible, and a well fitted slide latch would lock it in place, but then you would not even need a lock because the friction of the connector would keep it it. So, if SMPTE is going to do it right, they need to consider the mechanical characteristics of the locking mechanism, as well as the ease of connection and disconnection. Mike disclaimer: My degree is E.E., not M.E., so I am relating experiences, not properly qualified professional opinion. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [3345@ut-emx.UUCP] <1988061514155200> From: dlnash@ut-emx.UUCP (Donald L. Nash) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Looking for comments on the 15-pin ethernet connector Message-ID: <3345@ut-emx.UUCP> Date: 15 Jun 88 14:15:52 GMT References: <5047@videovax.Tek.COM> <3352@phri.UUCP> <23340@bu-cs.BU.EDU> Organization: The University of Texas at Austin, Austin, Texas Lines: 36 In article <23340@bu-cs.BU.EDU>, bzs@bu-cs.BU.EDU (Barry Shein) writes: > > We have around 100 Suns here and other assorted items (this lousy > slide-latch is not unique to Suns by any means, it's ubiquitous) and > they're always falling out, the worst catastrophes occur when they ^^^^^^^ ^^^^^^ ^^^^^^^ ^^^ > fall out of centralized server machines, we've been out for hours and > hours while some poor operator tries to figure out what the problem is > (they're learning, we're all learning.) > It really gets interesting when the cable falls out just enough that the transmit wire gets disconnected but the receive wire is still in place. Then you have a machine which can listen but not talk. We had this happen on a MicroVAX II and almost went into a panic thinking the DEQNA had died. > I'll also add a vote to the Mac-like knurled screws, Me, too. Don Nash UUCP: ...!{allegra, seismo!ut-sally}!ut-emx!dlnash ARPA: dlnash@emx.utexas.edu BITNET: DLNASH@UTADNX, D.NASH@UTCHPC THENET: UTADNX::DLNASH, UTCHPC::D.NASH UUU UUU U U The University of Texas at Austin U TTTTUTTTTTTTTT Computation Center U T U TT T U U TT "The world is basically non-linear." UUUUUUU TT TT TTTT ----MESSAGE-END---- ----MESSAGE-BEGIN---- [5788@bloom-beacon.MIT.EDU] <1988061517415400> From: wesommer@athena.mit.edu (William Sommerfeld) Newsgroups: comp.protocols.tcp-ip Subject: Re: Looking for comments on the 15-pin ethernet connector Message-ID: <5788@bloom-beacon.MIT.EDU> Date: 15 Jun 88 17:41:54 GMT References: <8806151535.AA01779@ucbvax.Berkeley.EDU> Sender: daemon@bloom-beacon.MIT.EDU Reply-To: wesommer@athena.mit.edu (William Sommerfeld) Organization: Massachusetts Institute of Technology Lines: 6 Actually, I would vote for something similar to what DEC uses for serial console cables: screw connectors with knurled knobs which have a slot for a screwdriver in them; this way, you don't _need_ a screwdriver to connect or disconnect them, but if you have a screwdriver, you can save some wear and tear on your fingers... - Bill ----MESSAGE-END---- ----MESSAGE-BEGIN---- [5276@ecsvax.UUCP] <1988061518114900> From: tpmsph@ecsvax.UUCP (Thomas P. Morris) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Looking for comments on the 15-pin ethernet connector Summary: slide latch for e-net db15's sux Message-ID: <5276@ecsvax.UUCP> Date: 15 Jun 88 18:11:49 GMT References: <5047@videovax.Tek.COM> <3352@phri.UUCP> <23340@bu-cs.BU.EDU> Organization: UNC Educational Computing Service Lines: 19 In my limited experience with 3 hosts and 10 terminal servers and 2 DELNI's, those $#%@%&^%$ slide latches on the ethernet db15s are a real problem. As has been pointed out before, they are not built well enough to handle the actual weight and strain of the bulky transceiver cable, and they don't do their job as a result! Screws or knurled knobs or wire bails a la IEEE488 or Centronics would be a welcome relief! For our DELNIS we had to cobble together a custom strain-relief panel. For the servers we ended up tie-wrapping the cables to the frame supports. ----------------------------------------------------------------------------- Tom Morris BITNET: TOM@UNCSPHVX UNC School of Public Health UUCP : ...!mcnc!ecsvax!tpmsph ----------------------------------------------------------------------------- -- ----------------------------------------------------------------------------- Tom Morris BITNET: TOM@UNCSPHVX UNC School of Public Health UUCP : ...!mcnc!ecsvax!tpmsph ----------------------------------------------------------------------------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988061520130000> Received: from relay.MOD.UK by SRI-NIC.ARPA with TCP; Thu, 16 Jun 88 10:17:27 PDT Received: from rsre.mod.uk by relay.MOD.UK via PSS with NIFTP id aa01182; 15 Jun 88 23:38 WET To: Jim Kendall <@nss:iscuva!jimk@uunet.uu.net> From: John Laws (on UK.MOD.RSRE) Date: Thu, 16 Jun 88 01:13 In-reply-to: <1613@iscuva.ISCS.COM> Cc: tcp-ip <@relay.MOD.UK:tcp-ip@sri-nic.arpa> Message-Id: <16 JUN 1988 01:13:37 LAWS@RSRE> Subject: Re: TCP/IP Jim, '...eniac...' Hmmmmm.... in the spirit of competition and keeping the UK ahead of the game - I'll race down to the Science Museum London and hack TCP/IP onto the Babbage m/c ...... now where did I put my hacksaw (agreed a weak pun). Those of you strong on theory might like to try it on the Turing m/c - US folks would rather go to Church and Post a solution, or in these days of detente why not chain yourself to A Markov. Wales is a whisper away from here so don't be surprised if you hear on the news come 21/22 June that Stonehenge, after Hoyle (Fred and not the American maker of Rules quoted in a song), has been re- programmed with Theological Cosmic Prayer/Inter-galatic Protocol. John ----MESSAGE-END---- ----MESSAGE-BEGIN---- [58@stanton.TCC.COM] <1988061602102300> From: donegan@stanton.TCC.COM (Steven P. Donegan) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Looking for comments on the 15-pin ethernet connector Summary: Slide Locks Are @#!$#@ Convert Today - We Do! Message-ID: <58@stanton.TCC.COM> Date: 16 Jun 88 02:10:23 GMT References: <5047@videovax.Tek.COM> <1542@se-sd.sandiego.NCR.COM> Organization: Stanton Public Domain Systems, Stanton, Ca. Lines: 12 How many of you fools still swear at slide locks, experience massive down time due to same? Well, less than a dollars worth of hardware and the guts to mess with the 'standard' (read holy) connectors will buy you much peace of mind. We convert ALL slide-lock cables and devices to SCREW-DOWN style. Haven't lost a single server or transceiver due to our un-holy conversion to a much more secure fastening method. -- Steven P. Donegan Sr. Telecommunications Analyst Western Digital Corp. donegan@stanton.TCC.COM ----MESSAGE-END---- ----MESSAGE-BEGIN---- [585@ndcheg.UUCP] <1988061603213000> From: evan@ndcheg.UUCP (Evan Bauman) Newsgroups: comp.protocols.tcp-ip Subject: Re: Networks unreachable Summary: same situation at U. of Cincinnati Message-ID: <585@ndcheg.UUCP> Date: 16 Jun 88 03:21:30 GMT References: <1988.6.13.14.27.28.Eugene.Hastings@morgul> Organization: Univ. of Notre Dame Lines: 58 In article <1988.6.13.14.27.28.Eugene.Hastings@morgul>, Eugene.Hastings@MORGUL.PSC.EDU writes: > We have encountered a peculiar situation on a Proteon p4200 that has broken > connectivitiy for Ohio State, Case Western Reserve, and the Universith of > Michigan. The router in question is located in Cleveland and has T1 lines to > those institutions, and also to the routing stub where PSC-GW and companions > connect the ARPANET, NSFNET, PSCNET, and SURANET. Explicit RIP routes are > propagated, plus translated (from hello) NSFNET routes, plus default. (Let > me remind all and sundry that the present gated does not announce routes > learned via EGP, but relies on the propagation of default.) > > So far, so good. Default is propagated successfully to the affected schools, > but when data is sent to a net via default, the p4200 in Cleveland returns > net unreachable (in fact, if the Proteon console is queried for a route to > such a net, like MILNET, the response is "unable to route, reason none". > This reouter has been running v7.4 of Proteon's code for some time, and it > has only been very recently that it has failed. Proteon's response has been > to advise us to use a bugfix, v7.4b, which we have only just received. > No explanation of what may have happened to exercise this bug, or precisely > what bugs have been fixed has been offered. The new version should be > installed today. Just wanted to throw my two cents in on the subject. Although I'm posting from Notre Dame, I'm currently residing at the University of Cincinnati. They guys running the HPUX box here are new to the news and nets and have compiled the news a la FASCIST. So it's time to telnet back home to post until they work out outbound news with the upstream guys. In any case, I believe that we here are part of the Ohio network that is having its share of troubles. We've been experiencing the same "network not reachable" messages here. I've recently configured a set of Suns to work with a Proteon p4200, and from my experience there, I can tell that the routing tables on the HPUX here is correct. In fact, there were times that I was able to reach several sites that were not explicitly listed in the netstat -r output. Then sometime on Monday, net access was perfect. I could reach every site I could think of. This would coincide with the announcement from OSU that the new Proteon gateway software was installed. On Monday night, the net failed again here in Cincinnati. We got mostly "network not reachable" messages, but for a while, the attempted connection just timed out. Suddenly, tonight it came back up; as witnessed by my ability to post in Indiana while sitting at a desk in Ohio. I don't mean to gripe. Was just trying to let the guys in Columbus know what's happening here and help with the diagnostics. Evan Bauman University of Notre Dame ..!iuvax!ndcheg!evan <-- will forward to proper U. Cin. address -- --------------------------------------------------------------------------- This message has been sponsored by Powdermilk Biscuits in the big blue box. --------------------------------------------------------------------------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [16.JUN.1988.01:13:37.LAWS@RSRE] <1988061608130000> From: LAWS@rsre.mod.UK (John Laws, on UK.MOD.RSRE) Newsgroups: comp.protocols.tcp-ip Subject: Re: TCP/IP Message-ID: <16.JUN.1988.01:13:37.LAWS@RSRE> Date: 16 Jun 88 08:13:00 GMT References: <1613@iscuva.ISCS.COM> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 15 Jim, '...eniac...' Hmmmmm.... in the spirit of competition and keeping the UK ahead of the game - I'll race down to the Science Museum London and hack TCP/IP onto the Babbage m/c ...... now where did I put my hacksaw (agreed a weak pun). Those of you strong on theory might like to try it on the Turing m/c - US folks would rather go to Church and Post a solution, or in these days of detente why not chain yourself to A Markov. Wales is a whisper away from here so don't be surprised if you hear on the news come 21/22 June that Stonehenge, after Hoyle (Fred and not the American maker of Rules quoted in a song), has been re- programmed with Theological Cosmic Prayer/Inter-galatic Protocol. John ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806160522.aa02626@note.note.nsf.gov] <1988061609221000> From: steve@NOTE.NSF.GOV (Stephen Wolff) Newsgroups: comp.protocols.tcp-ip Subject: Re: TCP/IP Message-ID: <8806160522.aa02626@note.note.nsf.gov> Date: 16 Jun 88 09:22:10 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 4 128.91.2.22 eniac.seas.upenn.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1100@rel.eds.com] <1988061611313800> From: bob@rel.eds.com (Bob Leffler) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Looking for comments on the 15-pin ethernet connector Summary: connectors Message-ID: <1100@rel.eds.com> Date: 16 Jun 88 11:31:38 GMT References: <5047@videovax.Tek.COM> Organization: Electronic Data Systems, Troy, MI Lines: 33 In article <5047@videovax.Tek.COM>, dmc@videovax.Tek.COM (Donald M. Craig) writes: > Sun Microsystems also has a representative on the RP-125 committee. > "I am the Component Engineer for connectors at Sun. In regards to your .... > significant problems with mechanical integrity of the lock, or for that > matter with the connector in any aspect. If the connector is properly .... > In the face of this informal statement by Sun's component engineer, > I now need data about other people's experience with the DB-15 slide I can speak only from my own experience. We have many workstations located in the Engineer's cube at GM. Most of them are connected via a transceiver cable with the sliding connector that you are refering to in the previous article. We experienced at least one connector that was disconnected at least once a week. We would then have to dispatch somebody to the site, trouble shoot the problem, then plug the connector back in. Needless to say, this is very labor intensive and expensive. Almost all of our network problems turn out to be transceiver cables that are unplugged. I reported this problem to one of our vendors (Sun :-) ). I stated that in my environment, we would prefer a connector that could be fasten by screws. Local Sun Field service stated that they had received other similar complaints from other customers and that they would pass the suggestion back to their corporate office. -- Bob Leffler - EDS, GM Truck & Bus Account (313)456-5375 bob@rel.eds.com or {uunet!edsews, rutgers, umix}!rel!bob Opinions expressed may not be those of my employer. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [59@stanton.TCC.COM] <1988061613031600> From: donegan@stanton.TCC.COM (Steven P. Donegan) Newsgroups: comp.protocols.tcp-ip Subject: Re: Looking for comments on the 15-pin ethernet connector Summary: Vendors Have Converted Slide-Locks Message-ID: <59@stanton.TCC.COM> Date: 16 Jun 88 13:03:16 GMT References: <3352@phri.UUCP> <8806150602.AA11768@atom.hpl.hp.com> Organization: Stanton Public Domain Systems, Stanton, Ca. Lines: 42 In article <8806150602.AA11768@atom.hpl.hp.com>, robert@ATOM.HPL.HP.COM (Robert Michaels) writes: > > > The stupid little stamped sheet metal clips are simply not strong > >enough to secure a connector with a big fat, heavy, and fairly stiff > >tranciever cable on it. As long as the cable is secured so if can't move if > >accidentally moved, it's OK. For example, on the tranciever ends, we lash > >the cable to the main ethernet trunk cable with 2 (or sometimes 3) wire ties > >a few inches away. But on systems which might move a little (like a deskside > >Sun on wheels), or in situations where the cable might be disturbed (like > >hanging off the back of a desk) forget it. > > > > What was wrong with good-old RS-232-style screws? Or, if they really > > To me the problem is that the little clips are "standard". I would be very > surprised if a vendor will have enough courage to promote something more > effective. To alleviate your problem you could try using a lighter weight > > - Robert Michaels > HP Labs Our experience has shown the vendors we deal with to be very flexible. TCL and Bridge Communications have both agreed to sell us 'positive attachment' cables and interfaces (on the server and the transceiver). I really liked Bridges naming this option as 'positive attachment' :-))) The original transceiver cables used a cast slide rather than a stamped sheet metal slide - the casting was much thicker and did provide a somewhat firmer connection. Every cable, transceiver, server and multiport fan-out that we have used at WD have been possible to convert to screw-downs. The hardest to convert so far was the BICC multiport fan-out; this was due to their extreme use of shielding and screws to hold the unit together - it takes about 20-30 minutes and a large amount of patience to convert this unit. The results are worth the effort. -- Steven P. Donegan Sr. Telecommunications Analyst Western Digital Corp. donegan@stanton.TCC.COM ----MESSAGE-END---- ----MESSAGE-BEGIN---- [16136.8806161312@brahma.cs.hw.ac.uk] <1988061613122200> From: andy@cs.hw.ac.UK Newsgroups: comp.protocols.tcp-ip Subject: Re: Looking for comments on the 15-pin ethernet connector Message-ID: <16136.8806161312@brahma.cs.hw.ac.uk> Date: 16 Jun 88 13:12:22 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 30 Robert Michaels at HP Labs wrote... >To me the problem is that the little clips are "standard". I would be very >surprised if a vendor will have enough courage to promote something more >effective. About 3 years back we at Spider Systems decided that slidelocks were useless, and ever since have been fitting screwlocks instead to all our terminal servers, bridges and stuff. To let people attach to "standard" drop cables we provide a free 1 metre drop cable with a screwlock plug on one end, and a slidelock socket at the other. We call this a "tail". The point is that the slidelock part is then not at a strain position - it is a cable joint well away from the "immovable object" which the back of the box represents. It is twisting and bending which breaks slidelocks, not just pulling - slidelocks are fairly usable for in-line connections. Of course for people who are near to their network - for example in a rack with a DELNI, the length of the tail means you don't need another drop cable at all. Just to wrap it all up nicely, the screws have a knurled plastic knob on top for finger tightening. Of the thousands of products we have shipped, NOT ONE PERSON has reported a connector problem, and as far as I know NO-ONE has not bought something because we are "non-standard". We do get a lot of compliments though... Take heart, non-courageous HP - let good engineering win through! Andy Davis (andy@spider.uucp) Technical Director (andy@uk.co.spider) Spider Systems ----MESSAGE-END---- ----MESSAGE-BEGIN---- [5802@dcatla.UUCP] <1988061613332100> From: dnwcv@dcatla.UUCP (William C. VerSteeg) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Looking for comments on the 15-pin ethernet connector Summary: It is a dog!! Message-ID: <5802@dcatla.UUCP> Date: 16 Jun 88 13:33:21 GMT References: <5047@videovax.Tek.COM> <3352@phri.UUCP> <22269@tis.llnl.gov> Reply-To: dnwcv@sune.UUCP (William C. VerSteeg) Organization: DCA Inc., Alpharetta, GA Lines: 11 The 15-pin ethernet connector with a sliding latch has been the point of failure for more problems on my networks than all other problems combined. The problems have gotten even worse recently. It seems that in search of the extra buck, most companies are using thinner and weaker sheet metal on the sliding lock. This bends and causes intermittent problems. Do yourself a vavor and don't propigate this abomination to another hardware set. Standard Disclaimer Bill VerSteeg DCA ----MESSAGE-END---- ----MESSAGE-BEGIN---- [15733@tut.cis.ohio-state.edu] <1988061613573200> From: tom@OSCSUNA.osc.ohio-state.edu (Thomas Easterday) Newsgroups: comp.protocols.tcp-ip Subject: (none) Message-ID: <15733@tut.cis.ohio-state.edu> Date: 16 Jun 88 13:57:32 GMT Sender: daemon@tut.cis.ohio-state.edu Lines: 31 From MAILER-DAEMON Thu Jun 16 09:02:30 1988 Return-Path: Received: by OSCSUNA.osc.ohio-state.edu (4.0/SMI-DDN) id AB23005; Thu, 16 Jun 88 08:51:25 EDT Date: Thu, 16 Jun 88 08:51:25 EDT From: MAILER-DAEMON (Mail Delivery Subsystem) Subject: Returned mail: Host unknown Message-Id: <8806161251.AB23005@OSCSUNA.osc.ohio-state.edu> To: tom Status: R ----- Transcript of session follows ----- 421 Host ndcheg.uucp not found for mailer ddn. 550 evan@ndcheg.UUCP... Host unknown ----- Unsent message follows ----- Return-Path: Received: by OSCSUNA.osc.ohio-state.edu (4.0/SMI-DDN) id AA22999; Thu, 16 Jun 88 08:51:25 EDT Date: Thu, 16 Jun 88 08:51:25 EDT From: tom (Thomas Easterday) Message-Id: <8806161251.AA22999@OSCSUNA.osc.ohio-state.edu> To: ndcheg!evan Subject: Networks Unreachable The problem with the Univ. of Cinn. Monday night (until Wed 4:30pm ish) was unrelated to the router problem that was dicussed. This problem was a line problem which Cincinnati Bell repaired. Tom ----MESSAGE-END---- ----MESSAGE-BEGIN---- [126@edai.ed.ac.uk] <1988061613574300> From: tsa@edai.ed.ac.uk (Tom Alexander) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Looking for comments on the 15-pin ethernet connector Message-ID: <126@edai.ed.ac.uk> Date: 16 Jun 88 13:57:43 GMT References: <3352@phri.UUCP> Organization: AI Edinburgh Uni Lines: 53 From article <3352@phri.UUCP>, by roy@phri.UUCP (Roy Smith): > dmc@videovax.Tek.COM (Donald M. Craig) writes: >> I am looking for feedback on the quality and reliability of >> the slide latch mechanism used on the DB-15 ethernet connectors. > > In a nutshell, they suck! There is no doubt that the single most > common cause of problems in our entire network is loose ethernet tranciever > cables, particularly on the backs of Sun's which provide no mechanical > support for the cable at all. I agree entirely with the above comment. These bent bits of tin, laughingly described as retaining clips, are completely useless. They may work reasonably well with light, flexible cables but they certainly do nothing when used with the heavy, stiff transceiver drop cables. >> "I am the Component Engineer for connectors at Sun. In regards to your >> question concerning the Ethernet DB-15 [...] I am not aware of any >> significant problems with mechanical integrity of the lock, or for that >> matter with the connector in any aspect. > > I'm not given to public flamage, but this guy must have his head > firmly wedged in a dark place. If he's not aware of any problems, it because > he hasn't been listening. I've complained loudly about this on the net > before. I've complained to Sun field service. I've complained to Sun tech > support. Clearly those complaints havn't gotten back to the right people. > > The stupid little stamped sheet metal clips are simply not strong > enough to secure a connector with a big fat, heavy, and fairly stiff > tranciever cable on it. As long as the cable is secured so if can't move if > accidentally moved, it's OK. For example, on the tranciever ends, we lash > the cable to the main ethernet trunk cable with 2 (or sometimes 3) wire ties > a few inches away. But on systems which might move a little (like a deskside > Sun on wheels), or in situations where the cable might be disturbed (like > hanging off the back of a desk) forget it. > > What was wrong with good-old RS-232-style screws? Or, if they really > wanted a tool-less installation, why not Macintosh-style knurled screws, or > maybe even centronics-style wire bails? Does this guy never talk to field service people. We have complained bitterly to several field service engineers over the years. Hoods for this type of connector with knurled finger screws are readily available. I should add that Sun are not the only workstation supplier using this useless bit of bent tin as tranceiver drop cable retaining clamps. > I really don't know what the DIX guys had in mind when they designed > this connector. Administering a network is hard enough without having to > worry about which $5 connector is falling out. > -- > Roy Smith, System Administrator > Public Health Research Institute > 455 First Avenue, New York, NY 10016 > {allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net ----MESSAGE-END---- ----MESSAGE-BEGIN---- [179@iaoobelix.UUCP] <1988061615561400> From: woerz@iaoobelix.UUCP (Dieter Woerz) Newsgroups: comp.protocols.tcp-ip Subject: Problems with SLIP Keywords: SLIP, TCP/IP Message-ID: <179@iaoobelix.UUCP> Date: 16 Jun 88 15:56:14 GMT Sender: woerz@iaoobelix.UUCP Reply-To: woerz@iaoobelix.UUCP (Dieter Woerz) Organization: Fraunhofer Institut fuer Arbeitswirtschaft und Organisation Lines: 87 Hello, I had posted some time ago on comp.dcom.lans, but didn't get some satisfactory answers, so I decided to post this to the TCP/IP-wizards group in the hope to get more help. I have installed the program between a Sun 3/50 running SunOS 3.4 and a VAX 11/750 running 4.3BSD, but we have some severe problems with the connection. May be you can help me. My scenario is the following (Class B network 129.69, Subnetmask 0xffffff00): +--------------------+ +--------------------+ |Sun3/50 (SunOS 3.4) | |VAX 11/750 (4.3BSD) | | | sl0 sl0 | | | Slip IP .135.2 +-------------------------+ Slip IP .135.1 | | | | | |Ethernet IP .134.2 | |Ethernet IP .133.1 | +---------+----------+ +---------+----------+ | | 1. I can rlogin from the VAX to the Sun (Added routing info man- nually) 2. There is no exchange of routing info between the Sun and the VAX. 3. I can't connect directly to any node on the Ethernet connected to the Sun from the VAX. My netstat on Sun looks like that ((*) has been added manually) Destination Gateway Flags Refcnt Use Interface 129.69.135.0 129.69.135.2 UH 0 4278 sl0 129.69.135.1 129.69.135.2 UH 3 666 sl0 129.69.135.2 129.69.135.2 UH 0 0 sl0 129.69.134.0 129.69.134.2 U 10 35523 le0 129.69.135.0 129.69.135.2 U 0 0 sl0 129.69.0 129.69.134.2 U 2 4280 le0 default 129.69.135.2 U 0 6974 sl0 (*) 127.0.0 127.0.0.1 U 5 4989 lo0 After the startup, the netstat on the VAX looks like this: Destination Gateway Flags Refcnt Use Interface 129.69.133.1 127.0.0.1 UH 0 69 lo0 127.0.0.1 127.0.0.1 UH 0 0 lo0 129.69.135.2 129.69.135.1 UH 1 10 sl0 129.69.135 129.69.135.2 UG 3 547 sl0 129.69.133 129.69.133.13 UG 0 0 de0 129.69 129.69.133.1 U 0 49 de0 When the routing table entries have timed out, it looks like that: Destination Gateway Flags Refcnt Use Interface 129.69.133.1 127.0.0.1 UH 1 153 lo0 127.0.0.1 127.0.0.1 UH 0 0 lo0 Then, I have to manually reconfigure the interfaces and add the routes, which are marked with a (*) Destination Gateway Flags Refcnt Use Interface 129.69.133.1 127.0.0.1 UH 1 217 lo0 127.0.0.1 127.0.0.1 UH 0 0 lo0 129.69.135.2 129.69.135.1 UH 0 3 sl0 129.69 129.69.133.1 U 0 45 de0 129.69.134 129.69.135.1 U 1 327 sl0 (*) I hope, someone can help me correcting my problems. If someone needs more information, please contact me. Please reply by mail, because I think this is not in the interest of many other readers of this newsgroup. If there is interest, I will post a summary to both comp.dcom.lans and comp.protocols.tcp-ip, as soon as the link is working as desired. Thanks in advance -- ------------------------------------------------------------------------------ Dieter Woerz Fraunhofer Institut fuer Arbeitswirtschaft und Organisation Abt. 453 Holzgartenstrasse 17 D-7000 Stuttgart 1 W-Germany BITNET: iaoobel.uucp!woerz@unido.bitnet UUCP: ...{uunet!unido, pyramid}!iaoobel!woerz ----MESSAGE-END---- ----MESSAGE-BEGIN---- [3356@phri.UUCP] <1988061616043100> From: roy@phri.UUCP (Roy Smith) Newsgroups: comp.protocols.tcp-ip Subject: Re: Looking for comments on the 15-pin ethernet connector Message-ID: <3356@phri.UUCP> Date: 16 Jun 88 16:04:31 GMT References: <5788@bloom-beacon.MIT.EDU> Reply-To: roy@phri.UUCP (Roy Smith) Organization: Public Health Research Inst. (NY, NY) Lines: 39 wesommer@athena.mit.edu (William Sommerfeld) writes: > screw connectors with knurled knobs which have a slot > for a screwdriver in them Yeah, but... make sure you implement it right. I've seen some connectors of the type William is talking about in which the knurled plastic grip was longer than the metal screw shaft inside and the screwdriver slot on the end was nothing more than an indentation in the plastic; stick a screwdriver in it and turn and all you end up doing is making shreaded plastic. Also, while I'm on the subject, let's make those screws and threaded sockets out of steel, not brass. I know you're not supposed to gorilla-ize the screws, but it doesn't take much force to strip the threads on a 4-40 brass screw. How much more does a steel 4-40 screw cost than a brass one in quantities of thousands? A few tenths of a cent? How much does it cost in valuable time each time you strip one and have to fight to the the connector out? Tens of dollars? And one more thing, please, please, please, please, don't attach the threaded sockets with nuts which turn in the same direction as the screws on the connectors! Anybody who doesn't know what I'm talking about should take a look at Inmac part number 853 (female mounting screws). For an example of how to properly design a threaded socket, take a look at the back of a humble ADM-5 or ADM-3 -- steel sockets embedded so they can't come loose when you unscrew the connector. Hey, I'm sorry if I seem to be getting all hot and bothered about such a trivial thing but it's time the computer industry realized that this is important and it's not worth trying to save a buck or two on the connectors for a $100,000 piece of equipment (or even a $500 one). I used to think this stuff got designed so badly because nobody really cared; once I found out that Sun actually has a component engineer in charge of connectors, I just flipped! If Sun has one, I'm sure DEC and IBM and everybody else does too (maybe bigies like DEC and IBM have whole rooms full of connector engineers?). Damned if I can figure out what they do. -- Roy Smith, System Administrator Public Health Research Institute 455 First Avenue, New York, NY 10016 {allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1118@aucs.UUCP] <1988061617373500> From: paul@aucs.UUCP (Paul Steele) Newsgroups: comp.dcom.lans,comp.protocols.appletalk,comp.protocols.tcp-ip Subject: Netware vs. PC-NFS Message-ID: <1118@aucs.UUCP> Date: 16 Jun 88 17:37:35 GMT Reply-To: paul@aucs.UUCP (Paul Steele) Distribution: na Organization: School of Computer Science, Acadia Univ., Nova Scotia Lines: 14 Has anyone had any done a comparison between Novell Netware (2.1) and PC-NFS? We are debating whether a PC-Lab would be better using a Sun for a file server with PC-NFS, or using Netware. Also, is NFS available for Macintoshes? Since our news feed is not very reliable, please send any responses to my BITNET address below if possible. Thanks. -- Paul H. Steele USENET: {uunet|watmath|utai|garfield}!dalcs!aucs!Paul Acadia University BITNET: Paul@Acadia Wolfville, NS Internet: Paul%Acadia.BITNET@CUNYVM.CUNY.EDU CANADA B0P 1X0 (902) 542-2201x587 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [19519.582492787@glacier.ics.uci.edu] <1988061619330700> From: raj@GLACIER.ICS.UCI.EDU (Richard Johnson) Newsgroups: comp.protocols.tcp-ip Subject: Re: Looking for comments on the 15-pin ethernet connector Message-ID: <19519.582492787@glacier.ics.uci.edu> Date: 16 Jun 88 19:33:07 GMT References: <23340@bu-cs.BU.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 28 We have a lot of Sun fileservers around here and thus we've had a lot of problems with the transceiver connectors. The problem with Sun equipment in particular is that the fashion in which the connector is attached to the outside of the ethernet board (same thing goes for the ethernet connector on the CPU board). The screws onto which the slide connector is supposed to catch are mounted on the OUTSIDE of the board whereas the connector itself is mounted on the INSIDE. This means that the transceiver cable connector can't make full contact with the one on the board. (I tried to draw this in this message but it's too difficult.) The problem is that the pins on the transceiver cable connector side don't go all of the way into the holes on the board side because the catches for the connector are mounted too far away from the top of the board side connector. (Take a look at it, you'll see.) We finally just removed the screws from both sides as well the slide latch and replaced them with screws going straight through the cable side connector and into the nuts on the board side connector. This allows the connectors to be close enough together so that they make good contact. We've never had problems with any that we done this to so this is the first thing I do whenever we start having problems now. If Sun would solve the basic problem, however (as described above) I think the latches would be just fine. ----------------------------------------------------------------------------- Richard A. Johnson raj@rome.ics.uci.edu (Internet) UCI ICS Assistant Technical Manager ucbvax!ucivax!raj (UUCP) Postmaster / Network Services raj@tertius.ics.uci.edu (via Nameservers) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [22108@amdcad.AMD.COM] <1988061620580300> From: phil@amdcad.AMD.COM (Phil Ngai) Newsgroups: comp.protocols.tcp-ip Subject: Re: Looking for comments on the 15-pin ethernet connector Message-ID: <22108@amdcad.AMD.COM> Date: 16 Jun 88 20:58:03 GMT References: <5788@bloom-beacon.MIT.EDU> <3356@phri.UUCP> Reply-To: phil@amdcad.UUCP (Phil Ngai) Organization: Advanced Micro Devices Lines: 18 In article <3356@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: >I used to think this >stuff got designed so badly because nobody really cared; once I found out that >Sun actually has a component engineer in charge of connectors, I just flipped! >If Sun has one, I'm sure DEC and IBM and everybody else does too (maybe bigies >like DEC and IBM have whole rooms full of connector engineers?). Damned if I >can figure out what they do. Well, if you don't care why should they care? If you care, let them know. Make a case out of it with your salesman. Tell people like Sun that they should follow the ISO 802.3 international standard for transceiver cable connectors and mount them on the OUTSIDE of the panel. Like DEC does. Many people do not realize how important this is. Many people have not looked at the connection system carefully. -- I speak for myself, not the company. Phil Ngai, {ucbvax,decwrl,allegra}!amdcad!phil or phil@amd.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [27666@pyramid.pyramid.com] <1988061622541800> From: schamp@pyrglass (Craig Schamp) Newsgroups: comp.protocols.tcp-ip Subject: Information sought on Van Jocobson's algorithm Message-ID: <27666@pyramid.pyramid.com> Date: 16 Jun 88 22:54:18 GMT Sender: daemon@pyramid.pyramid.com Reply-To: schamp@pyrglass.UUCP (Craig Schamp) Organization: Pyramid Technology Corp., Mountain View, CA Lines: 14 I've been away from the net for about a year now, so I missed what I presume to have been avid discussion about Van Jocobson's algorithm that was on the net recently. I'm very interested in reading more about this before SIGCOMM. Could someone point me in the right direction? Please send responses directly to me via e-mail. Thanks, Craig Schamp Pyramid Technology Corporation, Mountain View, CA (415) 965-7200 x4550 {allegra,ames,decwrl,hplabs,munnari,sun,uunet,utai}!pyramid!schamp schamp@pyramid.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [23249@teknowledge-vaxc.ARPA] <1988061701033700> From: mkhaw@teknowledge-vaxc.ARPA (Mike Khaw) Newsgroups: comp.unix.questions,comp.protocols.tcp-ip Subject: ftp hash marks in binary mode Message-ID: <23249@teknowledge-vaxc.ARPA> Date: 17 Jun 88 01:03:37 GMT Organization: Teknowledge, Inc., Palo Alto CA Lines: 10 If I'm transferring a file of length x*1024 bytes in BINARY mode in ftp, how do I calculate the number of hash marks that hash mode should print? (I know that in ASCII mode, I should see ceiling(x) hash marks.) Thanks, Mike Khaw -- internet: mkhaw@teknowledge.arpa uucp: {uunet|sun|ucbvax|decwrl|uw-beaver}!mkhaw%teknowledge-vaxc.arpa hardcopy: Teknowledge Inc, 1850 Embarcadero Rd, POB 10119, Palo Alto, CA 94303 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [534@mailrus.cc.umich.edu] <1988061702295600> From: emv@mailrus.cc.umich.edu (Edward Vielmetti) Newsgroups: comp.protocols.tcp-ip Subject: a.cc.umich.edu <-> euler.berkeley.edu problem. Message-ID: <534@mailrus.cc.umich.edu> Date: 17 Jun 88 02:29:56 GMT Sender: usenet@mailrus.cc.umich.edu Reply-To: emv@mailrus.cc.umich.edu (Edward Vielmetti) Organization: University of Michigan Computing Center, Ann Arbor Lines: 29 There's a piece of mail on a.cc.umich.edu (35.1.33.90) destined for euler.berkeley.edu that's been sitting around for a few days. If mail can't go from Michigan to Berkeley in a day, it's usually an indicator that something's quite wrong, so I decided to snoop around some. I called the Merit NOC and found this out: It's possible to FTP from the 35.1.1 network to 128.32.142.1 just fine, with no unusual delays. The traffic is routed through the proteon link to Cleveland (the one that was a source of problems earlier this week). It's impossible to FTP from the 35.1.33 network to 128.32.142.1, where 35.1.33 is connected to 35.1.1 with two proteons and a T1 in the middle of them. 35.1.1 - proteon - T1 - proteon - 35.1.33 As far as my limited ability to check into routing tables goes, everything looks OK. The only guess that I have at this point is that the packets take too many hops and are dropped somewhere. I can get to 128.32.140 and 128.32.137 just fine. Not knowing what the particular network looks like at Berkeley, it's hard to give any more information than this. Even if there are mailer problems at euler (could very well be) it's still an odd problem. --Ed Edward Vielmetti, U of Michigan mail group ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988061704145200> Received: from ccq.bbn.com by SRI-NIC.ARPA with TCP; Fri, 17 Jun 88 05:39:38 PDT Date: Fri, 17 Jun 88 08:14:52 EDT From: Ken Pogran Subject: Those D connectors To: tcp-ip@sri-nic.arpa (Say, don't we have a "components" mailing list or something? This hardly seems like something for TCP-IP. Oh, well.) I thought a bit of history might be interesting: The "D-series" connectors made their debut in the 1950s to interconnect military electronics "modules", which at the time were assemblies in metal boxes that plugged into "pans" and "trays". Interestingly, they were NOT designed for cable applications and they were NOT designed to support weight: the modules in their little boxes were supported mechanically by the pans and trays. The connectors were, however, pretty rugged -- they were all MIL-SPEC varieties. By the way, to give an idea of the size and scale of things at the time, they were referred to in 1960s connector literature as "D-subminiature" connectors. The Bell System began the large-scale use of these connectors on cables with the introduction of DataPhones (Bell's trademark for their modem service). Remember the rather ornate-looking light gray hard plastic shells? One advantage of the D-series connectors was the density of pins, and their use really took off -- especially for cable applications, precisely what they were NOT designed for! Manufacturers have tried a lot of ideas to cope with cables and their weight, with not a lot of success; the basic design of the connectors just isn't intended for it. And couple that with cost-reduction efforts (seen any MIL-SPEC versions of these connectors in products you've bought recently?) which have made many of the connectors even flimsier and you have a recipe for trouble. On the other hand, there's the overkill approach: The old, nearly-impossible-to-get $75 48-series round connector that BBN spec'ed a long, long time ago for the 1822 Distant Interface connector ... (since replaced by a 37-pin D connector, of course!) Ken Pogran ----MESSAGE-END---- ----MESSAGE-BEGIN---- [724@cernvax.UUCP] <1988061706242800> From: jmg@cernvax.UUCP (jmg) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Looking for comments on the 15-pin ethernet connector Message-ID: <724@cernvax.UUCP> Date: 17 Jun 88 06:24:28 GMT References: <5047@videovax.Tek.COM> <3352@phri.UUCP> Reply-To: jmg@cernvax.UUCP () Organization: CERN European Laboratory for Particle Physics, CH-1211 Geneva, Switzerland Lines: 12 One other funny (correlates with the bread and butter law): on the fan-out units which we have the connector has to be pushed upwards to lock. From then on some evil force (Isaac Newton had a word for it!) is constantly trying to unlock it again, and each slight movement helps this evil force. Oh, how simple it would have been to invert the connector. The force is against you! -- _ _ o | __ | jmg@cernvax.uucp | | | | _ / \ _ __ _ __ _| jmg@cernvax.bitnet | | | | |_) /_) | __/_) | (___\ | (_/ | J. M. Gerard, Div. DD, CERN, | | |_|_| \_/\___ \__/ \___| (_|_| \_|_ 1211 Geneva 23, Switzerland ----MESSAGE-END---- ----MESSAGE-BEGIN---- [3053@ihlpe.ATT.COM] <1988061706525400> From: billq@ihlpe.ATT.COM (Quayle) Newsgroups: comp.protocols.tcp-ip Subject: Re: Looking for comments on the 15-pin ethernet connector Summary: NO MORE SLIDE LOCKS! Message-ID: <3053@ihlpe.ATT.COM> Date: 17 Jun 88 06:52:54 GMT References: <5047@videovax.Tek.COM> <8806151700.AA03253@ucbvax.Berkeley.EDU> Organization: AT&T Bell Laboratories - Naperville, Illinois Lines: 45 In article <8806151700.AA03253@ucbvax.Berkeley.EDU>, brescia@PARK-STREET.BBN.COM (Mike Brescia) writes: # # > I am looking for feedback on the quality and reliability of # > the slide latch mechanism used on the DB-15 ethernet connectors. # # > The Society of Motion Picture and Television Engineers has a # > standard known as RP-125 which specifies a parallel digital # > television interface. The connector for that interface is # > a 25 pin D-type (DB-25) with a slide latch like the ethernet # > connector. The RP-125 standard is up for revision, ... # # So far, I have seen people flaming the slide latch, but no comment on the # Dtype connectors. While using screws to replace the slide latch helps in some # cases, the main problem seems to be that the long, narrow connector with 2 # rows of pins cannot withstand stress from a heavy or thick or stiff cable. # There should be some analysis of why you should not use cable that is an inch # in diameter to contain 18 individually shielded twisted pairs for your # rs422/rs449 and try to connect it with a DC-37. # # The slide latch can only handle a little stress on the long dimension, and can # handle none on the narrow dimension. The DB15 would be ok with a ribbon # cable, because the ribbon is both light and flexible, and a well fitted slide # latch would lock it in place, but then you would not even need a lock because # the friction of the connector would keep it it. # # So, if SMPTE is going to do it right, they need to consider the mechanical # characteristics of the locking mechanism, as well as the ease of connection # and disconnection. Outside the Ethernet realm, and in an industry that required a connector that would withstand strain due to cable motion, we used an Amphenol MS connector. For those unfamiliar, this is a round, keyed connector, with a screw-on shell. Those things would withstand any ammount of cable motion (not to mention some pretty nasty envrironmental hazards), without the least bit of wear or loss of contact. BTW, as our net grows to nearly fifty nodes, I'm still the only one I trust manufacturing and installing those $*^%*&^*$ drop cables!!! W.R. Quayle AT&T Bell Labs. Disclaimer: I have no connection (beit slidelock or otherwise) to any company mentioned in my reply. My ideas are my personal feelings only! ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806171904.AA22084@ucbvax.Berkeley.EDU] <1988061712145200> From: pogran@CCQ.BBN.COM (Ken Pogran) Newsgroups: comp.protocols.tcp-ip Subject: Those D connectors Message-ID: <8806171904.AA22084@ucbvax.Berkeley.EDU> Date: 17 Jun 88 12:14:52 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 37 (Say, don't we have a "components" mailing list or something? This hardly seems like something for TCP-IP. Oh, well.) I thought a bit of history might be interesting: The "D-series" connectors made their debut in the 1950s to interconnect military electronics "modules", which at the time were assemblies in metal boxes that plugged into "pans" and "trays". Interestingly, they were NOT designed for cable applications and they were NOT designed to support weight: the modules in their little boxes were supported mechanically by the pans and trays. The connectors were, however, pretty rugged -- they were all MIL-SPEC varieties. By the way, to give an idea of the size and scale of things at the time, they were referred to in 1960s connector literature as "D-subminiature" connectors. The Bell System began the large-scale use of these connectors on cables with the introduction of DataPhones (Bell's trademark for their modem service). Remember the rather ornate-looking light gray hard plastic shells? One advantage of the D-series connectors was the density of pins, and their use really took off -- especially for cable applications, precisely what they were NOT designed for! Manufacturers have tried a lot of ideas to cope with cables and their weight, with not a lot of success; the basic design of the connectors just isn't intended for it. And couple that with cost-reduction efforts (seen any MIL-SPEC versions of these connectors in products you've bought recently?) which have made many of the connectors even flimsier and you have a recipe for trouble. On the other hand, there's the overkill approach: The old, nearly-impossible-to-get $75 48-series round connector that BBN spec'ed a long, long time ago for the 1822 Distant Interface connector ... (since replaced by a 37-pin D connector, of course!) Ken Pogran ----MESSAGE-END---- ----MESSAGE-BEGIN---- [3057@ihlpe.ATT.COM] <1988061716101000> From: billq@ihlpe.ATT.COM (Quayle) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Looking for comments on the 15-pin ethernet connector Summary: TIME FOR A CHANGE! Message-ID: <3057@ihlpe.ATT.COM> Date: 17 Jun 88 16:10:10 GMT References: <5047@videovax.Tek.COM> Organization: AT&T Bell Laboratories - Naperville, Illinois Lines: 23 <> First off, I'd like to know who designed the slide-lock mechanism. Did they get fired for it? If not, they should have! I would gladly change every connector on my net to something real if a new standard was aggreed upon. Second point: Who the heck is responsible for positioning the watchdog reset button on the Sun 3 Motherboard directly next to said-flimsy-*ss-switch? This individual needs shock therapy! <> W.R. Quayle Lab Coordinator - 52182 AT&T Bell Labs Naperville, Il Disclaimer: These thoughts are all mine! (My that felt good!) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806171739.AA19848@sccgate.scc.com] <1988061717394400> From: oconnor@SCCGATE.SCC.COM (Michael J. O'Connor) Newsgroups: comp.protocols.tcp-ip Subject: 4.0 SOS questions Message-ID: <8806171739.AA19848@sccgate.scc.com> Date: 17 Jun 88 17:39:44 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 17 I've got some problems with our Sun OS (SOS) 4.0 machines and DDN services. They are all RoadRunners, but I've seen the same problem on a Sun-3 running SOS 4.0. The first problem is that I can't ftp into a 4.0 SOS machine unless I use the user name root. All other accounts are denied access. The local service people say there is a memo about ftp security being on by default but can't tell me how to undefault it. I can't find any mention of ftp security in the manual pages except for the old "anonymous" remarks. I haven't been able to find an analogue to ftpusers either. The second problem is that I can't get the ftp and telnet programs to use the name domain server. Named runs fine as does nslookup and the MX version of sendmail, but ftp and telnet tell me that any host not in the yellow system is unknown. I'm running ypserv with the old secret -i flag just like I do on our 3.n systems but have no joy. Does anyone know if the secret flag to ypserv has changed? Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1162@thumper.bellcore.com] <1988061717415600> From: dvw@thumper.bellcore.com (Dan V. Wilson) Newsgroups: comp.protocols.tcp-ip Subject: Re: Looking for comments on the 15-pin ethernet connector Summary: Slide locks = @&%$##%(*%#@ Message-ID: <1162@thumper.bellcore.com> Date: 17 Jun 88 17:41:56 GMT References: <5788@bloom-beacon.MIT.EDU> <3356@phri.UUCP> <22108@amdcad.AMD.COM> Organization: Bell Communications Research Lines: 45 In article <22108@amdcad.AMD.COM>, phil@amdcad.UUCP writes: > Well, if you don't care why should they care? If you care, let them > know. Make a case out of it with your salesman. Tell people like Sun > that they should follow the ISO 802.3 international standard for > transceiver cable connectors and mount them on the OUTSIDE of the > panel. Like DEC does. Many people do not realize how important this > is. Many people have not looked at the connection system carefully. > > -- > > I speak for myself, not the company. > Phil Ngai, {ucbvax,decwrl,allegra}!amdcad!phil or phil@amd.com Phil is absolutely right. My experience with the DB-15 connectors and the slide locks is that they work fine IF the slide is mounted directly on the connector body (are you listening, Sun?) AND the connector is mounted on the outside of the panel AND the posts are the proper height AND the slide hasn't been strained or bent AND the phase of the moon and several other planets is correct. My favorite fix is to make a short stub cable out of DB-15 crimp on connectors and a few inches of 15 conductor flat cable, and to insert this short cable between the tranceiver cable and the piece of equipment. I've found that this has eliminated problems with the transceiver cable connections on Sun 3/75's and 3/160's, which are notorious for having a thick panel between the connector and slide lock on the Ethernet connection. I know, I know, the stub cable probably radiates, but I don't care. I've found that the friction grip from the crimp-on connectors is usually better than that provided from the connector plus slide lock. One should note that Sun may use lots of DB-series connectors, but they DO NOT use slide locks to my knowledge other than on Ethernet connectors. They always use another type of lock, either the 'wings' (can't think of a better term), or screws. I find myself wishing that I believed in Hell just so I could hope the designer of the slide lock and the connector engineer at Sun could roast there. Honorable mention should probably go to the writers of the two original Ethernet specifications for not specifying the transceiver connectors more fully. Dan Wilson dvw@bellcore.com bellcore!dvw ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806172103.AA00200@sneezy] <1988061721035000> From: cpw%sneezy@LANL.GOV (C. Philip Wood) Newsgroups: comp.protocols.tcp-ip Subject: Re: PING with source/record route Message-ID: <8806172103.AA00200@sneezy> Date: 17 Jun 88 21:03:50 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 1 The sands have shifted, Lambda.lanl.gov is now 128.165.4.4 or 26.0.0.90. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [3360@phri.UUCP] <1988061801202200> From: roy@phri.UUCP (Roy Smith) Newsgroups: comp.protocols.tcp-ip Subject: Re: Looking for comments on the 15-pin ethernet connector Message-ID: <3360@phri.UUCP> Date: 18 Jun 88 01:20:22 GMT References: <16136.8806161312@brahma.cs.hw.ac.uk> Reply-To: roy@phri.UUCP (Roy Smith) Organization: Public Health Research Inst. (NY, NY) Lines: 21 andy@cs.hw.ac.UK writes: > About 3 years back we at Spider Systems decided that slidelocks were > useless, and ever since have been fitting screwlocks instead to all our > terminal servers, bridges and stuff. A big "Thank you!" to the folks at Spider for having the courage to stand up in public and (proudly) admit that they did something non-standard because it was better. Not just better, but a hell of a lot better, and downward-compatable to boot! Now all we have to is get all the other network vendors to do the same thing (and get catalog houses like Inmac to start stocking screw-post drop cables). Sun may say "The network is the computer" but I say "the connector is the network"! Could you imagine if 50 companies a day, I say 50 companies a day stood up and said "slide locks suck" and started shipping screw-in ethernet connectors? I'd be a revolution, friends. (Apologies to Arlo Guthrie). -- Roy Smith, System Administrator Public Health Research Institute 455 First Avenue, New York, NY 10016 {allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988061813540000> Received: from G.BBN.COM by SRI-NIC.ARPA with TCP; Sat, 18 Jun 88 14:55:02 PDT Date: 18 Jun 1988 17:54-EDT Sender: URBANIAK@G.BBN.COM Subject: Ethernet Addresses and Type Field From: URBANIAK@G.BBN.COM To: tcp-ip@SRI-NIC.ARPA, big-lan@SUVM.ACS.SYR.EDU Cc: Urbaniak@G.BBN.COM Message-ID: <[G.BBN.COM]18-Jun-88 17:54:55.URBANIAK> Since its last posting, a substantial number of individuals and some vendors have contributed additions and corrections to this list. Some Known Ethernet and IEEE802.3 "Type" Fields 6/18/88 The 13th and 14th octets of an Ethernet or IEEE802.3 packet (after the preamble) consist of the "Type" or "Length" field. These values are managed by XEROX. Some assignments are public, others private. Current information includes: Xerox Public Ethernet Packet Type documentation; IEEE802.3 Std; NIC RFC960; contributions from network managers and vendors. Hex 0000-05DC IEEE802.3 Length Field (0.:1500.) 0200 Xerox PUP (conflicts with IEEE802.3 Length Field range) (see 0A00) 0201 Xerox PUP Address Translation (conflicts ...) (see 0A01) 0600 Xerox NS IDP * 0800 DOD Internet Protocol (IP) * # 0801 X.75 Internet 0802 NBS Internet 0803 ECMA Internet 0804 CHAOSnet 0805 X.25 Level 3 0806 Address Resolution Protocol (ARP) * (for IP and for CHAOS) 0807 XNS Compatibility 081C Symbolics Private 0888 Xyplex 0900 Ungermann-Bass network debugger 0A00 Xerox IEEE802.3 PUP 0A01 Xerox IEEE802.3 PUP Address Translation 0BAD Banyan Systems 1000 Berkeley Trailer negotiation 1001-100F Berkeley Trailer encapsulation 1600 VALID-machine protocol? * 5208 BBN Simnet Private % 6000 DEC unassigned 6001 DEC Maintenance Operation Protocol (MOP) Dump/Load Assistance 6002 DEC Maintenance Operation Protocol (MOP) Remote Console 6003 DECNET Phase IV 6004 DEC Local Area Transport (LAT) 6005 DEC diagnostic protocol (at interface initialization?) 6006 DEC customer protocol 6007 DEC Local Area VAX Cluster (LAVC) 6008 DEC unassigned 6009 DEC unassigned 7000 Ungermann-Bass download 7002 Ungermann-Bass diagnostic/loopback 8003 Cronus VLN 8004 Cronus Direct 8005 HP Probe protocol 8006 Nestar 8010 Excelan 8013 Silicon Graphics diagnostic 8014 Silicon Graphics network games 8015 Silicon Graphics reserved 8016 Silicon Graphics XNS NameServer, bounce server 8019 Apollo DOMAIN 8035 Reverse Address Resolution Protocol (RARP) 8038 DEC LanBridge Management 8039 DEC unassigned 803A DEC unassigned 803B DEC unassigned 803C DEC unassigned 803D DEC Ethernet Encryption Protocol 803E DEC unassigned 803F DEC LAN Traffic Monitor Protocol 8040 DEC unassigned 8041 DEC unassigned 8042 DEC unassigned 805B Stanford V Kernel, experimental 805C Stanford V Kernel, production 807C Merit Internodal 8080 Vitalink TransLAN III Management 809B EtherTalk (AppleTalk over Ethernet) 80DE TRFS (Integrated Solutions Transparent Remote File System) 80F3 AppleTalk Address Resolution Protocol (AARP) 8107 Symbolics Private 8108 Symbolics Private 8109 Symbolics Private 8137 Novell 9000 Loopback (Configuration Test Protocol) 9001 Bridge Communications XNS Systems Management 9002 Bridge Communications TCP/IP Systems Management FF00 BBN VITAL-LanBridge cache wakeups % * These protocols use Ethernet broadcast, where multicast would be preferable. # BBN Butterfly Gateways also use 0800 for non-IP, with IP version field = 3. % BBN Private Protocols, not registered Some Known Ethernet Vendor Addresses 6/18/88 Ethernet hardware addresses are 48 bits, expressed as 12 hexadecimal digits (0-9, plus A-F, capitalized). These 12 hex digits consist of the first/left 6 digits (which should match the vendor of the Ethernet interface within the station) and the last/right 6 digits which specify the interface serial number for that interface vendor. Ethernet addresses might be written unhyphenated (e.g. 123456789ABC), or with one hyphen (e.g. 123456-789ABC), but should be written hyphenated by octets (e.g. 12-34-56-78-9A-BC). These addresses are physical station addresses, not multicast nor broadcast, so the second hex digit (reading from the left) will be even, not odd. At present, it is not clear how the IEEE assigns Ethernet block addresses. Whether in blocks of 2**24 or 2**25, and whether multicasts are assigned with that block or separately. A portion of the vendor block address is reportedly assigned serially, with the other portion intentionally assigned randomly. If there is a global algorithm for which addresses are designated to be physical (in a chipset) versus logical (assigned in software), or globally-assigned versus locally-assigned addresses, some of the known addresses do not follow the scheme. 00000C Western Digital 00002A TRW 00005A S & Koch 000093 Proteon 00009F Ameristar Technology 0000AA Xerox Xerox machines 0000C0 Western Digital? 0000DD Gould 000102 BBN BBN internal usage (not registered) 001700 Kabel 00DD00 Ungermann-Bass 00DD01 Ungermann-Bass 020701 Interlan UNIBUS or QBUS machines, Apollo 020406 BBN BBN internal usage (not registered) 02608C 3Com IBM PC; Imagen; Valid 02CF1F CMC Masscomp, Silicon Graphics 080002 Bridge 080005 Symbolics Symbolics LISP machines 080008 BBN 080009 Hewlett-Packard 080010 AT+T 080014 Excelan BBN Butterfly, Masscomp, Silicon Graphics 080017 NSC 08001A Data General 08001B Data General 08001E Apollo 080020 Sun Sun machines 080025 CDC 080028 TI Explorer 08002B DEC UNIBUS or QBUS machines, VAXen, LANBridges (DEUNA, DEQNA, DELUA) 080045 ??? 080047 Sequent 080049 Univation 08004C Encore 08004E BICC 080068 Ridge 080069 Silicon Graphics 08006E Excelan 08007C Vitalink TransLAN III 080089 Kinetics AppleTalk-Ethernet interface 08008B Pyramid 08008D XyVision XyVision machines AA0003 DEC Global physical address for some DEC machines AA0004 DEC Local logical address for systems running DECNET Some Known Ethernet Multicast Addresses 6/18/88 Ethernet Type Address Field Usage Multicast Addresses: 09-00-09-xx-xx-xx ???? HP multicasts 09-00-2B-01-00-00 8038 DEC LanBridge Copy packets 09-00-2B-01-00-01 8038 DEC LanBridge Hello packets 1 packet per second, sent by the designated LanBridge AB-00-00-01-00-00 6001 DEC Maintenance Operation Protocol (MOP) Dump/Load Assistance AB-00-00-02-00-00 6002 DEC Maintenance Operation Protocol (MOP) Remote Console 1 System ID packet every 8-10 minutes, by every: DEC LanBridge DEC DEUNA interface DEC DELUA interface DEC DEQNA interface (in a certain mode) AB-00-00-03-00-00 6003 DECNET Phase IV end node Hello packets 1 packet every 15 seconds, sent by each DECNET host AB-00-00-04-00-00 6003 DECNET Phase IV Router Hello packets 1 packet every 15 seconds, sent by the DECNET router AB-00-00-05-00-00 ???? Reserved DEC through AB-00-03-FF-FF-FF AB-00-04-00-00-00 ???? Reserved DEC customer private use through AB-00-04-00-FF-FF AB-00-04-01-xx-yy 6007 DEC Local Area VAX Cluster groups CF-00-00-00-00-00 9000 Ethernet Configuration Test protocol (Loopback) Broadcast Address: FF-FF-FF-FF-FF-FF 0600 XNS packets, Hello or gateway search? 6 packets every 15 seconds, per XNS station FF-FF-FF-FF-FF-FF 0800 IP (e.g. RWHOD via UDP) as needed FF-FF-FF-FF-FF-FF 0806 ARP (for IP and CHAOS) as needed FF-FF-FF-FF-FF-FF 1600 VALID packets, Hello or gateway search? 1 packets every 30 seconds, per VALID station ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12407461411.16.NIC@SRI-NIC.ARPA] <1988061817010800> From: NIC@SRI-NIC.ARPA (DDN Reference) Newsgroups: comp.protocols.tcp-ip Subject: Re: Need rfc 877 Message-ID: <12407461411.16.NIC@SRI-NIC.ARPA> Date: 18 Jun 88 17:01:08 GMT References: <3c910032.8a06@apollo.uucp> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 41 RFCs are available via electronic mail from the NIC. To get RFC 877 from the NIC send a message to SERVICE@SRI-NIC.ARPA with the command RFC 877 in the subject line of your message. Here is some information about using SERVICE. NIC Mail Services June 1988 This is an automated service provided by the DDN Network Information Center. It allows access to NIC documents and information via ordinary electronic mail. This is especially useful for people who do not have access to the NIC via a direct Internet link, such as BITNET, CSNET and UUCP sites. To use the mail service, send a mail message to SERVICE@SRI-NIC.ARPA. In the SUBJECT field, request the type of service you wish followed by any needed arguments. The message body is normally ignored. Large files will be broken into smaller separate messages. The information you request will be sent back to you as soon as possible. The following services are currently available: HELP This message; a list of current services. RFC nnn nnn is the RFC number or the word INDEX. IEN nnn nnn is the IEN number or the word INDEX. NETINFO xxx xxx is a file name or the word INDEX. SEND xxx xxx is a fully specified file name. HOST xxx Returns information about host xxx. WHOIS xxx Returns information about xxx from the WHOIS service. Use "WHOIS HELP" for information on how to use WHOIS. Example SUBJECT lines: HELP RFC 822 RFC INDEX NETINFO DOMAIN-TEMPLATE.TXT SEND IDEA:IDEA0002-00.TXT HOST SRI-NIC.ARPA WHOIS LOTTOR, MARK Send comments or suggestions to SUGGESTIONS@SRI-NIC.ARPA. Send questions and bug reports to NIC@SRI-NIC.ARPA. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806181919.AA22300@orc.olivetti.com] <1988061819194500> From: roode@orc.olivetti.COM (David Roode) Newsgroups: comp.protocols.tcp-ip Subject: Ethernet transceiver connector slide-locks Message-ID: <8806181919.AA22300@orc.olivetti.com> Date: 18 Jun 88 19:19:45 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 23 A variable which significantly affects reliability of the slide-lock is the weight of the transceiver cable. Some manufacturers have much heavier cable than others. Some (DEC) make an extra-light cable for use when the run is not too far. Also, right angle connectors are available from some transceiver cable manufacturers (DEC again). I second the comments for strain relief. Even the alternative use of screws and nut posts is subject to mechanical damage due to the vulnerable way these jacks are often located, and strain relief via an offset bar or other means would be a good idea regardless of the use of slide locks. The slide locks are excellent when used to couple two transceiver cables together. In many cases the built in thin-net transceiver makes operation without external transceivers over thin-net more desirable than using the 15-pin transceiver port anyway. For the price of 10 transceivers, a multiport thin repeater can be purchased. This will allow operation of 8 independent thin segments with a length of 180 meters each, fanning out from the multiport repeater. On each segment, up to 31 thin transceivers may be located. Holding each segment to 5 or so stations yields a compartmentalized network which is easy to debug, and robust in the event of a disturbance to the (now thin rather than thick) coax. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[G.BBN.COM]18-Jun-88.17:54:55.URBANIAK] <1988061821540000> From: URBANIAK@G.BBN.COM Newsgroups: comp.protocols.tcp-ip Subject: Ethernet Addresses and Type Field Message-ID: <[G.BBN.COM]18-Jun-88.17:54:55.URBANIAK> Date: 18 Jun 88 21:54:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 199 Since its last posting, a substantial number of individuals and some vendors have contributed additions and corrections to this list. Some Known Ethernet and IEEE802.3 "Type" Fields 6/18/88 The 13th and 14th octets of an Ethernet or IEEE802.3 packet (after the preamble) consist of the "Type" or "Length" field. These values are managed by XEROX. Some assignments are public, others private. Current information includes: Xerox Public Ethernet Packet Type documentation; IEEE802.3 Std; NIC RFC960; contributions from network managers and vendors. Hex 0000-05DC IEEE802.3 Length Field (0.:1500.) 0200 Xerox PUP (conflicts with IEEE802.3 Length Field range) (see 0A00) 0201 Xerox PUP Address Translation (conflicts ...) (see 0A01) 0600 Xerox NS IDP * 0800 DOD Internet Protocol (IP) * # 0801 X.75 Internet 0802 NBS Internet 0803 ECMA Internet 0804 CHAOSnet 0805 X.25 Level 3 0806 Address Resolution Protocol (ARP) * (for IP and for CHAOS) 0807 XNS Compatibility 081C Symbolics Private 0888 Xyplex 0900 Ungermann-Bass network debugger 0A00 Xerox IEEE802.3 PUP 0A01 Xerox IEEE802.3 PUP Address Translation 0BAD Banyan Systems 1000 Berkeley Trailer negotiation 1001-100F Berkeley Trailer encapsulation 1600 VALID-machine protocol? * 5208 BBN Simnet Private % 6000 DEC unassigned 6001 DEC Maintenance Operation Protocol (MOP) Dump/Load Assistance 6002 DEC Maintenance Operation Protocol (MOP) Remote Console 6003 DECNET Phase IV 6004 DEC Local Area Transport (LAT) 6005 DEC diagnostic protocol (at interface initialization?) 6006 DEC customer protocol 6007 DEC Local Area VAX Cluster (LAVC) 6008 DEC unassigned 6009 DEC unassigned 7000 Ungermann-Bass download 7002 Ungermann-Bass diagnostic/loopback 8003 Cronus VLN 8004 Cronus Direct 8005 HP Probe protocol 8006 Nestar 8010 Excelan 8013 Silicon Graphics diagnostic 8014 Silicon Graphics network games 8015 Silicon Graphics reserved 8016 Silicon Graphics XNS NameServer, bounce server 8019 Apollo DOMAIN 8035 Reverse Address Resolution Protocol (RARP) 8038 DEC LanBridge Management 8039 DEC unassigned 803A DEC unassigned 803B DEC unassigned 803C DEC unassigned 803D DEC Ethernet Encryption Protocol 803E DEC unassigned 803F DEC LAN Traffic Monitor Protocol 8040 DEC unassigned 8041 DEC unassigned 8042 DEC unassigned 805B Stanford V Kernel, experimental 805C Stanford V Kernel, production 807C Merit Internodal 8080 Vitalink TransLAN III Management 809B EtherTalk (AppleTalk over Ethernet) 80DE TRFS (Integrated Solutions Transparent Remote File System) 80F3 AppleTalk Address Resolution Protocol (AARP) 8107 Symbolics Private 8108 Symbolics Private 8109 Symbolics Private 8137 Novell 9000 Loopback (Configuration Test Protocol) 9001 Bridge Communications XNS Systems Management 9002 Bridge Communications TCP/IP Systems Management FF00 BBN VITAL-LanBridge cache wakeups % * These protocols use Ethernet broadcast, where multicast would be preferable. # BBN Butterfly Gateways also use 0800 for non-IP, with IP version field = 3. % BBN Private Protocols, not registered Some Known Ethernet Vendor Addresses 6/18/88 Ethernet hardware addresses are 48 bits, expressed as 12 hexadecimal digits (0-9, plus A-F, capitalized). These 12 hex digits consist of the first/left 6 digits (which should match the vendor of the Ethernet interface within the station) and the last/right 6 digits which specify the interface serial number for that interface vendor. Ethernet addresses might be written unhyphenated (e.g. 123456789ABC), or with one hyphen (e.g. 123456-789ABC), but should be written hyphenated by octets (e.g. 12-34-56-78-9A-BC). These addresses are physical station addresses, not multicast nor broadcast, so the second hex digit (reading from the left) will be even, not odd. At present, it is not clear how the IEEE assigns Ethernet block addresses. Whether in blocks of 2**24 or 2**25, and whether multicasts are assigned with that block or separately. A portion of the vendor block address is reportedly assigned serially, with the other portion intentionally assigned randomly. If there is a global algorithm for which addresses are designated to be physical (in a chipset) versus logical (assigned in software), or globally-assigned versus locally-assigned addresses, some of the known addresses do not follow the scheme. 00000C Western Digital 00002A TRW 00005A S & Koch 000093 Proteon 00009F Ameristar Technology 0000AA Xerox Xerox machines 0000C0 Western Digital? 0000DD Gould 000102 BBN BBN internal usage (not registered) 001700 Kabel 00DD00 Ungermann-Bass 00DD01 Ungermann-Bass 020701 Interlan UNIBUS or QBUS machines, Apollo 020406 BBN BBN internal usage (not registered) 02608C 3Com IBM PC; Imagen; Valid 02CF1F CMC Masscomp, Silicon Graphics 080002 Bridge 080005 Symbolics Symbolics LISP machines 080008 BBN 080009 Hewlett-Packard 080010 AT+T 080014 Excelan BBN Butterfly, Masscomp, Silicon Graphics 080017 NSC 08001A Data General 08001B Data General 08001E Apollo 080020 Sun Sun machines 080025 CDC 080028 TI Explorer 08002B DEC UNIBUS or QBUS machines, VAXen, LANBridges (DEUNA, DEQNA, DELUA) 080045 ??? 080047 Sequent 080049 Univation 08004C Encore 08004E BICC 080068 Ridge 080069 Silicon Graphics 08006E Excelan 08007C Vitalink TransLAN III 080089 Kinetics AppleTalk-Ethernet interface 08008B Pyramid 08008D XyVision XyVision machines AA0003 DEC Global physical address for some DEC machines AA0004 DEC Local logical address for systems running DECNET Some Known Ethernet Multicast Addresses 6/18/88 Ethernet Type Address Field Usage Multicast Addresses: 09-00-09-xx-xx-xx ???? HP multicasts 09-00-2B-01-00-00 8038 DEC LanBridge Copy packets 09-00-2B-01-00-01 8038 DEC LanBridge Hello packets 1 packet per second, sent by the designated LanBridge AB-00-00-01-00-00 6001 DEC Maintenance Operation Protocol (MOP) Dump/Load Assistance AB-00-00-02-00-00 6002 DEC Maintenance Operation Protocol (MOP) Remote Console 1 System ID packet every 8-10 minutes, by every: DEC LanBridge DEC DEUNA interface DEC DELUA interface DEC DEQNA interface (in a certain mode) AB-00-00-03-00-00 6003 DECNET Phase IV end node Hello packets 1 packet every 15 seconds, sent by each DECNET host AB-00-00-04-00-00 6003 DECNET Phase IV Router Hello packets 1 packet every 15 seconds, sent by the DECNET router AB-00-00-05-00-00 ???? Reserved DEC through AB-00-03-FF-FF-FF AB-00-04-00-00-00 ???? Reserved DEC customer private use through AB-00-04-00-FF-FF AB-00-04-01-xx-yy 6007 DEC Local Area VAX Cluster groups CF-00-00-00-00-00 9000 Ethernet Configuration Test protocol (Loopback) Broadcast Address: FF-FF-FF-FF-FF-FF 0600 XNS packets, Hello or gateway search? 6 packets every 15 seconds, per XNS station FF-FF-FF-FF-FF-FF 0800 IP (e.g. RWHOD via UDP) as needed FF-FF-FF-FF-FF-FF 0806 ARP (for IP and CHAOS) as needed FF-FF-FF-FF-FF-FF 1600 VALID packets, Hello or gateway search? 1 packets every 30 seconds, per VALID station ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806190209.AA22526@orc.olivetti.com] <1988061902092700> From: roode@orc.olivetti.COM (David Roode) Newsgroups: comp.protocols.tcp-ip Subject: Re: Cisco terminal servers? Message-ID: <8806190209.AA22526@orc.olivetti.com> Date: 19 Jun 88 02:09:27 GMT References: <8806150420.AA20750@ucbvax.Berkeley.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: Olivetti Research Center, Menlo Park, CA Lines: 30 I've used the cisco Terminal servers for 2 years now, and been very happy with them. It's the same box as their gateway, and the code load etc. is the same, so if you deal with both your personal system-entity count is only incremented by one. . It either boots from PROM or down from the net. The configuration can be changed from any terminal by entering a password. The normal method is to download a modified configuration file from a Unix server. They also offer their normal bubble memory option so the configuration doesn't have to be downloaded either, but it always can be, if desired. The reliability is excellent, as is the performance (can put up to 96 terminal lines in a single box, though I only put 80 and in our (typical) situation rarely saw more than 40 active at once. They now offer a 68020 option on the processor, and the terminal server supports SLIP to typical PC-based products or compatible. Estimate is that not too many of these should be flying full tilt at once-- about 8 or so is the estimate I had, for the 68000 CPU. Main memory is 1mb, and the configuration and operation is fairly user friendly. Each port can support a practically unlimited number of connections (telnet) simultaneously, with the ability to cycle between them conveniently, optionally notify if output waiting, etc. They also implement RLOGIN, and they can use multiple flavors of name servers or support hard-wire host name. They support milking machine mode to make RS232 ports in hunt groups available to provide Telnet server access to remote access to RS232 devices that do not support Telnet--such as dial out modems, devices with RS232 monitoring available, and the like. The devices can have their own unique emulated IP address or answer on alternate TCP service ports of the main boxes address. Finally, they also support parallel printers connected to the box and accessible to the network, as well as printers accessed over an ordinary serial port. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988061912040000> Received: from bluto.scc.com by SRI-NIC.ARPA with TCP; Sun, 19 Jun 88 13:11:00 PDT Date: 19 Jun 88 16:04:00 EDT From: Subject: Transceiver connectors To: "tcp-ip" Folks: Many of the writers addressing this topic have complained about bending of the slide lock metal (allowing the connector to become partially or fully dislodged). Still more writers have suggested various revenge scenarios against the inventor of the connector, and the abandonment of the connector's use. Maybe improvements can be made without resorting to the guillotine (or wire cutters). I have noted differnces in the "strength" of the slide locks provided on the cables from various suppliers. While the geometry may make the applied forces great, it may still be possible to spec a sufficiently "strong" slide lock to meet most user's needs. Perhaps the use of higher quality metal will be the only change necessary. Reinforcement of the slide lock through other methods such as ribbing and spot welding may also be usefull. I suppose we could machine high quality slide locks that were strong enough to lift a car (or at least a Sun Workstation). What I'm affraid of however, is that we'll start to see the mating chasis hardware failing. Wider use of right angle connectors, and provisions for EASILY lashing the cable to the equipment chasis should round out the remedy though. Bob Enger ----MESSAGE-END---- ----MESSAGE-BEGIN---- [3363@phri.UUCP] <1988061914032700> From: roy@phri.UUCP (Roy Smith) Newsgroups: comp.protocols.tcp-ip Subject: Re: Looking for comments on the 15-pin ethernet connector Message-ID: <3363@phri.UUCP> Date: 19 Jun 88 14:03:27 GMT References: <5788@bloom-beacon.MIT.EDU> <3356@phri.UUCP> <22108@amdcad.AMD.COM> <1162@thumper.bellcore.com> Reply-To: roy@phri.UUCP (Roy Smith) Organization: Public Health Research Inst. (NY, NY) Lines: 29 phil@amdcad.UUCP writes: > Tell people like Sun that they should follow the ISO 802.3 international > standard for transceiver cable connectors and mount them on the OUTSIDE of > the panel. (To the tune of "look what they've done to my song") Look what they've done to my SUN, DIX, Look what they've done to my SUN. They've gone and moved, the cable plug, From the outside to the in, DIX. Look what they've done to my SUN... > Like DEC does. Come to think of it, we've had a lot less trouble with out DELNI than with our Suns. Warning: do not construe the previous sentence to mean that I actually think the slide locks might work right if constructed strictly according to the specs. All I'm saying is that they wouldn't be as bad. > Many people have not looked at the connection system carefully. Perhaps, but I'll bet that lots of people have looked at the connection system angrily, obscenely, and with violent thoughts of destruction. -- Roy Smith, System Administrator Public Health Research Institute {allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net "The connector is the network" ----MESSAGE-END---- ----MESSAGE-BEGIN---- [23285@teknowledge-vaxc.ARPA] <1988061917441700> From: mkhaw@teknowledge-vaxc.ARPA (Mike Khaw) Newsgroups: comp.protocols.tcp-ip Subject: Re: Cisco terminal servers? Message-ID: <23285@teknowledge-vaxc.ARPA> Date: 19 Jun 88 17:44:17 GMT References: <8806190209.AA22526@orc.olivetti.com> Organization: Teknowledge, Inc., Palo Alto CA Lines: 16 > TCP service ports of the main boxes address. Finally, they also > support parallel printers connected to the box and accessible to the > network, as well as printers accessed over an ordinary serial port. Not all serial printers work with Cisco boxes. In particular, we were interested in moving our Apple LaserWriters off direct lines on one of our VAXes and putting them on a Cisco box so that they'd be more accessible over our LAN. We were told that it wouldn't work because the LaserWriters need to send data back to the host, and the Cisco serial printer connection didn't support that direction of data flow. Mike Khaw -- internet: mkhaw@teknowledge.arpa uucp: {uunet|sun|ucbvax|decwrl|uw-beaver}!mkhaw%teknowledge-vaxc.arpa hardcopy: Teknowledge Inc, 1850 Embarcadero Rd, POB 10119, Palo Alto, CA 94303 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806192137.AA28570@ucbvax.Berkeley.EDU] <1988061920040000> From: enger@GBURG.SCC.COM Newsgroups: comp.protocols.tcp-ip Subject: Transceiver connectors Message-ID: <8806192137.AA28570@ucbvax.Berkeley.EDU> Date: 19 Jun 88 20:04:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 22 Folks: Many of the writers addressing this topic have complained about bending of the slide lock metal (allowing the connector to become partially or fully dislodged). Still more writers have suggested various revenge scenarios against the inventor of the connector, and the abandonment of the connector's use. Maybe improvements can be made without resorting to the guillotine (or wire cutters). I have noted differnces in the "strength" of the slide locks provided on the cables from various suppliers. While the geometry may make the applied forces great, it may still be possible to spec a sufficiently "strong" slide lock to meet most user's needs. Perhaps the use of higher quality metal will be the only change necessary. Reinforcement of the slide lock through other methods such as ribbing and spot welding may also be usefull. I suppose we could machine high quality slide locks that were strong enough to lift a car (or at least a Sun Workstation). What I'm affraid of however, is that we'll start to see the mating chasis hardware failing. Wider use of right angle connectors, and provisions for EASILY lashing the cable to the equipment chasis should round out the remedy though. Bob Enger ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806192129.AA00190@bel.isi.edu] <1988061921291000> From: postel@VENERA.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Getting RFCs Message-ID: <8806192129.AA00190@bel.isi.edu> Date: 19 Jun 88 21:29:10 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 9 RFCs can be obtained via FTP from SRI-NIC.ARPA with the pathname RFC:RFCnnnn.TXT where "nnnn" refers to the number of the RFC. Log in with FTP username ANONYMOUS and password GUEST. The NIC also provides an automatic mail service for those sites which cannot use FTP. Address the request to SERVICE@SRI-NIC.ARPA and in the subject field of the message indicate the RFC number, as in "Subject: RFC nnnn". ----MESSAGE-END---- ----MESSAGE-BEGIN---- [114@snaring.UUCP] <1988061922150900> From: steve@alberta.UUCP (Steve Sutphen) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Looking for comments on the 15-pin ethernet connector Summary: slide locks and jack screws Keywords: slides, screws Message-ID: <114@snaring.UUCP> Date: 19 Jun 88 22:15:09 GMT References: <5047@videovax.Tek.COM> <1100@rel.eds.com> Reply-To: steve@snaring.UUCP (Steve Sutphen) Organization: U. of Alberta, Edmonton, Alberta, Canada Lines: 26 We have been using these slide lock connectors since before we installed Ethernet 5 years ago (they were also used on the HP 2621 terminals keyboards). While I will grant that we have had some problems with them, I wouldn't say that they have been a constant headache -- maybe our people take more care in the installation and use of equipment than at other sites. If someone is doing a new specification as was indicated in the original article then I think that they should take a serious look at the factors involved. I think that a major part of the problem is that 1) right angle shells are not as commonly available as they should be and people installing the cables don't bother choosing the correct connector (right angle vs strait). 2) the Transciever cable is part of the problem - it is very stiff, large and heavy. This excrabates all the other problems. I would not say that jack screws as are used on RS-232 connectors are completely fool proof though either. We have had our share of 1) stripped female locking nut 2) loose female locking screws because of binding of the jack screw, or simply beacuse the nut loosens (even when "properly" installed). For a while we would go through all the screws on new equipment and tightnen up the female locking screws. I even thought about putting locktite on some of the ones that were more problematic (on the old Sun-100 chassis). steve. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988062002540100> Received: from clash.cisco.com by SRI-NIC.ARPA with TCP; Mon, 20 Jun 88 09:56:16 PDT Received: from clash.cisco.com by clash.cisco.com with TCP; Mon, 20 Jun 88 09:54:03 PDT To: mkhaw@teknowledge-vaxc.arpa (Mike Khaw) Cc: tcp-ip@sri-nic.arpa, customer-service@cisco.com Subject: Re: Cisco terminal servers? In-Reply-To: Your message of 19 Jun 88 17:44:17 +0000. <23285@teknowledge-vaxc.ARPA> Date: Mon, 20 Jun 88 09:54:01 PDT From: lougheed@clash.cisco.com Hello Mike - cisco Terminal Servers have always supported data flow in both directions when attached to a printer. In house we use a Laserwriter attached to a Terminal Server in just such a manner. We can print to the Laserwriter from UNIX and TOPS-20 systems. You may wish to send mail to "customer-service@cisco.com" if you need some pointers in setting up such a printing arrangement. Kirk Lougheed cisco Systems ----MESSAGE-END---- ----MESSAGE-BEGIN---- [211@execu.UUCP] <1988062003080800> From: dewey@execu.UUCP (Dewey Henize) Newsgroups: comp.protocols.tcp-ip Subject: Re: Transceiver connectors Message-ID: <211@execu.UUCP> Date: 20 Jun 88 03:08:08 GMT References: <8806192137.AA28570@ucbvax.Berkeley.EDU> Reply-To: dewey@execu.UUCP (Dewey Henize) Organization: Execucom Systems Corp., Austin, Texas Lines: 38 In article <8806192137.AA28570@ucbvax.Berkeley.EDU> enger@GBURG.SCC.COM writes: >Folks: > Many of the writers addressing this topic have complained >about bending of the slide lock metal (allowing the connector to become >partially or fully dislodged). Still more writers have suggested various >revenge scenarios against the inventor of the connector, and the abandonment >of the connector's use. Maybe improvements can be made without resorting to >the guillotine (or wire cutters). > > I have noted differnces in the "strength" of the slide locks >provided on the cables from various suppliers. While the geometry may make >the applied forces great, it may still be possible to spec a sufficiently >"strong" slide lock to meet most user's needs. Perhaps the use of higher >quality metal will be the only change necessary. Reinforcement of the slide >lock through other methods such as ribbing and spot welding may also be usefull Perhaps. Heck, perhaps we could make it work with epoxy glue too! :-) At the base of the problem is a different outlook though - this industry had managed to get along with 9 pin, 25 pin, and all kinds of n-pin connectors pretty well - but we got used to using a method of screwing things in THAT WORKED AND WAS EFFECTIVE. The DIX plug isn't. It sucks on a good day, and is flaky the rest of the time. And as a great many of the testimonials here have indicated, the 'fix' is simple - get rid of the poor design, go with one or more variants of tried and true screwlocks. Now if you (any you, not just Bob) can come up with a good reason to go with a more complicated, less effective method, please convince me. Or, of course, go get a job in the Pentagon in procurement - there are likely to be a few slots there real real soon... -- =============================================================================== | execu!dewey Dewey Henize @ Execucom Systems Corp 512/346-3008 | | You don't think my employer APPROVES of these ideas, do you?? Sheesh! | =============================================================================== ----MESSAGE-END---- ----MESSAGE-BEGIN---- [880619-231239-6050@Xerox] <1988062006101100> From: JLarson.pa@XEROX.COM Newsgroups: comp.protocols.tcp-ip Subject: Re: 4.0 SOS questions Message-ID: <880619-231239-6050@Xerox> Date: 20 Jun 88 06:10:11 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 16 can't ftp into a 4.0 SOS machine unless I use the user name root anonymous ftp works fine to my Sun OS 4.0 machine, after following the setup instructions in the ftpd man page. I'm running ypserv with the old secret -i flag just like I do on our 3.n systems but have no joy. 4.0 versions of ypserv don't use the "-i" option. You have to build yp host.by* maps using the "-b" option of makedbm. (See the makedbm man page). You will probably also need a new version of ypserv from Sun which fixes a critical bug with the "-b" option. mallen@sun.com should be able to help you with this. John Larson, Xerox PARC ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988062007080600> Received: from CUNYVM.CUNY.EDU by SRI-NIC.ARPA with TCP; Mon, 20 Jun 88 22:23:50 PDT Received: from NIHCU.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 2009; Mon, 20 Jun 88 11:11:49 EDT To: TCP-IP@SRI-NIC.ARPA From: "Roger Fajman" Date: Mon, 20 Jun 88 11:08:06 EDT Subject: Re: Looking for comments on the 15-pin ethernet connector > We have a lot of Sun fileservers around here and thus we've had a lot of > problems with the transceiver connectors. The problem with Sun equipment > in particular is that the fashion in which the connector is attached to > the outside of the ethernet board (same thing goes for the ethernet connector > on the CPU board). The screws onto which the slide connector is supposed > to catch are mounted on the OUTSIDE of the board whereas the connector > itself is mounted on the INSIDE. This means that the transceiver cable > connector can't make full contact with the one on the board. (I tried to > draw this in this message but it's too difficult.) The problem is that > the pins on the transceiver cable connector side don't go all of the way > into the holes on the board side because the catches for the connector > are mounted too far away from the top of the board side connector. (Take > a look at it, you'll see.) Someone from Bridge Communications recently pointed out to me that there are washers under the posts on the transceiver cable connector. Removing the washers allows the cables to make much better contact in this situation. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [193@sunbim.UUCP] <1988062012154000> From: wg@sunbim.UUCP (Walter Geens) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: 15 pin ethernet connector Keywords: sun, ethernet, bad contact Message-ID: <193@sunbim.UUCP> Date: 20 Jun 88 12:15:40 GMT Organization: BIM, Everberg Belgium Lines: 22 I have just seen the messages on the problems of the ethernet connector.O.K.The desing is not a 100% succes but is in use from the ethernet specs 1 from Xerox I think from about 1973! It is even described in the standards. Hard to change I believe. Now a solution. I had myself 2 days of troubles finding out what went wrong adding a terminal server to a network not willing to talk to anything. Believe it or not, it was the connector making no contact at all! What was the real cause? In fact, it is not the slide latch that has to maintainthe contact but the plug itself. What I found was that the problem lies in the cable, not the connector on the server! Under the 2 studs on the cable-connector are in general 2 rings. These rings brings the studs higher up the plug so preventing on many machines to push in the plug far enough. In most cases only the tip of the pins make contact. So if the plug is moved a little you are in deep trouble! All depend on the cable manufacturing. !Remove at least one ring and if necessary all rings from under the studs so that the plugs mate eachother correctly! Then secure the latch. It will work forever and You can take an enjoying holiday. I have done this modi- fication about 30 times here at BIM and at customer sites and never had to return until now. I only can hope You will have the same succes! Boni Dens sunbim!sos ----MESSAGE-END---- ----MESSAGE-BEGIN---- [2142@julian.uwo.ca] <1988062013530600> From: purple@julian.uwo.ca (Lori Corrin) Newsgroups: comp.protocols.tcp-ip Subject: Xenix and TCP/IP Summary: info needed Message-ID: <2142@julian.uwo.ca> Date: 20 Jun 88 13:53:06 GMT Reply-To: purple@julian.UUCP (Lori Corrin) Organization: University of Western Ontario, London Lines: 11 I'm looking for some infornation on TCP/IP running under Xenix. I'm looking for the basics really, Is it available, from whom how well does it work, things along those lines. I've been looking around but I suspect I'm looking in the wrong places since I don't seem to be finding much. Thanks purple (Lori Corrin purple@julian.uwo.ca purple@julian.UUCP) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [19880620161653.2.DOW@OTTO.CAD.MCC.COM] <1988062016160000> From: dow@MCC.COM (David F. Dow) Newsgroups: comp.protocols.tcp-ip Subject: Re: looking for comments on the 15-pin ethernet connectors Message-ID: <19880620161653.2.DOW@OTTO.CAD.MCC.COM> Date: 20 Jun 88 16:16:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: dow@MCC.COM Organization: The Internet Lines: 10 Since everyone is knocking this one around, let me insert my pet peeve. On Sun's 3/160 and 3/260 machines (and perhaps others) have you noticed what is right next to the fickle slide lock? THE RESET BUTTON! I don't care to think how many times our servers have gone off the air from the slide connector falling out, soon followed by a crash of the system from hitting the reset button while trying to replace it. grrrrr. Regards, -- David F. Dow ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988062016471100> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Mon, 20 Jun 88 21:44:35 PDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA13125; Mon, 20 Jun 88 11:05: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: 20 Jun 88 16:47:11 GMT From: hscfvax!mohamed@husc6.harvard.edu (Mohamed_el_Lozy) Organization: Health Sciences Computing Facility, Harvard University Subject: IEN-116 nameserver Message-Id: <581@hscfvax.harvard.edu> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa A couple of weeks ago an implementation of the IEN-116 nameserver (both server and client) for BSD 4.3 systems was posted to comp.sources.unix. Currently the PCs that are connected to my LAN use FTP Software's PC/TCP software, which uses the domain server for name to number mapping. Are there any products out there that still use the IEN-116 nameserver? If it is worth keeping it, how should it deal with the length octet? RFC-991 states: "The protocol details are ambiguous, in particular, the length octet either does or doesn't include itself and the op code". Assuming there are products which use it, what is their interpretation of this question? Thanks for any advice. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806202039.AA15584@ucbvax.Berkeley.EDU] <1988062016540100> From: lougheed@CLASH.CISCO.COM Newsgroups: comp.protocols.tcp-ip Subject: Re: Cisco terminal servers? Message-ID: <8806202039.AA15584@ucbvax.Berkeley.EDU> Date: 20 Jun 88 16:54:01 GMT References: <23285@teknowledge-vaxc.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 11 Hello Mike - cisco Terminal Servers have always supported data flow in both directions when attached to a printer. In house we use a Laserwriter attached to a Terminal Server in just such a manner. We can print to the Laserwriter from UNIX and TOPS-20 systems. You may wish to send mail to "customer-service@cisco.com" if you need some pointers in setting up such a printing arrangement. Kirk Lougheed cisco Systems ----MESSAGE-END---- ----MESSAGE-BEGIN---- [285@telebit.UUCP] <1988062016594500> From: rls@telebit.UUCP (Richard Siegel) Newsgroups: comp.dcom.modems,comp.protocols.tcp-ip,comp.sys.att,biz.comp.telebit Subject: Telebit Requests Information Keywords: What new features do you want in a modem? Message-ID: <285@telebit.UUCP> Date: 20 Jun 88 16:59:45 GMT Organization: Telebit Corporation, Cupertine, CA Lines: 31 Pardon the wide posting, but since so many of you are using the Telebit TrailBlazer Plus, this may be the best way to ensure that you see this. Basically, Telebit is making some decisions about what new features to incorporate into the TrailBlazer Plus (and future) modems. I would like email describing (briefly!!!) what new features you'd like to see in our modems. To get you started, here are some ideas that other people have already suggested. You may place votes for these, or add new features of your own. NEW MODEM FEATURE IDEAS.... 1. Fix Autobaud to work every time 2. Full Hayes command set (identical) 3. TCP/SLIP Support in the modem 4. V.32 compatability (along with PEP) 5. Higher Level MNP support (in slow speed modes), Level ? 6. 4-wire Leased line support 7. Group III Fax support 8. Synchronous to Async Conversion Remember, we ARE listening, so this is your chance to help define the next generation of Telebit products! Respond to me via email, please. Regards, Richard Siegel Phone: (415) 969-3800 Product Manager UUCP: {sun,uunet,ames,hoptoad}!telebit!rls Telebit Corporation ARPA: telebit!rls@ames.ARPA ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988062018092000> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Wed, 22 Jun 88 23:50:15 PDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA23475; Wed, 22 Jun 88 04:36:30 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: 20 Jun 88 18:09:20 GMT From: sdcrdcf!psivax!nrcvax!jean@oberon.usc.edu (Jean Sylwanowicz) Organization: Network Research Corp. Subject: libraries for PC TCP/IP Message-Id: <1505@nrcvax.UUCP> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa James Van Bokkelen writes: In fact, most commercial TCP/IP packages for DOS can be purchased with an Applications Programming Interface of some sort. Our PC/TCP, Sun's PC/NFS, Excelan's EXOS 8051, and NRC's all have libraries that emulate Berkeley sockets, for Microsoft C. I don't know details of Bridge's offering. I think each product supports all memory models, but I don't think anyone is shipping code for 5.0 or 5.1 yet. ------- Network Research (NRC) is providing support for Microsoft 5.0 with its Program Development System (PDS) libraries as an option to FUSION version 3.2 - it is to be released by the end of June. -- ============================================================================== Jean M. Sylwanowicz X-322 Marketing Comm--Inside Sales NRC 805-485-2700, 800-541-9508 (:|= (:|= nrcvax!jean@TRWIND.TRW.COM rutgers!citvax!elroy!nrcvax!jean hplabs!sdcrdcp!psivax!nrcvax!jean cit-vax!elroy!nrcvax!jean@RUTGETS.EDU ============================================================================== ----MESSAGE-END---- ----MESSAGE-BEGIN---- [CMM.0.86.582836229.ittai@vx2.GBA.NYU.EDU] <1988062018570900> From: ittai@VX2.GBA.NYU.EDU (Ittai Hershman) Newsgroups: comp.protocols.tcp-ip Subject: More TCP/IP hoopla Message-ID: Date: 20 Jun 88 18:57:09 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 8 In this week's edition of PCWeek/Connectivity, a front page story describes the network being used by NBC at the Seoul Olympics. Guess what-- it's TCP/IP based. More correctly, it is several Novell based LANS interconnected with a MicroVAX using the Micom-Interlan Novell-TCP/IP gateway. Just amazin' -Ittai ----MESSAGE-END---- ----MESSAGE-BEGIN---- [64200004@uxe.cso.uiuc.edu] <1988062019010000> From: sandrock@uxe.cso.uiuc.edu Newsgroups: comp.protocols.tcp-ip Subject: Re: Looking for comments on the 15-pin Message-ID: <64200004@uxe.cso.uiuc.edu> Date: 20 Jun 88 19:01:00 GMT References: <5047@videovax.Tek.COM> Lines: 8 Nf-ID: #R:videovax.Tek.COM:5047:uxe.cso.uiuc.edu:64200004:000:403 Nf-From: uxe.cso.uiuc.edu!sandrock Jun 20 14:01:00 1988 I haven't heard anyone mention it, but the VAXstation 2000 (and likely the later DEC workstations) are designed for screw-down type transceiver cables. The ones around here all have a short white (matching) transceiver cable, which screws into the back of the VS 2000, but has the infamous slide-lock mechanism at the other end. Just thought I'd mention it. Mark Sandrock, ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806201615.aa27628@Huey.UDEL.EDU] <1988062020152800> From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: [UDEL Mail System: Failed mail (msg.aa25782)] Message-ID: <8806201615.aa27628@Huey.UDEL.EDU> Date: 20 Jun 88 20:15:28 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 387 Ooop. ----- Forwarded message # 1: Date: Mon, 20 Jun 88 14:33:53 EDT From: UDEL Mail System (04-Jun-88/MMDF-2b_p#30) Sender: Mail System (MMDF) Subject: Failed mail (msg.aa25782) To: Mills@UDEL.EDU Message-ID: <8806201433.aa25894@Huey.UDEL.EDU> Your message could not be delivered to 'tcp-ip@sri.nic.arpa (host: Louie.UDEL.EDU) (queue: badhosts)' for the following reason: ' (BHST) Unknown host/domain name in "tcp-ip@sri.nic.arpa"' Your message follows: Date: Mon, 20 Jun 88 14:31:37 EDT From: Mills@UDEL To: tcp-ip@sri.nic.arpa, ineng-interest@isi.edu, ntp@trantor.umd.edu Subject: NTP server status and peering strategies Message-ID: <8806201431.aa25782@Huey.UDEL.EDU> Folks, First, let me apologize for the length of this message. I am sending it to the entire list because it applies to a surprisingly large number of hosts wittingly or unwittingly chiming the Network Time Protocol (NTP) and this may be the only effective way to reach them. The six NTP primary time servers are rapidly filling up with customers, so there is need for some discipline in access. This message outlines corrective strategies and lists the current servers, clients and points of contact. If these arcane issues do not tinkle your bell, you might want to discard this message before reading. If so, please be advised the ntp@trantor.umd.edu list is the official bazaar for NTP. Dave ============================================================================== For your information, at the end of this message are billboards showing the NTP peers of various fuzzballs known to me. They show the size of the peer population escalating sharply and cause some concern that server congestion may begin to occur sooner than expected. Accordingly, I would like to reaffirm the peerage suggestions made previously on this list and in the document defining the new Version 1 of NTP (which was submitted for consideration as an RFC, but has not yet seen the day of light). As a reminder, that document can be found in pub/ntp.doc on louie.udel.edu. First, all Unix chimers (are there any others?) should be using the latest ntpd daemon from Mike Petry, which supports variable-rate polling and can reduce the polling overhead by a factor of sixteen. Early versions of ntpd do not provide the best filtering and deglitching features and do not automatically adapt to failure modes. Second, unless there are compelling reasons to the contrary, no more than two secondary servers per network should rattle the five primary server cages and all retail (end-user) hosts should obtain time from one or more secondary servers. If two secondary servers are used, each of these should peer with two different primary servers, for a total of four distinct primary servers. The two secondary servers should peer with each other and with one or two secondary servers in other networks. Experience suggests that the peering population to stratum-one and stratum-two servers should be restrained; otherwise, the clock-selection algorithm can allow a gang of secondary servers to overwhelm a few primary servers. Third, as shown in the following billboards, some chimers may be tinkling the bells of inappropriate servers. The net 128.59 dudes tinkling udel2.udel.edu (192.5.39.88) aka dcn6.arpa (128.4.0.6) are actually getting stratum-three time or worse, although the time is currently pretty good. This host happens to be located at my home and is vulnerable to new, untried software, power glitches and marauding cats. Those dudes tinkling macom1.arpa (192.5.8.1, 10.0.0.111) may not be aware that the WWVB clock originally attached to that host has been moved. However, while this host no longer provides stratum-one time, it is appropriate for use as a stratum-two neighbor, as described above. Also, note that the address for primary server ford1.arpa has changed from 128.5.0.1 to 128.5.192.1. I see a lot of ICMP error messages along the way to 128.5.0.1, suggesting that this fact is not well known. Finally, note that primary server udel1.udel.edu (192.5.39.87) aka dcn1.arpa (128.4.0.1, 10.2.0.96) is in process of being moved to a new address, which should occur on or before 5 July. At the moment, the real WWVB clock is on host udel7.udel.edu (192.5.39.94), so that udel1.udel.edu is currently providing stratum-two time. A few of you guys cleverly figured that out and switched chimes to the '94 address. Not to worry; all will be fixed soon. Be advised that use of net number 192.5.39 is shortly to be discontinued along with its ARPANET gateway. In order that the transition be as smooth as possible, I suggest all chimers temporarily use ARPANET address 10.2.0.96. If you are a secondary server chiming a primary server, you should find your address in the following billboards. Hopefully, your net should appear no more than once per billboard, assuming you conform to the peering suggestions above. The format of these billboards are similar to those available with the Unix daemon. Where points of contact are not listed, contact me for pointers. ============================================================================== Host udel1.udel.edu is currently functioning as a secondary server (stratum two). Its functions are being taken over by udel7.udel.edu, but all addresses are shortly to be changed as mentioned above. Upon completion, this host will become the recommended east-coast ARPANET primary server. udel1.udel.edu (192.5.39.87, 10.2.0.96) AdrID Address Port Status Delay Offset Disp Update ------------------------------------------------------------------------ 0 [128.5.192.1] 123 377 756 64 95 16:48:58 1 [128.9.2.129] 123 377 732 133 297 16:49:12 2* [192.5.39.94] 123 377 35 -7 1 16:49:13 3 [128.153.4.2] 123 377 767 382 1269 16:48:52 4 [128.223.20.5] 123 000 659 -322 65535 01:10:36 5 [128.200.9.18] 123 377 451 35 160 16:48:55 6 [35.1.128.16] 123 377 419 -19 26 16:48:48 7 [26.6.0.2] 123 377 2135 -850 529 16:48:58 8 [128.45.1.1] 123 370 504 -6533 542 16:45:44 9 [128.8.251.56] 123 377 222 -317 64 16:48:58 10 [128.8.251.57] 123 377 256 -272 390 16:48:59 11 [26.18.0.124] 123 376 1600 -2808 791 16:48:49 12 [128.8.251.65] 123 377 208 -186 227 16:49:02 13 [128.8.251.64] 123 377 193 90 72 16:49:03 14 [10.1.0.17] 123 377 235 -1051 45 16:49:04 15 [128.200.16.5] 123 377 483 -190 62 16:49:05 16 [192.5.220.220] 123 377 211 415 101 16:49:06 17 [35.1.128.32] 123 376 346 -7 150 16:48:36 18 [192.5.57.1] 123 000 264 -2066 9 16:44:21 19 [128.200.16.7] 123 377 483 61 169 16:48:47 20 [15.255.64.2] 123 377 991 25 77 16:49:09 21 [128.8.251.67] 123 377 228 -278 338 16:48:45 22 [128.8.251.59] 123 377 228 -492 63 16:49:09 23 [128.8.10.14] 123 377 218 -6479 5553 16:49:10 24 [128.200.16.2] 123 377 517 -315 109 16:49:12 25 [128.2.249.123] 123 112 232 11 24 16:48:11 26 [128.8.251.58] 123 377 224 -474 123 16:49:14 27 [192.5.39.3] 123 377 23 63 44 16:49:15 28 [128.95.16.21] 123 377 490 -276 73 16:49:22 29 [128.175.2.13] 123 377 2 76 95 16:49:17 30 [128.8.251.61] 123 377 222 1703195130 53 16:49:18 31 [128.59.64.60] 123 003 319 373 32393 16:48:42 32 [129.48.1.1] 123 376 6669 -522 833 16:49:20 33 [128.174.5.50] 123 377 355 303 128 16:48:30 34 [10.0.0.31] 123 377 101 13 7 16:49:24 35 [128.8.251.51] 123 377 224 71 82 16:49:16 36 [128.208.1.14] 123 000 493 -35 65535 01:10:01 37 [128.116.64.3] 123 377 460 25 52 16:48:20 38 [128.8.251.60] 123 377 219 -100 208 16:49:13 39 [128.8.251.66] 123 377 238 -63 103 16:49:14 40 [128.49.16.7] 123 377 5321 -473 645 16:49:06 41 [128.200.16.6] 123 377 508 -125 101 16:48:29 42 [128.109.130.5] 3965 000 1275 -638 65022 08:05:05 43 [128.112.14.5] 123 377 95 3723 6 16:49:19 44 [128.112.14.25] 123 376 113 3741 6 16:48:27 45 [128.112.14.18] 123 000 102 -44954945 7180 14:01:21 46 [192.5.8.1] 123 377 166 -130 39 16:48:52 47 [15.255.17.2] 123 177 901 11 12 16:48:41 48 [128.59.64.60] 123 376 222 325 64 16:48:31 49 [128.95.16.22] 123 377 475 -340 250 16:48:41 Host wwvb.isi.edu is the recommended west-coast ARPANET/MILNET primary server. Contact Steve Casner (casner@isi.edu) for further information. wwvb.isi.edu (128.9.2.129) AdrID Address Port Status Delay Offset Disp Update ------------------------------------------------------------------------ 0 [128.116.64.3] 123 375 1204 64 442 17:39:52 1 [128.8.10.1] 123 377 1193 -18 577 17:34:40 2 [128.59.16.119] 123 376 1019 25 117 17:40:06 3 [128.200.16.7] 123 376 239 28 86 17:39:32 4* [192.5.39.94] 123 376 786 -149 422 17:40:06 5 [129.48.1.1] 123 376 5478 -501 911 17:39:59 6 [192.5.39.87] 123 376 710 -119 182 17:39:41 7 [128.200.16.2] 123 376 250 134 110 17:38:35 8 [128.59.16.125] 123 377 1029 -7 533 17:40:27 9 [128.59.16.111] 123 377 1092 156 474 17:40:30 10 [128.59.16.116] 123 377 1032 10 264 17:40:33 11 [128.59.16.112] 123 376 967 -6 249 17:40:12 12 [128.200.9.18] 123 216 228 25 41 17:39:49 13 [128.59.16.122] 123 376 1011 -156 183 17:39:50 14 [192.5.220.220] 123 377 894 -58 807 17:40:11 15 [128.200.16.5] 123 361 239 -64 149 17:38:39 16 [128.97.28.251] 123 376 141 -85 174 17:39:34 17 [128.59.16.120] 123 376 1020 -9 171 17:39:55 18 [192.12.252.4] 123 000 0 0 65535 17:39:43 19 [15.255.64.2] 123 367 1772 100 136 17:40:24 20 [128.200.16.6] 123 376 251 -41 146 17:40:19 21 [128.5.192.1] 123 376 2328 -98 1255 17:24:26 22 [15.255.17.2] 123 311 1583 17 225 17:39:05 Host ncar.nsf.net is one of the NSFNET Backbone switches. As most already know, the NSFNET Backbone is shortly to be retired and replaced by the Merit/IBM/MCI NSFNET Backbone, so that the ncar.nsf.net fuzzy will no longer have that mission. Hopefully, this host will remain in place, if only to provide good time and remain the recommended NSFNET midcontinent primary time server. ncar.nsf.net (128.116.64.3) AdrID Address Port Status Delay Offset Disp Update ------------------------------------------------------------------------ 0 [128.8.10.1] 123 376 397 -99 1 04:58:15 1 [128.4.0.1] 123 377 422 -16 132 05:09:21 2 [128.135.4.2] 123 376 136 -3 22 05:08:49 3* [192.5.39.94] 123 376 403 -13 99 05:09:05 4 [192.5.220.220] 123 305 550 -226 216 05:07:56 5 [128.200.16.7] 123 376 145 103 81 05:09:00 6 [128.135.20.72] 123 376 133 -19 9 05:08:57 7 [128.200.16.6] 123 376 153 -400 217 05:08:16 8 [128.138.240.4] 123 377 59 0 8 05:09:01 9 [15.255.64.2] 123 376 1168 29 72 05:09:34 10 [128.200.16.3] 123 377 158 55 297 05:09:04 11 [128.174.5.50] 123 377 93 1 7 05:09:30 12 [128.223.20.5] 123 337 418 32 142 05:09:39 13 [128.102.18.20] 123 173 206 308 193 05:09:32 14 [128.200.9.18] 123 376 159 -222 110 05:09:09 15 [128.200.16.5] 123 000 165 -90 65535 12:37:04 16 [128.200.16.2] 123 377 141 28 55 05:09:33 17 [128.42.1.64] 123 377 79 -2 4 05:09:08 18 [128.9.2.129] 123 136 1532 -17 843 04:53:47 19 [15.255.16.12] 123 327 1078 20 73 05:03:33 20 [15.255.17.2] 123 361 1038 23 47 05:08:14 21 [128.5.192.1] 123 376 900 82 116 05:01:48 22 [15.255.64.2] 2609 000 836 -418 65022 23:33:11 Ramshackle host ford1.arpa is presently at the end of a 9600-bps line at Dearborn, MI. Net 128.5 should soon be rehomed to MERIT (net 35) by a 56-Kbps line, in which case (net managers willing) it should become a recommended NSFNET midwestern primary server. It would be most polite if potential chimers were to contact Fred Ball (ball@ford-vax.arpa) before use. ford1.arpa (128.5.192.1) AdrID Address Port Status Delay Offset Disp Update ------------------------------------------------------------------------ 0 [128.9.2.129] 123 376 2208 -450 197 19:14:13 1 [128.116.64.3] 123 127 1160 92 173 19:26:40 2 [192.5.39.94] 123 333 667 -117 26 19:26:01 3 [128.59.16.121] 123 376 781 89 435 19:25:58 4 [192.5.220.220] 123 126 984 -67 198 19:26:02 5 [192.5.39.87] 123 376 762 -99 93 19:25:39 6 [15.255.17.2] 123 376 1635 -37 210 19:23:59 7 [15.255.16.12] 123 375 1575 -115 113 19:25:54 8 [128.59.16.1] 123 377 971 79 436 19:26:20 9* [192.5.8.1] 123 367 269 -36 46 19:26:07 10 [128.59.16.116] 123 377 794 50 217 19:26:34 11 [128.59.16.119] 123 376 935 12 323 19:26:00 12 [128.143.2.7] 123 376 807 -21 175 19:26:03 13 [128.59.16.122] 123 376 630 -30 157 19:26:25 14 [128.59.16.112] 123 377 806 -39 123 19:26:42 15 [128.59.16.125] 123 367 688 -19 209 19:26:45 16 [128.59.16.120] 123 375 763 -79 73 19:25:56 17 [128.59.16.111] 123 377 891 -186 324 19:25:58 18 [128.97.28.251] 123 361 1253 -153 302 19:25:04 19 [128.120.57.23] 2560 000 0 0 65535 19:15:07 Host umd1.umd.edu has become the busiest primary server; however, access via ARPANET is shortly to be curtailed. This is the recommended east-coast NSFNET MILNET primary server. Note that this server has 63 clients, which is just two shy of the 65-client maximum of the present configuration. Contact Mike Petry (petry@trantor.umd.edu) or Louie Mamakos (louie@trantor.umd.edu) for further information. umd1.umd.edu (128.8.10.1) AdrID Address Port Status Delay Offset Disp Update ------------------------------------------------------------------------ 0 [128.5.192.1] 123 346 627 45 148 17:46:49 1 [128.9.2.129] 123 377 992 38 156 17:47:22 2 [128.116.64.3] 123 052 581 71 26 17:39:58 3 [128.59.16.111] 123 376 232 -50 53 17:49:29 4 [128.8.251.57] 123 377 18 -347 112 17:49:15 5 [128.59.16.116] 123 377 189 -38 86 17:49:33 6 [128.143.2.7] 123 377 71 0 4 17:49:33 7 [128.200.16.2] 123 212 636 -34 479 17:40:17 8 [128.95.16.22] 123 377 1011 5 44 17:49:32 9 [35.1.128.32] 123 367 82 5 8 17:49:26 10 [128.8.251.51] 123 377 13 44 149 17:48:48 11 [128.59.64.60] 123 000 160 275 65535 16:47:45 12 [128.45.1.1] 123 000 570 -6419 65535 16:45:09 13 [35.1.128.16] 123 377 76 43 14 17:49:35 14 [128.59.16.122] 123 377 187 -56 87 17:48:50 15 [128.8.251.61] 123 377 14 1703195154 13 17:49:36 16 [36.22.0.8] 123 376 643 29 162 17:48:44 17 [35.1.128.16] 2289 000 0 0 65535 05:00:58 18 [128.59.16.120] 123 377 188 -37 51 17:48:55 19 [128.8.1.14] 123 376 21 -1174 14 17:48:35 20* [192.5.39.94] 123 377 173 -47 37 17:49:01 21 [10.0.0.31] 123 376 241 -2 33 17:48:39 22 [128.223.20.5] 123 000 1129 -266 65535 01:10:55 23 [128.200.9.18] 123 342 545 -143 175 17:46:40 24 [192.5.39.88] 123 376 389 -38 14 17:49:22 25 [128.8.251.65] 123 376 24 -224 78 17:48:42 26 [129.48.1.1] 123 201 6141 -1077 1814 17:48:45 27 [128.8.251.64] 123 372 13 -308 198 17:48:42 28 [128.8.251.58] 123 376 25 -514 158 17:48:41 29 [128.8.251.60] 123 376 8 -407 218 17:48:43 30 [128.8.251.56] 123 376 19 -246 123 17:48:45 31 [128.59.16.119] 123 376 191 -14 46 17:49:05 32 [128.95.16.21] 123 376 752 51 286 17:48:50 33 [128.97.28.251] 123 377 616 -425 733 17:49:40 34 [128.135.20.72] 123 377 508 -16 65 17:49:11 35 [129.2.1.6] 123 377 28 1 0 17:49:34 36 [128.8.132.10] 123 372 23 -2 2 17:49:13 37 [18.71.0.8] 123 376 0 0 65535 17:48:54 38 [128.175.2.13] 123 376 50 186 156 17:48:55 39 [128.200.16.5] 123 376 463 177 161 17:48:59 40 [128.8.251.66] 123 376 15 -463 110 17:48:55 41 [128.135.4.2] 123 376 348 -40 39 17:49:17 42 [128.8.251.67] 123 376 27 -347 328 17:48:59 43 [192.5.39.3] 123 376 143 37 17 17:48:58 44 [128.49.16.7] 123 377 3141 -2603 3143 17:49:31 45 [128.102.22.200] 123 377 918 -591 249 17:49:00 46 [128.8.251.59] 123 377 25 -439 236 17:49:06 47 [128.8.10.14] 123 377 16 -45 335 17:49:15 48 [128.59.16.125] 123 377 207 -56 44 17:49:27 49 [128.200.16.7] 123 375 501 49 279 17:49:17 50 [18.26.0.109] 123 377 0 0 65535 17:49:09 51 [128.153.4.2] 123 377 1130 -85 585 17:49:09 52 [192.5.220.220] 123 377 236 -67 2271 17:49:34 53 [128.102.18.20] 123 351 929 93 491 17:44:23 54 [128.42.1.64] 123 365 280 -5 17 17:44:46 55 [128.138.240.4] 123 154 387 -60 262 17:41:10 56 [128.200.16.6] 123 376 529 -269 350 17:49:09 57 [128.112.14.5] 123 377 208 -12 16 17:49:42 58 [128.112.14.25] 123 377 204 3696 15 17:45:12 59 [128.112.14.18] 123 000 0 0 65535 14:01:21 60 [192.5.8.1] 123 163 236 -103 26 17:49:34 61 [15.255.17.2] 123 376 1031 45 55 17:48:49 62 [128.95.16.22] 123 000 762 122 65535 17:35:27 63 [128.59.16.112] 123 376 237 -6 75 17:49:11 As mentioned above, host udel1.udel.edu is not presently a primary server, but obtains primary time from the following host udel7.udel.edu. On or before 5 July, this the address of udel7.udel.edu will be changed and it will become the official primary server instead of udel1.udel.edu. While the existence of udel7.udel.edu has not been officially revealed, some clever sods found it anyway, probably by chasing the IP address field of NTP updates. udel7.udel.edu (192.5.39.94) AdrID Address Port Status Delay Offset Disp Update ------------------------------------------------------------------------ 0 [128.5.192.1] 123 375 758 112 194 15:21:30 1 [128.9.2.129] 123 376 726 142 49 15:21:42 2 [128.8.10.1] 123 366 180 51 17 15:21:43 3 [128.116.64.3] 123 267 518 14 92 15:21:51 4* [18.72.0.3] 123 377 190 -25 15 15:22:12 5 [128.8.10.14] 123 377 158 81 555 15:21:45 6 [18.26.0.109] 123 364 212 -21 20 15:07:18 7 [192.5.39.87] 123 376 35 6 0 15:21:37 8 [18.71.0.8] 123 365 197 -81 110 15:15:34 9 [35.1.128.32] 123 215 296 98 12 15:20:41 10 [18.72.0.141] 3106 000 14633 -7317 65022 16:35:39 11 [35.1.128.16] 123 326 218 59 149 15:07:45 12 [18.72.0.106] 2333 000 181 -91 15967 00:53:31 As noted, host macom1.arpa is no longer a primary server. I assume the customers listed know that. Contact Mike Little (little@macom2.arpa) for further information. macom1.arpa (192.5.8.1, 10.0.0.111) AdrID Address Port Status Delay Offset Disp Update ------------------------------------------------------------------------ 0 [128.5.192.1] 123 375 294 171 43 13:23:45 1* [128.8.10.1] 123 377 226 169 19 13:24:22 2 [128.4.0.1] 123 376 152 161 22 13:24:23 3 [10.0.0.31] 123 125 224 125 117 13:09:54 4 [18.62.0.7] 123 125 276 120 255 13:24:36 5 [15.255.17.2] 123 053 1058 205 391 13:17:44 6 [15.255.16.12] 123 135 1030 150 13 13:24:48 7 [18.62.0.6] 123 000 182 -1030632 65535 08:20:52 8 [128.109.131.49] 1198 000 257 -129 24700 03:55:10 9 [128.109.130.5] 4126 000 181 -91 9859 08:02:11 Host udel2.udel.edu is probabably not an appropriate secondary server, so its net 128.59 customers should move elsewhere. Also, these customers should also upgrade to the latest ntpd. The other customers are mine. udel2.udel.edu (192.5.39.88) aka dcn6.arpa (128.4.0.6) AdrID Address Port Status Delay Offset Disp Update ------------------------------------------------------------------------ 0 [128.8.10.1] 123 373 383 61 13 01:49:39 1 [128.59.16.116] 123 376 469 -29 32 01:50:33 2 [128.59.16.112] 123 377 467 -9 13 01:50:39 3 [128.59.16.122] 123 377 465 -8 15 01:49:50 4 [128.59.16.120] 123 377 480 -10 32 01:49:55 5 [128.59.16.119] 123 377 491 1 46 01:50:05 6* [128.59.16.125] 123 377 455 -8 15 01:50:26 7 [128.59.16.111] 123 377 479 -13 43 01:50:30 8 [128.175.2.13] 123 377 231 132 61 01:50:00 ============================================================================== ----- End of forwarded messages ----MESSAGE-END---- ----MESSAGE-BEGIN---- [2348@elrond.CalComp.COM] <1988062020485600> From: bailey@elrond.CalComp.COM (Dave Bailey) Newsgroups: comp.protocols.tcp-ip Subject: TCP/IP in a real time kernal Keywords: TCP/IP realtime Message-ID: <2348@elrond.CalComp.COM> Date: 20 Jun 88 20:48:56 GMT Organization: Calcomp, A Lockheed Company, Hudson, NH, USA Lines: 9 Does anyone know of any TCP/IP implementations in small real time kernals? thanks. dave bailey -- David C. Bailey ...{decvax|harvard}!elrond!bailey Calcomp Inc, (A Lockheed Company) Display Products Division, 65 River Road, Hudson, NH 03051-0908, Mail Stop PTP2-2D01. (603) 885 8141 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1977@hubcap.UUCP] <1988062021002200> From: mrspock@hubcap.UUCP (Steve Benz) Newsgroups: comp.protocols.tcp-ip,comp.unix.questions,comp.sources.wanted Subject: Where do you suppose I could get egp or gated? Message-ID: <1977@hubcap.UUCP> Date: 20 Jun 88 21:00:22 GMT Organization: Clemson University, Clemson, SC Lines: 13 We have a Gould 9005 connected to the Milnet (26.0.0.80 is our number) and to a LAN connected to NSFnet. We've been running well for a while, except that we have no EGP, which means that we really don't get the kind of connectivity we'd like through the Milnet side. So we called Gould -- they said something like "eeh gee whut?" I understand that some folks at Cornell have written something called 'gated' and I believe that's what we need, since it deals with both RIP (for the LAN) and EGP (for the Milnet connection) in one program. Does anybody out there know where or if we can lay hands on such a thing? - Steve Benz ----MESSAGE-END---- ----MESSAGE-BEGIN---- [kIMa#/.@samsun.sm.unisys.com] <1988062021490400> From: darrelj@samsun.sm.unisys.com (Darrel VanBuer) Newsgroups: comp.protocols.tcp-ip Subject: Re: Ethernet transceiver connector slide-locks Message-ID: Date: 20 Jun 88 21:49:04 GMT References: <8806181919.AA22300@orc.olivetti.com> Reply-To: darrelj@samsun.sm.unisys.com (Darrel VanBuer) Organization: Unisys Santa Monica Lines: 16 Slide locks are not perfect, but when correctly implemented do not cause much trouble. Sun's violation of the 802.3 spec (and the more implicit specs in the orginal Ethernet document -- where you have to read the connector manufacturers' catalogs to get all the rules for correct adjustment) is a major headache. By putting a chassis between the connector flange and the slide, they steal about 1.5 mm of pin insertion out of a total of 3 mm pin insertion, leaving the connector quite wobbly. At one time, we dealt with this by modifying the drop cable to remove two washers which the spec says SHOULD be between the lock posts and the connector flange, resulting in a cable end which complements the Sun error, and gets a good fit. Of course this cable now fails to properly fit a conforming computer or extension cable :-(. When properly fit, a slide lock is quite strong. With poor QC or design, they are abysmal. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [363@manta.NOSC.MIL] <1988062022134200> From: gutman@manta.NOSC.MIL (Lewis M. Gutman) Newsgroups: comp.protocols.tcp-ip,comp.protocols.iso,comp.protocols.misc Subject: delta-t protocol Keywords: transport protocol, real-time communications Message-ID: <363@manta.NOSC.MIL> Date: 20 Jun 88 22:13:42 GMT Organization: Naval Ocean Systems Center, San Diego Lines: 7 I am looking for information about the delta-t protocol. I've heard that it is used for real-time communications, not much more. I would appreciate any references. Thanks. Lew Gutman Naval Ocean Systems Center San Diego, Ca. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [335@csvaxa.UUCP] <1988062100371600> From: edward@csvaxa.UUCP (Edward Wilkinson) Newsgroups: comp.emacs,comp.protocols.tcp-ip Subject: Remote Gnumacs servers? Message-ID: <335@csvaxa.UUCP> Date: 21 Jun 88 00:37:16 GMT Reply-To: edward@csvaxa.UUCP (Edward Wilkinson) Organization: Computer Centre, Massey University, Palmerston North, NZ. Lines: 20 Wobble-Factor: huge Rocky-Horror-Count: 18 Environment: Vax 11/750 under Ultrix 2.0 Is there a version of Gnumacs which allows a remote Gnumacs to run in conjunction with a local part? This would allow the local part to do such simple things as self-insert-command, delete-backward-char, while the remote part does things like byte-compile-file, load-file and other more expensive tasks. The main advantage with this is that a PC user could edit files with fast response times for simple stuff which usually takes ages on a highly loaded bigger machine. This approach could also work with workstations. Ideas? Or has this already been done? I know I'd prefer to use full Gnumacs on my PC instead of some local subsubset of emacs which fits into 640k or whatever. -- Ed Wilkinson @ Computer Centre, Massey University, Palmerston North, NZ uucp: {uunet,watmath!cantuar}!vuwcomp!csvaxa!edward DTE: 530163000005 Janet/Greybook: E.Wilkinson@nz.ac.massey Phone: +64 63 69099 x8587 CSnet/ACSnet/Internet: E.Wilkinson@massey.ac.nz New Zealand = GMT+12 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988062105355600> Received: from Storm-King.nyser.net by SRI-NIC.ARPA with TCP; Tue, 21 Jun 88 07:59:02 PDT Date: Tue, 21 Jun 88 09:35:56 EDT From: fedor@storm-king.nyser.net Received: by Storm-King.nyser.net (5.54/1.3-Storm-King at NYSERNet-NISC) id AA01180; Tue, 21 Jun 88 09:35:56 EDT Message-Id: <8806211335.AA01180@Storm-King.nyser.net> To: hubcap!mrspock@gatech.edu, tcp-ip@sri-nic.arpa Subject: Re: Where do you suppose I could get egp or gated? sounds like gated is what you need. it is FTP'able anonymously via devvax.tn.cornell.edu 128.84.238.200 or 10.2.0.15 look in the directory pub/gated for the latest and greatest. Mark ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1050@ipso.rss.ips.oz] <1988062107175800> From: shauna@ipso.rss.ips.oz (Shaun A'Rundell) Newsgroups: comp.protocols.tcp-ip,aus.wanted Subject: Reliable client/server libiary (SRI from sun) Message-ID: <1050@ipso.rss.ips.oz> Date: 21 Jun 88 07:17:58 GMT Reply-To: shauna@ipso.rss.ips.oz (Shaun A'Rundell) Organization: IPS Radio and Space Services. Sydney, Australia. Lines: 11 I have heard that there is a package or libiary of routines written by some one at SUn microsystems, to provide reliable client/server connections. If provides services like, re-establishing connections when a server dies. Has anybody seen this packages, do you know where I could get it from. I heard it was public domain. Thanks Shaun ARundell (shauna@ipso.rss.ips.oz) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988062107581000> Received: from venera.isi.edu by SRI-NIC.ARPA with TCP; Tue, 21 Jun 88 14:57:55 PDT Received: from bel.isi.edu by venera.isi.edu (5.54/5.51) id AA23556; Tue, 21 Jun 88 14:58:30 PDT Date: Tue, 21 Jun 88 14:58:10 PDT From: postel@venera.isi.edu Posted-Date: Tue, 21 Jun 88 14:58:10 PDT Message-Id: <8806212158.AA01829@bel.isi.edu> Received: by bel.isi.edu (5.54/5.51) id AA01829; Tue, 21 Jun 88 14:58:10 PDT To: tcp-ip@sri-nic.arpa Subject: re: IEN-116 nameserver Cc: hscfvax!mohamed@husc6.harvard.edu It is my hope that all IEN-116 name servers will die soon. (Actually, i wanted to believe they were all already dead.) Long live the Domain Name System. --jon. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [18488@cornell.UUCP] <1988062110413800> From: parmelee@wayback.cs.cornell.edu (Larry Parmelee) Newsgroups: comp.protocols.tcp-ip,comp.unix.questions,comp.sources.wanted Subject: Re: Where do you suppose I could get egp or gated? Message-ID: <18488@cornell.UUCP> Date: 21 Jun 88 10:41:38 GMT References: <1977@hubcap.UUCP> Sender: nobody@cornell.UUCP Reply-To: parmelee@wayback.cs.cornell.edu (Larry Parmelee) Organization: Cornell Univ. CS Dept, Ithaca NY Lines: 9 In article <1977@hubcap.UUCP> mrspock@hubcap.UUCP (Steve Benz) writes: > I understand that some folks at Cornell have written something called > 'gated' [...] it deals with both RIP [...] and EGP [...] in one program. Gated can be anonymous ftp'ed from devvax.tn.cornell.edu; Look in the pub/gated directory. The current maintainer is Jeff Honig, jch@devvax.tn.cornell.edu. -Larry Parmelee ----MESSAGE-END---- ----MESSAGE-BEGIN---- [350@chaos.informatik.uni-erlangen.de] <1988062113201400> From: dkhusema@faui44.informatik.uni-erlangen.de (Dirk Husemann) Newsgroups: comp.protocols.tcp-ip Subject: 4.3 public domain tcp/ip - fixes available ? Keywords: bug in netinet/tcp_input.c Message-ID: <350@chaos.informatik.uni-erlangen.de> Date: 21 Jun 88 13:20:14 GMT Lines: 60 Hi, yawl! Well, I'm in the process of porting the 4.3 public domain tcp/ip release to our PE's (manufactured by Concurrent Computer). Everything compiled real smoothly - in the net directory, that is, - except for the file netinet/tcp_input.c. The problem is caused by the following piece of source code: for (ifp = ifnet; ifp; ifp = ifp->if_next) { if (ifp->if_addr.sa_family != AF_INET) continue; sin = (struct sockaddr_in *)&ifp->if_addr; if ((sin->sin_addr.s_addr & mask) == i) return (1); } My compiler doesn't like a particular identifier: if_addr ! All he can be be seduced to say is: "tcp_input.c", line 1314: if_addr undefined "tcp_input.c", line 1314: member of structure or union required "tcp_input.c", line 1314: warning: struct/union or struct/union pointer required "tcp_input.c", line 1316: member of structure or union required As it turns out to be, the variable ifp is of struct ifnet, which in turn is defined in if.h (net/if.h). Looking it up yields that the member if_addr of the struct ifnet is NOT defined. Once you compare it with the 4.2 sour- ces you'll find it there. Question: Did I miss something important (i.e., have there been any fixes to this problem - I didn't follow the discussions on comp.protocols.tcp-ip that closely) ? Did we get our sources mingled up? What else? Perhaps somebody can enlighten me? ------------------ Smile, tomorrow will be worse! ------------- Business: Dirk Husemann Home: Dirk Husemann Friedrich-Alexander University Aufsess-Str. 19 Erlangen-Nuremberg D-8520 Erlangen Dep. Comp. Science IMMD IV West Germany Martensstrasse 3 +49 9131 302036 D-8520 Erlangen West Germany +49 9131 867908 email: dkhusema@immd4.informatik.uni-erlangen.de ------------------ Did I say smile? Forget it! ---------------- Disclaimer: The opinions, views, statements, ..., expressed here are NOT those of the university nor those of the student body as a whole. In fact, they're mine! --------------------------------------------------------------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806211125.AA06286@nisc.nyser.net] <1988062114261400> From: stan@H1.GCY.NYTEL.COM Newsgroups: comp.protocols.tcp-ip Subject: TTLs Message-ID: <8806211125.AA06286@nisc.nyser.net> Date: 21 Jun 88 14:26:14 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 30 There has recently been considerable discussion on this list about the increasing loss of network connectivity. I have not seen any discussion about TTL problems, however many of the problems that I have had to shoot with regard to loss of connectivity have been due to inappropriate TTL values. The increase in the size of the regionals and of the Internet as a whole has not been accounted for and TTL values are therefore set too low. This results in loss of connectivity, the cause of which is not readily apparent to the user. The matter is often further complicated by different TTL values for ping, ftp, tftp and telnet. Generally I have found that the highest TTL values are associated with the ping servers, so that when the user pings the host the network appears to be OK, but because ftp or telnet have a lower TTL, it is assumed that there is a problem with those servers and that they are not responding. The fact is that their TTL has gone to 0 somewhere in the network. There appears to be no consistency across vendor software implemenations, as I have seen TTL's for ftp range from 24 to 255. In my opinion, TTL for all services should be set to 255 as the network is not currently plagued with major looping problems and it seems to be more important to improve connectivity than to prevent the looping of a packet at 32 or 64 hops. Comments? Opinions? Similar experiences? Other solutions? ----------------------------------------------------------------------- Real Name : Stanfield L. Smith E-mail : stan@h1.gcy.nytel.com Company : New York Telephone Co. USmail : Room 203 LAB Phone : 516-294-7170 : 100 Garden City Plaza FAX G3 : 516-248-8489 : Garden City NY, 11530 ----------------------------------------------------------------------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [332@orange2.qtp.ufl.edu] <1988062118221200> From: bernhold@qtp.ufl.edu (David E. Bernholdt) Newsgroups: comp.protocols.tcp-ip Subject: Can users get *the* time? Message-ID: <332@orange2.qtp.ufl.edu> Date: 21 Jun 88 18:22:12 GMT Reply-To: bernhold@qtp.ufl.edu (David E. Bernholdt) Organization: University of Florida Quantum Theory Project Lines: 14 I know nothing about NTP and very little about TCP/IP and the various protocols, so this is probably a dumb question but here goes... Can a normal user ask one of the "time machines" for the *right* time? Does anyone have a quickie program to do this? I would like to see how it works. I mean if someone is broadcasting the info, other uses could certainly be made of it... Thanks in advance. -- David Bernholdt Internet: bernhold@orange.qtp.ufl.edu Quantum Theory Project BITnet: bernhold@ufpine.bitnet University of Florida HEPnet: 43129::59410::bernholdt Gainesville, FL 32611 Phone: 904/392 9306 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806212210.AA02171@sonny.proteon.com] <1988062122105700> From: jas@proteon.COM (John A. Shriver) Newsgroups: comp.protocols.tcp-ip Subject: TTLs Message-ID: <8806212210.AA02171@sonny.proteon.com> Date: 21 Jun 88 22:10:57 GMT References: <8806211125.AA06286@nisc.nyser.net> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 28 The TCP specification specifies that the IP time to live is 60, on page 51 of RFC 793. All that the various TCP/IP vendors using 4.xBSD need to do is edit netinet/tcp_timer.h, and change the definition of TCP_TTL to 60, and recompile. It was 15 (?) on 4.2BSD, and is 30 on 4.3BSD (including the "Van Jacobsen" version). Both of these values are too small. (None of the commercial versions I have here uses 60.) I guess the vendors might be able to get this out the door in 1 year... One does NOT want to set the IP time to live higher than 60 for TCP. This breaks certain assumptions that make the three-way handshake work, and re-use of port numbers. When the Internet is over 60 hops, then we will have a problem. For now, we should follow the standards we have set for ourselves. Looking at the 4.3BSD ICMP code, the echo reply code uses the received TTL as the TTL to send. (I won't try and decide if this is the "right" thing of ICMP to do.) Ping sends through a raw socket, which uses the default TTL of 255 (defined in netinet/ip.h). Thus the range of a ping is 127 hops. I would disagree about the absence of looping problems. So long as RIP, at least in the Berkeley routed implementation, is in use, there will be transient routing loops. This problem is minimized in the IDEA004 RIP. The host RFC authors should be sure to put this in their checklist, since it is such a common bug. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806212245.AA13645@hoquiam] <1988062122455900> From: don@SRI-LEWIS.ARPA (Donald Holman) Newsgroups: comp.protocols.tcp-ip Subject: Re: Looking for comments on the 15-pin Message-ID: <8806212245.AA13645@hoquiam> Date: 21 Jun 88 22:45:59 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 5 If I can get the floor for a moment, I call for an, 'enough already' vote. How about a second. Don ----MESSAGE-END---- ----MESSAGE-BEGIN---- [3861@saturn.ucsc.edu] <1988062201133600> From: eshop@saturn.ucsc.edu (Jim Warner) Newsgroups: comp.protocols.tcp-ip Subject: Re: TTLs Message-ID: <3861@saturn.ucsc.edu> Date: 22 Jun 88 01:13:36 GMT References: <8806211125.AA06286@nisc.nyser.net> Reply-To: eshop@saturn.ucsc.edu (Jim Warner) Organization: University of California, Santa Cruz Lines: 4 While we're looking at TTLs, how about setting them to SMALL numbers for packets that aren't supposed to propagate through the internet. I'm thinking of net hop routing packets (RIP) and rwho packets. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806230912.AA12169@ucbvax.Berkeley.EDU] <1988062206382400> From: BENEDET@BLIULG11.BITNET ("F. Benedet") Newsgroups: comp.protocols.tcp-ip Subject: TCP-IP on IBM mainframe Message-ID: <8806230912.AA12169@ucbvax.Berkeley.EDU> Date: 22 Jun 88 06:38:24 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 19 We are in the process of selecting products to connect (micro)VAX to IBM mainframe on ETHERNET and TCP-IP. The solutions which are distributed here in Belgium are(as far as I know) - IBM 8232 - ITT 8940 (which in fact is the INTEL FASTPATH) - Spartacus-Fibronics K200 I suppose this has become a trivial question for most of you but I should appreciate any comment, appreciation or experience on : - those products - the related software to be used on the IBM mainframe (VM/HPO) - the software to be used on the VAX systems (VMS) -opinion about the best way to provide 3270 simulation (in the VAX or in the IBM mainframe) Thanks Fernand Benedet Service General d'Informatique - Universite de Liege 15, Avenue des Tilleuls B4000 Liege (Belgium) Tel: + 32 41 52 01 80 (455) Fax: + 32 41 53 44 03 Acknowledge-To: ----MESSAGE-END---- ----MESSAGE-BEGIN---- [6770@sigi.Colorado.EDU] <1988062206515300> From: ziel@spot.Colorado.EDU (ZIEL FRED ADAM) Newsgroups: comp.protocols.tcp-ip,comp.dcom.lans Subject: Print Server Message-ID: <6770@sigi.Colorado.EDU> Date: 22 Jun 88 06:51:53 GMT Sender: news@sigi.Colorado.EDU Reply-To: ziel@spot.Colorado.EDU (ZIEL FRED ADAM) Organization: University of Colorado, Boulder Lines: 18 The architecture we are trying to test is more ideally implemented with independently adressable network devices, so I'm looking for a (hopefully cost effective) way of putting our printers on our ethernet network instead of hanging them off of a server. It sounds like we need some of the functionality of a cisco terminal server, but that looks to be a bit of overkill. Something similar was described in Comp.newprod from Excelan a few weeks ago. We would also like some method of having the tape drive be an independent device, but I think that is less important at the moment. I would appreciate any info (esp. pricing) on the minimum cisco or Excelan systems. I would also appreciate any suggested alternatives or problems with what we're trying to do. If I get enough (any :-) replies, I will post a summary. Thanks. ---------------------------------------------------------------------- Fred Ziel, Colorado Center for Astrodynamics Reserach, CU-Boulder uucp: ..!{nbires,ames!ncar}!boulder!ziel domain: ziel@spot.colorado.edu disclaimer.h (line 10): syntax error. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806231050.AA13467@ucbvax.Berkeley.EDU] <1988062209300000> From: YEHAVI@HUJIVMS.BITNET (Yehavi Bourvine +972-2-584279) Newsgroups: comp.protocols.tcp-ip Subject: sridge vs. Cisco IP routers Message-ID: <8806231050.AA13467@ucbvax.Berkeley.EDU> Date: 22 Jun 88 09:30:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 15 We are considering buying routers in order to connect our campuses' ethernets. There are two choices: GS-3 from Bridge and Cisco's routers. Has anyone tried them both and can compare them? Thanks in advance, __Yehavi: =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Yehavi Bourvine, Phones: +972-2-584279, H Computation Center, +972-2-521574 H The Hebrew University of Jerusalem, H Givat-Ram, Jerusalem 91904 H H H Fax: +972-2-527349 HH H BITnet: YEHAVI@HUJIVMS H H InterNet: YEHAVI@VMS.HUJI.AC.IL H H =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806221139.AA04743@mitre.arpa] <1988062211391200> From: jdobbs@MITRE.ARPA (John D. Dobbs) Newsgroups: comp.protocols.tcp-ip Subject: Please remove me from the TCP-IP list Message-ID: <8806221139.AA04743@mitre.arpa> Date: 22 Jun 88 11:39:12 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The MITRE Corp., Washington, D.C. Lines: 6 Please remove me from mail list Thanks John Dobbs ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988062211582400> Received: from CUNYVM.CUNY.EDU by SRI-NIC.ARPA with TCP; Thu, 23 Jun 88 00:47:06 PDT Received: from VM1.EARN-ULG.AC.BE by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 3675; Wed, 22 Jun 88 03:35:07 EDT Received: by BLIULG11 (Mailer X1.25) id 2622; Wed, 22 Jun 88 08:50:15 +0200 Date: Wed, 22 Jun 88 08:38:24 +0200 From: "F. Benedet" Subject: TCP-IP on IBM mainframe To: tcp-ip@sri-nic.arpa We are in the process of selecting products to connect (micro)VAX to IBM mainframe on ETHERNET and TCP-IP. The solutions which are distributed here in Belgium are(as far as I know) - IBM 8232 - ITT 8940 (which in fact is the INTEL FASTPATH) - Spartacus-Fibronics K200 I suppose this has become a trivial question for most of you but I should appreciate any comment, appreciation or experience on : - those products - the related software to be used on the IBM mainframe (VM/HPO) - the software to be used on the VAX systems (VMS) -opinion about the best way to provide 3270 simulation (in the VAX or in the IBM mainframe) Thanks Fernand Benedet Service General d'Informatique - Universite de Liege 15, Avenue des Tilleuls B4000 Liege (Belgium) Tel: + 32 41 52 01 80 (455) Fax: + 32 41 53 44 03 Acknowledge-To: ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806221523.AA02419@hogg.cc.uoregon.edu] <1988062215235500> From: jqj@HOGG.CC.UOREGON.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: TTLs Message-ID: <8806221523.AA02419@hogg.cc.uoregon.edu> Date: 22 Jun 88 15:23:55 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 8 We have seen exactly the same behavior Smith describes. We're deep in a regional (5 hops away from the NSF backbone), and have found a number of sites we could ping but could not otherwise communicate with. In one case (uunet), we contacted the vendor of their software (Sequent), and the vendor agreed that a higher initial TTL was appropriate. One more thing for the "how to write a host TCP/IP implementation" RFC? ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988062217300000> Received: from CUNYVM.CUNY.EDU by SRI-NIC.ARPA with TCP; Thu, 23 Jun 88 00:50:33 PDT Received: from HUJIVMS.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 4318; Wed, 22 Jun 88 07:16:09 EDT Received: by HUJIVMS (HUyMail-4c); Wed, 22 Jun 88 12:32:28 +0300 Date: Wed, 22 Jun 88 12:30 +0300 From: Yehavi Bourvine +972-2-584279 To: TCP-IP@SRI-NIC.ARPA Subject: sridge vs. Cisco IP routers We are considering buying routers in order to connect our campuses' ethernets. There are two choices: GS-3 from Bridge and Cisco's routers. Has anyone tried them both and can compare them? Thanks in advance, __Yehavi: =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Yehavi Bourvine, Phones: +972-2-584279, H Computation Center, +972-2-521574 H The Hebrew University of Jerusalem, H Givat-Ram, Jerusalem 91904 H H H Fax: +972-2-527349 HH H BITnet: YEHAVI@HUJIVMS H H InterNet: YEHAVI@VMS.HUJI.AC.IL H H =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988062217595900> Received: from UDEL.EDU by SRI-NIC.ARPA with TCP; Thu, 23 Jun 88 04:16:12 PDT Received: from huey.udel.edu by Louie.UDEL.EDU id aa05759; 22 Jun 88 22:02 EDT Date: Wed, 22 Jun 88 21:59:59 EDT From: Mills@UDEL.EDU To: "David E. Bernholdt" cc: tcp-ip@sri-nic.arpa Subject: Re: Can users get *the* time? Message-ID: <8806222200.aa25750@Huey.UDEL.EDU> David, Anybody can ask a time server for time, even normals. See the TCP/IP Protocol Handbook, available from SRI International, for details on the various protocols or the various other sources of protocol information. A friendly Unix system near you probably has most of those protocols, including daemons for NTP written by Mike Petry (petry@trantor.umd.edu for further details). Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [2993@emory.uucp] <1988062218394200> From: ospwd@emory.uucp (Peter Day {EUCC}) Newsgroups: comp.protocols.tcp-ip Subject: SLIP Keywords: SLIP serial IP Message-ID: <2993@emory.uucp> Date: 22 Jun 88 18:39:42 GMT Organization: Emory University Computing Center Lines: 10 Does anyone know where I can find a specification for SLIP, the Serial Line IP facility? Please respond directly to me and I will summarize. Peter Day Internet: ospwd%emoryu1@relay.cs.net Bitnet: ospwd@emoryu1 UUCP: gatech!emoryu1!ospwd ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988062219270100> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Thu, 23 Jun 88 23:56:03 PDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA16867; Thu, 23 Jun 88 07:21: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: 22 Jun 88 19:27:01 GMT From: necntc!drilex!axiom!linus!security!rpg@ames.arc.nasa.gov (Robert P. Goldsmith) Organization: The MITRE Corporation, Bedford MA Subject: Re: Need rfc 877 Message-Id: <34962@linus.UUCP> References: <3c910032.8a06@apollo.uucp> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa In article <3c910032.8a06@apollo.uucp> brezak@apollo.uucp (John Brezak) writes: >Could someone email RFC 877 to me. > Me too, please. =============================================================================== Usual disclaimers R. Goldsmith arpa: rpg@mitre-bedford.arpa US Mail: MITRE Corp MCI Mail: yes Mail Stop B330 voice: (617) 271-3625 Burlington Road Bedford, MA 01730 =============================================================================== ----MESSAGE-END---- ----MESSAGE-BEGIN---- [11100002@konech.UUCP] <1988062309330000> From: rudolf@konech Newsgroups: comp.protocols.tcp-ip Subject: SLIP Info wanted - (nf) Message-ID: <11100002@konech.UUCP> Date: 23 Jun 88 09:33:00 GMT Lines: 7 Nf-ID: #N:konech:11100002:000:223 Nf-From: konech!rudolf Jun 23 10:33:00 1988 I heard about the SLIP Protocol for running TCP/IP data over serial lines. Where can I get some info ? Thanks in advance Heinz Rudolf Kontron,Eching uucp: mcvax!unido!konech!rudolf ----MESSAGE-END---- ----MESSAGE-BEGIN---- [353@faui44.informatik.uni-erlangen.de] <1988062312150600> From: dkhusema@faui44.informatik.uni-erlangen.de (Dirk Husemann) Newsgroups: comp.protocols.tcp-ip Subject: Re: tcp-ip 4.3 public domain fixes ... Keywords: Solution found (?) Message-ID: <353@faui44.informatik.uni-erlangen.de> Date: 23 Jun 88 12:15:06 GMT Lines: 48 In a previous posting I asked about the struct member if_addr in netinet/tcp_input.c, well, - I'm a bit ashamed to tell, but after rechecking the source code - netinet/tcp_input.c - again today, we found out, that I *did* miss something - a little bitty #if: #if BSD<43 /* XXX this belongs in netinet/in.c */ in_localaddr(in) BSD is defined in include/netinet/tcp_var.h as 42 in case it isn't defined at all: #ifndef BSD #define BSD 42 /* if we're not 4.3, pretend we're 4.2 */ #define OLDSTAT /* set if we have to use old netstat binaries */ #endif As our UNIX operating system (XELOS/esd5) can handle 4.3bsd source code to a certain extent, we just defined BSD as 43, which took care of our problem! I assume that, in order to make 4.3 tcp-ip work under 4.2bsd,i.e. defining BSD as 42, one probably needs the _old_ header files, otherwise the question remains to be answered where one (tcp_input.c that is) shall get his/her hands on if_addr. Dirk ------------------ Smile, tomorrow will be worse! ------------- Business: Dirk Husemann Home: Dirk Husemann Friedrich-Alexander University Aufsess-Str. 19 Erlangen-Nuremberg D-8520 Erlangen Comp.Science Dep. IMMD IV West Germany Martensstrasse 1 +49 9131 302036 D-8520 Erlangen West Germany +49 9131 857908 email: dkhusema@faui44.informatik.uni-erlangen.de ------------------ Did I say smile? Forget it! ---------------- Disclaimer: The opinions, views, statements, ..., expressed here are NOT those of the university nor those of the student body as a whole. In fact, they're mine! --------------------------------------------------------------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [446@anagld.UUCP] <1988062313330300> From: rcsmith@anagld.UUCP (Ray Smith) Newsgroups: comp.protocols.tcp-ip Subject: Re: Xenix and TCP/IP Message-ID: <446@anagld.UUCP> Date: 23 Jun 88 13:33:03 GMT References: <2142@julian.uwo.ca> Reply-To: rcsmith@anagld.UUCP (Ray Smith) Organization: Analytics, Inc., Columbia, MD Lines: 19 In article <2142@julian.uwo.ca> purple@julian.UUCP (Lori Corrin) writes: > > I'm looking for some infornation on TCP/IP running under Xenix. ^^^^^^ ^^^^^ You might want to try: Network Research Corp. 2380 N. Rose Avenue Oxnard, Ca 93030 (805) 485-2700 -- Ray Smith | USnail: Suite 200, 9891 Broken Land Pky, Columbia, MD 21046 Analytics, Inc. | GEnie : rcsmith (301) 381-4300 | CIS : 72000,1111 | Net : ...!uunet!mimsy!aplcen!anagld!rcsmith =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "The trouble with doing something right the first time is that nobody appreciates how difficult it was." -Walt West =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8852310494.20601603.HEILNER_K] <1988062315490200> From: HEILNER_K@VAXC.STEVENS-TECH.EDU Newsgroups: comp.protocols.tcp-ip Subject: (none) Message-ID: <8852310494.20601603.HEILNER_K> Date: 23 Jun 88 15:49:02 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 11 Can anyone recommend a vendor who supplies a Micro Channel Architecture(MCA) Ethernet board??? Keith Heilner Network Coordinator Stevens Institute of Technology Heilner_k@sitvxb Heilner_k@vaxb.stevens-tech.edu ------------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [599@gouldnl.UUCP] <1988062317080600> From: ted@gouldnl.UUCP (Ted Lindgreen) Newsgroups: comp.protocols.tcp-ip,comp.unix.questions Subject: Re: Where do you suppose I could get egp or gated? Summary: gated is part of UTX Keywords: gated egp gould UTX Message-ID: <599@gouldnl.UUCP> Date: 23 Jun 88 17:08:06 GMT References: <1977@hubcap.UUCP> Reply-To: ted@gouldnl.UUCP (Ted Lindgreen) Organization: Gould European Unix Support Centre Lines: 16 In article <1977@hubcap.UUCP> mrspock@hubcap.UUCP (Steve Benz) writes: >We have a Gould 9005 connected to the Milnet (26.0.0.80 is our number) [deleted: need for gated] > >So we called Gould -- they said something like "eeh gee whut?" Gated is part of the Goulds standard operating systems UTX/32 2.1 (for Powernode, such as your 9005) and UTX/32 3.0 (for NP1), so so there are people at Gould that know about it. You should ask Gould again. If that does not succeed, please contact me by e-mail, I may give you a better reference. | Ted Lindgreen ...!mcvax!gouldnl!ted | | Gould European Unix Support Centre ted@gouldnl.nl | | Maarssenbroek, The Netherlands (USA) ...!gould!tlindgreen | ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988062318173700> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Fri, 24 Jun 88 00:33:15 PDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA21311; Thu, 23 Jun 88 11:50:59 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: 23 Jun 88 18:17:37 GMT From: haas@gr.utah.edu (Walt Haas) Organization: University of Utah CS Dept Subject: Re: Bridge vs. Cisco IP routers Message-Id: <2686@utah-gr.UUCP> References: <8806231050.AA13467@ucbvax.Berkeley.EDU> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa When shopping for routers don't forget that Proteon also makes one which is widely popular here - I don't know if it's sold in Israel or not. Walt Haas haas@cs.utah.edu utah-cs!haas ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12408787840.33.VAF@Score.Stanford.EDU] <1988062318272500> From: VAF@SCORE.STANFORD.EDU (Vince Fuller) Newsgroups: comp.protocols.tcp-ip Subject: Re: Looking for comments on the 15-pin Message-ID: <12408787840.33.VAF@Score.Stanford.EDU> Date: 23 Jun 88 18:27:25 GMT References: <8806212245.AA13645@hoquiam> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 4 Hear here! --Vince ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806231856.AA09224@uf.msc.umn.edu] <1988062318563900> From: fin@UF.MSC.UMN.EDU (Craig Finseth) Newsgroups: comp.protocols.tcp-ip Subject: Remote Gnumacs servers? Message-ID: <8806231856.AA09224@uf.msc.umn.edu> Date: 23 Jun 88 18:56:39 GMT References: <335@csvaxa.UUCP> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 25 I experimeted some time ago with a version of Gnu-Emacs that had been modified to use the LEAP features in an Encore Annex terminal concentrator. The LEAP features offload the terminal operations (echoing, etc.). Although not exactly the same situation as you describe, it did lead me to propose a conjecture (additional testing may turn it into a theorem): Moving processing from a central, shared resource to a distributed, private resource results in lowering the average response time while increasing the standard deviation of the response time. In this particular case, I felt that the increase in standard deviation resulted in crossing a threshold which made performance poor enough that it could not be offset by the decrease in average response. In particular, when you went from typing to editing, the pause was long (compared to echoing) and you had the impression that you editing character (e.g., ^N, ^A) was ignored, causing you to type it again. To say the least, this behavior is annoying (see previous paragraph.) My advice: quit while you're ahead. Craig A. Finseth fin@uc.msc.umn.edu [CAF13] Minnesota Supercomputer Center, Inc. (612) 624-3375 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806232023.AA22545@fermi.cray.com] <1988062320233900> From: hrp@fermi.CRAY.COM (Hal Peterson) Newsgroups: comp.protocols.tcp-ip Subject: ftp hash marks in binary mode Message-ID: <8806232023.AA22545@fermi.cray.com> Date: 23 Jun 88 20:23:39 GMT References: <23249@teknowledge-vaxc.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 11 This is a bug in the FTP client in both 4.2BSD and 4.3BSD. The code does not allow for the possibility of a read() returning less than a full buffer, which happens all of the time with a TCP socket, especially over a busy long-haul net. You get a hash mark for every successful read rather than for every BUFSIZ bytes transferred, and since the size of every read is unpredictable, there is no way to determine how many bytes you have transferred from the number of hash marks you have seen. -- Hal Peterson / Cray Research / 1440 Northland Dr. / Mendota Hts, MN 55120 hrp%hall.CRAY.COM@umn-rei-uc.ARPA ihnp4!cray!hrp (612) 681-3145 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [4227@mtgzz.att.com] <1988062321050700> From: jis@mtgzz.att.com (XMRP50000[jcm]-j.mukerji) Newsgroups: comp.protocols.tcp-ip Subject: Looking for public domain TCP/IP Message-ID: <4227@mtgzz.att.com> Date: 23 Jun 88 21:05:07 GMT Distribution: na Organization: AT&T, Middletown NJ Lines: 12 I am looking for a public domain version of TCP/IP for my own use. I would like to find a version for which I can get the source. Does such a beast exist? If it does, from where can I get it? Please email responses to jis@mtgzz.att.com, I will summarize. Thanks. -- Jishnu Mukerji, mtgzz!jis, jis@mtgzz.att.com +1 201 957 5986 AT&T, MT 3K-423, 200 Laurel Ave., Middletown NJ 07748 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [5281@batcomputer.tn.cornell.edu] <1988062401511300> From: north@batcomputer.tn.cornell.edu (Michael J. North) Newsgroups: comp.protocols.tcp-ip,comp.unix.questions,comp.sources.wanted Subject: Re: Where do you suppose I could get egp or gated? Message-ID: <5281@batcomputer.tn.cornell.edu> Date: 24 Jun 88 01:51:13 GMT References: <1977@hubcap.UUCP> Reply-To: north@tcgould.tn.cornell.edu (Michael J. North) Organization: Cornell Theory Center, Cornell University, Ithaca NY Lines: 13 You get "gated" via anonymous ftp to devvax.tn.cornell.edu. The latest version of it is about one month old. Have at it........ Mike -- Michael J. North "Guess who's heading for Urbana, IL next week?" Cornell Theory Center, 265 Olin Hall, Ithaca, NY 14853-5201 UUCP: {allegra,decvax,ihnp4,vax135}!cornell!batcomputer!north Arpa: north@tcgould.tn.cornell.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806240325.AA03662@Larry.McRCIM.McGill.EDU] <1988062403255600> From: philipp@LARRY.MCRCIM.MCGILL.EDU (Philip A. Prindeville) Newsgroups: comp.protocols.tcp-ip Subject: re: IEN-116 nameserver Message-ID: <8806240325.AA03662@Larry.McRCIM.McGill.EDU> Date: 24 Jun 88 03:25:56 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 14 From: postel@venera.isi.edu To: tcp-ip@sri-nic.arpa Subject: re: IEN-116 nameserver [ ... ] Long live the Domain Name System. --jon. As long as it doesn't out-live its usefulness. I figure it will be obsolete about the time the last (bug-free) release of BIND comes out (circa 4.381Beta)... -Philip ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806270235.AA21452@ucbvax.Berkeley.EDU] <1988062405210000> From: YEHAVI@HUJIVMS.BITNET (Yehavi Bourvine +972-2-584279) Newsgroups: comp.protocols.tcp-ip Subject: Bridge's GS/3 vs. Cisco AGS - summary. Message-ID: <8806270235.AA21452@ucbvax.Berkeley.EDU> Date: 24 Jun 88 05:21:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 5 Thanks to all who answered my question about Cisco routers vs. Bridge's ones. All the answers say that Cisco is far better than Bridge, and some of them even say that the GS/3 doesn't conform to RFC-1009. Thanks again, __Yehavi: ----MESSAGE-END---- ----MESSAGE-BEGIN---- [22198@amdcad.AMD.COM] <1988062406362500> From: percy@amdcad.AMD.COM (Percy Irani) Newsgroups: comp.protocols.tcp-ip,comp.dcom.lans Subject: Re: Print Server Message-ID: <22198@amdcad.AMD.COM> Date: 24 Jun 88 06:36:25 GMT References: <6770@sigi.Colorado.EDU> Reply-To: percy@amdcad.UUCP (Percy Irani) Organization: Advanced Micro Devices Lines: 11 We have used the Imagen printer with their Ethernet server. Works well for Unix and VMS hosts. You do have to install the Imagen software on all nodes you want to print from. Hope that helps. Imagen can be reached at (408) 986-9400. ---------------------------------------------------------- I speak for myself and not the Company. All opinions expressed are my own. -- Ignorance is bliss but can be embarassing at times! ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988062413210000> Received: from CUNYVM.CUNY.EDU by SRI-NIC.ARPA with TCP; Sun, 26 Jun 88 17:58:55 PDT Received: from HUJIVMS.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 5590; Fri, 24 Jun 88 01:24:58 EDT Received: by HUJIVMS (HUyMail-4c); Fri, 24 Jun 88 08:23:44 +0300 Date: Fri, 24 Jun 88 8:21 +0300 From: Yehavi Bourvine +972-2-584279 To: TCP-IP@SRI-NIC.ARPA Subject: Bridge's GS/3 vs. Cisco AGS - summary. Thanks to all who answered my question about Cisco routers vs. Bridge's ones. All the answers say that Cisco is far better than Bridge, and some of them even say that the GS/3 doesn't conform to RFC-1009. Thanks again, __Yehavi: ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806241112.aa18517@Huey.UDEL.EDU] <1988062415120100> From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: TCP/IP in a real time kernal Message-ID: <8806241112.aa18517@Huey.UDEL.EDU> Date: 24 Jun 88 15:12:01 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 7 Dave, Fuzzball, and it keeps very real time. I'm not sure you would call the kernel small and it is built in assembly code for the PDP11. I'm not sure you gain much comfort in that. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [22208@amdcad.AMD.COM] <1988062418265400> From: phil@amdcad.AMD.COM (Phil Ngai) Newsgroups: comp.protocols.tcp-ip,comp.dcom.lans Subject: Re: Print Server Message-ID: <22208@amdcad.AMD.COM> Date: 24 Jun 88 18:26:54 GMT References: <6770@sigi.Colorado.EDU> <22198@amdcad.AMD.COM> Reply-To: phil@amdcad.UUCP (Phil Ngai) Organization: Advanced Micro Devices Lines: 14 In article <22198@amdcad.AMD.COM> percy@amdcad.UUCP (Percy Irani) writes: > >We have used the Imagen printer with their Ethernet server. >Works well for Unix and VMS hosts. I disagree, I don't even use it because the default type size is not pica and you have to waste time screwing around with troff or such to get things to look normal. I complained about this to Percy and was ignored. -- I speak for myself, not the company. Phil Ngai, {ucbvax,decwrl,allegra}!amdcad!phil or phil@amd.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [880624191754.0000773F.AFGF.01@CDCCentr] <1988062500175400> From: dino@CDCCENTR.BITNET (Dino Farinacci - Control Data - CDCNET TCP/IP Development) Newsgroups: comp.protocols.tcp-ip Subject: Re: 802 (.2).3 TCP/IP Message-ID: <880624191754.0000773F.AFGF.01@CDCCentr> Date: 25 Jun 88 00:17:54 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 47 This is in response to ssc-vax!bruce@beaver.cs.washington.edu's memo <1919@ssc-vax.UUCP>: When we (CDC) initially started support of TCP/IP in CDCNET we made the decision to support all three of the Ethernet header formats. We were informed with the direction of OSI standards that 802.2/802.3 was the way to go. Our CDCNET systems already supported this header format but we needed to include Ethernet 2 and SNAP headers. We felt the effort was trivial for incoming frames. Just check the ether type field in the 802.3 (or version 2 header). If the value was greater than 1518 (maximum length Ethernet frame), then the header format was Ethernet 2. Otherwise it was 802.2/802.3. If 802.2 was present than another check is done to determine if a SNAP header follows. If so, use the ether type field in the SNAP as one would in the Ethernet 2 case. If no SNAP, use the 8-bit SAP value in the 802.2 to multiplex to the correct user. For outgoing frames, one does not know what header format the destination system supports. If it was our own system, it didn't matter (we supported all of them). There are two ways we allowed this information to be provided. One, staticly configure the header format with the IP address/ Ethernet address. Or two, let ARP find out. Obviously it was less of a burden to the Network Administrator if ARP did it. The disadvantage was that ARP broadcasts two ARP requests, each with a differnet header format (Ethernet 2 and SNAP - there is not an 8-bit 802.2 SAP value assigned for ARP). When the reply is received, the IP address/Ethernet address and header format is cached. We did this over a year and a half ago anticipating that workstation vendors would go to the SNAP. However, everything I've heard from the TCP/IP interoperability conferences indicates no one cares about it and everything works fine as it is today. Dino Farinacci Control Data Corp. CDCNET TCP/IP Design and Development Sunnyvale, CA. 408-744-5375 ------------------------------------------------------------------703 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988062503000400> Received: from CUNYVM.CUNY.EDU by SRI-NIC.ARPA with TCP; Sun, 26 Jun 88 19:55:41 PDT Received: from MSSTATE.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 5344; Sun, 26 Jun 88 20:29:33 EDT Date: Sat, 25 Jun 88 08:00:04 CDT From: Mike Rackley Subject: Domain name/subnet relationship. To: I attempted to post this question to the BIG-LAN discussion group about a week ago, but I think it got lost in transit. Anyhow, I apologize if you have seen this before. As we plan or campus network, we have decided to use 4 level domain names of the form: host.dept.MSSTATE.EDU. This seems to be in line with what a lot of other universities do. We also plan to assign internet addresses in a subnetted fashion even though initially we will be using MAC layer bridges instead of routers for traffic isolation. I am confused about the relationship of domains and subnets. Is there, or should there be, any specific relationship between domains and subnets? In particuar, is it possible to have a single domain that contains more than one subnet? Conversely, is it possible to have a single subnet that contains more than one domain? Can you have a single domain that is spread among several subnets? The situation I am wondering about is where a department is spread among several buildings on campus. Mike Rackley Mississippi State University ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806250040.AA26402@decwrl.dec.com] <1988062503400000> From: jain@erlang.DEC.COM (Raj Jain, DEC, 550 King St., Littleton, MA 01460, USA) Newsgroups: comp.protocols.tcp-ip Subject: DEC-TR-553: Error Characteristics of FDDI. Report Available. Message-ID: <8806250040.AA26402@decwrl.dec.com> Date: 25 Jun 88 03:40:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 53 The following DEC Technical Report DEC-TR-553 is now available for distribution: Title: Error Characteristics of Fiber Distributed Data Interface (FDDI) [32 pages] Author: Raj Jain Digital Equipment Corp. 550 King St. (LKG1-2/A19) Littleton, MA 01460 If you would like a hard copy of the report mailed to you, please send me your U.S. (or foreign) Mail address. Soft copies of the report are also available for LN03 and postscript printers. If you like a soft copy, please specify LN3 or PS. My network address on ARPAnet is Jain%Erlang.dec@decwrl.dec.com ABSTRACT Fiber Distributed Data Interface (FDDI) is a 100 megabits per second fiber optic local area network (LAN) standard being developed by the American National Standard Institute (ANSI). We analyze the impact of various design decisions on the error detection capability of the protocol. In particular, we quantify frame error rate, token loss rate, and undetected error rate. Several characteristics of the 32-bit frame check sequence (FCS) polynomial, which is also used in IEEE 802 LAN protocols, are discussed. The standard uses a ``non-return to zero invert on ones'' (NRZI) signal encoding and a 4 bit-to-5 bit (4B/5B) symbol encoding in the physical layer. Due to the combination of NRZI and 4B/5B encoding, many noise events are detected by code (or symbol) violations. A large percentage of errors is also detected by framing violations. Some of the remaining errors are detected by FCS violations. The errors that escape these three violations remain undetected. The probability of undetected errors due to creation of false starting delimiters, false ending delimiters, or merging of two frames is analyzed. It is shown that every noise event results in two code-bit errors, which in turn may result in up to four data-bit errors. The FCS can detect up to two noise events. Creation of a false starting delimiter or ending delimiter on a symbol boundary also requires two noise events. This assumes enhanced frame validity criteria. We justify the enhancements by quantifying their effect. This analysis here is limited to noise events not resulting in a change of symbol boundaries. Extensions to the case of changed symbol boundaries is continuing and will be presented at a later time. Version: June 1988 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806270548.AA23542@ucbvax.Berkeley.EDU] <1988062513000400> From: RACKLEY@MSSTATE.BITNET (Mike Rackley) Newsgroups: comp.protocols.tcp-ip Subject: Domain name/subnet relationship. Message-ID: <8806270548.AA23542@ucbvax.Berkeley.EDU> Date: 25 Jun 88 13:00:04 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 19 I attempted to post this question to the BIG-LAN discussion group about a week ago, but I think it got lost in transit. Anyhow, I apologize if you have seen this before. As we plan or campus network, we have decided to use 4 level domain names of the form: host.dept.MSSTATE.EDU. This seems to be in line with what a lot of other universities do. We also plan to assign internet addresses in a subnetted fashion even though initially we will be using MAC layer bridges instead of routers for traffic isolation. I am confused about the relationship of domains and subnets. Is there, or should there be, any specific relationship between domains and subnets? In particuar, is it possible to have a single domain that contains more than one subnet? Conversely, is it possible to have a single subnet that contains more than one domain? Can you have a single domain that is spread among several subnets? The situation I am wondering about is where a department is spread among several buildings on campus. Mike Rackley Mississippi State University ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806260135.AA01070@Larry.McRCIM.McGill.EDU] <1988062601350700> From: philipp@LARRY.MCRCIM.MCGILL.EDU (Philip A. Prindeville) Newsgroups: comp.protocols.tcp-ip Subject: Re: Print Server Message-ID: <8806260135.AA01070@Larry.McRCIM.McGill.EDU> Date: 26 Jun 88 01:35:07 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 7 On the subject of Imagens, has anyone considered making the ethernet print engine speak NFS so the fonts don't have to be installed locally? This would simplify updating the software imensely if you have many such printers at your site. Now if only the DESC.out (etc) files were read in network byte order... -Philip ----MESSAGE-END---- ----MESSAGE-BEGIN---- [488@cvaxa.sussex.ac.uk] <1988062617023600> From: aledm@cvaxa.sussex.ac.uk (Aled Morris) Newsgroups: comp.protocols.tcp-ip Subject: Re: Third TCP-IP Book? Summary: comer book available outside US (but in different wrapper) Message-ID: <488@cvaxa.sussex.ac.uk> Date: 26 Jun 88 17:02:36 GMT References: <8805170601.AA21125@Larry.McRCIM.McGill.EDU> <360@lalk.excelan.UUCP> Organization: School of Cognitive Sciences, Univ of Sussex, Brighton, UK Lines: 18 I just picked up a copy of the Comer book ("Internetworking with TCP/IP"), I would recommend it (there---I just did! :-) It is available in the UK (and presumably the rest of the world apart from the US, Mexico and Canada) in Prentice-Hall's "International Editions" series (with a red cover to match Tanenbam's networks and Minix books, etc etc) It's ISBN is 0-13-470188-7, and I paid #18.95 (thats pounds sterling). Aled Morris systems programmer Janet/Arpa: aledm@uk.ac.sussex.cvaxa | School of Cognitive Science uucp: ..!mcvax!ukc!cvaxa!aledm | University of Sussex talk: +44-(0)273-606755 e2372 | Falmer, Brighton, England "I'm living in the future/I feel wonderful/I'm tipping over backwards... I'm so ambitious/I'm looking back/I'm running a race and you're the book I read" ----MESSAGE-END---- ----MESSAGE-BEGIN---- [489@cvaxa.sussex.ac.uk] <1988062617241100> From: aledm@cvaxa.sussex.ac.uk (Aled Morris) Newsgroups: comp.protocols.tcp-ip Subject: Re: Looking for comments on the 15-pin ethernet connector Summary: for what it's worth... Message-ID: <489@cvaxa.sussex.ac.uk> Date: 26 Jun 88 17:24:11 GMT References: <3352@phri.UUCP> <8806150602.AA11768@atom.hpl.hp.com> Organization: School of Cognitive Sciences, Univ of Sussex, Brighton, UK Lines: 31 I too *hate* the clip arrangement on ethernet connectors. The most difficult manouver is trying to lever the sodding clip so you can disconnect the drop cable from the back of a "deskside" Sun, when there's something screwed firmly into port B, and you're worried about hitting that reset button 1inch down (plus, of course, you're leaning over the cabinet on your belly trying not to hit the power switch with your knee) [fume fume...] There are worse connectors...and those are the 3 pin mains leads, with absolutely NO RETAINER WHATSOEVER [god, they make me so ANGRY :-)] Forget about "ie0: ethernet jammed", one jerk (pun intended) and the machine goes down, lock stock and disk heads. Proividing FSCK does not make up for saving 50 cents on a decent screw-in cable lock. And another thing---that stupid "off" switch on the front panel, it really ought to be a key (with a "safe" position that disables L1-A). I'm so glad that others apart from myself are complaining about these stupid practices. Maybe we'll actually see some action from the vendors on this one? p.s. maybe this discussion ought to get moved elsewhere...? Aled Morris systems programmer Janet/Arpa: aledm@uk.ac.sussex.cvaxa | School of Cognitive Science uucp: ..!mcvax!ukc!cvaxa!aledm | University of Sussex talk: +44-(0)273-606755 e2372 | Falmer, Brighton, England "I'm living in the future/I feel wonderful/I'm tipping over backwards... I'm so ambitious/I'm looking back/I'm running a race and you're the book I read" ----MESSAGE-END---- ----MESSAGE-BEGIN---- [7@bambam.UUCP] <1988062703292000> From: hjp@bambam.UUCP (Howard J. Postley) Newsgroups: comp.protocols.tcp-ip,comp.dcom.lans Subject: Re: Print Server Message-ID: <7@bambam.UUCP> Date: 27 Jun 88 03:29:20 GMT References: <6770@sigi.Colorado.EDU> <22198@amdcad.AMD.COM> <22208@amdcad.AMD.COM> Organization: On Word, Inc.; Santa Monica, CA Lines: 29 In article <22208@amdcad.AMD.COM>, phil@amdcad.AMD.COM (Phil Ngai) writes: > In article <22198@amdcad.AMD.COM> percy@amdcad.UUCP (Percy Irani) writes: > > > >We have used the Imagen printer with their Ethernet server. > >Works well for Unix and VMS hosts. > > I disagree, I don't even use it because the default type size is not > pica and you have to waste time screwing around with troff or such to > get things to look normal. > > I complained about this to Percy and was ignored. I don't know how you guys at AMD set your printer up but on ours the font is controlled by the "of" filter in /etc/printcap and the default font is settable in an environment variable. Admittedly, the default default font (failing setting the var to change it) is not Courier. Bummer |-). // Howard -- Howard Postley usenet: uunet!bambam!hjp On Word phone: +1 213 399 7733 snail: 2434 Main St; Santa Monica, CA 90405 -- Howard Postley usenet: uunet!bambam!hjp On Word phone: +1 213 399 7733 snail: 2434 Main St; Santa Monica, CA 90405 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988062709324500> Received: from MITVMA.MIT.EDU by SRI-NIC.ARPA with TCP; Mon, 27 Jun 88 10:40:05 PDT Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 3333; Mon, 27 Jun 88 13:40:00 EDT Received: by MITVMA (Mailer X1.25) id 3331; Mon, 27 Jun 88 13:39:58 EDT Date: Mon, 27 Jun 88 13:32:45 EDT From: Edward Kodinsky Subject: TCP/IP for MVS To: TCP-IP@SRI-NIC.ARPA Recently James VanBokkelen from FTP Software Inc. stated that the Spartacus KNET/MVS product had its ancestry from the UCLA MVS code. This is not the case. The Spartacus MVS productline is a substantially modified version of Spartacus' KNET/VM product. Spartacus has not used any of the UCLA MVS code. Edward Kodinsky Director of Software Development Spartacus Inc. 617-937-1600 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [747@cunixc.columbia.edu] <1988062712473700> From: alan@cunixc.columbia.edu (Alan Crosswell) Newsgroups: comp.protocols.tcp-ip Subject: Re: Domain name/subnet relationship. Message-ID: <747@cunixc.columbia.edu> Date: 27 Jun 88 12:47:37 GMT References: <8806270548.AA23542@ucbvax.Berkeley.EDU> Reply-To: alan@cunixc.columbia.edu (Alan Crosswell) Organization: Columbia University Lines: 28 In article <8806270548.AA23542@ucbvax.Berkeley.EDU> RACKLEY@MSSTATE.BITNET (Mike Rackley) writes: >I am confused about the relationship of domains and subnets. Is there, >or should there be, any specific relationship between domains and subnets? >In particuar, is it possible to have a single domain that contains more than >one subnet? Conversely, is it possible to have a single subnet that contains >more than one domain? Can you have a single domain that is spread among >several subnets? The situation I am wondering about is where a department is >spread among several buildings on campus. Domains are basically a *user* convenience for naming an IP address. There is no required relationship between a domain name and an IP address, network, subnet, campus, etc. In usual practice they happen to correspond since single departments tend to be on a single subnet. However, it is perfectly reasonable to have members of the same subdomain be located on radically different networks (e.g. on opposite sides of the world). You just better hope that a domain name server for that domain is reachable from both those networks (not necessarily the same one!). A lot of people get domains and networks locked together in their minds mainly as a result of poor examples of domain usage like .BITNET and .UUCP where the domain is actually being used to indicate a specific non-IP network. Work is progressing in both these networks to convert to proper domain names. There are now many "MX" servers on the Internet that respond to domain lookups for BITNET and UUCP hosts. Alan Crosswell Columbia University ----MESSAGE-END---- ----MESSAGE-BEGIN---- [111:nittmann@rusvx1.rus.uni-stuttgart.dbp.de] <1988062713131000> From: nittmann@rusvx1.rus.uni-stuttgart.dbp.de ("Michael F.H. Nittmann ") Newsgroups: comp.protocols.tcp-ip Subject: historical defaults Message-ID: <111:nittmann@rusvx1.rus.uni-stuttgart.dbp.de> Date: 27 Jun 88 13:13:10 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 47 Throwing in the following I would like to see if it is worth being discussed: there are two defaults in the telnet standard that are a little bit hampering on networks since on my opinion they cause lots of evitable network charge: go ahead and remote echo. On my own experience most communications in interactive telnet use are from a workstation to a mainframe computer. The lines are full duplex as seen from the telnet side. A virtual circuit of two phone lines or a x.25 virtual circuit look as a full duplex line to the telnet. So: why bother with a go ahead as a default start and not just set SGA as a default. The same I think holds for the remote echo. This is a very useful option when operating over very unreliable lines to very unreliable hosts. When communicating over a standard network which is reliable as seen from the bottom side of telnet, and when the tcp/ip used as a type 4 protocol would take care of resending characters if they are lost or timed out, so why charge the already overcrowded network ( re. the breakdowns early in '88) with those single character echo packets. I would guess that nowadays - in 88, not in times on NCP-->TCP transition - most communications could easily be done with SGA and local echo. Seen from the mainframe pespective I personnally judge it a gigantesque waste of resources to let a multi user mainframe echo single characters - mainframes may of course switch that off by negotiating, as is done with SGA. The problem I see in my experience is that some implementations heavily rely on the defaults. When confronted with a non default negotiation at communication start some implementations don't work correctly. They either insist negotiating their default or just hang waiting for a GA. By switching the defaults - SGA and local echo - I think we could avoid network charge - two defaults together never would negotiate e.g. the echo since there is no reson so they will send those silly 1 character packets. On the other hand implementors would perhaps be oriented to the more useful modes as is SGA. Or is there somebody who really knows he needs the GA any more? Perhaps this will result in a level 3 or level 4 discussion opposed to the link level discussion on connectors.(this is OSI terminology). And as usual: these are my personal views. Michael F.H.Nittmann ----MESSAGE-END---- ----MESSAGE-BEGIN---- [19880627135421.6.DCP@SWAN.SCRC.Symbolics.COM] <1988062713540000> From: DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer) Newsgroups: comp.protocols.tcp-ip Subject: Domain name/subnet relationship. Message-ID: <19880627135421.6.DCP@SWAN.SCRC.Symbolics.COM> Date: 27 Jun 88 13:54:00 GMT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 13 Date: Sat, 25 Jun 88 08:00:04 CDT From: Mike Rackley ... I am confused about the relationship of domains and subnets. Is there, or should there be, any specific relationship between domains and subnets? They are completely orthogonal. You can, if you want, establish relationships, but it would be for purely personal and/or administrative reasons; there would be (and can be) no technical reason for doing so. The basic thing to remember is that domains are an administrative naming system, whereas subnets are a physical cable numbering system (more or less). ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806271403.AA03455@uf.msc.umn.edu] <1988062714034100> From: fin@uf.msc.umn.EDU (Craig Finseth) Newsgroups: comp.protocols.tcp-ip Subject: Domain name/subnet relationship. Message-ID: <8806271403.AA03455@uf.msc.umn.edu> Date: 27 Jun 88 14:03:41 GMT References: <8806270606.AA20956@uc.msc.umn.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 13 There is no need for any particular relationship between domains and subnets. You may choose -- for administrative ease -- to divvy up the subnet address space into blocks for each department. In that case, you will likely have some departments that occupy lots of subnets and other groups of departments that share a subnet. My advice is to have a central authority give out subnets on demonstrated need (e.g., new building or >200 or so hosts alread in place). In many places, once you give out a subnet, it becomes difficult to get back if the campus' needs as a whole should change. Craig A. Finseth fin@uc.msc.umn.edu [CAF13] Minnesota Supercomputer Center, Inc. (612) 624-3375 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806271410.AA03579@uf.msc.umn.edu] <1988062714100200> From: fin@UF.MSC.UMN.EDU (Craig Finseth) Newsgroups: comp.protocols.tcp-ip Subject: historical defaults Message-ID: <8806271410.AA03579@uf.msc.umn.edu> Date: 27 Jun 88 14:10:02 GMT References: <111:nittmann@rusvx1.rus.uni-stuttgart.dbp.de> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 13 Your suggestion that local echo is acceptable implies that the local host knows exactly when and how to echo locally. As of now, the local host does not know when and how to locally echo (what about display editors such as Emacs and vi?). In the latest IETF meeting (held a couple of weeks ago), there was a discussion about Telnet EXTENSIONS to handle this type of negotiation on a dynamic basis (i.e., negotiate which characters are for editing, how to handle editing, how and when to go in and out of "raw" mode, etc.) Craig A. Finseth fin@uc.msc.umn.edu [CAF13] Minnesota Supercomputer Center, Inc. (612) 624-3375 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806271428.AA20040@tut.cis.ohio-state.edu] <1988062714283700> From: tom@TUT.CIS.OHIO-STATE.EDU (Tom Easterday) Newsgroups: comp.protocols.tcp-ip Subject: Remove from list Message-ID: <8806271428.AA20040@tut.cis.ohio-state.edu> Date: 27 Jun 88 14:28:37 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 3 Please remove my name from your mailing list. Thanks. Tom ----MESSAGE-END---- ----MESSAGE-BEGIN---- [Jun.27.11.56.09.1988.1130@athos.rutgers.edu] <1988062715561000> From: hedrick@athos.rutgers.edu (Charles Hedrick) Newsgroups: comp.protocols.tcp-ip Subject: Re: historical defaults Message-ID: Date: 27 Jun 88 15:56:10 GMT References: <111:nittmann@rusvx1.rus.uni-stuttgart.dbp.de> Organization: Rutgers Univ., New Brunswick, N.J. Lines: 23 To: nittmann@rusvx1.rus.uni-stuttgart.dbp.de I agree that the telnet defaults are archaic. However in most cases there's going to have to be some negotiation at startup anyway (to pass terminal type, for example). So changing the defaults wouldn't simplify very much, and would lead to great confusion. Around universities in the U.S., I think telnet is typically used with Unix machines or DEC timesharing systems. Both of these OS's expect full-duplex connections. They sometimes do things with characters other than just echoing them. E.g. editors like emacs move the cursor around in response to single characters. Even when you are not in Emacs, there are commands for editing single lines in the normal command scanner. While I agree that it would be best to do as much work locally as possible, there are few systems where you can do this by using local echo in the sense it is defined in the telnet spec. Since most systems these days expect various characters to trigger special actions, in order to echo locally, the local host is going to have to be told something about those special characters. This means that a new telnet option will be defined that allows the host to tell the local system what characters are special. Discussions are currently going on within the Internet Engineering Taskforce about such an option. I think you'll see an RFC or the draft for one fairly soon. (Of course there are existing experimental protocols that do this already, such as SUPDUP, and the protocol used by Encore for their terminal servers.) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [3138@tekgen.BV.TEK.COM] <1988062717274800> From: sytek@tekgen.BV.TEK.COM (Mike Ewan) Newsgroups: comp.protocols.tcp-ip Subject: Re: (none) Message-ID: <3138@tekgen.BV.TEK.COM> Date: 27 Jun 88 17:27:48 GMT References: <8852310494.20601603.HEILNER_K> Reply-To: sytek@tekgen.BV.TEK.COM (Mike Ewan) Organization: Tektronix, Inc., Beaverton, OR. Lines: 7 In article <8852310494.20601603.HEILNER_K> HEILNER_K@VAXC.STEVENS-TECH.EDU writes: >Can anyone recommend a vendor who supplies a Micro Channel >Architecture(MCA) Ethernet board??? > Try AST. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806280952.AA19146@ucbvax.Berkeley.EDU] <1988062717324500> From: PETTY@MITVMA.MIT.EDU (Edward Kodinsky) Newsgroups: comp.protocols.tcp-ip Subject: TCP/IP for MVS Message-ID: <8806280952.AA19146@ucbvax.Berkeley.EDU> Date: 27 Jun 88 17:32:45 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 9 Recently James VanBokkelen from FTP Software Inc. stated that the Spartacus KNET/MVS product had its ancestry from the UCLA MVS code. This is not the case. The Spartacus MVS productline is a substantially modified version of Spartacus' KNET/VM product. Spartacus has not used any of the UCLA MVS code. Edward Kodinsky Director of Software Development Spartacus Inc. 617-937-1600 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [535@wrs.UUCP] <1988062718001200> From: jerry@wrs.UUCP (Jerry Fiddler) Newsgroups: comp.protocols.tcp-ip Subject: Re: TCP/IP in a real time kernal Keywords: TCP/IP realtime Message-ID: <535@wrs.UUCP> Date: 27 Jun 88 18:00:12 GMT References: <2348@elrond.CalComp.COM> Reply-To: jerry@wrs.UUCP (Jerry Fiddler) Organization: Wind River Systems, Emeryville, CA Lines: 12 In article <2348@elrond.CalComp.COM> bailey@elrond.CalComp.COM (Dave Bailey) writes: >Does anyone know of any TCP/IP implementations in small real time kernels? We sell a real-time OS called VxWorks that fits those needs. It runs on 68K-based targets now, and will run on SPARC targets in October. Rather than expound upon the (extensive) capabilities of VxWorks here (against net policy, after all) I'll send you some materials directly. -- Jerry Fiddler Wind River Systems {sun,rtech}!wrs!jerry ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988062719105100> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Mon, 27 Jun 88 18:25:30 PDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA08428; Mon, 27 Jun 88 15:36: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: 27 Jun 88 19:10:51 GMT From: killer!tness7!tness1!nuchat!texhrc!cml@ames.arc.nasa.gov (Chris Lonvick) Organization: Texaco Houston Res. Cntr Hou, Tx Subject: Re: IEN-116 nameserver Message-Id: <245@texhrc.UUCP> References: <581@hscfvax.harvard.edu> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa In article <581@hscfvax.harvard.edu>, mohamed@hscfvax.harvard.edu (Mohamed_el_Lozy) writes: > mapping. Are there any products out there that still use the IEN-116 > nameserver? > Bridge Communication's CS/1 may be configured for either IEN-116 or Domain Name Server. - Usual disclaimers. Chris Lonvick Texaco EPTD ----MESSAGE-END---- ----MESSAGE-BEGIN---- [23603@hi.unm.edu] <1988062721004000> From: kurt@hi.unm.edu (Kurt Zeilenga) Newsgroups: comp.protocols.tcp-ip Subject: Allocating subnets Message-ID: <23603@hi.unm.edu> Date: 27 Jun 88 21:00:40 GMT Reply-To: kurt@hi.unm.edu (Kurt Zeilenga) Organization: U. of New Mexico, Albuquerque Lines: 17 Just a note on allocating subnets (using a single netmask): 1) Pick an appropriate subnet mask (for then example: 255.255.255.0 for a B). 2) Then allocate the subnets by changing the high order bits of the subnet field (ie: X.X.128 first, then 64, 192, 32, 96, ...) 3) Allocate hosts within a subnet using the low order bits of the host field (ie: 1, 2, 3). Why? Because what you think now might be the right subnet mask may not be the right one in the future. With this allocation scheme you will have limited freedom to change the netmask later with minimal hardship (renumbering). - Kurt ----MESSAGE-END---- ----MESSAGE-BEGIN---- [281@mrsvr.UUCP] <1988062721592700> From: barbiaux@mrsvr.UUCP (Bill Barbiaux) Newsgroups: comp.protocols.tcp-ip Subject: Re: TCP/IP in a real time kernal Message-ID: <281@mrsvr.UUCP> Date: 27 Jun 88 21:59:27 GMT References: <2348@elrond.CalComp.COM> Organization: GE Medical, MR Center, Milwaukee Lines: 15 From article <2348@elrond.CalComp.COM>, by bailey@elrond.CalComp.COM (Dave Bailey): > Does anyone know of any TCP/IP implementations in small real time > kernals? thanks. We are using VxWorks, a real-time system and development environment with good networking facilities. It uses TCP/IP, and is built around the VRTX kernal. It is designed to fit well in a UNIX development environment (supports remote login, remote file access, a shell, etc.), while its kernal makes it useful for real-time applications. VxWorks is marketed by Wind River Systems, Inc., Emeryville, CA (415)428-2623. ALSO: I'm looking for TCP/IP implementations running under iRMX. Can anyone help me out? Thanks Bill Barbiaux ----MESSAGE-END---- ----MESSAGE-BEGIN---- [251*piyu@deervax.concordia.cdn] <1988062800200000> From: piyu%deervax.concordia.CDN@ean.ubc.ca (piyu tripathy) Newsgroups: comp.protocols.tcp-ip Subject: Remove from list Message-ID: <251*piyu@deervax.concordia.cdn> Date: 28 Jun 88 00:20:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 3 Please remove my name from your mailing list. Thanks. piyu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988062801390000> Received: from nrl.arpa by SRI-NIC.ARPA with TCP; Tue, 28 Jun 88 02:53:50 PDT Date: 28 Jun 88 05:39:00 EDT From: "NRL::FARNHAM" Subject: Re: Getting started To: "tcp-ip" cc: farnham HI! HOW DOES ONE GET A COPY OF THE HEADRICK MATERIAL. I CHECKED WITH THE UNIVERSITY OF MD. BOOK EXCHANGE AND THEY DIDN'T HAVE IT. I ALSO ASKED OUR NETWORK PEOPLE HERE AT NRL AND THEY DIDN'T HAVE IT. HEEELLLPPP!!! I'D REALLY LIKE TO READ IT. EMILY D. FARNHAM CODE 2861.7 NAVAL RESEARCH LABORATORY 4555 OVERLOOK AVE. S.W. WASHINGTON, D.C. 20375-5000 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988062804411800> Received: from LABS-N.BBN.COM by SRI-NIC.ARPA with TCP; Tue, 28 Jun 88 05:44:23 PDT Date: Tue, 28 Jun 88 8:41:18 EDT From: Alex McKenzie To: Charles Hedrick cc: tcp-ip@SRI-NIC.ARPA Subject: Re: historical defaults Of course, instead of the IETF inventing a new set of Telnet options, the community could consider the (shudder) ISO Virtual Terminal Protocol, which was designed to do all this. Alex McKenzie ----MESSAGE-END---- ----MESSAGE-BEGIN---- [220@turnkey.TCC.COM] <1988062805180200> From: jack@turnkey.TCC.COM (Jack F. Vogel) Newsgroups: comp.protocols.tcp-ip Subject: telnet server code Message-ID: <220@turnkey.TCC.COM> Date: 28 Jun 88 05:18:02 GMT Reply-To: jack@turnkey.TCC.COM (Jack F. Vogel) Distribution: na Organization: Turnkey Computer Consultants, Costa Mesa,CA Lines: 19 I have been experimenting with the KA9Q TCP/IP package both under DOS and under SCO Xenix. So far I have a variant of the package running as a background FTP and SMTP server under Xenix. The biggest limitation of the package for serious server usage is the lack of a Telnet server. Could some kind soul out there point me at some existing telnet code that I could access to integrate into the KA9Q stuff; it would make life much easier. If anyone else is interested in this package under Xenix send me some email and I can let you know the details. Please email and I will summarize should interest warrant it. Thanks so much, -- Jack F. Vogel Turnkey Computer Consultants, Costa Mesa, CA UUCP: ...{nosc|uunet}!turnkey!jack Internet: jack@turnkey.TCC.COM ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1002@ndsuvax.UUCP] <1988062805220100> From: ncoverby@ndsuvax.UUCP (Glen Overby) Newsgroups: comp.protocols.tcp-ip Subject: Re: TCP/IP in a real time kernal Summary: XINU V7 Message-ID: <1002@ndsuvax.UUCP> Date: 28 Jun 88 05:22:01 GMT References: <2348@elrond.CalComp.COM> <281@mrsvr.UUCP> Reply-To: ncoverby@ndsuvax.UUCP (Glen Overby) Organization: Silo Tech Fargo, ND Lines: 12 From article <2348@elrond.CalComp.COM>, by bailey@elrond.CalComp.COM (Dave Bailey): > Does anyone know of any TCP/IP implementations in small real time > kernals? thanks. I don't know if you consider XINU to be real-time or not (device drivers should be able to meet real-time requirements), and Version 7 contains TCP/IP(see Comer's second edition, "Operating System Design: The XINU Approach; Internetworking with XINU"). -- Glen Overby Bitnet: ncoverby@ndsuvax UUCP: uunet!ndsuvax!ncoverby ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806282327.AA02909@ucbvax.Berkeley.EDU] <1988062809390000> From: farnham%nrl.DECnet@NRL3.ARPA ("NRL::FARNHAM") Newsgroups: comp.protocols.tcp-ip Subject: Re: Getting started Message-ID: <8806282327.AA02909@ucbvax.Berkeley.EDU> Date: 28 Jun 88 09:39:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 13 HI! HOW DOES ONE GET A COPY OF THE HEADRICK MATERIAL. I CHECKED WITH THE UNIVERSITY OF MD. BOOK EXCHANGE AND THEY DIDN'T HAVE IT. I ALSO ASKED OUR NETWORK PEOPLE HERE AT NRL AND THEY DIDN'T HAVE IT. HEEELLLPPP!!! I'D REALLY LIKE TO READ IT. EMILY D. FARNHAM CODE 2861.7 NAVAL RESEARCH LABORATORY 4555 OVERLOOK AVE. S.W. WASHINGTON, D.C. 20375-5000 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806290207.AA05637@ucbvax.Berkeley.EDU] <1988062812411800> From: mckenzie@LABS-N.BBN.COM (Alex McKenzie) Newsgroups: comp.protocols.tcp-ip Subject: Re: historical defaults Message-ID: <8806290207.AA05637@ucbvax.Berkeley.EDU> Date: 28 Jun 88 12:41:18 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 5 Of course, instead of the IETF inventing a new set of Telnet options, the community could consider the (shudder) ISO Virtual Terminal Protocol, which was designed to do all this. Alex McKenzie ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806281427.AA24672@zaphod.ncsa.uiuc.edu] <1988062814275800> From: timk@NCSA.UIUC.EDU (Tim Krauskopf) Newsgroups: comp.protocols.tcp-ip Subject: Re: MCA Ethernet boards Message-ID: <8806281427.AA24672@zaphod.ncsa.uiuc.edu> Date: 28 Jun 88 14:27:58 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 27 Date: 27 Jun 88 17:27:48 GMT From: tektronix!tekgen!sytek@ucbvax.Berkeley.EDU (Mike Ewan) In article <8852310494.20601603.HEILNER_K> HEILNER_K@VAXC.STEVENS-TECH.EDU writes: >Can anyone recommend a vendor who supplies a Micro Channel >Architecture(MCA) Ethernet board??? > Try AST. Mike Don't bother "trying" AST. As of April, 1988, only two vendors were SHIPPING MCA Ethernet boards, Ungermann-Bass and 3Com. They both use the Intel 82586 chip, the 3Com board has an on-board transceiver and the UB does not. MICOM and Western Digital have announced boards which may be on some dealer's shelves by the time you read this, but I don't know any users which have them in hand. These companies market some of the lower-priced boards for the PC bus, so they may be good price competitors. Tim Krauskopf timk@ncsa.uiuc.edu (ARPA) National Center for Supercomputing Applications (NCSA) University of Illinois, Urbana-Champaign ----MESSAGE-END---- ----MESSAGE-BEGIN---- [2144@julian.uwo.ca] <1988062815240800> From: purple@julian.uwo.ca (Lori Corrin) Newsgroups: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: Thanks Message-ID: <2144@julian.uwo.ca> Date: 28 Jun 88 15:24:08 GMT Reply-To: purple@julian.UUCP (Lori Corrin) Organization: University of Western Ontario, London Lines: 18 Thanks to all who replied to my message for help with TCP/IP under Xenix. I've passed the replies on to the powers that be around here so they can make the final decisions, but the Excelean product seem to be the most common choice. Thanks Lori Corrin Computing and Communications Services University of Western Ontario London, Ontario, Canada purple@uwo.ca purple@julian.UUCP purple@uwovax.BITNET (...!watmath!julian!purple) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [Jun.28.11.46.21.1988.24281@topaz.rutgers.edu] <1988062815462400> From: ron@topaz.rutgers.edu (Ron Natalie) Newsgroups: comp.protocols.tcp-ip Subject: Re: Print Server Message-ID: Date: 28 Jun 88 15:46:24 GMT References: <6770@sigi.Colorado.EDU> Organization: Rutgers Univ., New Brunswick, N.J. Lines: 21 While CISCO sells a parallel printer and software for their terminal servers, it is possible to hang a printer off a CISCO serial port (provided it is an RS-232) printer. We have a number of dumb line printers and Postscript printers of various sorts that used to run on RS-232 ports off UNIX machines running on CISCO boxes. There are two ways of doing this. One way is that I have a program that sits on a PTY and shuffles everything to the remote cisco serial port. This is handy for places where you won't want to dink with the output filters. We do have some minor problems with this on the postscript printers especially when the printer times out due to long delays in the host spitting data into it. We've also hacked the Adobe Transcript driver to open connections to the device directly. As far as pricing, CISCO now has a midrange server that is probably a bit cheaper than the price you saw before. They are also rumored to be working on a very small RS-232/Ethernet only server. All there other servers can talk to a variety of network interfaces. CISCO gives discounts to educational institutions and EDUCOM/BITNET members. The MIDRANGE server I recall (discounted) was about the same price as the (discounted) price for the ANNEX (somewhere in the low $4000's for 16 lines). -Ron ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988062815524700> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Tue, 28 Jun 88 13:04:05 PDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA27974; Tue, 28 Jun 88 12:14:46 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 Jun 88 15:52:47 GMT From: elbereth.rutgers.edu!zydeco.rutgers.edu!latzko@rutgers.edu (Alexander Latzko) Organization: Rutgers Univ., New Brunswick, N.J. Subject: Re: IEN-116 nameserver Message-Id: References: <581@hscfvax.harvard.edu>, <245@texhrc.UUCP> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa The bridge CS/1 may only be configured to use Domain name service if it is running release 20000 of thier software. To run this release you must have the 512K version of the box. The 256K version is limited to release 19000 and IEN116. The upgrade path for a 256K box is to replace the mother board w/ the 512K version for some relativly high amount. What you might want to do is write an IEN116 server which simply issues a gethostbyname which your local resolver will then take and deal with. cheers /S* ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988062816450000> Received: from CUNYVM.CUNY.EDU by SRI-NIC.ARPA with TCP; Wed, 29 Jun 88 14:09:37 PDT Received: from ICNUCEVM.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 6095; Tue, 28 Jun 88 10:13:53 EDT Received: by ICNUCEVM (Mailer X1.25) id 7954; Tue, 28 Jun 88 15:50:18 SET Date: Tue, 28 Jun 88 15:45 SET From: Erina Ferro Subject: New OZONE mailing list! To: , , , A new computer conference is being formed. Please ignore this message if you have already received it. Sorry for duplicates. Please DO NOT ignore this message if it is the first time you read it! PLEASE FORWARD THIS MESSAGE TO EVERYBODY COULD BE INTERESTED. This mail is sent you by a group of researchers of the Italian National Council (C.N.R.), working at the CNUCE Institute, in order to wake up the sensitivity of people working in the scientific institutions about the extremely serious problem of the pollution in the world. As you certainly know, the hole in the ozone, the "hot-house effect", the acid rains and the toxic waste are disasters provoked by man by using the Nature as a "never-ending" resource. Everybody can verify other effects of the pollution, in the cities, in the seas, in the rivers, etc. We think that the scientific community must create an opinion movement able to force some decisions at political level. We think we are still in time to do something to save Nature with the help of everybody. A computing conference is going to be opened and you can partecipate by sending your ideas to the following address: OZONE@ICNUCEVM.CNUCE.CNR.IT or OZONE%ICNUCEVM.BITNET@CUNYVM.CUNY.EDU or OZONE%ICNUCEVM.BITNET@ICNUCEVM.CNUCE.CNR.IT In order to be included to the list of the partecipants to the conference, send a mail message to: LISTSERV@ICNUCEVM.CNUCE.CNR.IT or LISTSERV%ICNUCEVM.BITNET@CUNYVM.CUNY.EDU or LISTSERV%ICNUCEVM.BITNET@ICNUCEVM.CNUCE.CNR.IT containing only the following line: SUB OZONE If you need info about the computing conference send a mail message to the same address containing only the following line: HELP Please, inform your collegues about this conference. Thank you for your collaboration. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806281732.AA05558@terminus.UMD.EDU] <1988062817323800> From: dzoey@TERMINUS.UMD.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: historical defaults Message-ID: <8806281732.AA05558@terminus.UMD.EDU> Date: 28 Jun 88 17:32:38 GMT References: <8806281543.AA01535@trantor.UMD.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 26 > From: Alex McKenzie > Subject: Re: historical defaults > Of course, instead of the IETF inventing a new set of Telnet options, the > community could consider the (shudder) ISO Virtual Terminal Protocol, which > was designed to do all this. I don't think the internet community would want to do this because the various profiles for VTP (a profile is similar to a set of telnet options describing how all terminal capabilities should be mapped) are still being defined at NBS. This doesn't mean that people shouldn't take an active interest in VTP, just that they probably won't want telnet to emulate it. What is interesting is that the telnet way of doing terminal negotiation (one attribute at a time) can be done with VTP, but only with the extended model, not the basic one (forgive me if my terms are fuzzy, my copy of the VTP spec is at home). It sometimes seems that the Internet and ISO picked different ends of the implementation spectrum and are now busy rushing toward each other. That's what I like about standards, there's so many to choose from :-) Joe Herman U of Md. dzoey@terminus.umd.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [10301@ncc.Nexus.CA] <1988062820112300> From: lyndon@ncc.Nexus.CA (Lyndon Nerenberg) Newsgroups: rec.ham-radio.packet,comp.unix.questions,comp.protocols.tcp-ip Subject: SLIP protocol specification Message-ID: <10301@ncc.Nexus.CA> Date: 28 Jun 88 20:11:23 GMT Organization: Nexus Computing Inc. Lines: 346 Lately there have been a number of requests for a description of the SLIP encapsulation scheme for sending IP packets over serial links. SRI has (finally :-) issued an RFC describing how this is currently implemented. It's only six pages long, so I've attached a copy. Apologies if you've already seen this. (cut the .signature at the end) --lyndon VE6BBM -----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<----- Network Working Group J. Romkey Request for Comments: 1055 June l988 A NONSTANDARD FOR TRANSMISSION OF IP DATAGRAMS OVER SERIAL LINES: SLIP INTRODUCTION The TCP/IP protocol family runs over a variety of network media: IEEE 802.3 (ethernet) and 802.5 (token ring) LAN's, X.25 lines, satellite links, and serial lines. There are standard encapsulations for IP packets defined for many of these networks, but there is no standard for serial lines. SLIP, Serial Line IP, is a currently a de facto standard, commonly used for point-to-point serial connections running TCP/IP. It is not an Internet standard. Distribution of this memo is unlimited. HISTORY SLIP has its origins in the 3COM UNET TCP/IP implementation from the early 1980's. It is merely a packet framing protocol: SLIP defines a sequence of characters that frame IP packets on a serial line, and nothing more. It provides no addressing, packet type identification, error detection/correction or compression mechanisms. Because the protocol does so little, though, it is usually very easy to implement. Around 1984, Rick Adams implemented SLIP for 4.2 Berkeley Unix and Sun Microsystems workstations and released it to the world. It quickly caught on as an easy reliable way to connect TCP/IP hosts and routers with serial lines. SLIP is commonly used on dedicated serial links and sometimes for dialup purposes, and is usually used with line speeds between 1200bps and 19.2Kbps. It is useful for allowing mixes of hosts and routers to communicate with one another (host-host, host-router and router- router are all common SLIP network configurations). AVAILABILITY SLIP is available for most Berkeley UNIX-based systems. It is included in the standard 4.3BSD release from Berkeley. SLIP is available for Ultrix, Sun UNIX and most other Berkeley-derived UNIX systems. Some terminal concentrators and IBM PC implementations also support it. SLIP for Berkeley UNIX is available via anonymous FTP from uunet.uu.net in pub/sl.shar.Z. Be sure to transfer the file in binary mode and then run it through the UNIX uncompress program. Take Romkey [Page 1] RFC 1055 Serial Line IP June 1988 the resulting file and use it as a shell script for the UNIX /bin/sh (for instance, /bin/sh sl.shar). PROTOCOL The SLIP protocol defines two special characters: END and ESC. END is octal 300 (decimal 192) and ESC is octal 333 (decimal 219) not to be confused with the ASCII ESCape character; for the purposes of this discussion, ESC will indicate the SLIP ESC character. To send a packet, a SLIP host simply starts sending the data in the packet. If a data byte is the same code as END character, a two byte sequence of ESC and octal 334 (decimal 220) is sent instead. If it the same as an ESC character, an two byte sequence of ESC and octal 335 (decimal 221) is sent instead. When the last byte in the packet has been sent, an END character is then transmitted. Phil Karn suggests a simple change to the algorithm, which is to begin as well as end packets with an END character. This will flush any erroneous bytes which have been caused by line noise. In the normal case, the receiver will simply see two back-to-back END characters, which will generate a bad IP packet. If the SLIP implementation does not throw away the zero-length IP packet, the IP implementation certainly will. If there was line noise, the data received due to it will be discarded without affecting the following packet. Because there is no 'standard' SLIP specification, there is no real defined maximum packet size for SLIP. It is probably best to accept the maximum packet size used by the Berkeley UNIX SLIP drivers: 1006 bytes including the IP and transport protocol headers (not including the framing characters). Therefore any new SLIP implementations should be prepared to accept 1006 byte datagrams and should not send more than 1006 bytes in a datagram. DEFICIENCIES There are several features that many users would like SLIP to provide which it doesn't. In all fairness, SLIP is just a very simple protocol designed quite a long time ago when these problems were not really important issues. The following are commonly perceived shortcomings in the existing SLIP protocol: - addressing: both computers in a SLIP link need to know each other's IP addresses for routing purposes. Also, when using SLIP for hosts to dial-up a router, the addressing scheme may be quite dynamic and the router may need to inform the dialing host of Romkey [Page 2] RFC 1055 Serial Line IP June 1988 the host's IP address. SLIP currently provides no mechanism for hosts to communicate addressing information over a SLIP connection. - type identification: SLIP has no type field. Thus, only one protocol can be run over a SLIP connection, so in a configuration of two DEC computers running both TCP/IP and DECnet, there is no hope of having TCP/IP and DECnet share one serial line between them while using SLIP. While SLIP is "Serial Line IP", if a serial line connects two multi-protocol computers, those computers should be able to use more than one protocol over the line. - error detection/correction: noisy phone lines will corrupt packets in transit. Because the line speed is probably quite low (likely 2400 baud), retransmitting a packet is very expensive. Error detection is not absolutely necessary at the SLIP level because any IP application should detect damaged packets (IP header and UDP and TCP checksums should suffice), although some common applications like NFS usually ignore the checksum and depend on the network media to detect damaged packets. Because it takes so long to retransmit a packet which was corrupted by line noise, it would be efficient if SLIP could provide some sort of simple error correction mechanism of its own. - compression: because dial-in lines are so slow (usually 2400bps), packet compression would cause large improvements in packet throughput. Usually, streams of packets in a single TCP connection have few changed fields in the IP and TCP headers, so a simple compression algorithms might just send the changed parts of the headers instead of the complete headers. Some work is being done by various groups to design and implement a successor to SLIP which will address some or all of these problems. Romkey [Page 3] RFC 1055 Serial Line IP June 1988 SLIP DRIVERS The following C language functions send and receive SLIP packets. They depend on two functions, send_char() and recv_char(), which send and receive a single character over the serial line. /* SLIP special character codes */ #define END 0300 /* indicates end of packet */ #define ESC 0333 /* indicates byte stuffing */ #define ESC_END 0334 /* ESC ESC_END means END data byte */ #define ESC_ESC 0335 /* ESC ESC_ESC means ESC data byte */ /* SEND_PACKET: sends a packet of length "len", starting at * location "p". */ void send_packet(p, len) char *p; int len; { /* send an initial END character to flush out any data that may * have accumulated in the receiver due to line noise */ send_char(END); /* for each byte in the packet, send the appropriate character * sequence */ while(len--) { switch(*p) { /* if it's the same code as an END character, we send a * special two character code so as not to make the * receiver think we sent an END */ case END: send_char(ESC); send_char(ESC_END); break; /* if it's the same code as an ESC character, * we send a special two character code so as not * to make the receiver think we sent an ESC */ case ESC: send_char(ESC); send_char(ESC_ESC); break; Romkey [Page 4] RFC 1055 Serial Line IP June 1988 /* otherwise, we just send the character */ default: send_char(*p); } p++; } /* tell the receiver that we're done sending the packet */ send_char(END); } /* RECV_PACKET: receives a packet into the buffer located at "p". * If more than len bytes are received, the packet will * be truncated. * Returns the number of bytes stored in the buffer. */ int recv_packet(p, len) char *p; int len; { char c; int received = 0; /* sit in a loop reading bytes until we put together * a whole packet. * Make sure not to copy them into the packet if we * run out of room. */ while(1) { /* get a character to process */ c = recv_char(); /* handle bytestuffing if necessary */ switch(c) { /* if it's an END character then we're done with * the packet */ case END: /* a minor optimization: if there is no * data in the packet, ignore it. This is * meant to avoid bothering IP with all * the empty packets generated by the * duplicate END characters which are in Romkey [Page 5] RFC 1055 Serial Line IP June 1988 * turn sent to try to detect line noise. */ if(received) return received; else break; /* if it's the same code as an ESC character, wait * and get another character and then figure out * what to store in the packet based on that. */ case ESC: c = recv_char(); /* if "c" is not one of these two, then we * have a protocol violation. The best bet * seems to be to leave the byte alone and * just stuff it into the packet */ switch(c) { case ESC_END: c = END; break; case ESC_ESC: c = ESC; break; } /* here we fall into the default handler and let * it store the character for us */ default: if(received < len) p[received++] = c; } } } Romkey [Page 6] -- {alberta,pyramid,uunet}!ncc!lyndon lyndon@Nexus.CA ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12195@mimsy.UUCP] <1988062823291400> From: chris@mimsy.UUCP (Chris Torek) Newsgroups: comp.lang.c,comp.unix.questions,comp.unix.wizards,comp.protocols.tcp-ip Subject: For non-USENET readers only Message-ID: <12195@mimsy.UUCP> Date: 28 Jun 88 23:29:14 GMT Reply-To: chris@mimsy.umd.edu (Chris Torek) Organization: University of Maryland, Dept. of Computer Sci. Lines: 34 (Apologies to USENET readers, but if I mailed this to the corresponding ARPA/CS/BIT/...net mailing lists you would see it four times rather than once. You can skip the rest of this.) For those wishing to subscribe to any of the four mailing lists on which this message is appearing, or for those who are already on such a mailing list and want to get off it, please do NOT send your requests to the mailing list itself. This sends the message on out to every reader of the list and across some gateway software to USENET; it thus reaches literally thousands of machines and merely serves to annoy everyone except those who have control of the mailing list itself. More importantly, in many cases the mailing list editor (person) does not read the list itself, and messages to the list are thus worse than useless. Please send requests to the -request form of the list. For instance, to get on or off the Unix-Wizards list, rather than sending a message to Unix-Wizards@brl.arpa, send it to Unix-Wizards-Request@brl.arpa. Remember that mail gets delayed and that people take vacations, and that mailing list maintenance is often a low priority project; it can easily take two or three weeks to get action on some request. Moreover, many lists have local redistribution points, to ease the load on mailers (using a mail system as a bulletin board has some drawbacks!). You should check for a local redistribution list first before sending mail to the -request address. Likewise, if you were added to a local redistribution list, asking the -request address to remove your name from the list is unlikely to be effective. BITNET mail is often handled through automatic mail servers located at specific BITNET redistribution points. Information as to which lists are located where, and how to use them, should be available from your BITNET administrator (I myself have no idea which, where, and how). -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris ----MESSAGE-END---- ----MESSAGE-BEGIN---- [113:nittmann@rusvx1.rus.uni-stuttgart.dbp.de] <1988062902012000> From: nittmann@rusvx1.rus.uni-stuttgart.dbp.de ("Michael F.H. Nittmann ") Newsgroups: comp.protocols.tcp-ip Subject: historical defaults Message-ID: <113:nittmann@rusvx1.rus.uni-stuttgart.dbp.de> Date: 29 Jun 88 02:01:20 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 81 This is a lengthy mail on echo no echo remote local etc. and telnet. Perhaps You even do not need to read it. Just to tell, I am fully aware of char. use of vi. But what vi needs is not the remote echo but the single character TRANSMISSION. And this is just the point I wanted to go to: why not use vi together with nfs, avoid those small char. sequences ( these are not the 1 char. echoes of course), and get a more secure vi session since the buffer just being edited will survive network/host crashes due to the statelesness of nfs. The same holds for all fullscreen editors and unix likes. Naturally there will be some VMS or so who will really need character mode. Let's ask: who is the most important section. Dynamic switching of modes is also already possible: I type escape ,mode line, return, return to the session and I am in line mode. I can change it back to character mode when I really need it (for a direct vi session). To do it better on a defined special character basis is a very good extension, let's hope that the extension rfc will come in soon. The point I see is that agreed defaults are never renegotiated and sessions that do not need these quasi default modes will run with them and waste resources. Doesn't this become even more true when there is an extended option on negotiated special characters? I would say that then even less sessions need to start in dont SGA. And since special characters are negotiated there is no need for single character mode of the sending NVT. With "agreed defaults" of course I do not only mean rfc854 defaults since there is already line mode stated as default for a telnet client's NVT. To order my imprecise formulation: only those who really have a physical half duplex terminal should need a GA, not the Unix-likes nor VMS. I agree that confusion would be too big in changing that particular - and rfc854 standardized - default since the GA is purely optional. But: A standard developed - or let's call it an implementor's easyway, or a sneeked in maniere - that telnet clients start in character mode, ask for remote echo and ping pong single characters between vaxes or suns, where by the way in line mode the line editing could be easily done locally and where NVT function codes pass. (the user has of course to enter some stty statements in his .cshrc ,.login or dec/new into login.com to get the editings done at the appropriate place and ctl c's understood on the other side) Of course some telnet implementations are really clumsy in passing NVT function codes and do ask the poor user to enter the escape to return to the client's command level and enter some sort of 'send IP' or so. People who have to use some of these should be able to go into the single character transmission mode WITHOUT at the same time ask for a remote echo. So perhaps I formulate it as a request to the developers: cannot we leave alone the agreed or sneeked in standard of starting in char. mode with remote echo and return to rfc defined real standard at the start of a session. And when a user really needs a character per character transmission ( it is that what is needed for vi, not the remote echo ) do just that but do not always request at the same time a server's echo. Vi is a very good example here since vi does not just an echo but a reply to the single character entry : on some escape ...A it sends cursor control to put the cursor up, dependent on the terminal type e.g. defined in .cshrc or login.com (for edt/tpu). And if I type a colon I do not get a colon echoed in command mode but my cursor is placed into the down left corner of the vi window and then my colon and command are replicated ( to use this to distinguish it from mere echo ). What is echoed at most is a rubout sequence for the already echoed colon. So the vi case is even worse than everything You thought of: you let remotely echo Your entered character and then vi comes and does a rubout on it since we do not need that colon in the middle of the screen! Couldn't such a rubout candidate be bought cheaper by local echo? If You properly set up Your terminal definitions on both sides, vi will work without the echo and know when to reply a character with itself echoed. I know I have a difficulty with writing clearly and simple so breath freely, this is my last on that. Michael F.H. Nittmann ----MESSAGE-END---- ----MESSAGE-BEGIN---- [780@uhnix1.uh.edu] <1988062902072700> From: mkkam@wael.cs.uh.edu (Francis Kam) Newsgroups: comp.sys.mac,comp.protocols.tcp-ip Subject: SLIP, telnet and ftp on Mac Message-ID: <780@uhnix1.uh.edu> Date: 29 Jun 88 02:07:27 GMT Sender: nntppost@uhnix1.uh.edu Reply-To: mkkam@wael.cs.uh.edu (Francis Kam) Organization: University of Houston Lines: 14 I am trying to connect some of our Mac II's and SE's to a Sun network. I am considering using SLIP then I don't have to buy ethercard for the Mac's. Does anyone know any public domain SLIP, telnet and ftp source for Mac? Or any supply source that sell them? Please give me some hints. ------------- Francis Kam Computer Science Department Internet: mkkam@wael.cs.uh.edu University of Houston CSNET: mkkam@houston.csnet 4800 Calhoun Phone: (713)749-1748 Houston, TX 77004. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988062903403600> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Tue, 28 Jun 88 23:48:52 PDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA09114; Tue, 28 Jun 88 23:10: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: 29 Jun 88 03:40:36 GMT From: rlgvax!dennis@uunet.uu.net (Dennis.Bednar) Organization: Computer Consoles Inc, Reston VA Subject: Some sub-net questions Message-Id: <948@rlgvax.UUCP> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa Can someone please tell me which version of BSD first supported sub-netting? Does the Berkeley implementation follow the related RFC's (917, 940, 950) closely, or does it deviate in any manner? Any other documentation besides the RFC's? Thanks in advance. -- FullName: Dennis Bednar UUCP: {uunet|sundc}!rlgvax!dennis USMail: CCI; 11490 Commerce Park Dr.; Reston VA 22091 Telephone: +1 703 648 3300 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988062904540700> Received: from LABS-N.BBN.COM by SRI-NIC.ARPA with TCP; Wed, 29 Jun 88 05:57:20 PDT Date: Wed, 29 Jun 88 8:54:07 EDT From: Alex McKenzie To: tcp-ip@SRI-NIC.ARPA Subject: ISO VTP Based on comments received, I must not have expressed myself clearly. I meant to suggest that the community consider adopting the ISO VTP (or a subset) to *replace* Telnet, not to simulate ISO VTP with a bunch of Telnet options. Since the ISO VTP is intended to provide the mechanisms to dynamically define which user input characters trigger transmission and suspend "local" echoing, it seems to me we should look at that solution first (i.e., before the IETF goes off to invent a new set of Telnet options to do a similar thing). Alex ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988062908085000> Received: from xenurus.Gould.COM by SRI-NIC.ARPA with TCP; Wed, 29 Jun 88 11:12:01 PDT Received: from vger (vger.Urbana.Gould.COM) by xenurus.Gould.COM (5.52/) Date: Wed, 29 Jun 88 13:08:50 CDT From: tucker%vger@xenurus.Gould.COM (Tim Tucker) Received: by vger (5.54/) Message-Id: <8806291808.AA05734@vger> To: TCP-IP@sri-nic.arpa Subject: NAMED and IP forwarding >/* ---------- "NAMED and IP forwarding" ---------- */ >From tcp-ip-RELAY@SRI-NIC.ARPA Wed Jun 29 12:35:41 1988 >Date: Wed, 29 Jun 88 07:43:04 MDT >From: Capt Geoff Mulligan >Subject: NAMED and IP forwarding > >2. Does anyone know if the 2.0 libraries are compiled to use the name >server so that they will use resolver routines and the >/etc/resolv.conf file? No, Gould UTX2.0 doesn't include any name server support. > >3. How can I get my gould to act as an IP router? I would like it to >act as our gateway from a ethernet and a couple of slip hosts to the >Milnet. > > geoff Gould's latest version of the UTX operating system for your machine supports all of those things. It includes a recent version of BIND, and support for EGP thru the Cornell Gated program. Tim Tucker Gould Computer Systems Division tucker@xenurus.Gould.COM (Milnet) ..ihnp4!uiucdcs!urbsdc!tucker (UUCP) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8807012307.AA07445@ucbvax.Berkeley.EDU] <1988062912540700> From: mckenzie@LABS-N.BBN.COM (Alex McKenzie) Newsgroups: comp.protocols.tcp-ip Subject: ISO VTP Message-ID: <8807012307.AA07445@ucbvax.Berkeley.EDU> Date: 29 Jun 88 12:54:07 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 10 Based on comments received, I must not have expressed myself clearly. I meant to suggest that the community consider adopting the ISO VTP (or a subset) to *replace* Telnet, not to simulate ISO VTP with a bunch of Telnet options. Since the ISO VTP is intended to provide the mechanisms to dynamically define which user input characters trigger transmission and suspend "local" echoing, it seems to me we should look at that solution first (i.e., before the IETF goes off to invent a new set of Telnet options to do a similar thing). Alex ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806291343.AA03844@usafa.ARPA] <1988062913430400> From: geoff@USAFA.ARPA (Capt Geoff Mulligan) Newsgroups: comp.protocols.tcp-ip Subject: NAMED and IP forwarding Message-ID: <8806291343.AA03844@usafa.ARPA> Date: 29 Jun 88 13:43:04 GMT References: <8806282104.AA08938@wasatch.utah.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 11 1. Why does gould not provide the bind name server? 2. Does anyone know if the 2.0 libraries are compiled to use the name server so that they will use resolver routines and the /etc/resolv.conf file? 3. How can I get my gould to act as an IP router? I would like it to act as our gateway from a ethernet and a couple of slip hosts to the Milnet. geoff ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806291453.AA14672@burdvax.PRC.Unisys.COM] <1988062914531900> From: perry@PRC.UNISYS.COM (Dennis Perry) Newsgroups: comp.protocols.tcp-ip Subject: Re: ISO VTP Message-ID: <8806291453.AA14672@burdvax.PRC.Unisys.COM> Date: 29 Jun 88 14:53:19 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 5 I think Alex's words are words we should strongly consider, just as with network managment moving towards ISO, we should move Telnet towards VTP. dennis ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806291504.AA11495@gaak.LCS.MIT.EDU] <1988062915043800> From: map@GAAK.LCS.MIT.EDU (Michael A. Patton) Newsgroups: comp.protocols.tcp-ip Subject: Domain name/subnet non-relationship. Message-ID: <8806291504.AA11495@gaak.LCS.MIT.EDU> Date: 29 Jun 88 15:04:38 GMT References: <8806280650.AA09320@gaak.LCS.MIT.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 17 How names are subdivided (with domain naming) and how networks are sudivided (with subnetting) have no intrinsic relationship. You are free to apply a relationship if that is beneficial but no relationship is required (or even implied) by the standards. In fact one of the subnets here has hosts with names in three (at least) different domains and each of those domains exist on at least half a dozen subnets. The purpose of the hierarchical domain naming system is to distribute the responsibility for assigning non-conflicting names, the purpose of subnetting is to ease the design of routing protocols internal to a single network. Mike Patton, Network Manager Laboratory for Computer Science Massachusetts Institute of Technology Disclaimer: The opinions expressed above are a figment of the phosphor on your screen and do not represent the views of MIT, LCS, or MAP. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [297@scolex] <1988062919033400> From: timon@sco.COM (timon) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.iso Subject: TLI transport specific addresses Keywords: TLI transport independence Message-ID: <297@scolex> Date: 29 Jun 88 19:03:34 GMT Organization: The Santa Cruz Operation, Inc. Lines: 29 a puzzle for the net: AT+T chose not to define an addressing scheme for their TLI library. Instead they require the user program to pass to the transport a pointer to an undefined address structure. This requires that the user program know what address structure the transport is expecting, and therefore makes each user program transport specific. This seems to make their interface completely unportable. They claim to have designed TLI to allow application programs to be completely independent of the transport. I don't see how this can work if each and every user program must have hard-coded dependencies based on a particular transport's addressing scheme. - Why did they fall short here (aside from being lazy)? - Is at+t working on a standard for this? Is any other group/vender? - Are standards/conventions emerging for particular transports (tcp/ip, osi tp4, netbios)? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Timon Sloane The Santa Cruz Operation timon@sco.com {uunet | decvax!microsof}!sco!timon (408) 458-1422 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806292004.AA02924@bel.isi.edu] <1988062920042300> From: postel@VENERA.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Telnet Message-ID: <8806292004.AA02924@bel.isi.edu> Date: 29 Jun 88 20:04:23 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 9 Hi. The Telnet defaults will not be changed. Not ever. Additional Telnet Options are very likely. --jon. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806292148.AA25642@venera.isi.edu] <1988062921481700> From: pvm@VENERA.ISI.EDU (Paul Mockapetris) Newsgroups: comp.protocols.tcp-ip Subject: Re: Domain name/subnet non-relationship. Message-ID: <8806292148.AA25642@venera.isi.edu> Date: 29 Jun 88 21:48:17 GMT References: <8806291504.AA11495@gaak.LCS.MIT.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 14 As many have pointed out there is no necessary correspondance between the name of a host, mailbox, etc. and the subnet that the host's IP address occupies. However, in the IN-ADDR.ARPA domain, which is used to map from IP addresses to host names, the name structure is constrained (by convention, not technically), with each level of the name corresponding to an octet of the IP address. Since the names break at octet boundaries, domains/zones can only break at octet boundaries, and thus if you want to separately administer address assignment, its much simpler if your subnet masks and octet boundaries correspond. For class C, this means you are out of luck. paul ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806292258.AA16727@cod.nosc.mil] <1988062922581600> From: neerma@COD.NOSC.MIL (Merle A. Neer) Newsgroups: comp.protocols.tcp-ip Subject: Forwarded: questions on UDP broadcast Message-ID: <8806292258.AA16727@cod.nosc.mil> Date: 29 Jun 88 22:58:16 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 28 ------- Forwarded mail follows: From neerma Wed Jun 29 13:44:49 1988 Date: Wed, 29 Jun 88 13:44:21 PDT From: neerma (Merle A. Neer) Message-Id: <8806292044.AA05975@cod.nosc.mil> To: tcp-ip-relay@sri.nic.arpa Cc: neerma Subject: questions on UDP broadcast Hi, We're trying to develop server/clients on UDP to do broadcast. We are interested in hearing from anyone with experience on UNIX or IBM AT using Network Research FUSION package. We would appreciate any help offered. Thanks, Merle Neer neerma at nosc.mil ------- ------- ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1200@thumper.bellcore.com] <1988063001465000> From: karn@thumper.bellcore.com (Phil R. Karn) Newsgroups: comp.protocols.tcp-ip Subject: Re: Looking for comments on the 15-pin ethernet connector Message-ID: <1200@thumper.bellcore.com> Date: 30 Jun 88 01:46:50 GMT References: <3352@phri.UUCP> <8806150602.AA11768@atom.hpl.hp.com> <489@cvaxa.sussex.ac.uk> Organization: Bell Communications Research, Inc Lines: 15 > I'm so glad that others apart from myself are complaining about these > stupid practices. Maybe we'll actually see some action from the vendors > on this one? Don't hold your breath. Flushed with success in designing Ethernet transceiver clips, they're now all busily bringing you OSI. One feature I wish they had included in the Ethernet transceiver connector is a remotely-triggerable disconnect, similar to the explosively-driven bolt and cable cutters used on space launchers. (One was featured in 2010 as HAL's "emergency pull".) I'd wire them all to a big panel in my office. Then the next time somebody's broken host software sends out a bogus broadcast packet, I'd turn the switch, and... Phil ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1988063008310600> Received: from GUNTER-ADAM.ARPA by SRI-NIC.ARPA with TCP; Thu, 30 Jun 88 11:32:03 PDT Date: 30 Jun 1988 13:31:06 CDT Subject: Hewlett-Packard Interfaces From: AFDDN.1973CG@GUNTER-ADAM.ARPA To: tcp-ip@SRI-NIC.ARPA cc: AFDDN.1973CG@GUNTER-ADAM.ARPA To Anyone Who Knows, I'm looking for information on TCP/IP interfaces available for an HP-3000 with MPE-IV. I'd specifically like to know where I can get them if available and what is required to support them interms of memory, disk, etc. Please respond to my mailbox directly since I'm not on the TCP-IP mail list. Thanks in advance, John Wandelt ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806301435.AA01487@sneezy] <1988063014351900> From: cpw%sneezy@LANL.GOV (C. Philip Wood) Newsgroups: comp.protocols.tcp-ip Subject: Re: gateways and more-than-one-IP-net on one ethernet Message-ID: <8806301435.AA01487@sneezy> Date: 30 Jun 88 14:35:19 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 5 Get rid of the Level 2 Bridge(s). Put IP routers in their place. Don't have two networks on the same LAN. I define LAN as a network of hosts all sharing the same network address. phil wood (cpw@lanl.gov) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806301447.AA08745@usafa.ARPA] <1988063014474400> From: geoff@USAFA.ARPA (Capt Geoff Mulligan) Newsgroups: comp.protocols.tcp-ip Subject: NAMED and IP forwarding Message-ID: <8806301447.AA08745@usafa.ARPA> Date: 30 Jun 88 14:47:44 GMT References: <8806291808.AA05734@vger> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 3 What version of UTX is it that supports NAMED and IP forwarding? geoff ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8807020049.AA09877@ucbvax.Berkeley.EDU] <1988063018310600> From: AFDDN.1973CG@GUNTER-ADAM.ARPA Newsgroups: comp.protocols.tcp-ip Subject: Hewlett-Packard Interfaces Message-ID: <8807020049.AA09877@ucbvax.Berkeley.EDU> Date: 30 Jun 88 18:31:06 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 11 To Anyone Who Knows, I'm looking for information on TCP/IP interfaces available for an HP-3000 with MPE-IV. I'd specifically like to know where I can get them if available and what is required to support them interms of memory, disk, etc. Please respond to my mailbox directly since I'm not on the TCP-IP mail list. Thanks in advance, John Wandelt ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8806302103.AA03654@uc.msc.umn.edu] <1988063021035100> From: slevy@UC.MSC.UMN.EDU ("Stuart Levy") Newsgroups: comp.protocols.tcp-ip Subject: Re: gateways and more-than-one-IP-net on one ethernet Message-ID: <8806302103.AA03654@uc.msc.umn.edu> Date: 30 Jun 88 21:03:51 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 8 You should be able to handle reaching a gateway, on the same wire as you but on a different (sub)network number, using the following awful kludge: Allocate a fake IP address on your own (sub)net for the remote gateway. On the local machine: arp -s fake-gw-address gateway-Ether-address perm On the local machine: route add destination-net fake-gw-address 1 and hope the "permanent" arp is never purged from the cache. ----MESSAGE-END----