|
|
ARCHIVE: TCP-IP Distribution List - Archives (1987)
DOCUMENT: TCP-IP Distribution List for August 1987 (275 messages, 141404 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1987/08.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.
START OF DOCUMENT
-----------[000000][next][prev][last][first]---------------------------------------------------- Date: Sat, 1-Aug-87 13:47:54 EDT From: bzs@BU-CS.BU.EDU (Barry Shein) To: comp.protocols.tcp-ip Subject: Wollongong TCP/IP for Sys V
From: Marty Schoffstall <schoff@nic.nyser.net> >PS: RPI told AT&T that we HAD to have tcp/ip and ethernet on > ours or we simply wouldn't use them, AT&T delivered > tcp/ip. From my discussions with others who took > donated equipment, stances like that were rare. Or fell on deaf ears (we waited 24 months for an ethernet board and finally just gave up.) -Barry Shein, Boston University Moderator, INFO-3B
-----------[000001][next][prev][last][first]---------------------------------------------------- Date: Sat, 1-Aug-87 15:23:39 EDT From: MRC@PANDA.COM (Mark Crispin) To: comp.protocols.tcp-ip Subject: Re: Telnet, <CR><LF>, etc.
Greg Minshall -
The last time I used a hardwired terminal connected to a Unix
system, I found that the RETURN key on the terminal's keyboard
would cause the Unix system to believe that it had received a
newline. While it is possible that the terminal had been modified
so that the RETURN key sent a linefeed, there was a separate LINE
FEED key. I forget whether or not I tried using the LINE FEED key
as an alternative newline.
What your Telnet implement has, in effect, done is eliminate
transparency. Most implementors of Telnet programs across the
network have been very careful to make sure that transparency is
preserved, since the ARPANET was traditionally a heterogenous
network. Now, it may be true that today's Internet is a mostly
homogenous Unix network, but there are still some non-Unix boxes
out there.
I cannot help but get the impression from the tone of your
message that you have no real justification for your implementation's
behavior other than a possible interpretation of admittedly ambiguous
standards. You haven't offered any operational explanation as to
why your implementation must behave in the way it does. Is there
something particularly special about 4.3 that demands this behavior
that other versions of Unix did not have?
Please don't get me wrong; I have been a frequent critic of
the explanations in the Telnet standards as they are presently
reflected in the RFC's. I have periodically pontificated about
various finer operational details that are glossed over in the
standards or are inadequately explained; during a recent TCP/IP
conference I had a presentation on these details (I'm also
supposed to write an article about this for Connexions...).
We're not out to criticize you or make your life difficult.
Your mistake is only one of many that have come up in various
Telnet implementations over the years. Please accept our
judgement not as a criticism of your basically fine work, but
rather as a source of information on what you must do to get
your implementation interoperating correctly with the rest of
the network. We all have a shared interest in maximizing
interoperability, and the folklore we have developed over the
years is based on long, hard experience and much compromise.
Thank you.
-- Mark --
-------
-----------[000002][next][prev][last][first]---------------------------------------------------- Date: Sat, 1-Aug-87 21:40:00 EDT From: richards@uiucdcsb.cs.uiuc.edu To: comp.protocols.tcp-ip Subject: Re: telnet CR processing, bridge comm s
Be careful here...
We, too, got the 13000 software to fix that problem, and another, insidious
bug popped up. Enabling "NetAscii" on ports caused those ports to send a
non-printable ASCII character (I think Ctrl-A) at various times out the
serial port of telnet sessions. I believe they corresponded to times when
a packet arrived with the tcp "PUSH" option set.
Run a telnet session on the CS/1 with a terminal that can be set to display
the entire ascii character set, and run VI. See if you get some unwanted
characters inserted at random places. We observed it when it started appearing
inside escape sequences (e.g. ESC-Y-Row-Col types of character sequences would
become something like ESC-Y-CTRLA-Row-Col, with obviously wrong results).
I called this in to Bridge a few months ago, but aside from verifying that
they observed the behaviour, havn't heard anything about a fix yet.
Paul Richards University of Illinois at Urbana-Champaign, Dept of Comp Sci
UUCP: {pur-ee,convex,inhp4}!uiucdcs!richards
ARPA: richards@b.cs.uiuc.edu
-----------[000003][next][prev][last][first]---------------------------------------------------- Date: Sat, 1-Aug-87 23:46:02 EDT From: mar@ATHENA.MIT.EDU To: comp.protocols.tcp-ip Subject: adversity or perversity
Multiple network numbers on a single wire can work if you are careful. Proteon gateways will support this, as will 4.3BSD acting as a gateway. What you really have to watch out for are broadcast packets. But if you don't run the rwhod or routed, it is unlikely that there will be any IP broadcasts on your net. -Mark
-----------[000004][next][prev][last][first]---------------------------------------------------- Date: Sun, 2-Aug-87 06:22:05 EDT From: HANK@BARILVM.BITNET (Henry Nussbacher) To: comp.protocols.tcp-ip Subject: Mitek MVS solutions?
I have been looking into various solutions for MVS systems. I have looked at Fibronics KNET, Network Solutions DDN/MVS and have recently been talking to ACC and their ACCES/MVS. Just now I found a new company called Mitek that does not appear in the Vendors Guide. They have two boxes - M2130 which talks to a 37xx (SDLC) and an M2030 that talks directly to a channel. The other side of the connection is an Ethernet. They have 2 models of the M2130 - low speed (RS232) and hi speed (V.35). On the software side, they have an SNA Kernel, Ethernet Tcp/Ip software and the M2x30 Supervisor. They claim to support Telnet and FTP. No doc on ARP, SMTP, ICMP, etc. I'd like to hear from people who are using Mitek for connecting an MVS to Ethernet. Does their stuff work? Thanks, Hank
-----------[000005][next][prev][last][first]---------------------------------------------------- Date: Sun, 02 Aug 87 13:22:05 P From: Henry Nussbacher <HANK%BARILVM.BITNET@wiscvm.wisc.edu> To: IBM mainframes and networking conference <Ibm-Nets@Bitnic> Cc: tcp-ip@sri-nic.ARPA Subject: Mitek MVS solutions?
I have been looking into various solutions for MVS systems. I have looked at Fibronics KNET, Network Solutions DDN/MVS and have recently been talking to ACC and their ACCES/MVS. Just now I found a new company called Mitek that does not appear in the Vendors Guide. They have two boxes - M2130 which talks to a 37xx (SDLC) and an M2030 that talks directly to a channel. The other side of the connection is an Ethernet. They have 2 models of the M2130 - low speed (RS232) and hi speed (V.35). On the software side, they have an SNA Kernel, Ethernet Tcp/Ip software and the M2x30 Supervisor. They claim to support Telnet and FTP. No doc on ARP, SMTP, ICMP, etc. I'd like to hear from people who are using Mitek for connecting an MVS to Ethernet. Does their stuff work? Thanks, Hank
-----------[000006][next][prev][last][first]---------------------------------------------------- Date: Sun, 2-Aug-87 22:22:14 EDT From: hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick) To: comp.protocols.tcp-ip Subject: Re: How do you break up a B class number?
There is a compromise possible on the variable net mask issue. Many implementations of IP allow for more than one subnet on a given Ethernet. So you could pick a single mask that led to smallish network sizes, and then for a few networks with lots of hosts, simply use more than one subnet number for tmemq
-----------[000007][next][prev][last][first]---------------------------------------------------- Date: Sun, 2-Aug-87 22:31:14 EDT From: hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick) To: comp.protocols.tcp-ip Subject: Re: How do you break up a B class number?
We currently use multiple subnet numbers for two cases: a system of Ethernets connected by bridges, and a single Ethernet that has 3 different groups on it that expect to move to different Ethernets shortly. Our gateways are from Cisco. Unix can be set up to know that several different networks are on the same cable. Add the extra subnets by using route add ..subnet.. ..local host address.. 0 The Cisco gateways have a similar ability. The only problem we have is that I don't like putting route commands in all the startup files for the individual machines. At the moment we are using route add default ..local host address.. 0 and depending upon the Cisco gateways to do proxy ARP. (For non-Unix hosts, we just don't tell them about subnetting, which gives the same effect.) Thus we don't have to make any changes on our hosts. But this is not my favorite way of doing routing. I'd rather be able to have a default route to a gateway, and have a form of ICMP redirect that says "do it yourself, dummy" for hosts that are on the same Ethernet but have different network numbers. But if you are willing to access proxy ARP, there doesn't seem to be any problem with using multiple subnet numbers on one network.
-----------[000008][next][prev][last][first]---------------------------------------------------- Date: Sun, 2-Aug-87 22:37:31 EDT From: hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick) To: comp.protocols.tcp-ip Subject: Re: Streams TCP/IP
Does it bother anyone else that streams doesn't seem to make provisions for multi-processor implementations? With BSD, you can hack the kernel all you like to allow for multiple processors. As long as your sockets behave the same to the user, he doesn't care. But with streams, users are supposed to be able to write portable code to do protocols. Clearly that level of code is going to need to do synchronization on multi-processor machines. As far as I can tell, the only reason multi-processor implementations are going to be able to pass the validation tests is because the validation tests don't do anything non-trivial. If they included something like a portable TCP/IP, then it would not be possible to run them unmodified on a multi-processor system. Since most non-workstation Unix systems these days are multi-processor, this is of some practical concern. What are implementors doing about this?
-----------[000009][next][prev][last][first]---------------------------------------------------- Date: Mon, 3-Aug-87 09:20:00 EDT From: DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer) To: comp.protocols.tcp-ip Subject: Re: IBM TCP.
Date: 31 Jul 87 16:30:00 GMT
From: uxc.cso.uiuc.edu!sandrock@a.cs.uiuc.edu
DECnet uses the node address to set the least significant 16 bits of the
48-bit Ethernet hardware address while setting the most significant 32
bits to a "known" constant value. Specifically, the Ethernet address
will be AA-00-04-00-xx-xx, where the xx-xx fields are the DECnet node
address (area-number * 1024) + node-number.
There may be both certain advantages and also disadvantages to this
approach, but is it true that these addresses are not globally unique?
Mark Sandrock, (sandrock@uxc.cso.uiuc.edu)
The DECnet scheme "only" allows 64K hosts, or probably more precisly,
only 64 areas. I would be quite surprised if there are only 64
installations of DECnet in the world. Therefore, if we assume that
people conventionally number node within an area starting with 1, then
there is likely a global non-uniqueness between machines of two
installations that have the same area number. I have no idea how DECnet
area numbers are assigned.
The major disadvantage is that if ACME Computers (read: some other
vendor) also used an algorithmic approach, it would be impossible, 100%
impossible, for a machine to be able to support both protocols at once
on one transciever, since it would require the transceiver to have two
Ethernet addresses. Such multi-protocol machines do exist. Luckily,
there is only one vendor that I know of (DEC) that uses an algorithmic
Ethernet address. I'm pretty sure DEC knew about ARP in time; I'd have
to get some ancient mail files off of tape to make sure.
-----------[000010][next][prev][last][first]---------------------------------------------------- Date: Mon, 3-Aug-87 10:56:53 EDT From: YAKOV@IBM.COM (Jacob Rekhter) To: comp.protocols.tcp-ip Subject: TCP/IP on IBM Token Ring and Source Routing
I am the person who introduced source routing into TCP/IP code for AIX on IBM Token Ring. Note, that both PC and VM implementations were based on AIX code and therefore can interoperate with each other. First of all Source Routing which is implemented on AIX has nothing to do with IP source routing (IP source routing is part of IP header, while Token Ring Source Routing is part of MAC (Medium Access Control) header). Originally I though of ignoring MAC Source Routing completely. However, since IBM Token Ring has support for MAC layer Bridges and since AIX requirement was to support both TCP/IP and SNA over the token ring, I introduced MAC Source Routing. MAC Source Routing is implemented as a part of ARP. ARP cache is extended to include both hardware address and routing information (if present). Initial ARP broadcast is done either to all rings/all stations or to local ring/all stations (this is a configurable parameter). Notice, that both VM and PC doing broadcast to all ring/all stations. I made this option in order to decrease the number of broadcasts when multiple rings are connected via both MAC layer bridges (used for SNA) and by real IP routers (used by TCP). I asked J. Postel whether it would be feasable to (1) include MAC layer routing information into ARP reply (2) assign separate ARP hardware type for 802.5. The answer to both were "no". I would suggest, that other implementations which do not want to support MAC layer Source Routing should accept ARP requests with RCF (Route Control Field), but should indicate in reply that MAC Routing Information is not present (just turn off bit 0 of byte 0 of your source hardware address in MAC header in ARP reply). I would appreciate any comments/suggestions. Jacob Rekhter (YAKOV@IBM.COM)
-----------[000011][next][prev][last][first]----------------------------------------------------
Date: Mon, 3-Aug-87 12:23:00 EDT
From: Ata@RADC-MULTICS.ARPA ("John G. Ata")
To: comp.protocols.tcp-ip
Subject: Re: Telnet, <CR><LF>, etc.
Greg,
I have to disagree with your TELNET sending a <CR><NL> if the
user types a <CR> with local echoing and sending a <CR><NUL> if remote
echoing takes place. While this may be useful in some UNIX
applications, who expect this convention, it certainly confuses some of
us non-UNIX hosts out there trying to talk to you. For example, we use
remote echoing to supress the local echo of a password. Thus, when a
user types her password, remote echoing takes place and the <CR> typed
at the end of the password gets sent as a <CR><NUL>. This gets
interpreted at our end as a <CR> which is NOT our end-of-line character.
Of course, this causes a hang which can be very frustrating. Please, do
not confuse local/remote echoing with some sort of private mode where
TELNET ASCII characters get interpreted differently. I realize that
this may be convenient for you, but it makes talking to different
machines on the network, much more difficult.
John G. Ata
-----------[000012][next][prev][last][first]---------------------------------------------------- Date: Mon, 3-Aug-87 13:50:33 EDT From: fedor@DEVVAX.TN.CORNELL.EDU (Mark Fedor) To: comp.protocols.tcp-ip Subject: Re: Wollongon TCP/IP for AT&T 3B2
Yeah, I run the same wollengong software on my 3b2/300 and the 513/udp port is the rwhod. I have a gateway (Proteon p4200) that picks these up all the time (since they are a broadcast) and reports "no server port 513" or some such and throws it away. Kill the rwhod if you don't want the port 513 annoyance. BTW, port 513/tcp is the rlogin port. Mark Also, my sendmail accepts "."'s I believe..... I have noticed that the wollongong telnet sometimes has difficulty establishing a connection with other telnet daemons. Have you? Also, the routed program doesn't seem to work, but early versions of routed never worked anyways..... :^) This tcp/ip software really makes the 3b2 halfway useable!
-----------[000013][next][prev][last][first]---------------------------------------------------- Date: Mon, 3-Aug-87 14:03:27 EDT From: pdg@ihdev.ATT.COM (Joe Isuzu) To: comp.protocols.tcp-ip Subject: Re: Streams TCP/IP
In article <8707311655.AA20489@topaz.rutgers.edu> ron@TOPAZ.RUTGERS.EDU (Ron Natalie) writes: >Is streams in the SVID? Really? Well DAMN ship back this AT&T SVR3 >release because streams ain't in it. Actually, streams is (are?) an extension in SVID (SVID is a broken into base and extension requirements). TLI is the same way. -- Paul Guthrie "Another day, another Jaguar" ihnp4!ihdev!pdg -- Pat Sajak
-----------[000014][next][prev][last][first]---------------------------------------------------- Date: Mon, 3-Aug-87 14:17:07 EDT From: gwl@rruxa.UUCP (George W. Leach) To: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Streams TCP/IP
In article <24336@sun.uucp>, guy@gorodish.UUCP writes:
>
> The concept is the same in Dennis Ritchie's version and in the S5R3
> version, but some of the details are different. I believe the S5R3
> version is bigger and more complicated.
>
I beleive that I have seen a socket interface built on top of
streams in 8th Edition UNIX. Has anyone else? Also, has anyone noticed
if the interface to stream i/o has changed between the 8th Edition and
System V implementations?
George W. Leach
Bell Communications Research New Jersey Institute of Technology
444 Hoes Lane 4A-1129 Computer & Information Sciences Dept.
Piscataway, New Jersey 08854 Newark, New Jersey 07102
(201) 699-8639
UUCP: ..!bellcore!indra!reggie
ARPA: reggie%njit-eies.MAILNET@MIT-MULTICS.ARPA
From there to here, from here to there, funny things are everywhere
Dr. Seuss "One fish two fish red fish blue fish"
-----------[000015][next][prev][last][first]---------------------------------------------------- Date: Mon, 3-Aug-87 14:35:58 EDT From: haas%gr@CS.UTAH.EDU (Walt Haas) To: comp.protocols.tcp-ip Subject: Re: IBM TCP.
In article <171500006@uxc.cso.uiuc.edu>, sandrock@uxc.cso.uiuc.edu writes:
> DECnet uses the node address to set the least significant 16 bits of the
> 48-bit Ethernet hardware address while setting the most significant 32
> bits to a "known" constant value. Specifically, the Ethernet address
> will be AA-00-04-00-xx-xx, where the xx-xx fields are the DECnet node
> address (area-number * 1024) + node-number.
> There may be both certain advantages and also disadvantages to this
> approach, but is it true that these addresses are not globally unique?
>
> Mark Sandrock, (sandrock@uxc.cso.uiuc.edu)
Not globally unique by a long shot - there can be only 65534 DECnet addresses
by this number system.
However there is an even more embarrassing problem with this arrangement-
(and this problem also occurs with XNS which does the same thing).
Suppose you have a DECnet (XNS) host which is connected to two Ethernets.
Now each DECnet (XNS) node is allowed only a single DECnet (XNS) address,
which the software loads into [all of] the Ethernet interface[s] attached
to the node. This means that the node has the same 48-bit Ethernet
address on both Ethernets. OK, now what happens when you attach a
learning Ethernet bridge, such as the DEC LANbridge 100 or any of the
numerous competitors between the same pair of Ethernets? Well, what
happens is that when the node sends a packet on one Ethernet, the bridge
learns the node is on that net, and starts routing all packets with
that destination to the net where it saw the node's address. Then the
same node sends a packet on the other net, using the same Ethernet
source address, and the bridge says "whoops, that node just moved"
and commences to route all packets for the node across to the other
Ethernet!
----------------*
Cheers -- Walt ARPA: haas@cs.utah.edu uucp: ...utah-cs!haas
"...The unforgivable but by no means uncommited sin in this connection occurs
when, A calling down that his rope is caught, it devolves that B is himself
standing upon it. Any second man once guilty of this precious bit deserves
to be demoted from his position for the remainder of the season!"
Robert L. M. Underhill, "ON THE USE AND MANAGEMENT OF THE ROPE
IN ROCK WORK," Sierra Club Bulletin, February 1931, p. 80.
-----------[000016][next][prev][last][first]---------------------------------------------------- Date: Mon, 3-Aug-87 16:54:35 EDT From: sy.Ken@CU20B.COLUMBIA.EDU (Ken Rossman) To: comp.protocols.tcp-ip Subject: Re: IBM TCP.
We've had a reasonable amount of experience with medium to large DECnet networks here at Columbia. We have our own internal network, and we also connect to various other sites who also have their own DECnet networks. I am not sure how Ethernet addresses are administered (I was under the impression that one or more of the larger corporations plugging Ethernet divvy up the board addresses by board manufacturer). In any case, the first four bytes of a DECnet transformed Ethernet address are, by some "global allocation" method, preassigned to DEC as I understand it. Since, as David Plummer points out, DECnet IV only currently supports 64K nodes on any single DECnet (well, really 63K --- area 0 is not a real area, and generally designates Phase III nodes), it doesn't really matter whether the limitation occurs at the ethernet addressing level or at the DECnet addressing level. The limit is still the same -- 63K. There is no "global" administration of DECnet areas that I know of. I deal them out for CCnet (the DECnet here that spans the CU campus and several other schools). In fact, awhile back, we were looking at connecting to other large DECnets (PHYSnet, I think, was the name of one of them, or something close to that), and we were given AN area to live in by the PHYSnet administrators. Since we were already multi-area, this made it basically impossible for us to connect with them, and we bagged the idea. As for DECnet, ARP, and ethernet addresses, Ultrix handles this just fine. We just make sure that DECnet comes up before IP does, so that the ethernet address that ARP uses is the DECnet-transformed one. /Ken -------
-----------[000017][next][prev][last][first]---------------------------------------------------- Date: Mon, 03 Aug 87 21:21:21 -0400 From: Craig Partridge <craig@NNSC.NSF.NET> To: postel@isi.edu Cc: tcp-ip@sri-nic.ARPA Subject: re: What to Name the NIC
> Wrong. The namedroppers list is for the discussion of the design
> and operation of the domain name system, not for the discussion
> of what the names are or what names would be nice.
Jon:
I'm afraid you and I are working from different definitions.
According to list-of-lists (23 Jun 87) , the namedroppers mailing list
is to be used for "discussing the concepts, principles, design and
implementation of the domain style *names*". (Italics mine).
Now I understand that doesn't mean arguing about how to restructure
the namespace (i.e., the debate about whether the choice of top-level
domains was correct, which seems to be the particular bane of namedroppers)
but I think the definition easily permits the discussion of questions about
proper selection of names within the existing namespace. And NAMEDROPPERS
is certainly more appropriate than TCP-IP.
If you think that's the wrong definition of the list, then let's get
it changed.
Craig
-----------[000018][next][prev][last][first]---------------------------------------------------- Date: Mon, 3-Aug-87 20:36:56 EDT From: postel@ISI.EDU To: comp.protocols.tcp-ip Subject: Naming the NIC
Craig:
Wrong. The namedroppers list is for discussion of the design and
operation of the domain name system, not for the discussion of what
the names are or what names would be nice.
--jon.
----- Begin Forwarded Message -----
To: tcp-ip@sri-nic.ARPA
Subject: Naming the NIC
Date: Fri, 24 Jul 87 13:18:42 -0400
From: Craig Partridge <craig@NNSC.NSF.NET>
Hey guys,
There is a forum for these sorts of naming issues -- the namedroppers list.
I recommend that any continued debate migrate to that list and will even
be so good as to resist the instinct to point out that the issue of how
to name NICs and NOCs was settled (I thought) over a year ago.
Craig Partridge
----- End Forwarded Message -----
-----------[000019][next][prev][last][first]---------------------------------------------------- Date: Mon, 3-Aug-87 21:42:27 EDT From: craig@NNSC.NSF.NET (Craig Partridge) To: comp.protocols.tcp-ip Subject: re: What to Name the NIC
> Wrong. The namedroppers list is for the discussion of the design
> and operation of the domain name system, not for the discussion
> of what the names are or what names would be nice.
Jon:
I'm afraid you and I are working from different definitions.
According to list-of-lists (23 Jun 87) , the namedroppers mailing list
is to be used for "discussing the concepts, principles, design and
implementation of the domain style *names*". (Italics mine).
Now I understand that doesn't mean arguing about how to restructure
the namespace (i.e., the debate about whether the choice of top-level
domains was correct, which seems to be the particular bane of namedroppers)
but I think the definition easily permits the discussion of questions about
proper selection of names within the existing namespace. And NAMEDROPPERS
is certainly more appropriate than TCP-IP.
If you think that's the wrong definition of the list, then let's get
it changed.
Craig
-----------[000020][next][prev][last][first]---------------------------------------------------- Date: Tue, 4-Aug-87 09:33:00 EDT From: DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer) To: comp.protocols.tcp-ip Subject: Re: IBM TCP.
Date: Mon 3 Aug 87 16:54:35-EDT
From: Ken Rossman <sy.Ken@CU20B.COLUMBIA.EDU>
We've had a reasonable amount of experience with medium to large DECnet
networks here at Columbia. We have our own internal network, and we also
connect to various other sites who also have their own DECnet networks.
I am not sure how Ethernet addresses are administered (I was under the
impression that one or more of the larger corporations plugging Ethernet
divvy up the board addresses by board manufacturer). In any case, the
first four bytes of a DECnet transformed Ethernet address are, by some
"global allocation" method, preassigned to DEC as I understand it.
Sorry. Ethernet addresses are, in theory, assigned to hardware
manufacturers in 2^24 address chunks and the manufacturer is responsible
for administering its 2^24 addresses. DEC is "reassigning" the original
hardware Ethernet address to be a DEC-specific protocol-related hardware
address. That is not the intention of the Blue Book. DEC does not
"manufacture" Interlan, 3Com, Symbolics, TI, etc, hardware, yet the
hardware Ethernet addresses used would indicate DEC does.
...
As for DECnet, ARP, and ethernet addresses, Ultrix handles this just fine.
We just make sure that DECnet comes up before IP does, so that the ethernet
address that ARP uses is the DECnet-transformed one. /Ken
That's not what I meant. What I meant was that ARP existed in time for
DECnet IV to use it, and that if DECnet used ARP instead of its current
algorithmic translation, (a) we could preserve globally unique
addresses, (b) you wouldn't have to worry about bringing up DECnet
before IP (or any other protocol), and (c) if somebody else goes against
the intention of the Blue Book we could still run DECnet and that other
protocol at the same time (since it wouldn't then require different
Ethernet addresses).
-----------[000021][next][prev][last][first]---------------------------------------------------- Date: Tue, 4 Aug 87 13:26:00 MDT From: paclark%ford-cos1.arpa@ford-cos1.ARPA (Patricia A. Clark) To: haas%gr%cs.utah.edu@ford-cos1.arpa, tcp-ip@sri-nic.ARPA Subject: Re: IBM TCP.
-----------[000022][next][prev][last][first]---------------------------------------------------- Date: Tue, 4-Aug-87 12:34:26 EDT From: unit@hpindda.HP.COM (Tom Engleman) To: comp.protocols.tcp-ip Subject: Re: fyi Wollongong TCP/IP for VAX/VMS - Reply to Mark Crispin
/ hpindda:comp.protocols.tcp-ip / JERRY@STAR.STANFORD.EDU / 2:29 pm Jul 15, 1987 /
This is Dave Crocker, not Jerry Scott. I recently joined The
Wollongong Group as Vice President, Software Engineering. We will
soon be a host on MilNet, so I have not established an interim
mailbox elsewhere. Please direct any short-term mail to me via
Jerry at this address.
The recent flurry of messages about Wollongong requires a formal
response. As you are aware, The Wollongong Group has been
selling TCP/IP-based products for some years. While we have been
successful in doing so, we have been less successful in maintaining
an unblemished reputation within the Internet community. Recently,
we began taking actions to improve user perceptions. From a technical
standpoint, the most significant of these actions involves upgrades
to our VAX/VMS product called WIN/TCP, especially converting to the
use of 4.3BSD as a code base for the TCP/IP implementation. By doing
so, many long-standing problems were solved and performance has been
substantially improved.
On reviewing the messages that were sent to this distribution list,
it appears that the basis for two of the three explicitly critical
notes was a) system administration errors, and b) the use of very
old software.
At the present time, the new release (3.0) does not have any major
TCP/IP bugs known to us, nor does it crash the operating system. The
immediately previous version (2.3) has not had any bugs that crash
VAXes for a time longer that any Wollongong personnel can remember.
It is our policy to work closely with all users of our products to
satisfy their needs. Mark Crispin's July 6 email message, while it
contained no specific details, has been partially addressed in a
public reply citing cockpit error, rather than faulty software. The
message was sent by a system administrator whose contact with Mark
triggered Mark's note. The system administrator cockpit error we
identified does not involve any software bugs, but it does result in
setting the hosts's own name to a constant ("Unknown"). To eliminate
this confusion, we are changing the software to simply use the text
version of the IP address, whenever a similar administrator error is
made.
As part of a test against one of the systems running Mark's TCP, we
did encounter a client SMTP bug. WIN/TCP 3.1, which will be
released shortly, fixes it. It was only discovered because of high
delay in the Arpanet, thereby causing an extraordinary timeout.
In addition to providing technically competent software, Wollongong must
provide support for our products. This is critical. Although admittedly
flawed in the past, this, too, is being significantly improved, as the
recent TCP/IP activity cited above demonstrates. "Support" is a
separate product and has to be purchased. There have been some customers
who purchased the TCP product but did not, for whatever reason, purchase
support. They then passed on the product to the real end-users and
claimed, falsely, that we would not provide support. The cited case of
our software crashing a VAX cluster appears to be an example of this.
Although we subsequently established direct contact with a portion of
the actual end-users affected in this way, we were unfortunately unable
to find the remainder.
The suggestion about our connecting the the Internet is extremely well-
taken. Part of the reason I was asked to join Wollongong was to bring
some Internet experience in-house. The wheels were already in motion,
I discovered, to get a connection when I came on-board. We were
supposed to be on MilNet about 4 months ago, and are in the final
stages of debugging the telecom link.
Lastly, with regard to our AT&T version of TCP/IP...it should be noted
that we developed this product at the specification of AT&T and we are
not free to add features on our own (AT&T markets the product; we
do not). Hence, please ask them to suggest to us any changes that you
deem appropriate.
Dave
----------
-----------[000023][next][prev][last][first]---------------------------------------------------- Date: Tue, 4-Aug-87 12:47:24 EDT From: postel@ISI.EDU To: comp.protocols.tcp-ip Subject: the namedroppers list policy
NAMEDROPPERS POLICY
Scope:
This NAMEDROPPERS mailing list is to be used for discussion of the
concepts, principles, design, and implementation of the domain style
names. The main focus of this group is the review of documents
describing domain style name system (currently RFCs 882, 883, 973, 974)
and discussion of the implementation of the system.
The scope is limited to the technical aspects of the system. It does
not include discussion of the actual names selected, or the semantics of
those names. There are other forums for those discussions (for example,
HEADER-PEOPLE, and ARPA-MHS).
Policy:
While one of the advantages of computer mail and mailing lists
mechanisms is fast response, in this list we prefer to go a little slow
to ensure thoughtful discussion. In general, one should let some time
go by (a day) between first reading a message and composing a response.
Even during periods of intense activity on this list one should not send
more than one message per day. Typically this would allow one to
discuss several other contributions in one message.
* Wait a day between reading and sending.
* Send at most one message per day.
On the other hand, this is a list for participants in a discussion, not
observers. Everyone on the list is expected to contribute from time to
time.
To get on or off NAMEDROPPERS send your request to
NAMEDROPPERS-REQUEST@SRI-NIC.ARPA.
Related mailing lists:
HEADER-PEOPLE
This group is for the discussion of issues in the design and
implementation of the Internet community Text mail system (based on RFCs
821 and 822). Comments are welcome from any community that uses these
conventions. This may include the interaction of the domain style names
with the operation of this mail system.
To get on or off HEADER-PEOPLE send your request to
HEADER-PEOPLE-REQUEST@MIT-MC.ARPA.
ARPA-MHS
This group is explicitly focused on the development of means for
interoperation and interconnection of the Internety community Text mail
system and the international standards community X.400/MHS mail systems.
This includes developing a mapping between the naming procedures used in
these two systems.
To get on or off ARPA-MHS send your request to
ARPA-MHS-REQUEST@BRL.ARPA.
MMM-PEOPLE
This group is exploring the issues in multimedia computer mail (i.e.,
mail that includes text, bitmap, voice, graphics, and other special data
types). This is based on work that has gone on for several years under
both DARPA and NAVY sponsorship. There is consideration in this group
of the use of X.400/MHS as a basis for further work on multimedia mail.
To get on or off MMM-PEOPLE send your request to
MMM-PEOPLE-REQUEST@C.ISI.EDU.
Multiple Addresses:
Nearly everyone in NAMEDROPPERS is also on HEADER-PEOPLE. There is no
need to send a message to both NAMEDROPPERS and any other list.
People are pretty careful about which lists they are and are not on. It
is really best to send your message to exactly one list. If it was the
wrong one, someone will let you know. Sending a message to more than
one list will surely waste a significant amount of both computer and
people time and resources.
In fact, when sending to NAMEDROPPERS the only address needed is
NAMEDROPPERS@SRI-NIC.ARPA. If you are responding to a particular
comment by someone he or she will get the message without being
explicitly addressed, and you will get a copy back too.
History:
All of the previous discussion of the NAMEDROPPERS can be found in the
files
<NAMSER>NAMEDROPPERS.YYYY on SRI-NIC.ARPA,
where YYYY is the year. There are currently files for 1983, 1984, and
1985. <NAMSER>NAMEDROPPERS.MAIL contains the most current NAMEDROPPERS
dialog. These files can be accessed via anonymous FTP. New member of
NAMEDROPPERS may which to copy and read these archives before joining
the discussion.
-----------[000024][next][prev][last][first]---------------------------------------------------- Date: Tue, 4-Aug-87 13:25:46 EDT From: herber@bgsuvax.UUCP To: comp.protocols.tcp-ip,comp.unix.wizards,comp.bugs.4bsd Subject: Problems starting vv0 Proteon PROnet-10 driver
OK, this is a good one...... I have 2 4.3BSD VAXen on an ethernet using Interlan interfaces (il0) and a Proteon, PROnet-10 using Proteon pronet interfaces (vv0). I have just changed from using class A address numbers (we didn't talk to anyone else in the world) to a class B Internet address using subnetting. Everything worked all along with the class A addresses. When I tried the following sequence of commands in /etc/rc.local, ifconfig vv0 inet 129.1.1.1 netmask 0xffffff00 ifconfig il0 inet 129.1.2.3 netmask 0xffffff00 ifconfig lo0 localhost the ifconfig for the vv0 interface fails with an "ifconfig: ioctl (SIOCSIFADDR): Can't assign requested address" and the internet address is left at 0.0.0.0. The netmast is correctly set at 0xffffff00 though (see below); # ifconfig vv0 vv0: flags=63,UP,BROADCAST,NOTRAILERS,RUNNING> inet: 0.0.0.0 netmask ffffff00 # If I try the EXACT SAME ifconfig vv0 statement AFTER the initial failure, it works and the address is correctly set at 129.1.1.1. I then switched the order of the statements in the /etc/rc.local to ifconfig lo0 localhost ifconfig il0 inet 129.1.2.3 netmask 0xffffff00 ifconfig vv0 inet 129.1.1.1 netmask 0xffffff00 and reboot, it works just fine the FIRST TIME........ ARGH!!!!!!!!! I looked at the if_vv.c driver and the error is returned to the ioctl() that is used in ifconfig to initialize the address. The error is returned in if_vv.c when the host node number on the board is not the same as that of the host number in the address. It looks to be some kind of a problem when using the subnetting/netmask features. Now that I found a combination that works, I will continue to use it but I would love to hear someone's opinion (guess, even:-) of why this doesn't work consistantly. -- Steve Herber CSNET herber@bgsu.edu Sr. Systems Programmer UUCP ...!osu-eddie!bgsuvax!herber Bowling Green State Univ.
-----------[000025][next][prev][last][first]---------------------------------------------------- Date: 4 Aug 87 15:06:00 EST From: "GBURG::ENGER" <enger%gburg.decnet@bluto.scc.com> To: "tcp-ip" <tcp-ip@sri-nic.arpa> Cc: enger Subject: No echo from the NIC
I experienced some difficulty connecting to the NIC on Sunday night. This led me to try to PING off of them (issue ICMP echo request). I did not receive any response from them on either their net-10 or net-26 address. I was able to receive ICMP echo replies from hosts on a number of networks so I wrote it off as a temporary network problem. I PINGed them again on monday, still no response. I called the NOC. They used TELNET to test connectivity, and they got through. The NOC was also able to TELNET to my host. When I told them I couldn't PING off the NIC, they became concerned. Taking their lead, I tried to TELNET to the NIC, and lo I got through as well. Yet, when I closed out the session, and tried PINGing them again, still nothing. I called up the NIC. They took down my complaint, and the next day someone from engineering called me back. He said the NIC has turned off their ICMP echo replies. He said they were getting too many ECHO requests and that it was loading the machine down. ICMP ECHO request/reply has been a usefull debugging tool. I hope this doesn't start a trend. ------
-----------[000026][next][prev][last][first]----------------------------------------------------
Date: Tue, 4-Aug-87 16:06:00 EDT
From: enger%gburg.DECnet@BLUTO.SCC.COM ("GBURG::ENGER")
To: comp.protocols.tcp-ip
Subject: No echo from the NICI experienced some difficulty connecting to the NIC on Sunday night. This led me to try to PING off of them (issue ICMP echo request). I did not receive any response from them on either their net-10 or net-26 address. I was able to receive ICMP echo replies from hosts on a number of networks so I wrote it off as a temporary network problem. I PINGed them again on monday, still no response. I called the NOC. They used TELNET to test connectivity, and they got through. The NOC was also able to TELNET to my host. When I told them I couldn't PING off the NIC, they became concerned. Taking their lead, I tried to TELNET to the NIC, and lo I got through as well. Yet, when I closed out the session, and tried PINGing them again, still nothing. I called up the NIC. They took down my complaint, and the next day someone from engineering called me back. He said the NIC has turned off their ICMP echo replies. He said they were getting too many ECHO requests and that it was loading the machine down. ICMP ECHO request/reply has been a usefull debugging tool. I hope this doesn't start a trend. ------
-----------[000027][next][prev][last][first]----------------------------------------------------
Date: Tue, 4-Aug-87 16:28:00 EDT
From: WANCHO@SIMTEL20.ARPA ("Frank J. Wancho")
To: comp.protocols.tcp-ip
Subject: TAC "noise"
This one has got me stumped, and I'd appreciate it if this
message was redirected to a more appropriate forum if there is one.
We have noticed this "noise" problem on and off for quite some
time and are now realizing that perhaps what we and our users are
seeing is not line noise but something else.
In general, when a user calls to complain about seeing "noise"
from a TAC connection, we naturally assume the problem is caused by
line noise in the phone circuit between the user and the TAC port
modem. However, it has turned out that we have not been asking the
right question in determining the noise characteristic. The question
is: are you seeing "noise" when there is supposed to be no activity on
the line, or are you seeing it as garbage only when the remote host is
sending a long string of characters. If the answer is yes to the
former, the problem is probably a "bad" circuit. However, if the
answer is yes to the latter, then we have a whole new problem, or so
it seems.
I've seen the latter problem only at 2400bps. Others have
reported the problem at 1200, and some even at 300. With the rumored
eventual upgrade to 9600bps dialup TAC access, I am concerned that
there may be an underlying basic TAC-to-modem interface problem that
needs to be found and fixed before higher speeds become commonly
available and useable.
The characteristic of this form of "noise" is that the first
several lines of expected output appear OK, then garbage (noise).
This is consistently repeatable. We have empirically ruled out
several possible causes, including real line noise, and noise caused
by level settings in the modems themselves. It seems one possibility
remains: that there is a "slight" speed mismatch between what the TAC
outputs and what the modem expects and bits eventually get shifted...
There is one further complication that makes things harder to
track: it appears that the TAC software *may* have been undergoing
"minor" changes during this time without the version number changing
in the TAC herald. Thus, it is somewhat difficult to pinpoint when
this problem started to occur relative to TAC version.
I suggest that followups to this message be made privately amongst
interested parties unless there is some general interest in this
subject on this list. The only reason for bringing this up here is
that I have several high level users wanting answers *now* and I can't
evade the queries for much longer...
--Frank
-----------[000028][next][prev][last][first]----------------------------------------------------
Date: Tue, 4-Aug-87 17:03:00 EDT
From: JOHNSON@NUHUB.ACS.NORTHEASTERN.EDU ("I am only an egg.")
To: comp.protocols.tcp-ip
Subject: ethernet interface perversity
Hold it a minute. I have received many responses from my query
about network numbers on an ethernet. Thank you for all the positive
help for those who gave it but . . .
I NEVER intended to complain or panic about IP. I was in search of
verification of something and perhaps I phrased it poorly. And yes I
know that one ethernet wire can have large numbers of internet addresses
floating around on it.
We did some experimentation with our various ethernet interfaces
and discovered that something which was hinted at in many of the
responses seems to be true. The ethernet interfaces we have will each
respond to only one internet number at a time. I talked to Micom for
example and they even said as much for their np100 board.
*FLAME ON*
It seems very dumb that I need at least one gateway node on one
ethernet wire so that nodes on that wire can all talk to each other when
some of the nodes run with different internet numbers.
Although my problem is really an administrative one (I don't run
the whole network here, I just get dumped on when it doesn't work), I
don't see why I should be having a problem at all. I read ARP, rfc 826,
and it talks about an address translation table. Note the use of the
word TABLE. In this age of micro-processors it seems more than feasible to
put some real table driven ARP intelligence out there so that interface
boards can RESPOND TO MORE THAN ONE BLOODY ADDRESS.
I suppose someone is going to ask how big the table should be. I
don't know. Memory is cheap. It could easily be big enough to handle
16 or 32 network numbers. It could even be content addressable and thus
FAST. Allowing for 16 or 32 network numbers (or more) should reduce the
frequency of ether_type$ADDRESS_RESOLUTION packets to small for most
cases.
*FLAME OFF*
I'm just upset with the vendors for giving me ulcers again. So
what else is new :-(.
USnail:
Chris Johnson
Academic Computer Services
Northeastern University 39RI
360 Huntington Ave.
Boston, MA. U.S.A. 02115
AT&T: (617) 437-2335
CSNET: johnson@nuhub.acs.northeastern.edu
ARPANET: johnson%nuhub.acs.northeastern.edu@relay.cs.net
BITNET: johnson%nuhub.acs.northeastern.edu@csnet-relay
(Always vote. There may not be anything you want to vote for, but
there might be something you want to vote against.)
-----------[000029][next][prev][last][first]---------------------------------------------------- Date: Tue, 4 Aug 87 17:03 EDT From: "I am only an egg." <JOHNSON%nuhub.acs.northeastern.edu@RELAY.CS.NET> To: tcp-ip@SRI-NIC.ARPA Subject: ethernet interface perversity
Hold it a minute. I have received many responses from my query
about network numbers on an ethernet. Thank you for all the positive
help for those who gave it but . . .
I NEVER intended to complain or panic about IP. I was in search of
verification of something and perhaps I phrased it poorly. And yes I
know that one ethernet wire can have large numbers of internet addresses
floating around on it.
We did some experimentation with our various ethernet interfaces
and discovered that something which was hinted at in many of the
responses seems to be true. The ethernet interfaces we have will each
respond to only one internet number at a time. I talked to Micom for
example and they even said as much for their np100 board.
*FLAME ON*
It seems very dumb that I need at least one gateway node on one
ethernet wire so that nodes on that wire can all talk to each other when
some of the nodes run with different internet numbers.
Although my problem is really an administrative one (I don't run
the whole network here, I just get dumped on when it doesn't work), I
don't see why I should be having a problem at all. I read ARP, rfc 826,
and it talks about an address translation table. Note the use of the
word TABLE. In this age of micro-processors it seems more than feasible to
put some real table driven ARP intelligence out there so that interface
boards can RESPOND TO MORE THAN ONE BLOODY ADDRESS.
I suppose someone is going to ask how big the table should be. I
don't know. Memory is cheap. It could easily be big enough to handle
16 or 32 network numbers. It could even be content addressable and thus
FAST. Allowing for 16 or 32 network numbers (or more) should reduce the
frequency of ether_type$ADDRESS_RESOLUTION packets to small for most
cases.
*FLAME OFF*
I'm just upset with the vendors for giving me ulcers again. So
what else is new :-(.
USnail:
Chris Johnson
Academic Computer Services
Northeastern University 39RI
360 Huntington Ave.
Boston, MA. U.S.A. 02115
AT&T: (617) 437-2335
CSNET: johnson@nuhub.acs.northeastern.edu
ARPANET: johnson%nuhub.acs.northeastern.edu@relay.cs.net
BITNET: johnson%nuhub.acs.northeastern.edu@csnet-relay
(Always vote. There may not be anything you want to vote for, but
there might be something you want to vote against.)
-----------[000030][next][prev][last][first]---------------------------------------------------- Date: Tue, 4-Aug-87 20:01:09 EDT From: M.JSOL@DEEP-THOUGHT.MIT.EDU (Jon Solomon) To: comp.protocols.tcp-ip Subject: Dr. Postel's comments about the namedroppers list
I agree with KLH's comments that there is a need to discuss naming conventions and names. Now that the internet (small-i) is much larger than just the TCP/IP speaking Internet, it is useful to recognize that not all people agree on what things should be called. HOWEVER: I think there is policy which can be used to handle the naming of the NIC, which is to ask the people who run the NIC for the DDN. When we started using domains, we were given fairly free reign over what we wanted to call our second-level domain, we eventually chose bu.edu. Also, our host names all contain "bu" in them in addition to the .bu.edu suffix (i.e. buit1.bu.edu, bu-cs.bu.edu, bu-ma.bu.edu). We find this preferrable to "it1.bu.edu" or "1.it.bu.edu". The point is, it was our choice, and now what I see here is a consensus of people who want to name the NIC, and it is really the NIC admin's responsibility to name it. SO, Ken, if you want to start a list to discuss naming, feel free, but remember that you have the ultimate authority to name the NIC however seems convenient and useful. -------
-----------[000031][next][prev][last][first]---------------------------------------------------- Date: Tue, 4-Aug-87 22:05:36 EDT From: CASNER@VENERA.ISI.EDU (Stephen Casner) To: comp.protocols.tcp-ip Subject: Re: Telnet, <CR><LF>, etc.
(Another LONG MESSAGE)
Greg Minshall -
You are correct, the Telnet spec does NOT make it clear whether the
client program should send CR-LF or CR-NUL when the user hits the
"return" key. The discussion is clear for characters flowing in the
opposite direction to the NVT printer, and we are left to infer a choice
for the NVT keyboard to server direction from statements about symmetry.
The following sentence is the one that I think causes trouble; you have
undoubtedly read it before, but I'll quote it here for discussion:
Therefore, the sequence "CR LF" must be treated as a single "new
line" character and used whenever their combined action is intended;
the sequence "CR NUL" must be used where a carriage return alone is
actually desired; and the CR character must be avoided in other
contexts.
What is intended when the user hits the "return" or "enter" key? Those
who believe the return key means the user is finished with the current
line and wants a new line might quote the first part of the sentence to
show that CR-LF "must be ... used". Those who believe that carriage
return alone is desired, because on many (most?) terminals the "return"
key generates a single CR character, might quote the second part of the
sentence to show that CR-NUL "must be used".
NEITHER group can "prove" its case from the spec, but this is not a
legal contest. As Mark Crispin says, "we all have a shared interest in
maximizing interoperability".
I believe the Telnet spec should say exactly which of these two choices
should be used, just to avoid the present confusion of interpretation.
In any case, by the "robustness principle", EITHER sequence (CR-LF or
CR-NUL) should be accepted by the Telnet server to mean that the
"return" / "enter" key was pushed because we know there are some systems
that send one and some systems that send the other.
So, for the moment at least, my complaint was and is not that the 4.3BSD
telnet client sends CR-NUL but only about the 4.3BSD telnetd maps CR-LF
to '\n' instead of '\r'.
You say that you could have mapped CR-LF to '\r', but that it would have
violated the philosophy of Unix that '\n' is the newline character. I
disagree, because the philosophy of Unix does not require that terminals
send '\n' to the tty driver; instead the tty driver receives '\r' from
the terminal and maps it to '\n' WHEN APPROPRIATE. Since telnetd does
not feed the application program directly, but rather feeds a pty, I
claim telnetd should map CR-LF to '\r' and let the pty driver map to
'\n' when appropriate. This is the same argument that Kevin Carosso
wrote. This change was also posted to comp.bugs.4bsd on 29-Jan-87 by
J. Robert Ward.
You gave a second reason that anyone unfortunate enough to be connecting
from a client unwilling to send a LF alone would face a problem getting
a '\n' sent towards their program. Again I disagree, because the pty
will map '\r' to '\n' for those programs that don't distinguish between
the two characters and expect only '\n'. To fully utilize a program
that uses cbreak or raw mode and does distinguish between '\r' and '\n',
the telnet client must be able to send two distinct codes: CR-LF or
CR-NUL when the "return" key is pushed, and LF alone when the "linefeed"
key is pushed. Some keyboards don't have "linefeed", but they probably
do have "control" and "J" keys. Is there any client that won't send LF
alone?
There are many clients that don't provide any mechanism to send CR-NUL
instead of CR-LF. They are NOT violating the spec either! Dave Borman,
Kevin Carosso and Dan Hoey suggest the Bridge box may be in error
because it doesn't or can't send CR-NUL. While it might be more robust
to have an option to send either CR-LF or CR-NUL, it's certainly not a
bug to send CR-LF. As you point out, many of the old hands in the
Telnet business, participants in the "let's define and bring up TELNET
meetings", believe CR-LF to be the correct choice over CR-NUL.
Bob Braden refreshed my memory that at the "TCP Bakeoffs" when the first
implementations of TCP/TELNET were being tested against each other, only
Charles Lynn's TENEX implementation sent CR-NUL and everyone else sent
CR-LF. It was subsequently agreed that CR-LF was the correct choice,
but obviously that choice wasn't clearly stated in the spec. BSD Unix
chooses CR-NUL and that causes trouble for some of the older server
implementations (cf John G. Ata's message). My personal choice would be
for BSD Unix to change to send CR-LF, but I recognize that this would
cause trouble when connecting to telnetd's that map CR-LF to '\n'.
Perhaps it would be wise to enhance the BSD telnet program so the user
can select whether CR-LF or CR-NUL will be sent. Our goal should be to
clarify this issue in the spec so that eventually all machines can
interoperate naturally without the need for such inconveniences.
You have stated your case well for the choices made in the 4.3 BSD
implementation. But given the additional information put forth by
several people since then, do you still believe telnetd should map CR-LF
to '\n' and not to '\r'? What will 4.4 BSD do?
-- Steve Casner
-------
-----------[000032][next][prev][last][first]---------------------------------------------------- Date: Wed, 5-Aug-87 08:41:40 EDT From: pogran@CCQ.BBN.COM (Ken Pogran) To: comp.protocols.tcp-ip Subject: Re: No echo from the NIC
Regarding PINGing and the report that the NIC has elected to turn
off ICMP echo replies ("He said they were getting too many ECHO
requests and that it was loading the machine down. ICMP ECHO
request/reply has been a usefull debugging tool. I hope this
doesn't start a trend."):
This issue is only about thirteen or fourteen years old. Perhaps
Mike Padlipsky will supply us with the correct bibliographic
reference; back in the NCP days he wrote an RFC entitled
something like, "... but my NCP costs $500 a day!" complaining
about incessant NCP ECHO requests from TENEX hosts that were
causing the MIT-Multics Network Daemon to wake up constantly to
send ECHO REPLYs. The solution for us at MIT, back then, was
two-fold: 1) Get the TENEXes to stop frequent pinging which was
being done for the sole purpose of keeping track who was really
up on the ARPANET and who was not, and 2) move the Multics
ECHO-processing code into an interrupt handler and out of a
process that needed to be awakend for each echo. Both were
accomplished.
Yes, pings are nice. They provide you with assurance that
someone is really there. As the Internet grows though (and we're
over 250 truly active nets, now), unnecessary or gratuitous pings
are a waste of everyone's cycles -- hosts, gateways, PSNs. And
at a well-known, heavily-used host like the NIC -- imagine the
horror experienced by a system manager who, trying to respond to
user complaints of slow service, does a profile of where his
cycles are going and discovers that a substantial fraction is
going into ICMP ECHO replying! (I haven't talked with the NIC,
so my description here is purely hypothetical.) Here, clearly,
is a way to "buy back" cycles that can be used to improve service
to users.
Is it going to start a trend? Given the ever-increasing number
of nets out there, we might indeed begin to see more "defensive"
moves made by major service hosts who begin to perceive completely
open, full, and friendly participation as a drain on their
resources.
Food for thought.
Ken Pogran
-----------[000033][next][prev][last][first]---------------------------------------------------- Date: Wed, 5 Aug 87 8:41:40 EDT From: Ken Pogran <pogran@ccq.bbn.com> To: "GBURG::ENGER" <enger%gburg.decnet@bluto.scc.com> Cc: "tcp-ip" <tcp-ip@sri-nic.arpa>, enger@bluto.scc.com, pogran@ccq.bbn.com Subject: Re: No echo from the NIC
Regarding PINGing and the report that the NIC has elected to turn
off ICMP echo replies ("He said they were getting too many ECHO
requests and that it was loading the machine down. ICMP ECHO
request/reply has been a usefull debugging tool. I hope this
doesn't start a trend."):
This issue is only about thirteen or fourteen years old. Perhaps
Mike Padlipsky will supply us with the correct bibliographic
reference; back in the NCP days he wrote an RFC entitled
something like, "... but my NCP costs $500 a day!" complaining
about incessant NCP ECHO requests from TENEX hosts that were
causing the MIT-Multics Network Daemon to wake up constantly to
send ECHO REPLYs. The solution for us at MIT, back then, was
two-fold: 1) Get the TENEXes to stop frequent pinging which was
being done for the sole purpose of keeping track who was really
up on the ARPANET and who was not, and 2) move the Multics
ECHO-processing code into an interrupt handler and out of a
process that needed to be awakend for each echo. Both were
accomplished.
Yes, pings are nice. They provide you with assurance that
someone is really there. As the Internet grows though (and we're
over 250 truly active nets, now), unnecessary or gratuitous pings
are a waste of everyone's cycles -- hosts, gateways, PSNs. And
at a well-known, heavily-used host like the NIC -- imagine the
horror experienced by a system manager who, trying to respond to
user complaints of slow service, does a profile of where his
cycles are going and discovers that a substantial fraction is
going into ICMP ECHO replying! (I haven't talked with the NIC,
so my description here is purely hypothetical.) Here, clearly,
is a way to "buy back" cycles that can be used to improve service
to users.
Is it going to start a trend? Given the ever-increasing number
of nets out there, we might indeed begin to see more "defensive"
moves made by major service hosts who begin to perceive completely
open, full, and friendly participation as a drain on their
resources.
Food for thought.
Ken Pogran
-----------[000034][next][prev][last][first]---------------------------------------------------- Date: Wed, 5-Aug-87 10:02:57 EDT From: jat@blnt1.UUCP (John A Tamplin) To: comp.protocols.tcp-ip Subject: Re: Streams TCP/IP
Streams TLI should not keep any state information in user space. I have written a streams TLI provider that keeps the state inside the driver (kernel space) for each upper stream. There is no reason to do otherwise. The only interface a user process has to the state machine is by issuing or receiving primitives. -- John Tamplin Blount Brothers Corporation gatech!blnt1!jat 2511 Fairlane Drive 205/244-6231 Montgomery, AL 36116
-----------[000035][next][prev][last][first]---------------------------------------------------- Date: Wed, 5-Aug-87 10:27:00 EDT From: DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer) To: comp.protocols.tcp-ip Subject: ethernet interface perversity
Date: Tue, 4 Aug 87 17:03 EDT
From: "I am only an egg." <JOHNSON%nuhub.acs.northeastern.edu@RELAY.CS.NET>
*FLAME ON*
It seems very dumb that I need at least one gateway node on one
ethernet wire so that nodes on that wire can all talk to each other when
some of the nodes run with different internet numbers.
What does this have to do with Ethernet numbers? Judging by the rest of
the message, you may be a little confused. My guess is that the reason
you need a gateway is because the structure of the Internet
implementation on the system(s) you are running requires it, and has
little to do with Ethernet. I'm guessing that if your IP were
convincible that A.B.C.0 and X.Y.Z.0 were both on the same cable, then
A.B.C.D would send an ARP for X.Y.Z.W and communicate directly instead
of sending it to a gateway that is on both A.B.C.0 and X.Y.Z.0.
Although my problem is really an administrative one (I don't run
the whole network here, I just get dumped on when it doesn't work), I
don't see why I should be having a problem at all. I read ARP, rfc 826,
and it talks about an address translation table. Note the use of the
word TABLE. In this age of micro-processors it seems more than feasible to
put some real table driven ARP intelligence out there so that interface
boards can RESPOND TO MORE THAN ONE BLOODY ADDRESS.
How many addresses? If you are going to relate hardware addresses with
network protocols, you need to respond to at least as many addresses as
there are protocols. One way to interpret the current situation is that
we already have such a scheme! "Addresses" are 64 bits long. 24 are
assigned to a hardware manufacturer, 24 are assigned by the hardware
manufacturer (these two give the 48 bit Ethernet address we know of
today), and 16 describe the protocol (the Ethernet type field). Using
this interpretation, boards already respond to 64K "addresses."
I suppose someone is going to ask how big the table should be. I
don't know. Memory is cheap. It could easily be big enough to handle
16 or 32 network numbers. It could even be content addressable and thus
FAST. Allowing for 16 or 32 network numbers (or more) should reduce the
frequency of ether_type$ADDRESS_RESOLUTION packets to small for most
cases.
Again, only if you relate hardware addresses to protocol addresses, as
DEC did. If the Ethernet were designed this way from the start, perhaps
we wouldn't be in this bind. Unfortunately, there are at least two
problems back then: (1) Content addressable memories weren't commodity,
and (2) algorithmic translation only works well if the protocol address
length is sufficiently smaller than the hardware address length. With
L(IP) being 4 and L(Ether) being 6, this leaves 2 bytes to denote it as
an IP address. Some people believe that IP addresses are too small;
being bigger makes the problem worse.
The practical problem is convincing every implementation to change at
this late date.
*FLAhavfonts
-----------[000036][next][prev][last][first]---------------------------------------------------- Date: Wed, 5-Aug-87 12:05:49 EDT From: sandrock@UXC.CSO.UIUC.EDU (Mark Sandrock) To: comp.protocols.tcp-ip Subject: Re: IBM TCP.
We don't have a DECnet host 1.1, and neither should any site which has links to the "outside world". All DECnet addresses on our campus are assigned by the PHYSnet management, which includes international address assignments as well. Also, I doubt that if "ACME" vendor tries to market a network that conflicts with DECnet that they will have many sales to systems which already have DECnet installed. They would most likely (and deservedly) soon be a defunct company.
-----------[000037][next][prev][last][first]---------------------------------------------------- Date: Wed, 5-Aug-87 12:18:21 EDT From: sandrock@UXC.CSO.UIUC.EDU (Mark Sandrock) To: comp.protocols.tcp-ip Subject: Re: IBM TCP.
Thanks for your message re: DECnet and Ethernet. All of our DECnet addresses here at the University of Illinois are assigned by the PHYSnet management (whoever that is). We have not yet seen the need for multiple areas on this campus. Also, one would expect that DEC might anticipate the need and expand the DECnet addressing scheme to something reasonable in a future version (Phase V?).
-----------[000038][next][prev][last][first]---------------------------------------------------- Date: Wed, 5-Aug-87 12:24:18 EDT From: sandrock@UXC.CSO.UIUC.EDU (Mark Sandrock) To: comp.protocols.tcp-ip Subject: Re: IBM TCP.
It sounds like you are claiming that DEC preempts Ethernet hardware addresses which have been officially assigned to other vendors, but I have yet to see a specific example of such an address. Is it asking to much either to see an example or else have everyone drop this claim?
-----------[000039][next][prev][last][first]---------------------------------------------------- Date: Wed, 5-Aug-87 13:18:00 EDT From: sandrock@uxc.cso.uiuc.edu To: comp.protocols.tcp-ip Subject: Re: IBM TCP.
I hope you will bear with me... not being yet familiar with the workings
of UNIX mail I don't know if my responses to individual mail will also
be posted here, but I would like to clarify my statements re: DECnet...
I still have not seen any example of a DECnet-assigned Ethernet address
which is NOT globally unique. Can someone give such an example of DEC's
preemption of another vendor's Ethernet address?
I realize that it would be possible for 2 DECnet nodes to choose the
same DECnet address thereby choosing the same Ethernet address, but in
practice of course this is not supposed to happen, anymore than 2 sites
choosing the same IP address.
While I also do not know of any "global administration" of DECnet ad-
dresses, it so happens that here at the University of Illinois we make
all DECnet address assignments through a contact with the PHYSnet man-
agement (no, I don't know any more details than that).
To say this another way, I am free to bring up my own Ethernet (in my
office, right!) and choose any DECnet and/or IP addresses I want for my
personal machines, but once I connect my net to the Internet or PHYSnet
or whatever, I obviously must choose to coexist in harmony (or suffer
the consequences!).
Also, I agree that 2**16 unique addresses is an undesirable limitation,
but at one time it was only 2**10 addresses, and so one might surmise
that DEC will once again respond to the perceived need for more addresses
in due time.
This may all be a moot discussion in light of newer protocols being
developed (?), but then who can really say? (Not me anyway (:^))
Mark Sandrock, (sandrock@uiucuxc.UUCP)
-----------[000040][next][prev][last][first]---------------------------------------------------- Date: Wed, 5-Aug-87 14:57:01 EDT From: starner@burdvax.PRC.Unisys.COM (Mark L. Starner) To: comp.protocols.tcp-ip,comp.bugs.4bsd Subject: ACC IF-11/HDH 4.3 Driver
We have had a problem with our ACC IF-11/HDH IMP (sorry, PSN) interface
since our conversion to 4.3 BSD. We finally tracked it down to be limited
to fragmented or full size (1006) packets.
For example, when we would do an FTP get from ucbvax, we would
never receive the large 1006 byte packet. All we would get is a 58
byte packet. Eventually, after 3 minutes, we would get a message:
netin: connection reset by peer
I contacted ACC for help once I discovered the the exact nature of
the problem and they told me that there was a bug in the 4.3BSD released
vaxif/if_hdh.c and that all 4.3 sites should get the new driver.
A temporary fix until you can receive the new driver is to
change all occurences of IMPMTU to IMPMTU+2 in if_hdh.c.
(this in fact solves the problem).
It is reccomended that you contact ACC to receive a copy
of the newest driver. They can be reached at:
SERVICE@ACC-SB-UNIX.ARPA
or at:
1-800-222-7308 (ask for Software Support)
The problem also shows itself with SYSERR from your sendmail daemon and
with "whois" returning nothing but your prompt if what the NIC is trying
to send you is more than 1006 bytes long.
Hope this saves someone the 4 months of frustration it caused me.
BTW, I would be interested to hear if anyone else knew about or has this
problem.
--
Mark Starner starner@prc.unisys.com
Unisys Corporation/Paoli Research Center {cbmvax,sdcrdcf}!burdvax!starner
Paoli, PA
-----------[000041][next][prev][last][first]---------------------------------------------------- Date: Wed, 5-Aug-87 16:21:58 EDT From: hsu_f@osupyr.UUCP (Frank Hsu) To: comp.protocols.tcp-ip Subject: Re: Wollongon TCP/IP for AT&T 3B2
I got your message. Yes, our Physics Dept. told me that their CAD/CAM IBM 4341 always receive packets from the 3B2 looking for port 513. I did not the reason. Now I stopped the RWHO daemon. Our "mailx" really have problems with dots in the host names. I reported this problem to AT&T, a technical support person in AT&T information system told me that "telnet" and "ftp" have no problem with dots. But "mailx" just can not take any dots in the host name. I kept the mail message from AT&T, I will mail it to you later. Our "telnet" on the 3B2/300 works fine. It can login to Pyramid, IBM 3081, iBM 4341, DEC VAX 11/780, Sun work stations, DEC-20. I can not see any difficulty in connecting to other hosts. I never tried routed "mailx". Frank C. Hsu IRCC, Ohio State Univ. Columbus, Ohio 43210
-----------[000042][next][prev][last][first]---------------------------------------------------- Date: Wed, 5-Aug-87 17:04:52 EDT From: leivian@dover.uucp (Bob Leivian) To: comp.protocols.tcp-ip Subject: Anybody have a socket interface library for SPARTACUS's K-routines
I am working to port a private protocol to IBM CMS using Spartacus's
KNET for TCP.
The code is written in C for Berkeley sockets and un*x.
Has anyone written a socket, bind, etc that interfaces to the ASM lang
routines supplied by Spartacus that they call K-Routines.
If not, I will write one so anyone with like tasks might want to contact
me to share horror stories about IBM TCP-IP.
--Bob L
--
Bob Leivian Motorola, Dover Shores (CAD Support) 602-994-6778
...{mcdsun, sun}!sunburn!dover!leivian Mesa, AZ
-----------[000043][next][prev][last][first]---------------------------------------------------- Date: Wed, 5-Aug-87 17:07:35 EDT From: postel@ISI.EDU To: comp.protocols.tcp-ip Subject: Re: SMTP question
Drew: Once upon a time long ago and far away there were computers that internally stored characters as 7-bit bytes. At the time that the mail protocols were designed such computers were a significant part of the network population. There are still some of these computers in existance, and some of them do a lot of mail forwarding. If a message passes through one of these computers the (high-order) eighth bit will be lost as it is stored (however temporarally) and a zero value (high-order) eighth bit will be supplied as the message is forwarded on. If somehow your message does not pass through any of these aging beasts and passes only through computers that work on eight-bit bytes internally it probably will keep all eight-bits of every byte just the way you wanted them. But there are no guarantees about it. Go ask some old time BBN-er "What does 'TENEX' mean?". --jon.
-----------[000044][next][prev][last][first]---------------------------------------------------- Date: Wed, 5-Aug-87 18:56:23 EDT From: mrose@GREMLIN.NRTC.NORTHROP.COM (Marshall Rose) To: comp.protocols.tcp-ip Subject: tcp on 802.4
Hi. I recall this being discussed, but don't remember the outcome. Can someone give me a pointer to the authoritative source for how one speaks TCP on an 802.4 net? Replies to me only. Thanks! /mtr
-----------[000045][next][prev][last][first]---------------------------------------------------- Date: Wed, 5-Aug-87 20:51:00 EDT From: alexandr@uiucuxe.cso.uiuc.edu To: comp.protocols.tcp-ip Subject: Re: Telnet, <CR><LF>, etc.
Sorry if this is too much UNIX for the rest of you...
Well, I think Greg has explained things very nicely. Since he feels
that this is a UNIX related issue, let me toss my two cents in.
1) Pty(4), like tty(4) has CRMOD. Therefore, it can already map
<CR> to <NL> for you. in.telnetd should take advantage of this fact.
2) Programs such as tip run in raw mode, expecting carriage returns,
not line-feeds. Therefore, it should always be easy to give
them one. Again, sending <CR> seems more reasonable.
Therefore, it seems to me that in.telnetd should always send a <CR>
to the pty unless the user explicitly sends an <LF>. This seems to
allow maximum compatibilty w/ existing software and other operating
systems.
-- Steve Alexander, Workstation Programmer,
National Center for Supercomputing Applications
stevea@lurch.ncsa.uiuc.edu
stevea%lurch@uxc.cso.uiuc.edu
stevea@uiucvmd.bitnet
...!{ihnp4,convex,pur-ee}!uiucdcs!uiucuxc!lurch!stevea
-----------[000046][next][prev][last][first]---------------------------------------------------- Date: Wed, 5-Aug-87 22:01:56 EDT From: fedor@DEVVAX.TN.CORNELL.EDU (Mark Fedor) To: comp.protocols.tcp-ip Subject: Re: Problems starting vv0 Proteon PROnet-10 driver
Here is a fix and explanation to the problem....
This was posted to USENET some time ago, I get no credit
for this fix, but I should get something for finding
this article out of all the tons of News articles I
have saved.... :^)
Hope this helps!
Mark
-----------------------------------
Article 3887 of net.unix-wizards:
>From: ron@BRL.ARPA
Newsgroups: net.unix-wizards
Subject: brl-vgr Bug Report
Message-ID: <4577@brl-smoke.ARPA>
Date: 13 Oct 86 23:15:30 GMT
Sender: news@brl-smoke.ARPA
Subject: Unable to set vv address on subnet
Index: sys/vaxif/if_vv.c 4.3BSD
Description:
Ifconfig returns an error when you try to set the address on
the proteon when using subneting.
Repeat-By:
ifconfig vv0 128.63.4.3 netmask 255.255.255.0
Fix:
The vv driver checks to see if the local net part of
address corresponds to the hardware address of the interface
installed in your system. The subnet mask can not be set
before the address because the mask has to be tied to a
particular internet address.
The fix is to make the vv driver mask off all but the lowest
eight bits of the address before making the validity check.
This is OK since the device can only deal with eight local
address bits. In vvioctl:
/*
* Attempt to check agreement of protocol address
* and board address.
*/
switch (ifa->ifa_addr.sa_family) {
case AF_INET:
if ((in_lnaof(IA_SIN(ifa)->sin_addr) & 0xFF) !=
vv_softc[ifp->if_unit].vs_host)
error = EADDRNOTAVAIL;
break;
}
break;
-----------[000047][next][prev][last][first]---------------------------------------------------- Date: Wed, 5-Aug-87 23:56:57 EDT From: Mills@UDEL.EDU To: comp.protocols.tcp-ip Subject: Re: No echo from the NIC
Bob, I can't believe this. Nobody (!?) pings the NIC unless they can't connect and wants to find out why not. So the NIC turns off ICMP as a defense measure? My prior experience has been that ICMP worked, but TCP connections took a v e r y long time to complete. It is certainly obvious that the NIC is overloaded; however, if a significant contributory factor is ICMP echoes, I submit turning them off will only result in their replacement by TCP connection attempts. Considering the TOPS-20 initial-connection TCP design, this would be an even worse disaster. Dave
-----------[000048][next][prev][last][first]----------------------------------------------------
Date: Thu, 6-Aug-87 00:22:00 EDT
From: WANCHO@SIMTEL20.ARPA ("Frank J. Wancho")
To: comp.protocols.tcp-ip
Subject: TAC "noise"
Apparently some readers of my message about TAC "noise" inferred
that we had reported this bug and received no action. We have not yet
reported this problem, although we believe others elsewhere may have
reported something similar with no resolution.
My intent in sending that message was to try to gather some
hypotheses to present when I do report the problem to give the problem
more credibility and a higher likelihood of receiving attention and
maybe even getting fixed. After all, the "true" nature of the problem
is often easily misunderstood.
It was also an attempt to discover if anyone else has experienced
the same problem - TAC users are an individually isolated contigent of
users with no one to represent them and no forum to bring up their
problems, except, maybe NIC folks who mainly handle TAC Access card
problems and refer technical problems to the NOC. Most TAC users
aren't technical enough to push their statement of the problem past
the "well, it must be line noise" answer, and the problem is not
properly surfaced.
However, the readership of this forum, not necessarily the forum
itself, is, as hoped, quite technically knowledgeable. I immediately
received several detailed responses basically supporting my suspicion
that clock tolerances are the most likely culprit. In fact one
respondent was actually able to prove the point by using an old 300
bps modem with a clock heavily suspected of having drifted over the
years and observing the same "noise" characteristic as I described.
So, with apologies to BBN for not having made my message clear, I
will now go off and report the problem through conventional channels.
Thank you all for bearing with me while I interrupted your discussions
on the more esoteric aspects of TCP/IP.
--Frank
-----------[000049][next][prev][last][first]---------------------------------------------------- Date: Thu, 6-Aug-87 00:34:59 EDT From: hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick) To: comp.protocols.tcp-ip Subject: Re: IBM TCP.
As far as I know, in phase V the DECnet address will consist of two bytes of subnet and then the Ethernet address. Once phase IV compatibility is not needed (typically this would be at the next phase), one could presumably stop using the special Ethernet address forced on you by the phase IV DECnet design, and use the preassigned Ethernet address. So at that point, machines using DECnet would have unique addresses. I think this discussion has diverged from its intent. I was simply trying to explain what was meant when someone said that machines running DECnet did not have globally unique Ethernet addresses. Your comments about how DECnet addresses are assigned on your campus show that there can't be any conflict in DECnet addresses at your installation. However the fact remains that your hosts no longer have globally unique Ethernet addresses. There are almost certainly at least two hosts on the DEC corporate network with the same address (since they have several DECnet networks each of which have very full address space), and presumably some on other large corporate networks as well. This is not a criticism: obviously your machine will not become confused with those other machines. It is simply an explanation of a statement in a previous posting.
-----------[000050][next][prev][last][first]---------------------------------------------------- Date: Thu, 06 Aug 87 08:17:55 -0400 From: haverty@CCV.BBN.COM To: "Frank J. Wancho" <WANCHO@SIMTEL20.ARPA> Cc: TCP-IP@SRI-NIC.ARPA, haverty@CCV.BBN.COM Subject: Re: TAC "noise"
Frank -- from my experience, it would be worth looking at "stop bits" in addition to clock tolerances. If a receiver expects more stop bits than a sender sends, things tend to work when there is a non-continuous stream of characters, but get garbled when the line is running flat out - the first bit or two of the "next character" get eaten up as if they were stop bits for the current character. You can test this hypothesis by comparing the characters as received with those as sent, and seeing if bit-shifting would cause a match. Jack
-----------[000051][next][prev][last][first]---------------------------------------------------- Date: Thu, 6-Aug-87 07:54:13 EDT From: HANK@BARILVM.BITNET (Henry Nussbacher) To: comp.protocols.tcp-ip Subject: Tcp/Ip for MVS and Mitek revisited
Last week I asked for info on Mitek and their MVS solutions to Tcp/Ip. To date only one person has replied and that was only to tell me that he thinks that Mitek has signed to be a MAP of IBM. He did not know what MAP was. I did some further checking. IBM has a IMAP program (Industry Marketing Assistance Program). It is sort of like a 3rd party developer for IBM. Last year, IBM recruited several IMAP companies to promote DEC to System/370 connectivity. IBM has now been courting Mitek to develop System/36 and System/38 Tcp/Ip connectivity. Mitek has produced something called FTP/6.2 for 36 & 38 systems. Mitek was formed in 1982 by Bernie Hogan who previously owned Hogan Systems, Inc. This company suffered a pretax loss of $20 million in 1985 after delivering allegedly faulty software to 40 customers. Mitek now claims to have solutions for System/36, System/38, MVS, and SNA in the Tcp/Ip realm. This entire "thing" has me nervous. If IBM has decided to enter into an IMAP agreement with Mitek, why hasn't anyone on the network ever heard of them? Is there a single site out there using Mitek equipment? Thanks, Hank
-----------[000052][next][prev][last][first]---------------------------------------------------- Date: Thu, 6-Aug-87 08:40:57 EDT From: haverty@CCV.BBN.COM To: comp.protocols.tcp-ip Subject: Re: TAC "noise"
Frank -- from my experience, it would be worth looking at "stop bits" in addition to clock tolerances. If a receiver expects more stop bits than a sender sends, things tend to work when there is a non-continuous stream of characters, but get garbled when the line is running flat out - the first bit or two of the "next character" get eaten up as if they were stop bits for the current character. You can test this hypothesis by comparing the characters as received with those as sent, and seeing if bit-shifting would cause a match. Jack
-----------[000053][next][prev][last][first]---------------------------------------------------- Date: Thu, 6-Aug-87 10:30:58 EDT From: mcc@ETN-WLV.EATON.COM (Crockett) To: comp.protocols.tcp-ip Subject: TELNET ELF
(yet another long message)
1) Before I am chastised severely for my interpretations of the TELNET
protocol, I would like to note that much of the work that I perform
is related to communications over networks used within the DoDIIS
community. The acceptance of the DDN network architecture to replace
AUTODIN, DSSCS/DIN, IDHSC II, etc. presents some interesting problems.
First, the DoDIIS community has a significant involvement with Digital
Equipment Corporation and, in particular, PDP11 processors and the IAS
operating system. Second, there is a desire not to invalidate a rather
significant investment in software that has been developed over the
last ten (10) years. Third, there is a migration to LAN architectures
which permit workstations (PCs) to replace directly connected terminals.
As a result, the implementation and interpretation of TELNET is rather
significant. The Digital IAS, RSX-11M (PLUS), and VMS TT drivers/handlers
trigger on <CR> as the end-of-line terminator. From the perspective
of these operating systems, an <LF> is generally regarded simply as a
vertical positioning command to the next line from the current cursor/
print head position. TELNET software provided with various DDN protocol
suite packages present particular problems when they are too blatant in
their UNIX style treatment of an end-of-line condition (\n).
2) For the DDN three (3) different TELNET specifications/standards have
been established. They are:
a. RFC 854 which governs the ARPANET,
b. MIL-STD-1782 which governs the MILNET, and
c. DoDIIS TELNET Specification which governs other subnets that
are currently separated from the ARPANET and MILNET.
RFC 854 does not have the legal stature of a standard and cannot be
specified for government procurements; therefore, MIL-STD-1782 which
is a legal standard is the document that must be conformed to when
providing TELNET to DoD or other governmental agencies. The RFC and
the MIL-STD are essentially the same except that some of the asides
and discussions contained in the RFC have been abbreviated or deleted.
The most significant departure from the RFC is the deletion of the
reference to "...a companion document, 'TELNET Option Specifications',
which should be consulted..." and the inclusion of a set of appendices
which define the options that are required in the MIL-STD.
The DoDIIS TELNET Specification has the most significant differences
primarily as a result of the Network Virtual Data Entry Terminal
(NVDET) abstraction definition. In contracts, the DoDIIS TELNET is
generally specified in addition to the MIL-STD to include the NVDET.
[The neat trick is how to determine whether the remote terminal is
an NVT or an NVDET since some of the option defaults are different.]
3) My original comments on the use <CR><NUL> and <CR><LF> were based on
my interpretation of MIL-STD-1782. From my reading of RFC 854, there
is no reason for me to change my interpretation. Both documents state
that a "...<CR><LF> must be treated as a single 'new line' character
and used whenever their combined action is intended; the sequence <CR>
<NUL> must be used where a carriage return alone is actually desired...".
The following excerpt is from the discussion of the GA option but is
equally valid when discussing the action taken when a <CR> is encount-
ered.
"The 'local' computer is no longer able to decide whether to
retain control after seeing an end-of-line signal or not; this
decision can only be made by the 'remote' computer which is
processing the data."
When the ENTER or RETURN key is struck, the local host has no idea
what the intended action is to be and therefore should transmit a
<CR><NUL> and allow the remote host to provide the interpretation.
The transmission of a <CR><LF> is presumptuous except when the
user enters a <LF> as the next character.
In the case of a 'gateway' computer, it should perform absolutely
no conversions and pass the data on as it was received. <CR><NUL>
input, <CR><NUL> output. <CR><LF> input, <CR><LF> output.
4) An interesting question is what will happen when a TELNET connection
is used to edit, read, or write an AUTODIN message. The AUTODIN ELF
is <CR><CR><LF>. (Believe it or not, there are still devices out
there that require the <CR><CR> before the <LF> to compensate for
head travel time)
Merton Campbell Crockett
AN/GYQ-21(V) Program
EATON Information Management Systems
mcc@etn-wlv.EATON.COM
-----------[000054][next][prev][last][first]---------------------------------------------------- Date: Thu, 6-Aug-87 11:00:00 EDT From: rees@apollo.uucp (Jim Rees) To: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Streams TCP/IP
First, this is probably obvious, but "sockets" is an interface, and is best
compared to TLI. Streams is an implementation framework, and has no direct
counterpart in bsd4.3, although it was originally intended as a replacement
for clists and parts of tty.c.
I'm doing a streams implementation here (see my paper in the Phoenix Usenix
Proceedings). It has a TLI interface and a socket interface too. The two
don't always cooperate very well, but it sort of works. 8th edition has
a socket interface too, but I haven't seen it and don't know how it works.
Guy Harris:
If you want a STREAMS-based terminal driver, there will be some
problems with sharing a single pool of buffer resources between the
networking code and the terminal driver; it makes it more likely that
networking operations will exhaust these resources.
SysV neatly avoids this problem by not using streams for ttys! There
is a simple priority scheme that tries to avoid this problem, but it
isn't really adequate, especially since the guy (no relation to Guy)
who wrote the tty driver probably didn't talk to the guy who wrote the
IP multiplexor about who was going to allocate how much of which priority.
The concept is the same in Dennis Ritchie's version and in the S5R3
version, but some of the details are different. I believe the S5R3
version is bigger and more complicated.
AT&T added multiplexors (I believe), which are really necessary for
doing protocols. They also added the clone driver, a crock if I've ever
seen one. My version of this uses a special minor device number to
indicate a clone open, and there is no separate clone driver. The sysV
version of streams is indeed bigger and hairier than the v8.
The big potential advantage to streams, from my point of view, is that
it allows you to mix and match protocol modules. Want to run TCP on top
of X.25 transport? Buy a TCP multiplexor module from vendor A, a X.25
network multiplexor from vendor B, and a driver from vendor C. Plug them
all in and it just works. In practice, this requires everyone to use
the same messsages between all their modules, and the interconnectivity
problems make the TCP/IP interoperability problems we are all so painfully
aware of look as easy as tying your shoes in comparison.
-----------[000055][next][prev][last][first]---------------------------------------------------- Date: Thu, 6-Aug-87 11:05:00 EDT From: DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer) To: comp.protocols.tcp-ip Subject: Re: IBM TCP.
Date: Wed, 5 Aug 87 11:05:49 CDT
From: sandrock@uxc.cso.uiuc.edu (Mark Sandrock)
Also, I doubt that if "ACME" vendor tries to market a network that
conflicts with DECnet that they will have many sales to systems which
already have DECnet installed. They would most likely (and deservedly)
soon be a defunct company.
Well, what if it were UniSYS, IBM or GM? Muscle flexing is a very
impolite thing to do anyway, and in open network environments it may
achieve a marketing objective at the expense of thwarting the kinds of
atmospheres that lead to experimentation and creativity.
Date: Wed, 5 Aug 87 11:18:21 CDT
From: sandrock@uxc.cso.uiuc.edu (Mark Sandrock)
Thanks for your message re: DECnet and Ethernet. All of our DECnet
addresses here at the University of Illinois are assigned by the
PHYSnet management (whoever that is). We have not yet seen the need
for multiple areas on this campus. Also, one would expect that DEC
might anticipate the need and expand the DECnet addressing scheme to
something reasonable in a future version (Phase V?).
So Hedrick believes (Phase V). Unfortunately, it sounds like they are
going off in another wrong direction. From Hedrick's description, they
will in the future be basing DECnet protocol addresses on the Ethernet
hardware address. Well, what happens if your Ethernet hardware breaks
and you need to replace it? Answer as far as I can tell: you have to
force the new Ethernet address to be the same as the old. What happens
if you recommision the old board on the same net? Another problem: Does
this mean that DECnet Phase V has variable length addresses? What do
they do for networks that have a different number of hardware address
bytes than the Ethernet has? My belief is that protocol addresses are
logically attached to the machine as an entity, that hardware network
addresses are attached to hardware interfaces, and that they should not
be related because of the current problems with (1) DECnet Phase IV and
(2) my understand of Hedrick's description of Phase V. IP, Chaos and
PUP (and probably others I don't know about) do it right.
Date: Wed, 5 Aug 87 11:24:18 CDT
From: sandrock@uxc.cso.uiuc.edu (Mark Sandrock)
It sounds like you are claiming that DEC preempts Ethernet hardware
addresses which have been officially assigned to other vendors, but
I have yet to see a specific example of such an address. Is it asking
to much either to see an example or else have everyone drop this claim?
Sure. There is a Symbolics 3600 at our site that has an Ethernet
hardware address of 08-00-05-03-00-38. The 08-00-05- portion was
assigned to Symbolics by the Ethernet number Czar for use by Symbolics
for its Ethernet interfaces. That is the "official" hardware address of
the interface on that machine. That machine also has a DNA address of
41.69. Because of the way DNA works, the booting procedure for the
machine changes the Ethernet address of the interface to
AA-00-04-00-45-A4. Therefore, DNA has preempted our officially assigned
address.
-----------[000056][next][prev][last][first]---------------------------------------------------- Date: Thu, 6-Aug-87 11:37:00 EDT From: SYSTEM@CRNLNS.BITNET To: comp.protocols.tcp-ip Subject: Re: IBM TCP.
Mark, > It sounds like you are claiming that DEC preempts Ethernet hardware > addresses which have been officially assigned to other vendors, but > I have yet to see a specific example of such an address. Is it asking > to much either to see an example or else have everyone drop this claim? Herewith the DECnet Ethernet address for node 19.53, aka 19509:: AA-00-03-01-10-E7 I do not know if this conflicts with any other vendor's address assignments. Selden E. Ball, Jr. (Wilson Lab's network and system manager) Cornell University NYNEX: +1-607-255-0688 Laboratory of Nuclear Studies BITNET: SYSTEM@CRNLNS Wilson Synchrotron Lab ARPA: SYSTEM%CRNLNS.BITNET@WISCVM.WISC.EDU Judd Falls & Dryden Road PHYSnet/HEPnet/SPAN: Ithaca, NY, USA 14853 LNS61::SYSTEM = 44283::SYSTEM (node 43.251)
-----------[000057][next][prev][last][first]---------------------------------------------------- Date: Thu, 6 Aug 87 11:37 EDT From: <SYSTEM%CRNLNS.BITNET@wiscvm.wisc.edu> To: tcp-ip@sri-nic.arpa Subject: Re: IBM TCP.
Mark, > It sounds like you are claiming that DEC preempts Ethernet hardware > addresses which have been officially assigned to other vendors, but > I have yet to see a specific example of such an address. Is it asking > to much either to see an example or else have everyone drop this claim? Herewith the DECnet Ethernet address for node 19.53, aka 19509:: AA-00-03-01-10-E7 I do not know if this conflicts with any other vendor's address assignments. Selden E. Ball, Jr. (Wilson Lab's network and system manager) Cornell University NYNEX: +1-607-255-0688 Laboratory of Nuclear Studies BITNET: SYSTEM@CRNLNS Wilson Synchrotron Lab ARPA: SYSTEM%CRNLNS.BITNET@WISCVM.WISC.EDU Judd Falls & Dryden Road PHYSnet/HEPnet/SPAN: Ithaca, NY, USA 14853 LNS61::SYSTEM = 44283::SYSTEM (node 43.251)
-----------[000058][next][prev][last][first]---------------------------------------------------- Date: Thu, 6-Aug-87 11:46:23 EDT From: jas@MONK.PROTEON.COM (John A. Shriver) To: comp.protocols.tcp-ip Subject: TELNET ELF
So why can't the IAS system be generous and accept <CR><NUL> or <CR><LF> and type <CR> on the virtual teletype, and type <LF> on the virtual teletype when <LF> is received? The general interpretation in the Internet community is that <CR><LF> is what is sent as the generic end-of-line on input. (Making this change would be consonant with the robustness principle of TCP.) Of course, IAS can generate whatever it want on output, and it the user Telnet does the wrong thing with it, then shame on it. I think part of the clarity problem in the spec is that it does not adequately seperate the meanings on input and output.
-----------[000059][next][prev][last][first]---------------------------------------------------- Date: Thu, 6-Aug-87 12:02:13 EDT From: ROODE@BIONET-20.ARPA (David Roode) To: comp.protocols.tcp-ip Subject: Re: How do you break up a B class number?
Why don't you replace your DEC LANBridges with something at the IP level. In your description of the main ethernet, you indicate you use these to connect together a combination of thin and fat wires using these and repeaters. For the price of a DEC LANBridge, you can buy something like a cisco gateway, and voila, no more 100 host subnet. I can't see the real argument for ever desiring to put 1000 hosts on a single subnet, or even 300. Organizations that large are going to be naturally broken into administrative units of smaller size, each of which might be allocated a subnet, or a portion of a subnet shared with a limited number of other units. -------
-----------[000060][next][prev][last][first]---------------------------------------------------- Date: Thu, 6-Aug-87 13:43:53 EDT From: hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick) To: comp.protocols.tcp-ip Subject: Re: IBM TCP.
No, DEC does not preempt other vendors' addresses. Let's try this again. The Ethernet spec requires that a vendor allocate each Ethernet interface an address which is globally unique. That is, there is no other interface in the world with the same number. DEC interfaces have such an address. However when you turn on DECnet, the processor causes the interface to change addresses. It no longer uses its globally unique address, but instead uses an address that is produced algorithmically from the DECnet address. The first 4 bytes of the address are a constant. The last two are the DECnet address with various bit twiddling. (The exact algorithm is documented in the DECnet manual.) This address is obviously unique within your site, and even within the set of sites that are connected by DECnet, but is no longer globally unique, because any other site with the same DECnet address will now have the same Ethernet address. The Ethernet address is otherwise legal. The vendor prefix is DEC's. However the address as a whole is not unique across the whole world. Perhaps the confusion is whether DECnet addresses are globally unique? A DECnet address has two parts: area and host. There are 64 possible area numbers and 1024 possible host numbers. This is not a large enough address space to allow DECnet addresses to be globally unique. Again, they are obviously unique for any given DECnet network. But your DECnet network, DEC's, GM's, etc., may and probably do use the same addresses. The physics net, in which both of us participate, controls allocation of area numbers for the schools that participate. So among that set of schools DECnet addresses are unique. But there can only be 62 schools in that network, because the network itself uses one area number, and 0 is not allowable. There are certainly more than 62 universities in the country. Indeed there was a message on dcom.lan not long ago from someone who couldn't join the network because their local DECnet needed several areas, and therefore their address allocations conflicted with the physics nets'. There are other large organizations, such as DEC's engineering network, that use most of the possible DECnet addresses. So the conclusion is: DECnet addresses are unique within the specific DECnet network, but not on a world-wide basis. Furthermore, the address space is small enough that there could not be a DECnet network as large as the IP internet. Simple arithmetic will show that. DECnet uses 16 bits for its address. In general 16 bit addresses do not provide enough address space to allow globally unique addresses. Thus the 16-bit networks, including chaos, PUP, and DECnet, are used primarily as local networks, or between specific sets of institutions. For a large network, at least 32 bits is needed, and even that may be marginal. IP uses 32 bits, DECnet phase V uses 64 bits, and XNS uses 96 bits. All of these are designed to be used with large-scale networks.
-----------[000061][next][prev][last][first]---------------------------------------------------- Date: Thu, 6-Aug-87 15:27:46 EDT From: abe@j.cc.purdue.edu (Vic Abell) To: comp.protocols.tcp-ip Subject: Re: Telnet, <CR><LF>, etc.
Among the five telnet client and server applications available to me for for testing - 2.9BSD (4.1c/4.2 ancestry), 4.3BSD, ULTRIX 1.2, Wollongong VMS 3.0, and WISCNET/VM (IBM) - only one combination passes all my operability tests: 4.3BSD. (My tests did not including chaining - client to server to client to server, etc., etc.) 2.9BSD has all the 4.2 failings and more - particularly with respect to local character processing and CR forwarding. ULTRIX 1.2 telnet doesn't process local characters at all, but it does echo them. Its telnetd is reputed to have problems with echo mode changes. Both are 4.2 based. Wollongong telnet emits unnecessary NUL characters and doesn't seem to send anything but <CR><NUL> for end of line. WISCNET works well with everyone, but has only line-at-a-time mode, so character oriented applications (e. g., vi) don't work. Dave Borman and Greg Minshall should be complimented for having done well a difficult job of practical engineering in 4.3BSD. They managed to strike a reasonable compromise with the leaky and overloaded telnet protocol. It would be even better if 4.3BSD telnetd were changed to forward '\r' instead of '\n' to the application. That would represent another, good, practical compromise for assisting chaining and other character-oriented applications. Vic Abell Purdue University Computing Center
-----------[000062][next][prev][last][first]---------------------------------------------------- Date: Thu, 6-Aug-87 17:49:24 EDT From: lamaster@pioneer.arpa (Hugh LaMaster) To: comp.protocols.tcp-ip Subject: Re: Telnet, <CR><LF>, etc.
Stephen Casner writes:
**********************
>You are correct, the Telnet spec does NOT make it clear whether the
>client program should send CR-LF or CR-NUL when the user hits the
>"return" key. The discussion is clear for characters flowing in the
:
>The following sentence is the one that I think causes trouble; you have
>undoubtedly read it before, but I'll quote it here for discussion:
Therefore, the sequence "CR LF" must be treated as a single "new
line" character and used whenever their combined action is intended;
the sequence "CR NUL" must be used where a carriage return alone is
actually desired; and the CR character must be avoided in other
contexts.
>show that CR-LF "must be ... used". Those who believe that carriage
>return alone is desired, because on many (most?) terminals the "return"
>key generates a single CR character, might quote the second part of the
>sentence to show that CR-NUL "must be used".
I agree with ALMOST all of this. Now, I have just read the spec carefully
again myself, and it seemed clear to me that CR-NUL was intended originally to
be used on output for NVT printer overstrikes on the same line. It isn't
clear what, if anything, it means on input. However, through long use
(misuse?), CR-NUL should, it seems, ALSO be INTERPRETED as a newline on input.
Does anyone know what a TAC sends when it gets a CR from a keyboard?
>NEITHER group can "prove" its case from the spec, but this is not a
>legal contest. As Mark Crispin says, "we all have a shared interest in
>maximizing interoperability".
EXACTLY. Since interoperability is the PURPOSE, implementors have an
OBLIGATION to follow the robustness principle, even if it inconveniences
Un*x raw mode I/O.
>I believe the Telnet spec should say exactly which of these two choices
>should be used, just to avoid the present confusion of interpretation.
>In any case, by the "robustness principle", EITHER sequence (CR-LF or
>CR-NUL) should be accepted by the Telnet server to mean that the
>"return" / "enter" key was pushed because we know there are some systems
>that send one and some systems that send the other.
Yes, the spec should have defined ONE sequence exactly for what user telnet
should send to mean "newline". However, the spec does state very clearly that
CR-LF MUST (read it again) be INTERPRETED as a newline. Therefore, user
telnet MUST SEND CR-LF unless it has negotiated or otherwise knows that
something else is preferable. Versions of BSD telnet which don't follow this
are not consistent with the standard, pure and simple. In my opinion (let us
not get personal).
>So, for the moment at least, my complaint was and is not that the 4.3BSD
>telnet client sends CR-NUL but only about the 4.3BSD telnetd maps CR-LF
>to '\n' instead of '\r'.
I do not follow this. 4.3BSD telnetd MUST interpret CR-LF as a "newline"
(which means that a user PROCESS must receive \n (or \n\0 depending on how you
look at the \0) - whatever happens in between is the implementors problem) and
MUST SEND CR-LF as a "newline" to a (non-Unix) host. Obviously, there is
disagreement about this, but it seems very clear to me. Read the spec again.
The convention used to handle the raw-mode case must be consistent with this.
Some discussion seems to point to the need for programs in raw mode receiving
a \r or \r\0. I am not sure I follow this, but if the cooked mode case is
clear, then the raw mode case should make more sense.
(discussion about the difference between terminals and what a process receives
internally deleted - the discussion is correct: there is NO necessary
connection between the characters that telnet NVT uses and what Unix uses
internally, although 99% of the time they are the same).
Hugh LaMaster, m/s 233-9, UUCP {seismo,topaz,lll-crg,ucbvax}!
NASA Ames Research Center ames!pioneer!lamaster
Moffett Field, CA 94035 ARPA lamaster@ames-pioneer.arpa
Phone: (415)694-6117 ARPA lamaster@pioneer.arc.nasa.gov
"IBM will have it soon"
(Disclaimer: "All opinions solely the author's responsibility")
-----------[000063][next][prev][last][first]---------------------------------------------------- Date: 6 Aug 87 14:40:00 GMT From: apollo!rees@eddie.mit.edu (Jim Rees) To: tcp-ip@sri-nic.arpa Subject: RFS vs NFS
While we're at it, could anybody summarize the differences between RFS
and NFS?
I wrote an article for Unix/World a while ago on this topic. The big
technical difference is that NFS is stateless, and RFS statefull.
This means you get exact unix file system semantics with RFS, but
not with NFS. On the other hand, NFS clients are able to recover
from server crashes without a glitch, and continue processing where
they left off before the crash.
If you want file locking (and I do; there are ~2000 machines on my
local network sharing a single file system) then you can't get it on
NFS without adding state to the servers. If you do that, you've lost
much of the advantage of having a stateless server. Most people don't
care about this (yet).
I won't go into all the politics, but right now (and for the foreseeable
future) NFS is much more widely available.
Disclaimer: I dislike both RFS and NFS, but for different reasons.
-----------[000064][next][prev][last][first]---------------------------------------------------- Date: Thu, 6-Aug-87 19:40:19 EDT From: martin@felix.UUCP (Martin McKendry) To: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Streams TCP/IP
In article <24336@sun.uucp> guy%gorodish@Sun.COM (Guy Harris) writes: > >Since streams modules and drivers do not necessarily run in the >context of a process, even when servicing a request made in a process >(e.g., a "write" or an "ioctl"), they cannot block; thus, if a memory >allocation fails, you have to go through some amount of contortions >to retry the allocation if it's important to do so. Were STREAMS to >be implemented on top of a kernel that supported "lightweight >processes", one could guarantee that streams modules and drivers ran >in the context of a thread of control that could safely block, which >would considerably simplify this. We are considering using streams as a basis for some future work on our distributed file system, as well as for networking. The problem Guy cites above, inability to block on resources, seems to be a MAJOR one. The code I have seen seems to do mutual exclusion via spl, which is pretty crude but works. I guess we could do that, but often we need to block to read from disk, or to get long-held resources, such as inodes. So what work-arounds exist? I cannot believe that real software has been implemented with streams without this problem coming up. Any experience or suggestions? Or are the applications implemented so far sufficiently simple that this is not a problem? In which case, Streams are maybe half of a message handling mechanism, which is probably worse th