|
|
ARCHIVE: TCP-IP Distribution List - Archives (1987)
DOCUMENT: TCP-IP Distribution List for June 1987 (202 messages, 122330 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1987/06.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.
START OF DOCUMENT
-----------[000000][next][prev][last][first]---------------------------------------------------- Date: Mon, 01 Jun 87 11:26:03 -0400 From: Robert Hinden <hinden@CCV.BBN.COM> To: Nick Gimbrone <NJG%CORNELLA.BITNET@WISCVM.WISC.EDU> Cc: tcp-ip@SRI-NIC.ARPA, hinden@CCV.BBN.COM Subject: Re: IP Datagram sizes
Nick,
In fact most of the networks that make up the Internet have MTU's smaller
than 1500 bytes. Here is a summary:
Wideband 2048
Pronet Ring 2040
Ethernet 1500
Arpanet 1007
NSFNET 576
PDN 512
Suran 320
Satnet 256
Packet Radio 226
Hope this helps.
Bob
-----------[000001][next][prev][last][first]---------------------------------------------------- Date: Mon, 1-Jun-87 10:47:22 EDT From: jon@CS.UCL.AC.UK (Jon Crowcroft) To: comp.protocols.tcp-ip Subject: IP datagram sizes
Of course, if you use X.25 you don't have this problem :-). The switches can use level 2 to support fragment sizes properly over each hop, and level 3 to get end to end packet sizes efficient, and a well known transport protocol over that... Then all you need is to work out how to get CCITT to accept giant window size and packet size options to make it work well over a big network. The strain of hop by hop versus end to end arguments starts to show when you try and use an underengineered mil-spec net for heavy duty service. What Vint says sounds good to me - figure out how to get hop by hop information back to the end to end protocols so they can be taught how to behave properly. Real problem here is for short lived protocol entities - eg query systems running in PCs - who dont get a chance to used previously cached info... jon
-----------[000002][next][prev][last][first]---------------------------------------------------- Date: Mon, 1-Jun-87 11:00:11 EDT From: jon@CS.UCL.AC.UK (Jon Crowcroft) To: comp.protocols.tcp-ip Subject: Invalidating ARP Caches
I have only had one answer on how to invalidate arp caches in
hosts when i move my IP (proxy arp) subnet router, so here's my
thoughts...
--------------------------------------------------------------------
Could call this NARP (not arp):
I am considering writing a service that listens for IP broadcasts
(multicasts when available) and invalidates arp caches on basis
of these. When (before/after) a router moves, it will still
forward these packets so sitting on any host I can (hopefully
only with certain privilages) say:
arpinval {ip addr}*
which will broadcast some packet like
IP header with NARP type + <IP Addr Addr etc)
(has to be IP broadcast, not lower level or the IP subnet routers wont
forward it). When routers get clever, they could send this
packet for me.
Any reason not to do this, apart from the obvious possible
misuses and broadcast traffic (though only one broadcast to fix
a lot of hosts)?
jon
-----------[000003][next][prev][last][first]---------------------------------------------------- Date: Mon, 1-Jun-87 11:45:07 EDT From: hinden@CCV.BBN.COM (Robert Hinden) To: comp.protocols.tcp-ip Subject: Re: IP Datagram sizes
Nick,
In fact most of the networks that make up the Internet have MTU's smaller
than 1500 bytes. Here is a summary:
Wideband 2048
Pronet Ring 2040
Ethernet 1500
Arpanet 1007
NSFNET 576
PDN 512
Suran 320
Satnet 256
Packet Radio 226
Hope this helps.
Bob
-----------[000004][next][prev][last][first]---------------------------------------------------- Date: Mon, 1-Jun-87 14:22:11 EDT From: braden@ISI.EDU (Bob Braden) To: comp.protocols.tcp-ip Subject: Re: TN3270
I inquired of a Network Solutions salesperson after one of their presentations at the conference in Monterey this past March, and he said that their DDN/MVS did not support 3270-mode telnet. There must have been some misunderstanding about the question or the answer. DDN/MVS is based on the UCLA MVS code, which certainly does support 3270-mode Telnet, and always has. I have a tn3270 icon on my Sun screen, which I occasionally open to log into TSO on the UCLA 3090 and use PDF in full-screen. Now that the ARPANET is back from the dead, it works quite snappily, too. Bob Braden
-----------[000005][next][prev][last][first]---------------------------------------------------- Date: Mon, 1-Jun-87 15:25:50 EDT From: boesch@Shasta.STANFORD.EDU (Brian Boesch) To: comp.protocols.tcp-ip Subject: A question about link performance and TCP
I have a question about studies in performace of TCP over various networks and data links. Does anyone know of studies into the performance of TCP over various networks especially where different datalink protocols are involved. The current discussion of TCP segment size selection prompted my interest in this. I have read RFC889 "Internet Delay Experiments". Please reply to: boesch@umunhum.stanford.edu Thanks Brian
-----------[000006][next][prev][last][first]---------------------------------------------------- Date: Mon, 1 Jun 87 15:23:37 GMT-0:00 From: Jon Crowcroft <jon@Cs.Ucl.AC.UK> To: tcp-ip@sri-nic.arpa Subject: IP datagram sizes
Of course, if you use X.25 you don't have this problem :-). The switches can use level 2 to support fragment sizes properly over each hop, and level 3 to get end to end packet sizes efficient, and a well known transport protocol over that... Then all you need is to work out how to get CCITT to accept giant window size and packet size options to make it work well over a big network. The strain of hop by hop versus end to end arguments starts to show when you try and use an underengineered mil-spec net for heavy duty service. What Vint says sounds good to me - figure out how to get hop by hop information back to the end to end protocols so they can be taught how to behave properly. Real problem here is for short lived protocol entities - eg query systems running in PCs - who dont get a chance to used previously cached info... jon
-----------[000007][next][prev][last][first]---------------------------------------------------- Date: Mon, 1-Jun-87 19:41:16 EDT From: RAF@NIHCU.BITNET.UUCP To: comp.protocols.tcp-ip Subject: Domain Name Servers
Any recommendations as to what to use for an Internet domain name server if one doesn't have a VAX Unix machine to use? Our primary mainframe is an IBM 3090 running MVS/XA, but none of the IBM MVS implementations has a domain name server. I believe that the new IBM TCP/IP for VM product has one, but we don't run VM. A domain name server that could run on a PC, either under DOS or some flavor of Unix would be real handy for us. I am sending this to 3 lists, sorry for duplicates that you may receive. Roger Fajman BITNET: RAF@NIHCU Internet: RAF%NIHCU.BITNET@WISCVM.WISC.EDU
-----------[000008][next][prev][last][first]---------------------------------------------------- Date: Mon, 01 Jun 87 19:41:16 EDT From: "Roger Fajman" <RAF%NIHCU.BITNET@wiscvm.wisc.edu> To: TCP-IP@SRI-NIC.ARPA, nsfnet@nnsc.nsf.net, IBM-NETS@BITNIC Subject: Domain Name Servers
Any recommendations as to what to use for an Internet domain name server if one doesn't have a VAX Unix machine to use? Our primary mainframe is an IBM 3090 running MVS/XA, but none of the IBM MVS implementations has a domain name server. I believe that the new IBM TCP/IP for VM product has one, but we don't run VM. A domain name server that could run on a PC, either under DOS or some flavor of Unix would be real handy for us. I am sending this to 3 lists, sorry for duplicates that you may receive. Roger Fajman BITNET: RAF@NIHCU Internet: RAF%NIHCU.BITNET@WISCVM.WISC.EDU
-----------[000009][next][prev][last][first]---------------------------------------------------- Date: Mon, 1 Jun 87 15:51:14 GMT-0:00 From: Jon Crowcroft <jon@Cs.Ucl.AC.UK> To: tcp-ip@sri-nic.arpa Subject: Invalidating ARP Caches
I have only had one answer on how to invalidate arp caches in
hosts when i move my IP (proxy arp) subnet router, so here's my
thoughts...
--------------------------------------------------------------------
Could call this NARP (not arp):
I am considering writing a service that listens for IP broadcasts
(multicasts when available) and invalidates arp caches on basis
of these. When (before/after) a router moves, it will still
forward these packets so sitting on any host I can (hopefully
only with certain privilages) say:
arpinval {ip addr}*
which will broadcast some packet like
IP header with NARP type + <IP Addr Addr etc)
(has to be IP broadcast, not lower level or the IP subnet routers wont
forward it). When routers get clever, they could send this
packet for me.
Any reason not to do this, apart from the obvious possible
misuses and broadcast traffic (though only one broadcast to fix
a lot of hosts)?
jon
-----------[000010][next][prev][last][first]----------------------------------------------------
Date: Mon, 1-Jun-87 23:11:40 EDT
From: JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
To: comp.protocols.tcp-ip
Subject: Re: TN3270
I inquired of a Network Solutions salesperson ... and
he said that their DDN/MVS did not support 3270-mode telnet.
There must have been some misunderstanding about the question or the
answer. DDN/MVS is based on the UCLA MVS code, which certainly does
support 3270-mode Telnet, and always has....
Bob Braden
This is what I get for answering my mail while far from my references.
I know that one of the mainframe packages doesn't have TN3270. Is it
C.I.S.C.O. (not the Bay area gateway people) that doesn't?
jbvb
BTW: I'm still not on the list. Has there been any further discussion of
the RFC issue? Also, am I simply not aware of an official MIT redistribution
point? If so, could someone inform me whom to contact?
-----------[000011][next][prev][last][first]---------------------------------------------------- Date: Tue, 2-Jun-87 00:56:13 EDT From: Mills@UDEL.EDU.UUCP To: comp.protocols.tcp-ip Subject: Re: IP datagram sizes
Jon, THe X.25 model requires X.75 gateways to handle M-bit repacketizing between two networks with different packet sizes. This requires route-binding between the gateways, which runs completely contrary to the basic Internet architecure. If we are to accept your suggestion we would have to drop this fundamental cornerstone in the model. Is the increment in performance possibly achieved by route-binding justify the loss in robustness and flexibility inherent in the present model? I'm not looking for a debate, just refining the perspective. Dave
-----------[000012][next][prev][last][first]---------------------------------------------------- Date: Tue, 02 Jun 87 10:22:03 EDT From: Ross Patterson <A024012%RUTVM1.BITNET@wiscvm.wisc.edu> To: Bob Braden <BRADEN@ISI.EDU>, JBVB@AI.AI.MIT.EDU, TCP-IP@SRI-NIC.ARPA Subject: Re: TN3270
>
>
> I inquired of a Network Solutions salesperson after one of their
> presentations at the conference in Monterey this past March, and
> he said that their DDN/MVS did not support 3270-mode telnet.
>
>There must have been some misunderstanding about the question or the
>answer. DDN/MVS is based on the UCLA MVS code, which certainly does
>support 3270-mode Telnet, and always has. I have a tn3270 icon on my
>Sun screen, which I occasionally open to log into TSO on the UCLA 3090
>and use PDF in full-screen. Now that the ARPANET is back from the dead,
>it works quite snappily, too.
>
>Bob Braden
>
Not to question an authority in the field (and an author of the
code), but couldn't NSI have simply recompiled the modules affected by
the TN3270 support, and thus turned it off? UCLA ships this support
in object code, not in source, and it is very nicely compartmentalized
to allow one to turn it off. In fact, the installation manual warns
that recompiling these modules will have exactly that effect. I can
see where vendors might not want to offer code that they cannot
support, and might therefore excise it.
Ross Patterson
Rutgers University
-----------[000013][next][prev][last][first]---------------------------------------------------- Date: Tue, 2-Jun-87 10:54:11 EDT From: ron@TOPAZ.RUTGERS.EDU (Ron Natalie) To: comp.protocols.tcp-ip Subject: Re: TN3270
The Maryland CISCO, is a hardware implementation. It is a box that plugs into your MVS machine's channel and plugs into ethernet/DDN on the other side. While I've received glossy literature on these things in the past, I've never heard of someone that had one. Does anybody have one of these things? -Ron
-----------[000014][next][prev][last][first]---------------------------------------------------- Date: Tue, 2-Jun-87 11:37:54 EDT From: LYNCH@A.ISI.EDU.UUCP To: comp.protocols.tcp-ip Subject: Re: TN3270
Oh yeah, Bob, you brought up a point that I have ignored lately: the Arpanet is back from the dead lately. Why? Was something wonderful discovered or done? Or did some evil packet sprayer die in silence? Dan -------
-----------[000015][next][prev][last][first]---------------------------------------------------- Date: 2 Jun 1987 11:37:54 EDT From: Dan Lynch <LYNCH@A.ISI.EDU> To: Bob Braden <braden@VENERA.ISI.EDU> Cc: JBVB@AI.AI.MIT.EDU, tcp-ip@SRI-NIC.ARPA, LYNCH@A.ISI.EDU Subject: Re: TN3270
Oh yeah, Bob, you brought up a point that I have ignored lately: the Arpanet is back from the dead lately. Why? Was something wonderful discovered or done? Or did some evil packet sprayer die in silence? Dan -------
-----------[000016][next][prev][last][first]---------------------------------------------------- Date: Tue, 02 Jun 87 16:36:00 -0500 From: Frederick E Serr BBNCC 19/415 x2474 <fserr@ALEXANDER.BBN.COM> To: Dan Lynch <LYNCH@A.ISI.EDU> Cc: Bob Braden <braden@VENERA.ISI.EDU>, tcp-ip@SRI-NIC.ARPA Subject: Re: TN3270
The ARPANET had severe performance problems last October, and again during late January and February. In both cases we think the major culprit was oversubscribed network trunks. The network routing algorithm started thrashing about, looking for less congested routes. This sometimes led to less efficient use of the existing bandwidth, compounding the performance problems. Last fall the problems were triggered by trunk rehomings that were done in the wrong order. The most important "fix" was simply getting all the rehomings done, restoring the bandwidth that had been there before. The congestion in February was alleviated by adjustments to the parameters used in the network routing calculations. We lessened the ability of the network to route around congestion, but made it more stable in the face of limited bandwidth on important routes. Upgrading several key nodes to a more powerful hardware version may have had a small role in keeping performance at acceptable levels. Though things seem OK now, the network is still sensitive to increased traffic on key paths. (Transcontinental bandwidth seems to be the critical resource here.) Sometime very soon (perhaps this week), a new link will be added to the ARPANET between New England and northern California. This new cross-country trunk should improve performance still further, and start to provide some room for expansion beyond current traffic levels. Fred Serr Network Analysis Department BBN Communications
-----------[000017][next][prev][last][first]---------------------------------------------------- Date: Tue, 2-Jun-87 13:28:19 EDT From: jon@CS.UCL.AC.UK.UUCP To: comp.protocols.tcp-ip Subject: Re: IP datagram sizes
Dave, I agree X.75 cgoes contrary to internet philosophy. My suggestion is that something between the current route binding in X.25/X.75, and the fully dynamic routing of IP is required plus some. I think You need some kind of weak resource reservation scheme, combined with some means for end to end protocols to find out what the resources out there are, since pure feedback from the end to end protocol will give you information too late to adjust mtu's, rtx times etc, and will always give you unstable algorithms. Jon
-----------[000018][next][prev][last][first]---------------------------------------------------- Date: Tue, 2-Jun-87 13:41:34 EDT From: braden@ISI.EDU.UUCP To: comp.protocols.tcp-ip Subject: Re: TN3270
Nothing wonderful. Just good old BBN grunt work ("tuning") plus some
criminally-delayed line upgrades.
Bob
-----------[000019][next][prev][last][first]---------------------------------------------------- Date: Tue, 02 Jun 87 09:54:45 +0100 From: Jon Crowcroft <jon@Cs.Ucl.AC.UK> To: Mills@louie.udel.edu Cc: Jon Crowcroft <jon@Cs.Ucl.AC.UK>, tcp-ip@sri-nic.arpa, jon@Cs.Ucl.AC.UK Subject: Re: IP datagram sizes
Dave, I agree X.75 cgoes contrary to internet philosophy. My suggestion is that something between the current route binding in X.25/X.75, and the fully dynamic routing of IP is required plus some. I think You need some kind of weak resource reservation scheme, combined with some means for end to end protocols to find out what the resources out there are, since pure feedback from the end to end protocol will give you information too late to adjust mtu's, rtx times etc, and will always give you unstable algorithms. Jon
-----------[000020][next][prev][last][first]---------------------------------------------------- Date: Tue, 2-Jun-87 22:09:33 EDT From: fserr@ALEXANDER.BBN.COM.UUCP To: comp.protocols.tcp-ip Subject: Re: TN3270
The ARPANET had severe performance problems last October, and again during late January and February. In both cases we think the major culprit was oversubscribed network trunks. The network routing algorithm started thrashing about, looking for less congested routes. This sometimes led to less efficient use of the existing bandwidth, compounding the performance problems. Last fall the problems were triggered by trunk rehomings that were done in the wrong order. The most important "fix" was simply getting all the rehomings done, restoring the bandwidth that had been there before. The congestion in February was alleviated by adjustments to the parameters used in the network routing calculations. We lessened the ability of the network to route around congestion, but made it more stable in the face of limited bandwidth on important routes. Upgrading several key nodes to a more powerful hardware version may have had a small role in keeping performance at acceptable levels. Though things seem OK now, the network is still sensitive to increased traffic on key paths. (Transcontinental bandwidth seems to be the critical resource here.) Sometime very soon (perhaps this week), a new link will be added to the ARPANET between New England and northern California. This new cross-country trunk should improve performance still further, and start to provide some room for expansion beyond current traffic levels. Fred Serr Network Analysis Department BBN Communications
-----------[000021][next][prev][last][first]---------------------------------------------------- Date: Wed, 3-Jun-87 09:43:26 EDT From: YAKOV@IBM.COM.UUCP To: comp.protocols.tcp-ip Subject: tn3270
We (group of people at T.J. Watson Research Center, IBM Corp.) are working on a draft proposal which will attempt to standardize 3270 emulation over the Telnet. Any ideas/comments/suggestions are welcomed. Jacob Rekhter (yakov@ibm.com).
-----------[000022][next][prev][last][first]---------------------------------------------------- Date: Wed, 3-Jun-87 13:02:28 EDT From: narten@PURDUE.EDU To: comp.protocols.tcp-ip Subject: Re: TN3270
>Though things seem OK now, the network is still sensitive to increased >traffic on key paths. (Transcontinental bandwidth seems to be the >critical resource here.) Has anyone ever looked into the way EGP traffic (and the "extra hop" problem that goes with it) effects this? For instance, on the ARPANET, there are only 3 EGP servers sites publicly available. They are presumably located on the east coast (10.7.0.63 bnnet2-arpanet-gw.arpa), midwest (10.2.0.37 purdue-cs-gw.arpa), and on the west coast (10.3.0.27 gateway.isi.edu). Does anyone have any information on numbers and locations of sites peering with each server? Would it help to skew the peering so that sites on the east peered with bbnnet2, and so on, even if it means that the percentages of the total sites each server peers with is unequal? In looking at routing tables gotten via EGP from purdue-cs-gw.arpa, only a handful (less than 40 out of 240) of the routes actually go through those gateways. The rest go to specific (and presumably correct) gateways. Is this because everyone else peers with Purdue (and hence its EGP updates have the correct info) or because the "extra hop" problem really isn't a problem since ICMP redirects get things straightened out? Thomas
-----------[000023][next][prev][last][first]---------------------------------------------------- Date: Wed, 3-Jun-87 13:27:49 EDT From: jcollas@XN.LL.MIT.EDU (Juan Collas) To: comp.protocols.tcp-ip Subject: Re: tn3270 draft proposal
Jacob, About time, too. I did the Fibronics KNET tn3270 over telnet server. For documentation on the protocols I relied on a few telnet option RFCs and Greg Minshall's BSD TN3270 client telnet program. The lack of a spec caused some minor problems that are probably still uncorrected (ie negotiating for EOR). Have you thought about standardising for 3279s? color over telnet could be very nice. (I hear the groans of disgust already ...) How about dealing with graphics over 3279s? Differences in MVS vs VM SBAs? (I think that's a moot point, though). I'm sure you've already had these ideas. I'd be interested in getting a copy of the proposal. -Juan Collas, MIT Lincoln Labs
-----------[000024][next][prev][last][first]---------------------------------------------------- Date: Wed, 3-Jun-87 17:02:04 EDT From: utkey@ORNL-MSR.ARPA (Ken Key) To: comp.protocols.tcp-ip Subject: Looking for an X.409 parser...
HI, I'm working on a networking project and have a need for an X.409 parser. I just need octet strings and integers. Anything to keep from reinventing the wheel. Thanks, Ken Key utkey@ornl-msr.arpa KEY@UTKVX1.BITNET
-----------[000025][next][prev][last][first]---------------------------------------------------- Date: Wed, 3-Jun-87 18:11:13 EDT From: MAB@CORNELLC.BITNET (Mark Bodenstein) To: comp.protocols.tcp-ip Subject: Re: IEN documents
>
>All the IEN's are on line and available via anonymous FTP from SRI-NIC.ARPA.
Not so. I FTP'd IEN193 and got the following:
This note is not available online. Please request copies from
the NIC via message to NIC@SRI-NIC.ARPA.
IEN 193
Title: Timer-Based Mechanisms in Reliable Transport Protocol
Connection Management
Author: Dick Watson
As I recall, the NIC said they would supply a printed copy for a nominal fee.
Mark
-----------[000026][next][prev][last][first]---------------------------------------------------- Date: Wed, 3 Jun 1987 18:11:13 EDT From: Mark Bodenstein <MAB%CORNELLC.BITNET@wiscvm.wisc.edu> To: Patrick Barron <pdb%sei.cmu.edu@crnlvax2.BITNET> Cc: TCP-IP@sri-nic.arpa Subject: Re: IEN documents
>
>All the IEN's are on line and available via anonymous FTP from SRI-NIC.ARPA.
Not so. I FTP'd IEN193 and got the following:
This note is not available online. Please request copies from
the NIC via message to NIC@SRI-NIC.ARPA.
IEN 193
Title: Timer-Based Mechanisms in Reliable Transport Protocol
Connection Management
Author: Dick Watson
As I recall, the NIC said they would supply a printed copy for a nominal fee.
Mark
-----------[000027][next][prev][last][first]---------------------------------------------------- Date: Wed, 3-Jun-87 19:17:31 EDT From: steve@teletron.UUCP (Steve Tse) To: comp.protocols.misc,comp.dcom.lans,comp.protocols.tcp-ip Subject: StarLAN ?
Has anyone had experience with AT&T's StarLAN network? I was wondering how good is the performance of this 1 Mb/s, twisted pair, CSMA/CD network in terms of utilization, throughput, latency, end to end delay and capacity. Since the StarLAN using an inverted tree hierarchical star topology, each message sent by a node has to propagate to the HHUB through all the imtermediate levels and back to the node through the same route. Will this cause tremendous of delay and lower the throughput of the system ? Hence IEEE 802.3 designation of type 1BASE5, 1 stands for 1 Mb/s and BASE for baseband. What does 5 stand for? Does it stand for the maximun node-to-node distance 0.5 km ? I also would like to know how easy it is to get networking hardware and software (especially for TCP/IP-based systems) and what it all costs. I would appreciate any information anyone has on this network. Thanks, Steve Tse alberta!ncc!teletron!stolo/
-----------[000028][next][prev][last][first]---------------------------------------------------- Date: 3 Jun 87 17:07:55 GMT From: pioneer!lamaster@ames.arpa (Hugh LaMaster) To: tcp-ip@sri-nic.arpa Subject: Re: TCP/IP ETHERNET DECNET VAX
In article <2033@a.cs.okstate.edu> keith@a.cs.okstate.edu (Keith Lovelace) writes:
>Help!!!
>
>We here at OSU have just recently decided that we would purchase a VAX 8350 and
>run ULTRIX on it. We currently are running a VAX 11/780 with VMS. We would
>like to run DECNet to the two machines for file transferr, mail, etc. (our
>first attempt at DECNetting anything). We would then like to run a TCP/IP
>link on the 8350 to do the terminal interface. The first problem arises in
>the fact that there are very few DEC people who know anything about ULTRIX,
>much less TCP/IP. This is also our first attempt at providing a campus wide
>UNIX (at least a derivative) system, and also our first attempt at TCP/IP
>networking. In other words, we are stepping into unknown and previously
>untouched areas. To get on with it, my questions may be simple to you but
>are still confusing to me.
>
>Problem one. Can ULTRIX, or 4.2 BSD (since it is supposedly not changed by
>DEC) support both a DECNet link and a TCP/IP link at the same time without
>problems?
>
Here at Ames, we are running both TCP/IP and DECNET on an 11/780 using
Ultrix. There have been no problems that I am aware of.
>Problem two. Does ULTRIX do very well talking to terminal servers such as
>the ANNEX UX on TCP/IP?
>
Yes, it works fine. We have tested Ultrix with the Annex. No problems.
>The reason for going to the TCP/IP connection for terminals is based on the
>fact that we don't want to lock ourselves into $'s of DEC hardware for
This is good reasoning in my opinion.
I have no experience with the 8350. Sorry. We do have an 8650 running VMS, and
I have been impressed by its speed.
Hugh LaMaster, m/s 233-9, UUCP {seismo,topaz,lll-crg,ucbvax}!
NASA Ames Research Center ames!pioneer!lamaster
Moffett Field, CA 94035 ARPA lamaster@ames-pioneer.arpa
Phone: (415)694-6117 ARPA lamaster@pioneer.arc.nasa.gov
"In order to promise genuine progress, the acronym RISC should stand
for REGULAR (not reduced) instruction set computer." - Wirth
("Any opinions expressed herein are solely the responsibility of the
author and do not represent the opinions of NASA or the U.S. Government")
-----------[000029][next][prev][last][first]---------------------------------------------------- Date: Wed, 3-Jun-87 21:37:04 EDT From: swb@DEVVAX.TN.CORNELL.EDU (Scott Brim) To: comp.protocols.tcp-ip Subject: tn3270 draft proposal
Date: Wed, 3 Jun 87 13:27:49 EDT From: jcollas@XN.LL.MIT.EDU (Juan Collas) Have you thought about standardising for 3279s? color over telnet could be very nice. .... How about dealing with graphics over 3279s? We have a real requirement for this and I think the RFC would be incomplete without it. I too look forward to it. Scott
-----------[000030][next][prev][last][first]---------------------------------------------------- Date: Thu, 4-Jun-87 01:31:48 EDT From: robert@psych.psy.uq.oz (Robert Dal Santo) To: comp.unix.wizards,comp.protocols.tcp-ip Subject: Help Wanted - TCP/IP -> Sys V
We are running System V.2 on a Perkin Elmer 3210. PE's port of Sys V is called Xelos. We have just purchased a Micro Vax II and want to get the two talking over an ethernet. PROBLEM. The PE doesnt talk TCP/IP, and we have sources for Xelos, but not for Ultrix, so we want to get pseudo TCP/IP on the PE under Sys V (Xelos). The easiest would be to get an intelligent TCP/IP ethernet board, but thats unlikely. The other possibility is to 'graft' TCP/IP into our Sys V kernel. This looks to be no minor task. Is there anyone out there who has grafted TCP/IP into a Sys V kernel ? Even a partial graft, as we would be quite happy if we could just copy files between the two machines, and we could build from there. Please respond by E-mail. Thanks, Robert Dal Santo Phone: +61 7 377 4285 (International) Department of Psychology, ACSnet: robert@psych.psy.uq.oz University of Queensland, ARPA: robert%psych.psy.uq.oz@seismo.css.gov St Lucia, Brisbane, 4067 UUCP: ..!seismo!munnari!psych.psy.uq.oz!robert AUSTRALIA. JANET: psych.psy.uq.oz!robert@ukc
-----------[000031][next][prev][last][first]---------------------------------------------------- Date: Thu, 04 Jun 87 10:32:01 -0400 From: Mike Brescia <brescia@CCV.BBN.COM> To: narten@PURDUE.EDU Cc: tcp-ip@SRI-NIC.ARPA, egp-people@CCV.BBN.COM Subject: EGP, extra hop, and peers (was: TN3270)
>the network is still sensitive to increased traffic on key paths.
Has anyone ever looked into the way EGP traffic (and the "extra hop"
problem that goes with it) effects this?
There are two factors Tom asks about. 1) the EGP protocol routing overhead
2) the "extra hop problem"
For the first, yes, every gateway is pinging 2 or 3 egp core servers every 30
or 60 seconds, and polling for routing information every 2 (or more) minutes.
We recommended earlier that implementers lengthen the times to 60 seconds and
3 minutes. This suggestion was sent out to 'egp-people' list on March 3 and
again on May 18.
For the extra hop problem, we have been recommending that EGP connections be
maintained with 2 of the 3 servers, so that for any net you try to reach will
be known directly to you because both parties are likely to be doing EGP with
the same core server, and the direct route to the other net will be advertized
to you in the EGP net-reachability (NR) message. While your gateway is
not doing EGP with that other gateway, the information is relayed by the core,
and the user traffic is not expected to pass through the core gateway.
There is an extra hop problem when you are trying to reach a local (EGP
advertized) net on the MILNET (or if you are on the MILNET side, you are
trying to reach a local net attaced to the ARPANET). This is more properly
described as a GGP extra hop problem, rather than an EGP one.
Does anyone have any information on numbers and locations of sites
peering with each server?
I am sending a snapshot of the routing to Tom Narten. If you want a copy too,
send me a note. It's about 4 pages.
Would it help to skew the peering so that sites on the east peered with
bbnnet2, and so on...
This only helps distribute the EGP protocol traffic. We think we can handle
the 60 packets a minute.
In looking at routing tables gotten via EGP from purdue-cs-gw.arpa,
only a handful (less than 40 out of 240) of the routes actually go
through those [core] gateways.
You should be able to get good (ARPANET) routes directly from the EGP. ICMP
redirect will not help unless you are a host instead of (in addition to) a
gateway.
Mike
p.s.: Apologies to those on EGP-PEOPLE mailing list who get two copies. The
distributed mail data base is not yet capable of doing
( TCP-IP | EGP-PEOPLE ) /* c syntax instead of sql :-*/
-----------[000032][next][prev][last][first]---------------------------------------------------- Date: Thu, 4-Jun-87 10:46:14 EDT From: brescia@CCV.BBN.COM.UUCP To: comp.protocols.tcp-ip Subject: EGP, extra hop, and peers (was: TN3270)
>the network is still sensitive to increased traffic on key paths.
Has anyone ever looked into the way EGP traffic (and the "extra hop"
problem that goes with it) effects this?
There are two factors Tom asks about. 1) the EGP protocol routing overhead
2) the "extra hop problem"
For the first, yes, every gateway is pinging 2 or 3 egp core servers every 30
or 60 seconds, and polling for routing information every 2 (or more) minutes.
We recommended earlier that implementers lengthen the times to 60 seconds and
3 minutes. This suggestion was sent out to 'egp-people' list on March 3 and
again on May 18.
For the extra hop problem, we have been recommending that EGP connections be
maintained with 2 of the 3 servers, so that for any net you try to reach will
be known directly to you because both parties are likely to be doing EGP with
the same core server, and the direct route to the other net will be advertized
to you in the EGP net-reachability (NR) message. While your gateway is
not doing EGP with that other gateway, the information is relayed by the core,
and the user traffic is not expected to pass through the core gateway.
There is an extra hop problem when you are trying to reach a local (EGP
advertized) net on the MILNET (or if you are on the MILNET side, you are
trying to reach a local net attaced to the ARPANET). This is more properly
described as a GGP extra hop problem, rather than an EGP one.
Does anyone have any information on numbers and locations of sites
peering with each server?
I am sending a snapshot of the routing to Tom Narten. If you want a copy too,
send me a note. It's about 4 pages.
Would it help to skew the peering so that sites on the east peered with
bbnnet2, and so on...
This only helps distribute the EGP protocol traffic. We think we can handle
the 60 packets a minute.
In looking at routing tables gotten via EGP from purdue-cs-gw.arpa,
only a handful (less than 40 out of 240) of the routes actually go
through those [core] gateways.
You should be able to get good (ARPANET) routes directly from the EGP. ICMP
redirect will not help unless you are a host instead of (in addition to) a
gateway.
Mike
p.s.: Apologies to those on EGP-PEOPLE mailing list who get two copies. The
distributed mail data base is not yet capable of doing
( TCP-IP | EGP-PEOPLE ) /* c syntax instead of sql :-*/
-----------[000033][next][prev][last][first]---------------------------------------------------- Date: Thu, 4 Jun 87 11:03:16 EDT From: jqj@gvax.cs.cornell.edu (J Q Johnson) To: arpa.tcp-ip Subject: Re: ARPAnet congestion (was TN3270)
One of the troubling things many of us learned last fall was that most of the long distance Internet trunks are logical trunks leased from the various phone companies without much regard to the physical path they take. Has any progress been made in determining the physical paths that the long distance ARPAnet (and more importantly Milnet) links take? Has progress been made in insuring the survivability of Internet communications if a backhoe cuts through a major AT&T fiber on the NY Thruway?
-----------[000034][next][prev][last][first]---------------------------------------------------- Date: Thu, 4-Jun-87 12:29:22 EDT From: CMSMAINT@BROWNVM.BITNET.UUCP To: comp.protocols.tcp-ip Subject: tn3270 draft proposal: 3270 graphics
I think the best way to support graphics in tn3270 would be to use
3179 vector graphics instead of 3279 programmed symbols. The 3179
data streams are much shorter, and are fairly easy to map to calls to
a graphics package such as QuickDraw on a Macintosh. Also, the host
programs which support the 3179 can adapt to different screen sizes.
I've had some experience with this, having written a Macintosh 3270
emulation program which includes 3179 support.
Peter
-----------[000035][next][prev][last][first]---------------------------------------------------- Date: Thu, 04 Jun 87 12:29:22 EDT From: Peter DiCamillo <CMSMAINT%BROWNVM.BITNET@wiscvm.wisc.edu> To: TCP-IP@SRI-NIC.ARPA Subject: tn3270 draft proposal: 3270 graphics
I think the best way to support graphics in tn3270 would be to use
3179 vector graphics instead of 3279 programmed symbols. The 3179
data streams are much shorter, and are fairly easy to map to calls to
a graphics package such as QuickDraw on a Macintosh. Also, the host
programs which support the 3179 can adapt to different screen sizes.
I've had some experience with this, having written a Macintosh 3270
emulation program which includes 3179 support.
Peter
-----------[000036][next][prev][last][first]---------------------------------------------------- Date: Thu, 4-Jun-87 17:43:01 EDT From: ntm1569@dsacg3.UUCP To: comp.protocols.tcp-ip Subject: MVS TCP-IP Implementations
We need to run TCP/IP over an ethernet LAN between superminis running
(essentially) 4.3BSD and IBM/compatible mainframes running MVS.
Currently evaluating Network Solutions' DDN/MVS and Simware's SIM3278.
Any comments, suggestions etc. regarding these products or alternatives
would be much appreciated. Particularly interested in performance;
we may end up using FTP to transfer some sizeable files on a regular
basis. Read this newsgroup religiously but if you'd rather mail send to
seismo!gould!dsacg1!jroth
and if there are sufficient replies I will summarize.
--
Jeff Roth {seismo!gould,cbatt!osu-eddie}!dsacg1!jroth
Defense Logistics Agency Systems Automation Center | 614-238-9421
DSAC-TMP, P.O. Box 1605, Columbus, OH 43216 | Autovon 850-
All views expressed are mine, not necessarily anyone else's
-----------[000037][next][prev][last][first]---------------------------------------------------- Date: Fri, 5-Jun-87 03:21:52 EDT From: jaw@jpl-mil.jpl.nasa.GOV.UUCP To: comp.protocols.tcp-ip Subject: sendmail problem
I have been having trouble sending mail from our SUNs to several hosts (timeout after HELLO) including sri-nic.arpa. Using Eric Fair's sendmail.cf file (@sri-nic.arpa <netinfo>sendmail-internet-generic.txt) fixed the problem. When I find out the difference from what we were using, I will pass it on. Joe Wieclawek Mail stop: 602-145 Jet Propulsion Laboratory Office: (818)354-2419 FTS: 792-2419 4800 Oak Grove Drive jaw@sesun.jpl.nasa.gov Pasadena CA 91109 System Engineering Communications and Computing Network Services Section
-----------[000038][next][prev][last][first]---------------------------------------------------- Date: Fri, 5-Jun-87 11:30:27 EDT From: mike@BRL.ARPA.UUCP To: comp.protocols.tcp-ip Subject: Re: routing restrictions and routing consistencies.
Can anyone tell me (a) precisely what the changes to the "mail bridges" are going to be, and (b) what the implementation timetable is? I have heard a lot of speculation. About 85% of the speculation outlines configurations that are unacceptable to Army/AMC (which is 1/5th of the Army), and probably unacceptable to significant portions of the other services. Before I start shooting my mouth off in Washington, I need some hard facts. All help will be much appreciated. Best, -Mike Muuss
-----------[000039][next][prev][last][first]---------------------------------------------------- Date: Fri, 5-Jun-87 11:45:00 EDT From: VTTTELTY@FINFUN.BITNET.UUCP To: comp.protocols.tcp-ip Subject: Re: Netbioses and VT100-Telnet
A few weeks ago I sent the following request to PC-IP and TCP-IP
mailing lists:
>Where can I find the following products:
>
>1. Netbios on TCP/IP for IBM PC/AT and 3Com Ethernet controllers.
>
>2. VT100-Telnet (supporting function keys) for IBM PC/AT.
>
>3. Netbios on TCP/IP for VAX/VMS.
>
Here are the most interesting responses I got:
------------------------------------------------------------
From: <BEAME@MCMASTER>
Santtu,
Beame & Whiteside Software Ltd. have a VT100/VT52 - Telnet program
that runs on IBM PC/XT/AT machines using a 3Com EtherLink board. This
emulator includes a fully definable keyboard (every letter, function key).
The emulator also uses hardware scrolling for fast no-snow output (EGA
support also).
This program comes with TCP/IP but NOT NetBios. More information
can be obtained from me or :
Beame & Whiteside Software Ltd.
259 Fiddler's Green Road
Ancaster, Ontario
Canada L9G 1W9
- Carl Beame
P.S: I wrote the program, so notice the bias.
---------------------------------------------------------------
From: minshall%opal.Berkeley.EDU@BERKELEY.EDU
Hi. Your items 1 and 2 can probably be gotten from Ungermann-Bass.
Possibly from Excelan and 3COM also (though I don't know for sure).
Greg Minshall
---------------------------------------------------------------
From: CLYNN@G.BBN.COM
I am not sure about documents for the specific implementations
that you mentioned, but RFC1001 and RFC1002 specify how to do NETBIOS
over TCP/IP networks. They are available via anonymous FTP from
SRI-NIC.ARPA.
---------------------------------------------------------------
From: Dave Crocker <dcrocker%engr.ub.com@RELAY.CS.NET>
You might try contacting Lantec, for all of your needs.
Their postal address is:
Postboks 171 Olavsgt. 39B
3601 Kongsberg
NORWAY
Phone is +47-3-73-6880
Dave
----------------------------------------------------------------
From: cmcl2!aecom.yu.edu!cucard!naftoli%harvard@husc6.BITNET
Excelan makes a netbios over TCP/IP which works ok. We have
run the IBM PC network over it with no apprarent problems.
---
Robert N. Berlinger
Supervisor of Systems Support Compuserve: 73047,741
Albert Einstein College of Medicine Easylink: 62956067
UUCP: ...$philabs,cucard,pegasus,rocky2!aecom!naftoli GEnie: R.Berlinger
----------------------------------------------------------------
From: John Romkey <ROMKEY@XX.LCS.MIT.EDU>
Try getting in touch with FTP Software. (617) 868-4878. The address
is:
FTP Software, Inc.
PO Box 150
Kendall Square Branch
Boston, MA 02140
USA
FTP will be releasing a NetBIOS on TCP this summer, and already has a VT100
telnet available.
I am associated with FTP, so I do have some interest in these matters...
- john romkey
-------------------------------------------------------------------
From: RITCV!ROCKSVAX!ROCKSANNE!SUNYBCS!CANISIUS!ITECH1!SIA
@CS.ROCHESTER.EDU
A rather complete TCP/IP package for IBM PC/XT/AT's that includes
a VT100 Telnet is available from:
FTP Software, Inc.
P.O. BOX 150
Kendall Square Branch
Boston, MA 02142
(617) 864-1711
The stuff for the VAX running under VMS is available from:
The Wollongong Group, Inc.
1129 San Antonio Road
P.O. Box 51860
Palo Alto, CA 94303
(415)962-7100
Wollongong also has a TCP/IP for the PC.
Another source for these packages would be:
Network Research Corp.
2380 North Rose Avenue
Oxnard, CA 93030
(805)485-2700
********************************************************************************
Stewart I. Alpert @ Ingram Software, Inc. Department of Technical Services
UUCP: {ihnp4,sco,mwc,canisius}!itech1!sia
{allegra,decvax,watmath}!sunybcs!canisius!itech1!sia
ARPA/CSNET: itech1!sia%canisius@csnet-relay.ARPA
AT&T: 1-716-874-1874 or 1-800-828-7250 or 1-800-464-8488 (in NYS)
USnail: 2128 Elmwood Avenue, Buffalo, NY 14215
------------------------------------------------------------------------
Santtu M{ki
Technical Research Centre of Finland
Telecommunications laboratory
-----------[000040][next][prev][last][first]---------------------------------------------------- Date: Fri, 5-Jun-87 13:50:56 EDT From: jaw@sesun.Jpl.Nasa.GOV (Joe Wieclawek) To: comp.protocols.tcp-ip Subject: sendmail problem
>I have been having trouble sending mail from our SUNs to several hosts >(timeout after HELLO) including sri-nic.arpa. Using Eric Fair's >sendmail.cf file (@sri-nic.arpa <netinfo>sendmail-internet-generic.txt) >fixed the problem. When I find out the difference from what we were >using, I will pass it on. I changed our old sendmail.cf to include "E=\r\n" in the M record: Mether, P=[IPC], F=msDFMuCX, S=11, R=21, A=IPC $h, E=\r\n and this makes it work. Thanks to : scott@gateway.mitre.org dupuy@amsterdam.columbia.edu dplatt@teknowledge-vaxc.arpa Joe Wieclawek Mail stop: 602-145 Jet Propulsion Laboratory Office: (818)354-2419 FTS: 792-2419 4800 Oak Grove Drive jaw@sesun.jpl.nasa.gov Pasadena CA 91109
-----------[000041][next][prev][last][first]---------------------------------------------------- Date: Fri, 5-Jun-87 13:58:14 EDT From: Mills@UDEL.EDU.UUCP To: comp.protocols.tcp-ip Subject: A fuzzy proposal
Folks,
This is a proposal for a modification to the data base used by the NIC and
other organizations which identifies hosts and gateways. The modification is
suggested by certain routing configurations that commonly occur in the NSFNET
community and also elsewhere. These configurations involve cases where the
internal structure of an autonomous system is to be hidden from outside the
system for various good reasons.
The issues involved are best raised by an example involving a gateway/host
called the fuzzball and used in the NSFNET Backbone system, as well in other
systems. First a few words on fuzzballs and routing. In order to minimize
consumption of network numbers and local-net addresses, a peculiar addressing
model is enjoyed by the fuzzies. Each one is assigned a "home address,"
usually on the local Ether, which represents its entity title in ISOspeak.
This address is unique, so that unambiguous routes can always be computed.
When two fuzzies are spliced together by a serial line, each sends the other a
hello message with its home address in the IP source-address field. The other
one saves this address and uses it to update its local-entity routing tables
and network-entity routing tables (if both are on different networks). Thus,
fuzzies automatically build routing tables for not only the local routes, but
routes to adjacent networks. Additional data in the hello message is used to
construct routes to other than adjacent networks.
In order to reduce consumption of net numbers and local-net addresses, two
fuzzies connected as above do not need to know their address (if any) on the
adjacent network. This avoids the "null net" problem sometimes encountered
when two gateways belonging to different autonomous systems are connected by a
point-to-point line. Nevertheless, if necessary for other reasons, fuzzy
addresses can be assigned with appropriate handcrafted entries in the routing
data base (this is in fact done sometimes to create a "tunnel" where a host
physically connected to one network is assigned an address on some other
network). However, this defeats a very desirable self-configuration
characteristic and considerably complicates configuration control and
management.
Following is an example scenario involving UMICHNET (35) and MACOMNET
(192.5.8). The 35.1.1.1 fuzzy is connected to the 192.5.8.6 fuzzy by a serial
line. To the 35.1.1.1 fuzzy its end of the line appears an extension of net
192.5.8 while, to the 192.5.8.6 fuzzy its end of the line appears an extension
of net 35; however, neither fuzzy knows or cares about its specific address on
the other network (in fact no such address is used). However, each fuzzy
determines from the source address of received hello messages the specific net
number and updates its tables accordingly.
+---------------+ ARPANET
|192.5.8.x |35.x.x.x |
+---------+ +----+----+ +----+----+ +----+----+
| net 35 | |35.1.1.1 | |192.5.8.6| |192.5.8.1|
| host | | umich1 | |swamprat | | macom1 |
+----+----+ +----+----+ +----+----+ +----+----+
| | | |
=====O===============O==== =====O===============O=====
net 35 Ether net 192.5.8 Ether
Although attractive in these aspects, the fuzzball scheme does create some
problems. For instance, it is not possible to determine an unambiguous return
route, since a fuzzy may not know its address on the previous network. Also,
it is not possible to produce an unambiguous interface list suitable for
recording in the NIC or similar data bases. In fact, it is not possible to
contact either the 35.1.1.1 or 192.5.8.6 fuzzies using addresses on their
respective adjacent nets, since such addresses do not exist.
Comes now a proposal to deal with this problem. Henceforth, gateways in this
embarrasing situation shall be assigned synthetic addresses in the form
<net>*, where * indicates unknown or unassigned. For example, the
fuzzies above would be recorded as
GATEWAY : 35.1.1.1, 192.5.8.* : UMICH1
GATEWAY : 192,5,8,6 35.*.*.* : SWAMPRAT .
It is possible in the case of subnets to indicate finer granularity by
replacing * fields with assigned numbers; however, the subnet mask can only be
inferred and then only if it corresponds to octet fields.
The above notation can also be used when two or more gateways are operated as
a single autonomous system and where the internal structure of that system is
to be hidden. For instance, assume the ARPANET gateway 192.5.8.1 above wishes
to hide the other two gateays. This could be done by
GATEWAY : 10.0.0.111, 192.5.8.*, 35.*.*.* : MACOM1 .
The implication is that routing computations are to be done under the
assumption that MACOM1 has in fact direct interfaces to the nets listed and
that it will take responsibility for all traffic to those nets received at
10.0.0.111.
How might this proposal affect global routing schemes such as proposed for
the Dissimilar Gateway Protocol (DGP)? The DGP routing algorithm synthesizes
routes directly from interface lists in the form
<gate> <net1> <net2> ... ,
where <gate> is a unique gateway identifier and <net1>, etc., are the
interface addresses assigned to it. The algorithm constructs a path between
desginated endpoint addresses <source> and <destination> in the form
<source> <gate1> <net1> <gate2> <net2> ... <gaten> <destination> .
The particular algorithm used is a variant of the Dijkstra (SPF) algorithm
modified for a hierarchical data base, but this is not important for the
present discussion. However, note that the Dijkstra algorithm (and many other
ones similar to it) operate by extending paths from a given node to each of
several possible successor nodes. Say the algorithm is currently extending
paths from <gate1>, for example. It then adds to the path ending in <gate1>
new edges for each interface address, which according to the proposal above
could involve an incompletely specified address.
In some following step the incompletely specified node will be found. When
extending the path from that node the set of interface lists will be searched
for interface addresses on the same network and for each one found the
associated gateway will be added to the path. There are two cases:
1. The interface address on the next hop is completely specified. In this case
a complete source route can be constructed in the usual way.
3. The interface address on the next hop is not completely specified. A source
route must then be constructed to the previous-hop gateway, which then
has the responsibility to determine the remainder of the route.
Your advice and comment on this proposal will be appreciated.
Dave
-----------[000042][next][prev][last][first]---------------------------------------------------- Date: Fri, 5-Jun-87 14:54:12 EDT From: ron@TOPAZ.RUTGERS.EDU (Ron Natalie) To: comp.protocols.tcp-ip Subject: Re: Help Wanted - TCP/IP -> Sys V
I thought PE was now selling TCP/IP as an option for both their System V and older operating system. -Ron
-----------[000043][next][prev][last][first]---------------------------------------------------- Date: Fri, 5-Jun-87 17:58:17 EDT From: minshall@OPAL.BERKELEY.EDU To: comp.protocols.tcp-ip Subject: Re: tn3270
Jacob, Needless to say, a standard would be very welcome. It should be planned to be released as an RFC. Many people have asked about 3279, 3179, etc. I think the point is that the standard needs to address "3270 over telnet", where all of the above are in the class "3270". Peter is right that in general the 3179 G graphics are nice; but sometimes programmed symbols are nice. The point is we should allow "everything". I think the model (continues to be) how the IBM "PVM" (IBM's telnet-style program for VM systems) does it. I think that someone with PVM devleopment experience (and thus an IBMer) would be very useful in this endeavour. Anyway, I'm very interested in contributing to such a standard. Greg
-----------[000044][next][prev][last][first]---------------------------------------------------- Date: Fri, 5-Jun-87 21:21:34 EDT From: JBVB@AI.AI.MIT.EDU.UUCP To: comp.protocols.tcp-ip Subject: Re: Netbioses and VT100-Telnet
A couple of notes on Santtu ?Miki?'s posting: Excelan and Ungermann/Bass have TCP/IP NETBIOSs for the PC available now, but neither conforms to the RFCs, and because of this, they don't interoperate. I have heard rumors that Excelan will upgrade theirs to conform to the RFCs by early 4th quarter. I have no idea what U/B is up to, although I assume they're hard at work as well. When FTP Software's NETBIOS is available, it will conform to the RFCs. I have seen postings that suggested that Excelan either had a VMS NETBIOS (non-RFC-compatible), or was working on one (which could be planned for compatibility). I have no more facts, except that I am quite sure that neither MICOM-Interlan, The Wollongong Group, Network Research Corp., nor SRI (all vendors of VMS packages, see the Vendors Guide) have any NETBIOS support for VMS as of this date. I know that Telnets with VT100 emulators for the PC are available from Beame & Whiteside, Bridge, Excelan, FTP Software, The Wollongong Group Sun, and U/B, either separately, or as part of a larger TCP/IP package for the PC. U/B and Excelan require the use of the manufacturer's Ethernet board, and Bridge & TWG only support the 3Com dumb interface. Last I knew, NRC's package didn't have terminal emulation as such (their Telnet relied on ANSI.SYS), but that could have changed recently. FTP is the only company that offers a VT100 Rlogin, but that doesn't cut much ice against a VMS... The only one I've worked with is the one I maintain (FTPs). It does a straight VT100, less smooth scroll, 132 column mode, and double height/ double width. The release due out July 1 has no-snow CGA operation added. All function keys are handled, and the keypad layout works fairly well with EDT on VMS. Last I knew, Excelan had roughly the same layout, but I've never actually used it against a VMS. jbvb@ai.ai.mit.edu James B. VanBokkelen FTP Software Inc.
-----------[000045][next][prev][last][first]---------------------------------------------------- Date: 5 Jun 87 21:07:05 GMT From: pioneer!lamaster@ames.arpa (Hugh LaMaster) To: tcp-ip@sri-nic.arpa Subject: Re: comp.protocols.iso
I note that there is now a newgroup for discussing iso protocols:
comp.protocols.iso
Hugh LaMaster, m/s 233-9, UUCP {seismo,topaz,lll-crg,ucbvax}!
NASA Ames Research Center ames!pioneer!lamaster
Moffett Field, CA 94035 ARPA lamaster@ames-pioneer.arpa
Phone: (415)694-6117 ARPA lamaster@pioneer.arc.nasa.gov
"In order to promise genuine progress, the acronym RISC should stand
for REGULAR (not reduced) instruction set computer." - Wirth
("Any opinions expressed herein are solely the responsibility of the
author and do not represent the opinions of NASA or the U.S. Government")
-----------[000046][next][prev][last][first]---------------------------------------------------- Date: Fri, 5 Jun 87 17:45 O From: <VTTTELTY%FINFUN.BITNET@wiscvm.wisc.edu> To: TCP-IP@SRI-NIC.ARPA Subject: Re: Netbioses and VT100-Telnet
A few weeks ago I sent the following request to PC-IP and TCP-IP
mailing lists:
>Where can I find the following products:
>
>1. Netbios on TCP/IP for IBM PC/AT and 3Com Ethernet controllers.
>
>2. VT100-Telnet (supporting function keys) for IBM PC/AT.
>
>3. Netbios on TCP/IP for VAX/VMS.
>
Here are the most interesting responses I got:
------------------------------------------------------------
From: <BEAME@MCMASTER>
Santtu,
Beame & Whiteside Software Ltd. have a VT100/VT52 - Telnet program
that runs on IBM PC/XT/AT machines using a 3Com EtherLink board. This
emulator includes a fully definable keyboard (every letter, function key).
The emulator also uses hardware scrolling for fast no-snow output (EGA
support also).
This program comes with TCP/IP but NOT NetBios. More information
can be obtained from me or :
Beame & Whiteside Software Ltd.
259 Fiddler's Green Road
Ancaster, Ontario
Canada L9G 1W9
- Carl Beame
P.S: I wrote the program, so notice the bias.
---------------------------------------------------------------
From: minshall%opal.Berkeley.EDU@BERKELEY.EDU
Hi. Your items 1 and 2 can probably be gotten from Ungermann-Bass.
Possibly from Excelan and 3COM also (though I don't know for sure).
Greg Minshall
---------------------------------------------------------------
From: CLYNN@G.BBN.COM
I am not sure about documents for the specific implementations
that you mentioned, but RFC1001 and RFC1002 specify how to do NETBIOS
over TCP/IP networks. They are available via anonymous FTP from
SRI-NIC.ARPA.
---------------------------------------------------------------
From: Dave Crocker <dcrocker%engr.ub.com@RELAY.CS.NET>
You might try contacting Lantec, for all of your needs.
Their postal address is:
Postboks 171 Olavsgt. 39B
3601 Kongsberg
NORWAY
Phone is +47-3-73-6880
Dave
----------------------------------------------------------------
From: cmcl2!aecom.yu.edu!cucard!naftoli%harvard@husc6.BITNET
Excelan makes a netbios over TCP/IP which works ok. We have
run the IBM PC network over it with no apprarent problems.
---
Robert N. Berlinger
Supervisor of Systems Support Compuserve: 73047,741
Albert Einstein College of Medicine Easylink: 62956067
UUCP: ...$philabs,cucard,pegasus,rocky2!aecom!naftoli GEnie: R.Berlinger
----------------------------------------------------------------
From: John Romkey <ROMKEY@XX.LCS.MIT.EDU>
Try getting in touch with FTP Software. (617) 868-4878. The address
is:
FTP Software, Inc.
PO Box 150
Kendall Square Branch
Boston, MA 02140
USA
FTP will be releasing a NetBIOS on TCP this summer, and already has a VT100
telnet available.
I am associated with FTP, so I do have some interest in these matters...
- john romkey
-------------------------------------------------------------------
From: RITCV!ROCKSVAX!ROCKSANNE!SUNYBCS!CANISIUS!ITECH1!SIA
@CS.ROCHESTER.EDU
A rather complete TCP/IP package for IBM PC/XT/AT's that includes
a VT100 Telnet is available from:
FTP Software, Inc.
P.O. BOX 150
Kendall Square Branch
Boston, MA 02142
(617) 864-1711
The stuff for the VAX running under VMS is available from:
The Wollongong Group, Inc.
1129 San Antonio Road
P.O. Box 51860
Palo Alto, CA 94303
(415)962-7100
Wollongong also has a TCP/IP for the PC.
Another source for these packages would be:
Network Research Corp.
2380 North Rose Avenue
Oxnard, CA 93030
(805)485-2700
********************************************************************************
Stewart I. Alpert @ Ingram Software, Inc. Department of Technical Services
UUCP: {ihnp4,sco,mwc,canisius}!itech1!sia
{allegra,decvax,watmath}!sunybcs!canisius!itech1!sia
ARPA/CSNET: itech1!sia%canisius@csnet-relay.ARPA
AT&T: 1-716-874-1874 or 1-800-828-7250 or 1-800-464-8488 (in NYS)
USnail: 2128 Elmwood Avenue, Buffalo, NY 14215
------------------------------------------------------------------------
Santtu M{ki
Technical Research Centre of Finland
Telecommunications laboratory
-----------[000047][next][prev][last][first]---------------------------------------------------- Date: Sat, 06 Jun 87 11:41 PDT From: Michael Stein <CSYSMAS@UCLA-CCN.ARPA> To: tcp-ip@sri-nic.arpa Subject: Re: tn3270 model
> I think the model (continues to be) how the IBM "PVM" (IBM's > telnet-style program for VM systems) does it. I think that someone with > PVM devleopment experience (and thus an IBMer) would be very useful > in this endeavour. I think that this is the wrong model. A better model is IBM/VTAM. This does NOT require VTAM experience, VTAM transmits 3270 data streams transparently. (Once you get to transparent mode there is nothing to do!) The 3270 data stream has it's own internal "terminal type" query support, why not just use it. It would be simple to require all network "3270"s to support query even if the query response is just a pre-canned "dumb" response. Note that at least some tn3270 type programs will have to support query anyway for graphics or other special features.
-----------[000048][next][prev][last][first]---------------------------------------------------- Date: Sat, 6-Jun-87 10:08:48 EDT From: hwb@MCR.UMICH.EDU (Hans-Werner Braun) To: comp.protocols.tcp-ip Subject: Re: A fuzzy proposal
Dave: Why don't you leave the *'s out, as they seem redundant. All you are asking for is to leave host parts out to allow for net and subnet connections. It's obvious without marking explicit *'s. In fact, may be addresses not fully qualified (like 192.5.8) should be followed by a bit mask, to allow for subnets. E.g.: GATEWAY : 35.1.1.4, (35.128 : 255.128.0.0) : MERIT-DIRECT GATEWAY : 35.1.1.4, (35.1.128 : 255.255.224.0) : CITI Another possibility would be to use zeroes instead: GATEWAY : 35.1.1.4, (35.128.0.0 : 255.128.0.0) : MERIT-DIRECT GATEWAY : 35.1.1.4, (35.1.128.0 : 255.255.224.0) : CITI Note that the Merit packet switching nodes allow for the same addressing flexibility Fuzzballs do. However due to some of the limitations you outlined we will soon be able to "let devices know (additionally) what address they should use." This is important for, e.g., ARPs if you have more then one Ethernet interface. -- Hans-Werner
-----------[000049][next][prev][last][first]---------------------------------------------------- Date: Sat, 6-Jun-87 11:51:53 EDT From: Mills@UDEL.EDU.UUCP To: comp.protocols.tcp-ip Subject: Re: A fuzzy proposal
HW, Well, I like the idea of including bitmasks to indicate address ranges, but I thought that a bit radical to propose at this time. In fact, I have a whole bunch of really radical things to propose, all in good time. Meanwhile, I suggest using zeros instead of * might break something somewhere, like (old) local-net brodcasts. Dave
-----------[000050][next][prev][last][first]---------------------------------------------------- Date: Sat, 6-Jun-87 14:41:00 EDT From: CSYSMAS@OAC.UCLA.EDU.UUCP To: comp.protocols.tcp-ip Subject: Re: tn3270 model
> I think the model (continues to be) how the IBM "PVM" (IBM's > telnet-style program for VM systems) does it. I think that someone with > PVM devleopment experience (and thus an IBMer) would be very useful > in this endeavour. I think that this is the wrong model. A better model is IBM/VTAM. This does NOT require VTAM experience, VTAM transmits 3270 data streams transparently. (Once you get to transparent mode there is nothing to do!) The 3270 data stream has it's own internal "terminal type" query support, why not just use it. It would be simple to require all network "3270"s to support query even if the query response is just a pre-canned "dumb" response. Note that at least some tn3270 type programs will have to support query anyway for graphics or other special features.
-----------[000051][next][prev][last][first]---------------------------------------------------- Date: Sat, 6-Jun-87 21:36:00 EDT From: WANCHO@SIMTEL20.ARPA.UUCP To: comp.protocols.tcp-ip Subject: Strange problems with VAX/VMS DDN X.25 hosts
Karl Goodloe's machine is a VAX 11/750 running 4.2bsd with some Mt. Xinu fixes from a couple years back. The problem he describes below seems to happen only when VAX/VMS systems running Wollongong TCP/IP over a DDN X.25 connection attempt to send mail over a certain size to his host. If this situation looks familiar to anyone, or you might have some clue as to what's happening, please contact Karl directly and copy me in your message. Here are the details from Karl: Date: Wednesday, 3 June 1987 10:11-MDT From: kgoodloe at miser.ARPA (Karl G. Goodloe) To: fwancho Re: Mail Problem We really haven't installed any software updates on MISER. We have done a lot of work on the sendmail.cf file to accomodate the change in the host table. None of the ones that you gave us [Eric Fair's versions of the sendmail.cf files on SRI-NIC.ARPA] were compatible with the way that we have set up to exchange mail with our INTEL-310 systems. We use uucp; however, some changes were made in the normal way that uucp hosts are taken care of in the configuration file. When the problem to appeared, I changed back to the old sendmail.cf just to make sure that the changes weren't causing the problem. The problem occurs when we receive mail from a VAX/VMS host. A sendmail process is created for the message, and the corresponding dfAA<PID> file is created. No corresponding qfAA<PID> file is ever created, so it is a bit difficult to know where the message is coming from and more difficult to tell who it was supposed to be addressed to. We have always been able to find the addressee from the context of the message in the df* file, and eventually the host name shows up in the xfAA<PID> file where some hand shaking between the two machines is recorded. Nothing is ever entered into the syslog file. The worst of the problem is that the df* file just receives about the first five lines of the message, with the next line repeated millions of times until the file system is full. As if this wasn't bad enough, a few minutes later it will start up another process for the same message, with a new sendmail process and a new giant dfAA<PID> file. The file grows at about 100K/minute, so things get pretty bad in a hurry. Even if you see what is happening before the file system fills and other mail is rejected, twenty minutes later the VAX wakes up and sends it again. [Perhaps it is fortunate that Karl's machine is connected to a slow 9.6Kbps line or that growth rate would be even more dramatic!] This has gone on for days when it starts on a week-end. I presently have a shell script that watches for this to happen, and when the file gets larger than 100K, the process is killed and the files deleted. For the moment, I am considering it to be a problem with the new installations. They all seem to be VAX/VMS hosts running Wollongong software and connecting to DDN with X.25 protocol. Since one of these is Nuclear Effects [a local host, NEL.ARPA, in Karl's organization], we have someone nearby with considerable interest in solving the problem. Very short messages are not a problem, but they have to be less than 1000 bytes. The people at Nuclear Effects have also discovered that they can not FTP large files from NEL.ARPA to MISER.ARPA. The other way works fine. They assume that this is just another manifestation of the same problem, but this doesn't cause any trouble for MISER when they try. It seems to just sit there and do nothing until the job is killed. The other two hosts that we have had trouble with are AFOTEC.ARPA (26.1.0.87) and DPG-MT.ARPA (26.8.0.120). If you have any ideas, both I and Dave Watson (dwatson@MISER.ARPA), the NEL.ARPA system administrator, would be glad to hear from you. Karl PS: Overnight we had a similar problem caused by a message from AMC-4.ARPA, which is apparently a PYRAMID-90X running UNIX.
-----------[000052][next][prev][last][first]---------------------------------------------------- Date: Mon, 8-Jun-87 00:28:15 EDT From: hedrick@TOPAZ.RUTGERS.EDU.UUCP To: comp.protocols.tcp-ip Subject: Re: Strange problems with VAX/VMS DDN X.25 hosts
The 4.2 version of sendmail has some places where it should check for the connection being closed and does not. This can put it into infinite loops. We have also seen the situation where it writes a file while into this loop. As far as I know, the 4.3 version of sendmail does not have this problem. It is available from Berkeley by anonymous ftp, because it is part of the MX update. It will work under 4.2.
-----------[000053][next][prev][last][first]---------------------------------------------------- Date: Tue, 9-Jun-87 06:44:51 EDT From: geoff@eagle_snax.UUCP ( R.H. coast near the top) To: comp.protocols.tcp-ip Subject: Automatic IP address assignment
Does anyone have any experience with either on-the-fly IP
address assignment or automated IP host installation?
Since we started shipping PC-NFS, several people have
expressed concern about using PCs as IP nodes and have asked if there
was any standard way of automating IP address assignment,
either per-session or once-only at first connection. Now
I know that there's nothing in the RFCs, but I seem to remember
some talk at the December '85 PC/IP - MAC/IP Workshop at the
Univ. of Maryland. Can anyone help jog my memory?
--
"You want a disclaimer form? Next window, please..."
Geoff Arnold, Sun Microsystems East Coast Division (home of PC-NFS)
UUCP: {ihnp4,decwrl,...}!sun!garnold ARPA: garnold@sun.com
-----------[000054][next][prev][last][first]---------------------------------------------------- Date: Tue, 9-Jun-87 06:49:00 EDT From: CERF@A.ISI.EDU To: comp.protocols.tcp-ip Subject: Re: A fuzzy proposal
I'm with Dave on zeroes - the syntax should be explicit about intended "don't cares" as in logic design (0, 1, X). Vint
-----------[000055][next][prev][last][first]---------------------------------------------------- Date: Tue, 9-Jun-87 12:17:09 EDT From: jis@BITSY.MIT.EDU (Jeffrey I. Schiller) To: comp.protocols.tcp-ip Subject: Re: Automatic IP address assignment
I have been working on and off on a protocol to assign IP addresses on the fly. The idea being based on a combination of ARP and an RARP mechanism. I am putting together a document that I will submit as an RFC after I have done some coding and made sure it is a "sane" approach. It is a "configurationless" protocol. Ie. you don't preassign an IP address to some Ethernet address in advance of first use. Instead the first time a new machine (actually new ethernet address) shows up on the network it is assigned a semi-permanent IP address WHICH IT HAS TO DEFEND by responding to ARPS for its address. The biggest problem with using it on PCs is that (at least with PC/IP) when a PC isn't using a network application, it is deaf to the network. Is this still true with PC-NFS, or is the network software always active? Ifso then this protocol might work for you. I actually have a draft of this document but have been hesitant to give it much distribution until I test it. However if there is sufficient interest I can make it available (provided people respect its draft status). -Jeff
-----------[000056][next][prev][last][first]---------------------------------------------------- Date: 9 Jun 1987 16:21-PDT From: Steve Deering <deering@pescadero.stanford.edu> To: Jeffrey I. Schiller <jis@BITSY.MIT.EDU> Cc: tcp-ip@sri-nic.ARPA Subject: Re: Automatic IP address assignment
The other problem with "defended addresses", besides the issue of PCs not always running their networking software, is that the owner of an address may not hear a challenge if the network is partitioned. A local-area network can be partitioned by failure of a MAC-level bridge, temporary disconnection of a host-to-network cable, etc. Steve Deering
-----------[000057][next][prev][last][first]---------------------------------------------------- Date: Tue, 9-Jun-87 14:48:34 EDT From: Mills@UDEL.EDU To: comp.protocols.tcp-ip Subject: Re: Automatic IP address assignment
Geoff, See RFC-891, which among other things describes the scheme used by the so-called fuzzballs. The idea is that a newcomer squawks his IP address in a hello packet and then the local-net routing algorithm bumps and grinds to match. The scheme allows virtual hosts to pop up anywhere touched by the algorithm, even if a different network. The scheme is used for many permanently attached hosts, as well as dial-up hosts. Dave
-----------[000058][next][prev][last][first]---------------------------------------------------- Date: Tue, 9-Jun-87 14:54:00 EDT From: CERF@A.ISI.EDU To: comp.protocols.tcp-ip Subject: Re: Automatic IP address assignment
This sounds like the IP equivalent of NETBIOS which suffers from the need for the acquirer of a (name) (IP address) to DEFEND it whenever someone else tries to take that (name) (address). Maybe an improvement would be to have a server which does the assignment? A bit like a name server... Vint
-----------[000059][next][prev][last][first]---------------------------------------------------- Date: Tue, 9-Jun-87 17:30:39 EDT From: jis@BITSY.MIT.EDU (Jeffrey I. Schiller) To: comp.protocols.tcp-ip Subject: Re: Automatic IP address assignment
My approach is hybrid. The idea is that one host (in our environment the gateway that connects the Ethernet to the rest of the world) would maintain a RARP table. A booting machine will transmit an Ethernet level broadcast requesting information about the configuration of the Ethernet. This information serving host would respond immediately with necessary info (network number, subnet mask, range of assignable addresses etc.) and iff it has a RARP entry, the IP address to use. Other hosts would respond after a random delay, but without the IP address to use (in the event the information server is down). If this doesn't get it an address to use, it chooses one in the allowed range based on some hashing (algorithm yet to be designed) function. The information server would then note this address (which it would learn from ARPs) and remember it. However because the information server might fail, it is necessary that before attempting to use an IP address, that you ARP to see if it is in use, and yes you must respond to ARPs in order to DEFEND your address (sigh...). The design goal is for a reliable (no single point of failure), maintenance free system which tends to keep a given IP address with a given host, but doesn't guarantee this. Ie. the rate at which a given machine gets assigned a different address is minimized (so if it was registering its address with a nameserver, the update traffic would be reduced). -Jeff
-----------[000060][next][prev][last][first]---------------------------------------------------- Date: Tue, 9-Jun-87 18:16:57 EDT From: jis@BITSY.MIT.EDU (Jeffrey I. Schiller) To: comp.protocols.tcp-ip Subject: Re: Automatic IP address assignment.
I have placed a *DRAFT* copy of this document in /pub/dyn.doc on BITSY.MIT.EDU (18.72.0.3) feel free to pick up a copy. -Jeff
-----------[000061][next][prev][last][first]---------------------------------------------------- Date: Tue, 9-Jun-87 19:21:00 EDT From: deering@PESCADERO.STANFORD.EDU (Steve Deering) To: comp.protocols.tcp-ip Subject: Re: Automatic IP address assignment
The other problem with "defended addresses", besides the issue of PCs not always running their networking software, is that the owner of an address may not hear a challenge if the network is partitioned. A local-area network can be partitioned by failure of a MAC-level bridge, temporary disconnection of a host-to-network cable, etc. Steve Deering
-----------[000062][next][prev][last][first]---------------------------------------------------- Date: Wed, 10-Jun-87 05:19:52 EDT From: csg@pyramid.UUCP To: news.groups,comp.protocols.misc,comp.dcom.lans,comp.mail.misc,comp.protocols.tcp-ip Subject: Newgroup Proposal: comp.protocols.iso
The group comp.protocols.iso seems to be trickling around the net. There have been running discussions on ISO in at least three groups (comp.protocols.misc, comp.mail.misc, comp.dcom.lans). Generally the contributions have been of very high quality. Seems like about time to make comp.protocols.iso a formal group. The charter would be: comp.protocols.iso Discussion of ISO, MAP, TOP, and CCITT protocols This would include the whole stack: X.25, X.213, X.214, X.215, X.400, and all the appropriate ISO and MAP permutations. Discussions on DARPA/ISO gateways could be cross-posted to comp.protocols.tcp-ip. I suspect that the group would be especially interesting to European sites. I see no reason to make the group moderated. Send comments to me, both pro and con. I am not interested in "votes" per se, since they are not very meaningful. I want to know what people are thinking: why or why not this should become a regular "comp" group, and whether or not it would be helpful to you in your work. I'll summarize on the net and to the backbone site admins. <csg>
-----------[000063][next][prev][last][first]---------------------------------------------------- Date: Wed, 10-Jun-87 09:50:50 EDT From: woody@MACOM3.ARPA (robert a woodburn) To: comp.protocols.tcp-ip Subject: FUWO (For Unix Wizards Only)...
We're working on an experimental protocol and in the course
of prototype development, decided we needed to add a few
protocol numbers to the kernel configurations to do our work.
The strange part is that we had already successfully added one
protocol previously. Trying to add just one more seems to break
our kernel. The kernel works, but is flaky with the following symptoms:
>[woody@macom3|/usr/macserver/woody]<*> uptime
> 9:28am up 6369 days, 12:14, 1 user, load average: 0.00, 7168355.43, 7156480.00
>[woody@macom3|/usr/macserver/woody]<*> ps
> PID TT STAT TIME COMMAND
>ps: error reading proc table from /dev/kmem
>[woody@macom3|/usr/macserver/woody]<*> ps -uax
>ps: error reading text table from /dev/kmem
>[woody@macom3|/usr/macserver/woody]<*>
So as you can see the process table seems corrupt, or at least
applications trying to access kernel memory are confused for
some reason. The following lines were added to "/usr/sys/netinet/in.h"
#define IPPROTO_DGP 9 /* dgp */
#define IPPROTO_DGP1 8 /* dgp */
(Yes, I know, 8 is the number for EGP, but we're not running EGP,
so its ok)
and these lines were added to "/usr/sys/netinet/in_proto.c" to the
inetsw structure:
{ SOCK_RAW, PF_INET, IPPROTO_DGP, PR_ATOMIC|PR_ADDR,
rip_input, rip_output, 0, 0,
raw_usrreq,
0, 0, 0, 0,
},
{ SOCK_RAW, PF_INET, IPPROTO_DGP1, PR_ATOMIC|PR_ADDR,
rip_input, rip_output, 0, 0,
raw_usrreq,
0, 0, 0, 0,
},
Now, just adding one record is fine, but adding two causes the minor
brain damage described above. We only have a total of ten protocols
in use total. After making these changes, all that I do is run
/etc/config, and then make the kernel, and thats it, and it doesn't work.
If anyone out there has had this problem and found a solution, or even
if you haven't found a solutions, please send me mail.
THANKS!!!!
wood y
-----------[000064][next][prev][last][first]---------------------------------------------------- Date: Wed, 10-Jun-87 14:34:40 EDT From: woody@MACOM3.ARPA (robert a woodburn) To: comp.protocols.tcp-ip Subject: FUWO solution
Thanks to Jim Berets whose suggestion led me to the solution to my kernel troubles. wood y
-----------[000065][next][prev][last][first]---------------------------------------------------- Date: Wed, 10 Jun 87 16:13:19 EDT From: robert a woodburn <woody@MACOM3> To: tcp-ip@sri-nic.ARPA Subject: FUWO, the real story....
It turns out that, as do many UNIX problems, that my kernel "bug" had nothing whatsoever to do with compiling or configuring the kernel. I did everything right, I just hadn't put the executable in the appropriate place. Our configuration at M/A-COM consists of a server and three clients. The three diskless clients boot via tftpboot which loads them up with vmunix. However, they do NOT boot up with the vmunix located in the root partition, but rather are configured to boot from a common file in the public partition (I still haven't found where that is configured, but anyway...) I had done the following on the client I was testing the kernel on: mv /vmunix /vmunix.old which is just a pointer to the common file in /pub Now, I copied in the new kernel to /vmunix and rebooted. What I didn't know is that the client was still booting from /pub/vmunix since the boot process ignores the clients actual copy of vmunix. Anyway, to make a long story short, anytime I needed to look at the vmunix executable (ps, uptime, etc) I was using the offsets specified in the new kernel, but was still running the old. It just wasn't real obvious, since I didn't setup the server and client configuration to begin with. Now, before I get the hook for being long winded about a subject that has absolutely nil to do with tcp-ip... g'day... Thanks again to those who quickly jumped to my aid.
-----------[000066][next][prev][last][first]---------------------------------------------------- Date: Wed, 10-Jun-87 16:19:39 EDT From: woody@MACOM3.ARPA (robert a woodburn) To: comp.protocols.tcp-ip Subject: FUWO, the real story...
It turns out that, as do many UNIX problems, that my kernel "bug" had
nothing whatsoever to do with compiling or configuring the kernel. I
did everything right, I just hadn't put the executable in the appropriate
place. Our configuration at M/A-COM consists of a server and three
clients. The three diskless clients boot via tftpboot which loads them
up with vmunix. However, they do NOT boot up with the vmunix located in
the root partition, but rather are configured to boot from a common file
in the public partition (I still haven't found what file sets that
configuration, but anyway...) I had done the following on the client I was
testing the kernel on:
mv /vmunix /vmunix.old
which is just a pointer to the common file in /pub
Now, I copied in the new kernel to /vmunix and rebooted.
What I didn't know is that the client was still booting from /pub/vmunix
since the boot process ignores the clients actual copy of vmunix.
Anyway, to make a long story short, anytime I needed to look at the
vmunix executable (ps, uptime, etc) I was using the offsets specified
in the new kernel, but was still running the old. It just wasn't real
obvious, since I didn't setup the server and client configuration to
begin with. Now, before I get the hook for being long winded about a
subject that has absolutely nil to do with tcp-ip... g'day...
Thanks again to those who quickly jumped
to my aid.
-----------[000067][next][prev][last][first]---------------------------------------------------- Date: Wed, 10-Jun-87 17:56:33 EDT From: ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins) To: comp.protocols.tcp-ip Subject: Re: Automatic IP address assignment
We've had a great deal of success using Bill Croft's BOOTP (RFC 951). As currently implemented, a network node's IP address is permanently assigned to a particular ethernet address and put in a configuration file read by the bootp server. Address assignment is done once when the machine is booted, via a UDP broadcast. We've extended the protocol to also announce the subnet mask and default gateway along with a number of server addresses. There is really no reason why the BOOTP server could not be extended to dynamically create new addresses for unknown ethernet addresses. A scheme similiar to Jeff's could be used to defend them afterwards, or the server could try to maintain some sort of database. Dynamic address assignment is also done for Macintoshes. I'm not quite sure how it works (I'm sure someone else can fill in the details), but the Kinetics gateways are given a range of addresses which they dynamically assign to new Appletalk nodes. I think it uses NBP to request an address and later defend it. Drew
-----------[000068][next][prev][last][first]---------------------------------------------------- Date: Wed, 10-Jun-87 22:37:31 EDT From: geoff@eagle_snax.UUCP To: comp.protocols.tcp-ip Subject: Re: Automatic IP address assignment (long)
Thank you to all to replied on this subject. Most copied their
comments to "tcp-ip@SRI-NIC.ARPA"; let me quote a couple,
for selfish reasons (see below):
>From: Jeffrey I. Schiller <decvax!ucbvax!BITSY.MIT.EDU!jis>
>
> I have been working on and off on a protocol to assign IP
>addresses on the fly. The idea being based on a combination of ARP and
>an RARP mechanism. I am putting together a document that I will
>submit as an RFC after I have done some coding and made sure it is a
>"sane" approach.
>
[...I'll let Jeff speak for himself...]
>
>I have placed a *DRAFT* copy of this document in /pub/dyn.doc
>on BITSY.MIT.EDU (18.72.0.3) feel free to pick up a copy.
>
> -Jeff
-----------------------------------------------------------------------
>
>From: Raman Khanna <decvax!ucbvax!argus.stanford.edu!khanna>
>
>We were using RARP for this purpose - RARP server had a static ethernet
>address to IP address translation table and PCs were assigned IP address
>on connection. Problem with RARP was that it did not propagate through
>our routers and, therefore, we had to use a RARP server per subnet.
>
>Recently we made a switch to Bootp that overcomes the problem stated
>above.
>
>raman khanna
>Stanford
-----------------------------------------------------------------------
>From: decvax!ucbvax!UDEL.EDU!Mills
>
>Geoff,
>
>See RFC-891, which among other things describes the scheme used by the
>so-called fuzzballs. The idea is that a newcomer squawks his IP address
>in a hello packet and then the local-net routing algorithm bumps and
>grinds to match. The scheme allows virtual hosts to pop up anywhere
>touched by the algorithm, even if a different network. The scheme is
>used for many permanently attached hosts, as well as dial-up hosts.
>
>Dave
-----------------------------------------------------------------------
>From: decvax!ucbvax!A.ISI.EDU!CERF
>
>This sounds like the IP equivalent of NETBIOS which suffers from the
>need for the acquirer of a (name) (IP address) to DEFEND it whenever
>someone else tries to take that (name) (address).
>
>Maybe an improvement would be to have a server which does the
>assignment? A bit like a name server...
>
>Vint
>
All of which suggests that the problem of on-the-fly IP address
assignment is in good hands. However, the once-only case didn't
get addressed, and I guess that's where my primary focus lies.
Most of those who replied were clearly concerned with sharing a
limited set of IP addresses among a large but transient population of
clients. This is clearly a major problem, particularly in Universities,
and I don't want to belittle the problem or the proposed solutions.
In contrast, I had been focussing on an ease-of-use question: how
best to help a network-naive user "plug'n'play" a system into a
network in which it will operate for some time. For good ergonomic
reasons it makes sense to focus on making the initial contact with a
system simple and relatively foolproof. If I can get this one right,
I am prepared to accept the overhead of human involvement in
resolving some types of situations which typically occur further up
the user's learning curve: for example, changing the Ethernet
controller (and thus the Ethernet address) of a system, or changing
its name. (For anyone who wonders about the extent of this passion
for ease-of-use, come over to Sun ECD and I'll show you the "pizza
movie".)
Although at first sight this problem may seem to be solvable using
the "resource-sharing" techniques described by others, I think there's
a fairly major difference. I believe that for many users the most
important attribute of the system the work with is consistency; once
a system has been installed they want it to work forever(!). The idea
that one day they power it up and it reports that it can't join the
network because all addresses are in use is alien - a network address
is like a phone number, right? [If IP addresses had no user
visibility this would be less painful, but.... well, just take a look
at the last line of Jeff's mail above.] Since I'm mainly concerned
with automating the process of making a (relatively) permanent
name-address binding rather than something more transient, many
issues (such as "address defense") are irrelevant.
Let me now describe the kind of model I was thinking of:
(1) The (client) system RARP's as usual. This is a new node, nobody
knows about it, so nobody replies.
(2) The client broadcasts an IARP (Initial Address Resolution Protocol)
request including its Ethernet address, a suggested hostname and
a descriptive string (see below).
(3) If there is an IARP server on the net, it can return any of the
following responses:
OK - This is the first time the node has been connected
to the net. An Internet address is assigned, the name is
registered, and the Ethernet-IP address mapping is
stored for RARP purposes. The client should start over
by RARPing for its IP address, etc.
OK-MOVED- the client's Ethernet address was already recorded in
the RARP tables with an IP address which mapped to the
required hostname, but the IP address corresponded to
another network (or subnet). The system assumes that the
client has been physically moved and connected to a
new net. The IARP server assigns a new IP address,
deassigns the old one, and updates all the maps.
DUPNAME - the hostname was in use, and there's either no Ethernet
address associated with the corresponding IP address OR
the Ethernet address is different from that of the client.
BADNAME - the client's Ethernet address was recorded in the RARP
tables, but the IP address was not on this network AND the
hostname was wrong. (Assumption: this node has already been
configured under a different name.)
NOADDR - the server was unable to assign an address; a message
may be provided to further explain the failure (e.g. site
policy, no addresses available)
(3) Subsequently the client RARPs, and can then use an inverse name
lookup to verify that it is who it thinks it is...
(Note that this requires a fix to most versions of RARP, which will
happily return an Internet address even if the network number does not
correspond to the network from which the request originated. I have
seen people's hair go gray overnight with this one.....)
The idea of passing over a string of descriptive information about the
client is that it may help an IARP server in setting up the environment
for the client. For example, if the string read "SUN 3/50 DISKLESS"
a suitable IARP server might construct the necessary network boot
files before replying. This is a slippery slope: imagine having
IARP servers from several competing vendors each of which knows how to
(and is prepared to) set up only its "family" clients.....
There are three obvious problem areas. First, and probably the least
serious, is one of implementation: for Unix we're probably looking at
one more chunk to hack into the kernel, since we're not using IP at
this point. (Raw sockets tend to have rather undesirable performance
side-effects unless some low-level filtering can be specified.)
Second, the IARP server may need some significant amount of time to
set up the environment before it can send an OK or OK-MOVED; to avoid
client time-outs the server may need to send some kind of keepalive
(e.g. a WORKING packet) to prevent the client from giving up. Thirdly
we must address the problem of how we cope with multiple IARP servers
on a single Ethernet. (Just another implementation detail.:-)
Finally I should emphasize that all of this represents my personal
thoughts on how we can get the guru out of the loop for the average
user of these systems, and doesn't reflect the policies, plans or
products of Sun Microsystems Inc.
--
"You want a disclaimer form? Next window, please..."
Geoff Arnold, Sun Microsystems East Coast Division (home of PC-NFS)
UUCP: {ihnp4,decwrl,...}!sun!garnold ARPA: garnold@sun.com
-----------[000069][next][prev][last][first]---------------------------------------------------- Date: 11 Jun 87 11:22:00 PST From: <art@acc.arpa> To: "tcp-ip" <tcp-ip@sri-nic.arpa> Subject: Looking for book
I'm trying to obtain a copy of "Data Networks" by Bertsekas and Gallager. This is a brand new text and none of my local bookstores seem to have it in stock or on order. I'd prefer not to wait the 5-6 weeks a special order would take. If anyone happens to know of a bookstore that has it (and will take a charge card purchase over the phone) I'd appreciate getting their phone number. I seem to remember hearing about a computer oriented bookstore in the Silicon Valley area that was highly recommended. Anyone have their number? Art@acc.arpa ------
-----------[000070][next][prev][last][first]---------------------------------------------------- Date: Thu, 11-Jun-87 11:52:48 EDT From: robert@SPAM.ISTC.SRI.COM.UUCP To: comp.protocols.tcp-ip Subject: Problems with TCP/IP sockets under 4.2.
I have encountered a problem with TCP sockets under Sun 3.2 OS, and I was
wondering if anyone on the list has encountered the same problem, or if
anyone knows what could be causing the problem.
I have an application which listens on TCP sockets, in the AF_INET family,
for connections from other processes. The listening socket is set to non-
blocking with ioctl() (FIONBIO) after the call to socket() (AF_INET,
SOCK_STREAM,0). After the ioctl, setsockopt() (SOL_SOCKET,SO_REUSEADDR)
is called, followed by bind(), followed by listen() with a backlog paramater
of 5.
When a connection is 'heard', accept is called, and the file-descriptor
returned from accept is used to establish a 'full' connection to the
client process. This file-descriptor too has an ioctl done to it
(non-blocking = FIONBIO), after which it is read from.
The problem is this; if the client process goes away abruptly, the server
socket does not know about it. Further, if a select() is called on the
(now supposedly 'dead') file-descriptor for reading, it will indicate
that there is data there. If the fd is read, 0 bytes are received;
no error condition is indicated by the recv. I have seen upto 600 repeated
select()'s and recv()'s without getting a -1 from recv.
My questions: 1. Is this a bug of 4.2BSD networking code (it has been a
'feature' of the Sun kernel since OS 2.2 or so), or 2. incorrect coding
on my part in establishing the socket, or 3. a result of the fact that
exceptfd is not implemented for select on 4.2BSD, or 4. my use of the
non-blocking socket?
Currently I close down the socket after 100 0-byte recv()'s, but I'd like
to have a better idea of why this is happening, and how it can be fixed.
Any clues will be gratefully accepted.
Robert Allen,
robert@spam.istc.sri.com
415-859-2143
-----------[000071][next][prev][last][first]---------------------------------------------------- Date: Thu, 11-Jun-87 14:01:35 EDT From: hassler@LOGNET2.ARPA.UUCP To: comp.protocols.tcp-ip Subject: Serial IP
Can anyone direct me to a source (preferably Public Domain) for a Serial Line IP? Thanks in Advance, Barry D. Hassler Control Data Corp Professional Services Division Integrated Information Services
-----------[000072][next][prev][last][first]---------------------------------------------------- Date: Thu, 11-Jun-87 14:28:21 EDT From: ward@cfa.harvard.EDU (Steve Ward) To: comp.protocols.tcp-ip Subject: Bridge/Excelan VMS/TCP-IP problem
Help needed from TCP/IP, Telnet protocol experts!!!!!!!!
I have Bridge terminal servers talking to DEC MicroVAXes running VMS with
Excelan TCP/IP protocol/Ethernet interface boards.
Here is my most serious problem: In order to run CAD/CAE graphics and other
applications, the Telnet session must be in binary mode. The Excelan board
defaults to 7-bit(ASCII) mode. The Excelan board is designed to expect the
remote client to request binary mode through some Telnet command/request
mechanism. The Bridge Terminal Servers can easily be tailored by a user
to operate in binary mode, but have no user or system method to be made to
request binary mode on the part of a host. This means there is no way for
the Excelan board to operate in binary mode when a Bridge terminal server
is used to interface the terminal or other remote client.
All that is needed is for the Excelan board to provide some host-based
method for configuring binary mode, or the Bridge terminal server must
implement some method for requesting binary mode from the host. NOW FOR
THE REAL PROBLEM:
Bridge says that they used to implement client request for host
binary mode, but it caused havoc with SUN workstations, so they
took out the command/request mechanism for host binary mode.
Bridge further stated that the protocol specs are somewhat
ambiguous on whether the client or host is responsible for requesting
or implementing methods to enter binary mode, but at this point they feel
the host is burdened with this function, though they admit they felt
the opposite was true at an earlier point in time. Bridge sympathizes
with my problem, but declines to do anything to fix it since their
position is that they are conforming to the TCP/IP/Telnet specs.
Excelan takes the same position, saying that per the specs it is clear
that the Bridge terminal servers must issue the appropriate request
for host binary mode, and their board will respond properly to the
request. Now it is clear that one of these two products is broken, but
which one??? Bridge and Excelan sympathize, but in essence are saying
"nothing wrong with us or our stuff, go away kid, don't bother me."
What is disturbing is that neither outfit is interested in researching
and resolving the problem. I would think that both companies would
be interested in helping clarify the situation, even perhaps indulging in
a three way conversation, but this interest was not shown.
I do not have RPC's or specs of any kind. What I ask is that you network
protocol wizards out there discuss this issue and let's see if their is a
concensus as to whether Bridge or Excelan has a broken product in this case.
If the specs turn out to be truly ambiguous, can we initiate a clarification
to eliminate the confusion?
Excelan, Bridge, are you listening? I would appreciate a higher
level of concern and support whether you think your product
is broken or not. This problem will cause malfunctions with most,
if not all graphics terminals connected to Bridge terminal servers talking
to the Excelan TCP/IP board. Are there other TCP/IP protocol boards out
there that assume that the terminal server or other client must request
binary mode? If so, then using the Bridge terminal server is not wise
since it won't request the binary mode. If the host must provide a
method for entering binary mode, then clearly the Excelan product is
broken and these problems could be encountered using the Excelan board
with any terminal server or other client. This should concern all
present and potential customers for these two product lines.
Bridge and Excelan, if you are listening, replies to myself or Roger
Hauck should be e-mailed to me at: {seismo|ihnp4}!harvard!cfa!ward
or ward@cfa.harvard.EDU (ARPA)
This topic should be of broad interest and concern, so replies to the
net are also appropriate, in my view.
Steven Ward, Harvard-Smithsonian Astrophysical Observatory
{seismo|ihnp4}!harvard!cfa!ward
-----------[000073][next][prev][last][first]---------------------------------------------------- Date: Thu, 11-Jun-87 15:22:00 EDT From: art@ACC.ARPA To: comp.protocols.tcp-ip Subject: Looking for book
I'm trying to obtain a copy of "Data Networks" by Bertsekas and Gallager. This is a brand new text and none of my local bookstores seem to have it in stock or on order. I'd prefer not to wait the 5-6 weeks a special order would take. If anyone happens to know of a bookstore that has it (and will take a charge card purchase over the phone) I'd appreciate getting their phone number. I seem to remember hearing about a computer oriented bookstore in the Silicon Valley area that was highly recommended. Anyone have their number? Art@acc.arpa ------
-----------[000074][next][prev][last][first]---------------------------------------------------- Date: Thu, 11-Jun-87 21:12:36 EDT From: LYNCH@A.ISI.EDU.UUCP To: comp.protocols.tcp-ip Subject: Re: Looking for book
Art, The computer bookstore you are probably referring to is the Computer Literacy Bookstore at Techmart in Santa Clara. I just called them and snagged the last one in stock (a hot mover?) and had it shipped to you. Should arrive MOnday or Tuesday. The pnone number, anyway, is 408-562-5799. That bookstore (actually a collection of three stores up here) does a great job of stocking stuff we all can use (from time to time). Cheers, Dan -------
-----------[000075][next][prev][last][first]---------------------------------------------------- Date: 11 Jun 1987 21:12:36 EDT From: Dan Lynch <LYNCH@A.ISI.EDU> To: <art@ACC.ARPA> Cc: "tcp-ip" <tcp-ip@SRI-NIC.ARPA>, LYNCH@A.ISI.EDU Subject: Re: Looking for book
Art, The computer bookstore you are probably referring to is the Computer Literacy Bookstore at Techmart in Santa Clara. I just called them and snagged the last one in stock (a hot mover?) and had it shipped to you. Should arrive MOnday or Tuesday. The pnone number, anyway, is 408-562-5799. That bookstore (actually a collection of three stores up here) does a great job of stocking stuff we all can use (from time to time). Cheers, Dan -------
-----------[000076][next][prev][last][first]---------------------------------------------------- Date: Thu, 11-Jun-87 21:25:29 EDT From: BUDDENBERGRA@A.ISI.EDU.UUCP To: comp.protocols.tcp-ip Subject: SAFENET LAN protocol
Folks on the net might be interested in a sitrep on our work with a survivable LAN for shipboard use... Start with an IEEE-802.5 (or ISO 8802/5) token ring. Add a second, contra-rotating ring for redundancy. If the first ring fails, traffic shifts to the second. If a double cut or loos of node occurs, each last surviving node wraps data from one ring to another and, voila, self-healing. As ring is damaged further, partitioning occurs (cut up a starfish, get multiple starfish), but it keeps on trucking. The SAFENET philosophy is to specify a superset of the 802.5 standard that gains the survivability necessary for operational tactical purposes on ships (to replace a number of point-to-point links). Objective is to eventually influence the industry standard adequately so that no separate MilStd is required. The initial objective of providing service to computers within the ship appears within reach fairly quickly. The goal is something quotable by October. Other problems are cropping up that, in my estimation, will be nowhere near a standards solution this fall. Leading is the inability of the ISO stack to provide 'real-time' service. Since most of the issues are at higher layers, they are beyond the scope of a group formed to work on a specific LAN. Ditto for network management and multi-level security. This week we worked over revision 0 which was a 'very first draft'. Three subcommittees got their components 1) down in writing and 2) all in the same manuscript for the first time, so things were a bit rough. But things seem to be moving along; I'll try and post another report after the next meeting in July. [All above is personal appraisal and opinion] Rex Buddenberg -------
-----------[000077][next][prev][last][first]---------------------------------------------------- Date: 11 Jun 1987 21:25:29 EDT From: Rex Buddenberg <BUDDENBERGRA@A.ISI.EDU> To: tcp-ip@SRI-NIC.ARPA Cc: BUDDENBERGRA@A.ISI.EDU Subject: SAFENET LAN protocol
Folks on the net might be interested in a sitrep on our work with a survivable LAN for shipboard use... Start with an IEEE-802.5 (or ISO 8802/5) token ring. Add a second, contra-rotating ring for redundancy. If the first ring fails, traffic shifts to the second. If a double cut or loos of node occurs, each last surviving node wraps data from one ring to another and, voila, self-healing. As ring is damaged further, partitioning occurs (cut up a starfish, get multiple starfish), but it keeps on trucking. The SAFENET philosophy is to specify a superset of the 802.5 standard that gains the survivability necessary for operational tactical purposes on ships (to replace a number of point-to-point links). Objective is to eventually influence the industry standard adequately so that no separate MilStd is required. The initial objective of providing service to computers within the ship appears within reach fairly quickly. The goal is something quotable by October. Other problems are cropping up that, in my estimation, will be nowhere near a standards solution this fall. Leading is the inability of the ISO stack to provide 'real-time' service. Since most of the issues are at higher layers, they are beyond the scope of a group formed to work on a specific LAN. Ditto for network management and multi-level security. This week we worked over revision 0 which was a 'very first draft'. Three subcommittees got their components 1) down in writing and 2) all in the same manuscript for the first time, so things were a bit rough. But things seem to be moving along; I'll try and post another report after the next meeting in July. [All above is personal appraisal and opinion] Rex Buddenberg -------
-----------[000078][next][prev][last][first]---------------------------------------------------- Date: Thu, 11-Jun-87 22:36:36 EDT From: ief@geocub.UUCP To: comp.protocols.tcp-ip Subject: NSC HyperchannelB - Ethernet TCP/IP gateway
In our lab, we have a TCP/IP Ethernet network and a Network System Corp. HyperchannelB network. Thus we are naturally leaded to imagine a gateway between them : this gateway seems a rather difficult problem. More precisely, people are interested in file transfer between their minicompiters and mainframes on Hyperchannel (IBM 3090 and Sperry 1100). Has anybody tried to have something work, or does anybody know of some experience elsewhere ? P.Garda
-----------[000079][next][prev][last][first]---------------------------------------------------- Date: Fri, 12-Jun-87 08:23:04 EDT From: mckenzie@J.BBN.COM.UUCP To: comp.protocols.tcp-ip Subject: Re: Bridge/Excelan VMS/TCP-IP problem
Steve, The Telnet protocol was specifically designed to be symmetric; EITHER party to a Telnet connection is permitted to suggest a shift to binary mode, although both parties must agree before the shift takes place. On the other hand, Telnet is a specification of the PROTOCOL which takes place between two systems; it is NOT a spec of the interface to the user of Telnet on either system. What you are asking for is provision, in the local interface, for one Telnet user (the terminal user on the Bridge box, or the program on the uVAX) to ask the local Telnet to suggest the use of b