The 'Security Digest' Archives (TM)

Archive: About | Browse | Search | Contributions | Feedback
Site: Help | Index | Search | Contact | Notices | Changes

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 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.
------

-----------[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 than none at all.  Sadly.

--
	Martin S. McKendry
	FileNet Corp
	{hplabs,trwrb}!felix!martin

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      Thu, 6-Aug-87 20:54:57 EDT
From:      nowicki@SUN.COM (Bill Nowicki)
To:        comp.protocols.tcp-ip
Subject:   Re: Telnet, <CR><LF>, etc.

My two cents worth on this subject:

In SunOS 3.4 I changed the telnet daemon to send \r instead of \n to
the pty when it gets <CR><LF>.  However, this broke the local line edit
mode.  In SunOS 4.0 I originally put in a check to see if local editing
was being done, and if so sent \n to the pty, otherwise \r.  Steve
Casner's message, however, convinced me that a slightly cleaner fix
would be to just keep the pty in the mode that treats \r as \n when
doing local editing.  I don't understand the rationale behind the code
that explicitly cleared it.  

The change is simple (your line numbers may vary).  In the function
dontoption():

922,927c924,925
<     case TELOPT_ECHO:         
<         /*
<          * we should stop echoing, since the client side will be doing it,
<          * but keep mapping CR since CR-LF will be mapped to it.
<          */
<       mode(0, ECHO);
---
>     case TELOPT_ECHO:         /* we should stop echoing */
>       mode(0, ECHO|CRMOD);

This, in combination with the change from \n to \r for incoming <CR><LF>s
seems to work for most telnets in both line and character modes.

	- WIN

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      Thu, 06 Aug 87 14:54:13 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:   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
-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      Fri, 7-Aug-87 00:24:44 EDT
From:      jerry@oliveb.UUCP (Jerry F Aguirre)
To:        comp.protocols.tcp-ip
Subject:   Re: Telnet, <CR><LF>, etc.

In article <555127536.0.CASNER@VENERA.ISI.EDU> CASNER@VENERA.ISI.EDU (Stephen Casner) writes:
>You say that you could have mapped CR-LF to '\r', but that it would have
>violated the philosophy of Unix that '\n' is the newline character.  I
>disagree, because the philosophy of Unix does not require that terminals
>send '\n' to the tty driver; instead the tty driver receives '\r' from
>the terminal and maps it to '\n' WHEN APPROPRIATE.  Since telnetd does
>not feed the application program directly, but rather feeds a pty, I
>claim telnetd should map CR-LF to '\r' and let the pty driver map to
>'\n' when appropriate.

I agree.  The telnet daemon is not talking to "Unix" but to the pty.
For the pty driver linefeed is not necessarily the end of line
character.  The end of line character depends on the mode of the pty.
I would add that the telnet daemon should map CR-LF to '\n' if the pty
is in newline mode but should map it to '\r' if the mode is not newline.

The user can then, either automatically (via getty), or explicitly (via
stty), set the newline processing as appropriate for their terminal.
This offers greater functionality with no loss that I can perceive.

				Jerry Aguirre

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      6 Aug 87 22:35:53 GMT
From:      hi!kurt@hc.dspo.gov  (Kurt Zeilenga)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: RFS vs NFS
In article <3681e98d.b8ab@apollo.uucp> rees@apollo.uucp (Jim Rees) writes:
>If you want file locking (and I do; there are ~2000 machines on my
>local network sharing a single file system) then you can't get it on
>NFS without adding state to the servers.  If you do that, you've lost
>much of the advantage of having a stateless server.  Most people don't
>care about this (yet).

That's why we run statd and lockd along side of NFS on our systems.
-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      Fri, 7-Aug-87 08:20:32 EDT
From:      ben@cernvax.UUCP (ben)
To:        comp.sys.m68k,comp.protocols.tcp-ip
Subject:   TCP/IP for Motorola RMS68K O/S ??

We are looking for possible TCP/IP implementations for 68K systems running
the Motorola RMS68k operating system. We are interested both in the case where
all of the protocols and utilities run on the 68K, or where an intelligent
board is used, e.g. Excelan, CMC, etc. (for VME-based systems). A big bonus
would be the additional availability of (at least client) NFS.

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      Fri, 7 Aug 87 11:32:50 CDT
From:      lhl@parmesan.wisc.edu (L.H. Landweber)
To:        info-nets@think.com, namedroppers@sri-nic.arpa, tcp-ip@sri-nic.arpa
Cc:        lhl@parmesan.wisc.edu
Subject:   WISCVM FUTURE
PLEASE DISTRIBUTE THIS ANNOUNCEMENT

On December 1, WISCVM will be shut down.  Hence, as of 
that date, we will no longer be able to provide a mail 
relay service between Arpanet and BITNET.

WISCVM currently handles between 5 and 10 thousand
messages per day. Clearly, this service is very important 
to the academic/research network community. As such
it should be fully supported. Many of you may not
be aware that at present the WISCVM relay is only supported 
by a volunteer student (indeed, this summer he  
has a full-time job off campus).  Because of the 
(admittedly) inadequate level of support, problems
arise periodically. For example, for the past day
most messages have been rejected. The current problem
occurred because there was some ambiguity in our
instructions for installing new host tables.

We would be happy to provide advice on what is 
required to run a supported mail relay. Besides
operations and bug fixing, such support should  
include consulting for system administrators (if 
not for users).  Hopefully, some suitable
organization will be found to provide this
service.


Larry Landweber
-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      Fri, 7-Aug-87 10:52:49 EDT
From:      ron@TOPAZ.RUTGERS.EDU (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re:  TAC "noise"

Ether that or someone has their terminal set to 7 data-bits and
no parity.

-Ron

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      Fri, 7-Aug-87 15:42:12 EDT
From:      kurt@hi.UUCP (Kurt Zeilenga)
To:        comp.unix.wizards,comp.protocols.tcp-ip
Subject:   BSD route daemon

Most of the systems on our network run some form of the route daemon
'routed'.  Network == multiple (but few) IP networks (and subnets) on
ethernets.  Gateways are all 4.X BSD UNIX host computers. No Internet
gateway, YET (but we are hoping).

I would like to know the pros and cons of replacing the daemons with
hardcoded routes.  We are having problems with a few non-gateway
systems adverstising incorrect info.  Like today one system (Ultrix
1.2) said: "I'm a gateway to 255.255.255.255"!  Subjects I am interested
in are: system overhead, network drain, static vs dynamic route tables,
etc.

We will be bring up EGP on our gateways to Internet.

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      Fri, 7-Aug-87 16:10:52 EDT
From:      guy%gorodish@Sun.COM (Guy Harris)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Streams TCP/IP

> We are considering using streams as a basis for some future work on
> our distributed file system, as well as for networking.  The problem
> Guy cites above, inability to block on resources, seems to be a
> MAJOR one.

Nope.  AT&T's RFS uses STREAMS to talk to the transport layer it
uses, so there is an existence proof.

The secret is that the AT&T RFS (or NFS, or probably Todd Brunhoff's
RFS) server is implemented as a separate UNIX process; the server
code runs in the context of that process (or processes, if you have
more than one server).  *That* process can block waiting for a disk,
or other resource, if it wants to.

The client code probably also runs in the context of a UNIX process;
if it's running in the process that makes the request, it obviously
is, and NFS has a daemon to handle asynchronous requests.  This code
can also block if it has to.

The trick here is that none of the file system code is implemented as
a STREAMS module; that's not really what STREAMS were developed for.
However, there may be cases where something that STREAMS *was*
developed for, such as a network protocol implementation, would want
to block.  There are cases, both in the STREAMS framework and the
4BSD sockets/protocols framework, where it can't do this
conveniently.

The problem with the STREAMS mechanism is that there are *no* places
where you can *guarantee* that you can block, if you want to follow
the letter of the law.  If you "know" that there are no modules with
service procedures above you, and you "know" the way put procedures
are called, so that you "know" that your module's "put" procedure
will be called in the context of the process making the request that
causes the message to be sent downstream, you could cheat; however,
you can't really "know" any of those things.
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      7 Aug 87 14:00:44 GMT
From:      mcvax!ukc!its63b!adam@seismo.css.gov  (ERCF02 Adam Hamilton)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: IBM TCP. Really DECnet and Ethernet addresses
>    Date: Wed, 5 Aug 87 11:24:18 CDT
>    From: sandrock@uxc.cso.uiuc.edu (Mark Sandrock)
>
>    It sounds like you are claiming that DEC preempts Ethernet hardware
>    addresses which have been officially assigned to other vendors, but
>    I have yet to see a specific example of such an address. Is it asking
>    to much either to see an example or else have everyone drop this claim?
>
>Sure.  There is a Symbolics 3600 at our site that has an Ethernet
>hardware address of 08-00-05-03-00-38.  The 08-00-05- portion was
>assigned to Symbolics by the Ethernet number Czar for use by Symbolics
>for its Ethernet interfaces.  That is the "official" hardware address of
>the interface on that machine.  That machine also has a DNA address of
>41.69.  Because of the way DNA works, the booting procedure for the
>machine changes the Ethernet address of the interface to
>AA-00-04-00-45-A4.  Therefore, DNA has preempted our officially assigned
>address.

In IEEE802 and also XEROX Blue book, the format of an Ethernet address
is defined as having two special bits; these are the first two to be
transmitted.  Note that bits in an octet are transmitted
LEAST significant bit first, therefore these bits are the LEAST
significant bits of the first octet.
	The first bit signifies whether the address is individual or local,
the second signifies whether the address is globally (value 0) or locally
administered.  In the above example (AA-00- etc.) the second bit is set,
therefore the address is locally administered.
	All address allocations to manufacturers are globally administered.
All VMS machines I have seen have addresses which start AA-00.  All this
means that DECnet style addresses are NOT globally unique (as discussed)
but do NOT use values which are globally administered.  This should make no
difference unless the same address is used on more than one Ethernet
when a bridge (specifically selective frame-level repeater) may well get
confused.
	Presumably this bit was put in for DEC's benefit, but I'm just
guessing here.
-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      Fri, 7-Aug-87 18:23:48 EDT
From:      geof@imagen.UUCP (Geof Cooper)
To:        comp.protocols.tcp-ip
Subject:   Telnet CRLF's

The problem is REALLY:

    How do I get RETURN to work properly both at the
    command level and in EMACS (or other RAW mode
    application, like vi, tip, etc....).

At the command level (in "cooked tty" applications), the
"big key" on the terminal (which is usually RETURN these
days) is the one you want to type to end a command.  Unix
helps tty's to do this by internally mapping the '\r'
character into '\n' (newline == linefeed) in the default
terminal mode.

When you go into a raw-mode application, it usually turns
off this translation.  Thus, it must "know" what key is
the "big one" and let you use it.  Emacs wants to see a
'\r' to generate its "newline" function.

So on Unix itself, it would be better to use CR-NUL and
never generate newline, since the system will map CR-NUL
into the local newline convention.

BUT, in the generic case, you MIGHT be talking (perhaps
from a Unix machine) to a machine that isn't Unix, and
needs the CR-LF newline sequence.  Or you might want
the "big key" to generate the <<right thing>> without
having to worry about it.  So you DO want to generate
newline in your telnet user program.

The only resolution of this, in my mind, is for telnet
user programs to always provide an OPTION for what mapping
to use.  After all, how does the telnet program know
what the "big key" is, anyway!

- Geof Cooper

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      Fri, 7-Aug-87 18:48:22 EDT
From:      geof@imagen.UUCP (Geof Cooper)
To:        comp.protocols.tcp-ip
Subject:   Recursive Subnets

In all this discussion of how you can't accomodate different
sized subnets, I just wanted to mention that recursive subnets
offer a legal solution to the problem -- if you can build
the gateways to make them work.

In fact, I remember thinking of recursive subnets as a
solution to exactly this problem when the subnet specs were
being sledgehammered out.  The idea of using a subnet
mask was partly to allow obscure things like this.

The idea is to use higher order bits of the subnet address
to label "top-level subnets", and lower bits to label
"bottom-level" subnets.  The address might look like:

    NNNNNNNN NNNNNNNN TSSSSSSS HHHHHHHH

N => network number bits
T => top-level subnet number
S => bottom-level subnet bits
H => host number

There is one "top-level net" in this example (T=1),
with a 15-bit host address.  The other top-level subnetwork
(T=0) is really a subdivision of 128 different subnets,
each of which can have 256 hosts.  The bottom-level subnets
use a mask of 0xffffff00.  The top-level subnet
uses a mask of 0xffff8000.  It is easy to generalize the
above example to multiple top-level nets (or even
multiple levels of recursive subnets - gawk!).

All the gateways in all the subnets have to know the
global subnet configuration (at the levels to which they
are connected).  This means that the configuration tables
that were mentioned on the list -- with different subnet
masks for different subnets or hosts -- still exist
(they map to interfaces now), but only within the gateways.
Hosts just use the regular subnet routing, and don't
know about recursive subnets.

The usual restriction of subnets, that there be only
a single entry into the subnet world, still holds
(I think) between the top and bottom levels.  You could
have redundant gateways, but all would have to be
equally connected.  I guess that you could remove this
restriction with smarter gateways (all gateways know
about all subnets, regardless of size).

Hosts on the top-level network can send to hosts on
the bottom-level networks, because bottom level network
addresses look like hosts on the "other" top-level network
(with T=0), so the packets are sent to a gateway.
The Gateway Knows.

Hosts on a bottom-level network can send to hosts on
other bottom-level networks using the usual subnet-
routing algorithm.

Hosts on a bottom-level network can send to hosts on
a top-level network because all hosts on the top-level
network look like hosts on some other bottom-level
subnet (which happens to have T=1), so the packets
are sent to a gateway.  The Gateway Knows.

Everybody can send to hosts that are not on the subnet,
because such packets always look like they are on a 
different "subnet", and are sent to a gateway, and
The Gateway Knows.

Of course, you still have to do the work to make the
Gateways Know.

- Geof

-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      Fri, 7-Aug-87 20:55:35 EDT
From:      hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   Re:  No echo from the NIC

That's certainly true for us.  Since the NIC is not a gateway, the
only reason we would ever ping it is if we didn't get response from
the root name server and wanted to help diagnosi

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      Fri, 7-Aug-87 22:04:44 EDT
From:      mullen@NRL-CSS.ARPA (Preston Mullen)
To:        comp.protocols.tcp-ip
Subject:   Ethernet problems induced by bogus ICMP Address Mask Reply

Here's a new one to add to the list of things that can induce broadcast
storms and other serious problems.  It involves an unpleasant interaction
between SunOS 3.3 and 3.4 and Wollongong's WIN/VX software version 3.0.
(Ironically, this problem was noticed when the Suns and VAXes were
upgraded to what is generally considered to be better networking
software.)

When a diskless Sun 3 workstation running SunOS 3.3 or 3.4 boots, at
some point it sends out a broadcast ICMP Address Mask Request.  This is
in accordance with RFC950; unfortunately, an incorrect reply from any
machine on the network can be accepted by the workstation, and some
incorrect masks can induce the workstation to start sending all packets
as Ethernet broadcasts, which instantly leads to a broadcast storm.

If this happens, the workstation will probably fail to finish
booting completely, usually stopping during the NFS mount with
"RPC: not registered" messages, but sometimes sooner.  Also, the
workstation may itself then generate an incorrect reply (sent as an
Ethernet broadcast) to a subsequent ICMP Address Mask Request from
some other machine, thus spreading the virus.  Other symptoms that
may be observed include extremely sluggish operation of diskless
machines and "no carrier" and "Ethernet jammed" notices from Suns
(aside from those generated during broadcast storms).

This happened here on a non-subnetted Class B network when the 3.0
release of Wollongong's IP/TCP software was installed on two VAXes
running VMS.  Both VAXes replied to a Sun's ICMP Address Mask Request
with network masks of 0000FFFF instead of the correct FFFF0000.  The
diskless Sun gullibly swallowed this and began to encapsulate every IP
packet in an Ethernet broadcast packet.  Even after we isolated our
network from the offending VAXes, any Sun in this state would respond
with the bogus netmask to a broadcast from another Sun and thus
continue the problem.

The solution was to disconnect the offending VAXes from the network,
halt ALL the diskless Suns, then reboot them.  After that, we could let
the VAXes back on the network, but it was not really safe since any
diskless Sun reboot would start the cycle over again.

The people who own the VAXes that started the problem have told me
that the problem is really in the Wollongong software (i.e., not a
configuration error) and is a holdover from some "broken 4.3bsd code".
Evidently there are also problems with setting the address mask.
They report that Wollongong has sent them a fix.

==> Potential users of Wollongong 3.0 software should get a fix from
Wollongong before running 3.0 on a network where a machine might
broadcast an ICMP address mask request.

==> Sun should make their networking code smarter.  There is no way a
netmask of 0000FFFF could ever be valid, since it must include the
normal network part of the address as well as the subnet part.  The
Suns should have ignored the faulty replies instead of being driven
berserk by them.  I've reported this to Sun.  The problem doesn't
affect Suns running 3.2 or earlier releases since those releases have
no subnetting support.

It would probably be better if the diskless Sun did not broadcast the
Address Mask Request but instead sent it directly to the server.
I think that the request is broadcast after the ifconfig of the
diskless Sun's Ethernet interface (anyway, an "address mask set to
FFFF0000" report appears on the console quite a while before the
problem shows itself).  If that is so, then it's not clear why an ICMP
Address Mask Request needs to be sent at all, since the network mask
can be specified in the ifconfig in the rc.boot file.

By the way, our class B network is partitioned by level 2 bridges
(Digital DEBETs).  Needless to say, they passed every bad packet and
broadcast right through.  (The VAXes were on the other side of a bridge
from my Suns.)  Yep, I'll be moving my stuff behind an IP gateway now.

Many, many thanks to Van Jacobson for 'tcpdump', which proved
instrumental in tracking this down.  I hope Sun will let Van
release the source code for tcpdump.

	Preston Mullen
	Computer Science and Systems Branch
	Information Technology Division
	Naval Research Laboratory
	Washington DC 20375-5000

P.S.    Why do diskless Sun workstations running SunOS 3.4 broadcast an
	ARP request for IP address 0.0.60.216 very early in the boot
	sequence?  (The ARP packet asks that replies go to 0.0.60.216.)
	This appears to be wired into the Sun networking software.
	It's harmless enough, but it should not be there.  Maybe
	someone forgot to take out some debugging code.

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      Sat, 8-Aug-87 01:48:30 EDT
From:      haque@umn-cs.UUCP (Samudra E. Haque)
To:        comp.protocols.tcp-ip
Subject:   Re: IBM TCP.

> Herewith the DECnet Ethernet address for node 19.53, aka 19509::
> 
> AA-00-03-01-10-E7
> 
> I do not know if this conflicts with any other vendor's address
> assignments.
> 
This message possibly has got nothing to do with the actual subject..
But is there ANY gateway from the INTERNET to DECNET (dec's private
network). Specifically I am interested in contacting an individual who
works in the Sunnyvale Digital ?Plant? ?office?.

He has often said that there is no way that we can get messages
accross the network walls. 

Is there anybody out there willing to give me a route to his node? If
you mail me a note I will mail you back what information he gave me
and will try your suggestion. I am not that terribly familiar of
VMS based networking.


			Samudra E. Haque
			Computer Science Systems Group (CSSG)
			Computer Science Department
			University of Minnesota, Minneapolis
			(612) 625-0876
			haque@umn-cs.ARPA , haque@umn.UUCP

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      Sat, 8-Aug-87 15:46:04 EDT
From:      mcc@ETN-WLV.EATON.COM (Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re:  TELNET ELF

Sorry for not responding earlier to your message, John.

I fully intend to have a robust implementation under IAS; however, I want
to be sure that I understand what TELNET is doing and what it expects.

There are some IAS processes that a user could invoke during a TELNET
session that utilize <CR>, <LF>, or <ESC> as line terminators.  What the 
process will do is dependent upon which line terminator is used.  I would
prefer not to change any of these processes to distinguish between a local
terminal and a TELNET terminal or to prohibit the use of these processes
to a TELNET terminal.

At the moment we have a crude brute force TELNET port which suffers due
to archtectural differences between UNIX and IAS and will produce an
unacceptable system load in the target application system environment.
Our current TELNET port is based on one of our vendors upper layer protocol
support package for his TCP/IP board level implementation for an Ethernet
interface.  It's attrocious!  The code looks okay until you notice '/*'
and '*/' surrounding rather significant portions of code.

When linked to our 4.3bsd gateway machine, we found that it lies about its
ability to perform some of the options.

Unlike Unix, VMS, RSX-11M (11M PLUS), etc. which have device and pseudo
drivers that are integrated into the operating system; IAS has independent
tasks referred to as handlers to support devices and pseudo devices.  The
thought was to split "telnetd" into one portion that was to listen for and
accept connections and to integrate the remainder of it with the pseudo
terminal handler which significantly reduces the number of context switches
that would be required to pass data between the Ethernet interface handler,
telnetd, and pseudo terminal handler.

I could go off and do whatever I please since the rest of the world won't
be permitted access to the network until a "secure" gateway can be developed
but it seemed nicer to plan for the future when there will be a common
backbone for all the networks.

Merton Campbell Crockett

-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      Sat, 8-Aug-87 16:15:04 EDT
From:      karels%okeeffe@UCBVAX.BERKELEY.EDU (Mike Karels)
To:        comp.protocols.tcp-ip
Subject:   Re: Recursive Subnets

Round and round and round we go!  Your suggestion for recursive subnets
is exactly the original Berkeley subnet scheme and proposal (in RFC-something
or other), with the bit T inverted.  (We used T=1 to indicate bottom-level
subnets, T=0 for the trunk network.)

		Mike

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      Sat, 8-Aug-87 19:00:59 EDT
From:      hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   decnet phase V

Sorry, I should have been more clear about the phase V DECnet
addressing.  First let me note that I am basing this on a paper given
a few months ago at an IETF meeting.  I have not seen full
documentation for phase V.  According to this paper the basic DECnet
address will involve 2 bytes of area number and 6 bytes of system ID.
"DEC uses Ethernet absolute host ids in this field to ease address
administration.  The only requirement, however, is that the ID be
unique within an area for level 1 ISs and ESs, and unique within the
domain for level 2 ISs".  It appears that the ISO IS-ES (the ISO
equivalent to ARP) is used, so that there would be no problem handling
machines whose DECnet address differs from the Ethernet address.
There are other features of their addressing that makes it somewhat
more general than what is implied by the description here, but the
document is too vague for me to be sure what it means.  In particular,
an entire set of addresses, using the full 8 bytes described above, is
a "domain".  There is some provision for connecting multiple domains,
using fixed routing tables at the border nodes.  The DECnet format is
designed to use only 8 bytes in a fixed portion of the full ISO
address, in order to facilitate hashing.  There was also a comment in
the talk that if necessary other address formats could be used, but
handling them would be less efficient.  The upshot is that I know of
no problems with phase V DECnet addressing.  Maybe I'll find some once
I see it in detail, of course.

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      Sat, 8-Aug-87 19:40:44 EDT
From:      srg@quick.UUCP (Spencer Garrett)
To:        comp.protocols.tcp-ip
Subject:   Re: telnet CR processing, bridge comm servers and TWG telnet

In article <27@abvax.icd.ab.com>, wrk@abvax.icd.ab.com (William R. King) writes:
> Last week I posted a query about CR processing.
> The problem stemed from the connection between the Bridge CS/1 and
> the BSD 4.3 telnetd. The CS/1 was incorrectly sending \r\n as the
> line terminator instead of the correct \r\0 sequence. The BSD telnetd
> converted the \r\n sequence into \n and sent that into the pty. The
> \n was passed on to TWG telnet which interpeted \n as "delete the 
> word to the left of the cursor". So much for logging in.
> 
> I have since obtained a new release of Bridge CS/1 software (version
> 13000) which fixes the problem. They now offer the option (per port)
> of sending \r\n or \r\0 as the line terminator. 

But this is incorrect!  The Bridge box SHOULD be sending \r\n when you
hit <RETURN> or <ENTER> or whatever it's labelled on your keyboard.
This is the TELNET "end of line" indicator.  Telnetd correctly converts
this to \n which is the equivalent sequence in a UNIX context.  The
problem appears to be the Berkeley telnet program (as opposed to the
daemon) which is failing to convert \n to \n\r like it should, or
perhaps TWG telnet is failing to accept \r\n as the TELNET eol.  The
sequence \r\0 is a "bare" carriage return which should get you to the
beginning of the line WITHOUT ending the line.  This is the behaviour
you would get under UNIX with CRMOD turned off.  The proper sequence
should be:

	You hit <RETURN>
	The Bridge box sends \r\n
	telnetd converts \r\n to \n and feeds it to the pty
	telnet reads \n from its tty (pseudo-tty, but it shouldn't matter)
	telnet sends \r\n through its tcp stream to the vax
	the vax should convert \r\n to whatever it wants for EOL

Making the Bridge box precompensate for a bug elsewhere by sending an
incorrect sequence is not good polican 

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      Sat, 8-Aug-87 20:56:28 EDT
From:      hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   4.3 telnet handling of newline

As far as I can see, the Unix implementors have failed to note that
there are in effect two different end of line conventions in Unix,
conventions for files and those for terminals.  They are turning
telnet NEWLINE into <LF> because <LF> is what you put in a file to
indicate an end of line.  The problem is that telnetd is feeding its
output into a pty, and pty's are terminals.  On a terminal, we expect
a user to type <CR> to indicate end of line.  This is why there is a
special kernel mode to map one convention into the other by turning
<CR> into <LF>.  That allows naive programs to treat a terminal like
any other file, and to see <LF> as newline.  However when a program
goes into raw mode, it see what is actually typed, and so it needs to
be prepared to handle the device-dependent terminal conventions.  Thus
raw-mode programs expect to find <CR> as end of line, since that is in
fact the end of line convention used by terminals.  This is completely
consistent with the rest of Unix, where by default, there is a uniform
model for all device types, but it is possible to set up modes wherein
you see device-specific behavior.  Since telnetd is in effect typing
on a terminal, it is going to have to do things in a device-dependent
way, and issue a <CR> for NEWLINE.

Pragmatically, it probably makes sense to do this conversion in
two stages.  All 4.3 implementations should immediately change telnetd
to turn both <CR><LF> and <CR><NUL> into <CR>.  Only a <LF> should
be turned into <LF>.  I don't see any way that this change can break
things.  And it will allow people to run Emacs and other terminal-
dependent software when connected from implementations that do things
the right way.  Unfortunately, the matching change, which is fixing
telnet to send <CR><LF> (telenet NEWLINE) when the user types <CR>,
may have to be delayed until a site has updated all of its copies of
telnetd.  The problem is if a fixed telnet talks to a broken telnetd,
we will be back into the situation where you can't run Emacs.  One
user suggested an option to select which behavior you want.  I'm sorry
to say that this may really be necessary, or we can dream up a hack
(of a sort that is in fact already in telnetd) for determining
automatically whether the other end is running a broken copy of telnetd,
and adjust accordingly.

The most helpful thing would be for Berkeley to make an official
announcement that telnetd is regarded as broken and should be fixed.
We will attempt to issue SPR's against all of our supported Unix
implementations anyway, but it will be a mess if Berkeley persists in
maintaining that no fix is needed, while most of the users are
convinced that one is.  Since the fixed to telnetd it to accept
connections from either style of telnet, this can't possibly lose
anything, except for the ability to have hitting the CR key put
LF into a pty at the other end.  And I can't figure out any practical
use for that.

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      Sat, 8-Aug-87 21:46:23 EDT
From:      phil@BRL.ARPA (Phil Dykstra)
To:        comp.protocols.tcp-ip
Subject:   Re:  No echo from the NIC

Last time I looked at traffic from the NIC they seemed to be spending
most of their time sending ICMP Source Quenches in response to nameserver
requests.  The nameserver system is probably the major reason for their
load.  Some statistics gathered a month or two ago showed them fielding
an average of four queries a second.

- Phil

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      Sun, 9-Aug-87 05:30:40 EDT
From:      chris@COLUMBIA.EDU (Chris Maio)
To:        comp.protocols.tcp-ip
Subject:   Re: BSD route daemon

Kurt,

  you might be interested in what we did at Columbia.  We needed to partition
our network into different sized subnets, had to make the subnetting
transparent to hosts that don't implement subnets, and needed to support
ethernet bridges as well as IP gateways (for DECnet, etc), with multiple
subnets on the same ethernet cable, etc.

  Surprisingly, all it took to make this work was a few small changes to the
4.3bsd kernel in our IP gateways, to support proxy arp and a limited form of
variable width subnets; static routes (other than a default route) and routed
aren't necessary at all.  Subnet numbers are assigned naturally, e.g. large
departments have larger subnets than small departments, and a departmental
subnet can be further subdivided into smaller subnets.

  The basic strategy is that, since our network is more or less hierarchical,
every gateway has exactly one interface which is closest to the backbone, and
because subnet number/mask assignments match the physical topology, in the
absence of static routes the interface to which a packet should be sent is a
simple function of the destination address and the address and subnet mask for
each interface.  Even if a gateway isn't sure where the destination host is, it
always knows the correct interface to route to, and then proxy arp can be used
to find the next hop.  The proxy arp support in the gateways also means that no
changes are necessary to any host implementations.

  The two obvious restrictions are that (a) you have to stick to a hierarchical
topology, and (b) you have to put up with proxy arp broadcasts, which have to
be processed or discarded by every host on the ethernet cable.  In practice,
these aren't a problem for us; the hierarchical network is a fine match for the
structure of the university, and there are various ways to reduce the proxy arp
overhead, which is much less than you'd have if you used only ethernet bridges.
Of course, we're stuck with using either 4.3bsd gateways or ethernet bridges
until gateway vendors decide to support variable-width subnets.

  The advantages are that we can use different sized subnets, divide subnets up
into smaller subnets, replace ethernet bridges with IP gateways or vice versa
(or run them in parallel) with minimal hassles, and we don't need to run routed
or install static routes.  Most importantly, hosts that don't support subnets
can still talk to everybody else.

  Obviously this isn't a general solution, particularly because it depends on
the misuse of arp, but it's the only one available today that works in our
environment.
						Chris

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      Sun, 9-Aug-87 08:02:44 EDT
From:      hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   Re:  Ethernet problems induced by bogus ICMP Address Mask Reply

I believe your ARP request for 0.0.60.216 is used during the boot
sequence, at a point when the Suns don't know their Internet address.
They seem to use their serial number as an address.  You'll also find
such addressing in the routing tables in certain versions of SunOS.
I suggest that you take 60 * 256 + 216, and see if you don't have
a Sun with that serial number.

-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      Sun, 9-Aug-87 12:57:25 EDT
From:      PERRY@VAX.DARPA.MIL (Dennis G. Perry)
To:        comp.protocols.tcp-ip
Subject:   Re: WISCVM FUTURE

I should point out that any official gateway to BITNET from the Arpanet
need approval from DARPA.

dennis
-------

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      Sun, 9-Aug-87 15:11:59 EDT
From:      ron@TOPAZ.RUTGERS.EDU (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re:  Telnet CRLF's

I think the issue is getting a little confused here between what
is in the SPEC, what UNIX wants to do, and how UNIX accomplishes
it's goal.

THE SPEC:
    The image of a terminal is something with a big RETURN, ENTER, or
<--|, (I cant draw this) key.  The latter label is perhaps the most
descriptive showing both the down and return indicating a new line.
If you just want a down motion, then press the LINE FEED.  If for some
reason you want to return without new lining (<-<-- key) then send CR-NUL.

So the terminal should

    RETURN (down and left) send CR-LF
    LF (down) send LF
    <-<--- key or perhaps an escaped (quoted) RETURN (^Q^M for EMACS users)
	    send CR-NUL.

on receipt, the exact same semantics should apply.

UNIX:
    The UNIX internal model is that LF is the end of line.  CR is just
    a character and there is no explicit way to do other positioning.
    Since about the only terminal that works this way is the Model 37
    teletype, there is a compatibility feature, referred to as CRMOD
    or -nl mode.  This maps CR to NL on input and NL to CRLF on output.

THE PROBLEM:
    The reason UNIX gets really confusing in TELNET is that CRMOD can
    not be turned off in only one direction, so anyone who wants to
    buypass the output mapping to do finer positioning must suddenly
    start doing the processing for CR as end-of-line in their user
    code.

So the question is should the translation go

TERMINAL (CR) -> NVT (CR-LF) -> UNIX (LF) for line termination

we can emulate what UNIX thinks a terminal ought to me (like a Model 37)

or

TERMINAL (CR) -> NVT (CR-LF) -> Real World Virtual Terminal (CR) -> UNIX (LF)

for line termination.  The answer is probably the latter.  NVTs and the rest
of the world look a whole lot more like the VT100s than Model 37s.  Hence,
the UNIX telnet server should try to map the NVT back into the CR terminated
world before passing it to the UNIX tty driver.  UNIX programs violate the
LF termination rule all the time to do things such as line editing and such
because they know that there just aren't that many Model 37s left in operation.
To avoid surprises the NVT->UNIX transformation ought to make the incoming
TELNET look like that rather than attempting to map directly from NVT to
UNIX tty conventions.

-Ron

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      9 Aug 87 22:58:03 GMT
From:      mangler@csvax.caltech.edu  (System Mangler)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: RFS vs NFS
In article <3681e98d.b8ab@apollo.uucp>, rees@apollo.uucp (Jim Rees) writes:
> technical difference is that NFS is stateless, and RFS statefull.
> This means you get exact unix file system semantics with RFS, but
> not with NFS.  On the other hand, NFS clients are able to recover
> from server crashes without a glitch, and continue processing where
> they left off before the crash.

The claim of statelessness should not be taken too literally.  When one
of our disks got trashed (@*#% Xylogics!), we did the "obvious" thing -
we took the server down, created the filesystem afresh, restored all of
the backup tapes, and then let the clients continue where they left off
before the crash.  Talk about some confused clients...

"Stateless" only means that the state is kept on disk rather than RAM.

Don Speck   speck@vlsi.caltech.edu  {ll-xn,rutgers,amdahl}!cit-vax!speck
-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      10 Aug 87 03:56:21 GMT
From:      soliloquy.rutgers.edu!dpz@RUTGERS.EDU  (David P. Zimmerman)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: RFS vs NFS
In article <3537@cit-vax.Caltech.Edu> mangler@cit-vax.Caltech.Edu (System Mangler) writes:

> The claim of statelessness should not be taken too literally.  When one
...
> before the crash.  Talk about some confused clients...

Sun's ND (one of the weirdest beasts around) isn't stateless, you
can't use that as an example in this case.

					dpz
-- 
David P. Zimmerman           rutgers!dpz           dpz@rutgers.edu
-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10-Aug-87 08:15:16 EDT
From:      snorthc@NSWC-OAS.ARPA
To:        comp.protocols.tcp-ip
Subject:   Re:  No echo from the NIC

I have seen several replies from users saying they only ping the NIC
when they can't make a connection.  I was just looking through a
manual for TCP for PCs.  The example they give for ping is:
ping -t sri-nic.arpa where -t is an option to ping repeatedly.

Stephen Northcutt (snorthc@nswc-g.arpa)

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10-Aug-87 09:31:12 EDT
From:      timk@NEWTON.NCSA.UIUC.EDU (Tim Krauskopf)
To:        comp.protocols.tcp-ip
Subject:   Re:  Ethernet problems induced by bogus ICMP Address Mask Reply

We encountered the exact same problem (diagnosed with tcpdump) between our
diskless Sun 3/50 (SunOS 3.3) and a Vaxstation (TWG under VMS).  The icmpmask
response from TWG is backwards.

Easy work-around while waiting for bug fixes from TWG:
  Install the netmask parameter in the rc.boot files (ifconfig lines) of as
  many diskless Suns as you feel like.
  Each of the Suns with the mask installed will operate correctly.
  For the rest of the machines, the russian roulette has much better odds:
  When the ICMP request goes out, there are several Suns waiting to respond
  and they are faster at responding than the VAXen.  Whoever gets there first
  wins.

Isn't this fun?

Tim Krauskopf
National Center for Supercomputing Applications
University of Illinois
timk%newton@uxc.cso.uiuc.edu

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10-Aug-87 10:10:00 EDT
From:      DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer)
To:        comp.protocols.tcp-ip
Subject:   Re: IBM TCP. Really DECnet and Ethernet addresses


    Date: 7 Aug 87 14:00:44 GMT
    From: mcvax!ukc!its63b!adam@seismo.css.gov  (ERCF02 Adam Hamilton)

    In IEEE802 and also XEROX Blue book, the format of an Ethernet address
    is defined as having two special bits; these are the first two to be
    transmitted.  Note that bits in an octet are transmitted
    LEAST significant bit first, therefore these bits are the LEAST
    significant bits of the first octet.
	    The first bit signifies whether the address is individual or local,
    the second signifies whether the address is globally (value 0) or locally
    administered.  In the above example (AA-00- etc.) the second bit is set,
    therefore the address is locally administered.
	    All address allocations to manufacturers are globally administered.
    All VMS machines I have seen have addresses which start AA-00.  All this
    means that DECnet style addresses are NOT globally unique (as discussed)
    but do NOT use values which are globally administered.  This should make no
    difference unless the same address is used on more than one Ethernet
    when a bridge (specifically selective frame-level repeater) may well get
    confused.
	    Presumably this bit was put in for DEC's benefit, but I'm just
    guessing here.

I guess I'm hopelessly out of date.  My copy of the Blue Book is Version
1.0, Sepetmber 30, 1980.  In it, in section 6.2.1 on page 21, there is
no mention of this second bit being for local/global administration.  In
fact, of the physical address it says
	"A station's physical address should be distinct from the
	physical address of any other station on @i(any) Ethernet."
The italics are in the book.  Time marches on... standards change...

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10-Aug-87 13:17:55 EDT
From:      HANK@TAUNIVM.BITNET (Hank Nussbacher)
To:        comp.protocols.tcp-ip
Subject:   VMS and X.25

I have been looking at various VMS and microVMS solutions for Tcp/Ip
(Excelan, Interlan-Micom, Wollongong, SRI, Hyperlink, etc.) and all
of them assume an Ethernet.  How do sites connect lone VMS systems that
are geographically scattered over many kilometers?  The expensive solution
is to build a 1 meter Ethernet, buy a bridge and connect that way.  Do any
of these systems handle X.25?  What h/w do you need to buy?  Will the
Excelan and Interlan solutions work with an X.25 card or can an X.25
solution only be handled by a strictly software implementation (like
Wollongong or Hyperlink)?  Is there a way to do it with a leased line
without Ethernet or a bridge?

Thanks,
Hank

P.S. Plz send all replies directly to me.

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10-Aug-87 14:38:52 EDT
From:      sid@llama.rtech.UUCP (Sid Shapiro)
To:        comp.protocols.tcp-ip
Subject:   Re: telnet CR processing, bridge comm servers and TWG telnet

This is  going back a bit, and may not even be the same thing, but when I
switched a system to 4.3, we could no longer get a <CR> characters into
emacs (or vi for that matter, but vi didn't really care too much).  If
I remember correctly, the 4.3 telnetd was "smarter" - it could map
<CR>s to <NL>s if you wanted it to (default behavior).  This screwed
up the Bridge boxes, cause the bridge telnet client didn't have a
command to reset the telnetd to go back to the less smart behavior.  I
had to hack telnetd to turn off the mapping.

-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10-Aug-87 15:09:58 EDT
From:      jaj@utacs.UTA.FI (Jari J{ntti)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   NCSA Telnet for micros?

Please, anybody with ARPANET access, make the new NCSA TELNET for micros 
available through UUCP.

Below is the original announcement seen here a while ago.

Jari Jantti
Computing Centre
Univ. of Tampere, FINLAND
JJANTTI@FINFUN.BITNET



<<<original message begins>>>

From: timk%newton@UXC.CSO.UIUC.EDU (Tim Krauskopf, NCSA)
Newsgroups: comp.protocols.tcp-ip
Subject: Telnet for micros available
Message-ID: <8706282321.AA11880@babbage.ncsa.uiuc.edu>
Date: 28 Jun 87 23:41:57 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 87

---------------------------------------------

The National Center for Supercomputing Applications (NCSA) at the
University of Illinois has prepared and is distributing a telnet package
for IBM compatibles and Macintoshes.  It has many features that we haven't
found in anyone else's software.  If you have trouble getting it to run,
make sure I get a full description of your hardware setup including DOS
version.  I hope you like it.

Tim Krauskopf
Project leader, NCSA Telnet



release info:

National Center for Supercomputing Applications presents:

NCSA Telnet for the PC, version 1.1
NCSA Telnet for the Macintosh, version 1.1

These programs are copyrighted, but distributed in binary form with 
no license fee.  Source code is not available.  We are exploring the
possibility of distributing linkable libraries which support TCP/IP.


Features included in version 1.1 of NCSA Telnet:
-----------------------------------------------
DARPA standard telnet 
Built-in standard FTP server for file transfer
VT102 emulation in multiple, simultaneous sessions
Class A,B and C addressing with standard subnetting
Each session in a different window (Macintosh)
Tektronix 4010 graphics emulation (Macintosh)
Supports Croft gateway, i.e. KIP (Macintosh)
Capture text to a file (PC)
Full color support (PC)

How to obtain:
-------------
Anonymous FTP from   uxc.cso.uiuc.edu   in the NCSA subdirectory.

The PC version is a tar file which contain binary files.  After the
files are extracted from the tar file, some binary transfer (e.g.
kermit) should be used to download the files to the PC.  The
Macintosh version is several files encoded with BinHex 4.0.  Download
them with a similar transfer method (kermit) and use BinHex 4.0 to
extract the files.  Printable documentation is included with each
version; the Mac documentation is in MacWrite format.  After
downloading, you may copy the files as often as you wish, unmodified,
in binary form, with the copyright notices intact.

The PC version is also on this dial-up BBS:
The University of Illinois Excel project BBS:
(217)333-8301                    file name: NCSATEL.ARC
300-1200-2400 baud               size: 85K
Kermit/Xmodem

On-disk copies, with a printed manual are available for $20 each,
which covers handling and postage.  Orders can only be accepted if
accompanied by a check made out to the University of Illinois.  Send
to:

NCSA Telnet orders (specify PC or Macintosh version)
152 Computing Applications Building
605 E. Springfield Ave.
Champaign, IL 61820

Hardware required:
-----------------
PC: IBM PC, AT or 100% compatible. 3COM 3C501 Etherlink board.
	Support for other boards planned, which would you require?

Mac: Macintosh 512K, Plus, SE or Macintosh II.  
	Kinetics, Inc. FastPath, EtherSC or Etherport SE board.
	Kinetics gateway software or Stanford KIP (Croft) gateway software.

The best source of information about Kinetics is directly from the company.
Kinetics Inc.                     FastPath approx. $2500
Suite 110                         EtherSC approx. $1250
2500 Camino Diablo                educational and volume discounts
Walnut Creek, CA  94596
(415) 947-0998

Other questions:
---------------
mail to telbug%newton@uxc.cso.uiuc.edu


<<<<<<end of orig. msg>>>>>>>

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10-Aug-87 16:15:34 EDT
From:      PADLIPSKY@A.ISI.EDU (Michael Padlipsky)
To:        comp.protocols.tcp-ip
Subject:   Re: No echo from the NIC

Ken [and interested onlookers]--

I am appalled to have to report that I can't find "But My NCP Costs
$X00 a Day..." despite the facts that 1) I could have sworn I'd done
such a thing and 2) running my finger down all the lines of RFC 1012
should have confirmed it.  Either it was done as a Project MAC Memo
and didn't get out on the net, or it's hidden away under some  other
title (RFC 411, "New Multics Network Software Features," is a possibility,
but I can't get through to the NIC to check up), or (shudder) perhaps
there's an error of omission in RFC 1012....

Of course, the incident is immortalized, albeit in highly capsulized
form, in The Book: Horror Story Number 5, pp. 85-6 (and corresponding
Trailer Cartoon on p. 88); indeed, it seems to me I just cited it the
other week in a somewhat different context here on the List.  But that
isn't as gratifying as being able to point to a 14 (at least) year old
RFC (or MAC Memo, I guess).

Perhaps needless to say, I join you in urging all readers of this List
to be particularly cautious not to cause squandering of others' cpu
cycles, even if we can't prove just how long we've been preaching
that particular position.

cheers, map
-------

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      10 Aug 1987 16:15:34 EDT
From:      Michael Padlipsky <PADLIPSKY@A.ISI.EDU>
To:        Ken Pogran <pogran@CCQ.BBN.COM>
Cc:        "GBURG::ENGER" <enger%gburg.decnet@BLUTO.SCC.COM>, "tcp-ip" <tcp-ip@SRI-NIC.ARPA>, enger@BLUTO.SCC.COM
Subject:   Re: No echo from the NIC
Ken [and interested onlookers]--

I am appalled to have to report that I can't find "But My NCP Costs
$X00 a Day..." despite the facts that 1) I could have sworn I'd done
such a thing and 2) running my finger down all the lines of RFC 1012
should have confirmed it.  Either it was done as a Project MAC Memo
and didn't get out on the net, or it's hidden away under some  other
title (RFC 411, "New Multics Network Software Features," is a possibility,
but I can't get through to the NIC to check up), or (shudder) perhaps
there's an error of omission in RFC 1012....

Of course, the incident is immortalized, albeit in highly capsulized
form, in The Book: Horror Story Number 5, pp. 85-6 (and corresponding
Trailer Cartoon on p. 88); indeed, it seems to me I just cited it the
other week in a somewhat different context here on the List.  But that
isn't as gratifying as being able to point to a 14 (at least) year old
RFC (or MAC Memo, I guess).

Perhaps needless to say, I join you in urging all readers of this List
to be particularly cautious not to cause squandering of others' cpu
cycles, even if we can't prove just how long we've been preaching
that particular position.

cheers, map
-------
-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10-Aug-87 16:21:56 EDT
From:      haynes@ucscc.UCSC.EDU.ucsc.edu (99700000)
To:        comp.protocols.tcp-ip
Subject:   Subnets on TEK/CMU package

We'd like to know if the CMU distribution supports subnetting class B
network numbers, and if so how to configure it, and if not is anybody
planning to add this feature?


haynes@ucscc.ucsc.edu
haynes@ucscc.bitnet
..ucbvax!ucscc!haynes

-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10-Aug-87 17:35:19 EDT
From:      barmar@think.COM (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: telnet CR processing, bridge comm servers and TWG telnet

In article <109@quick.UUCP> srg@quick.UUCP (Spencer Garrett) writes:
>	You hit <RETURN>
>	The Bridge box sends \r\n

You said this twice in your message without justifying it.  The key is
labeled RETURN, which is generally taken to be a synonym for CR.  The
TELNET spec says that CR should be represented in NETASCII as CRNUL.
Why should the Bridge box assume that CR is NEWLINE?

>	telnetd converts \r\n to \n and feeds it to the pty
>	telnet reads \n from its tty (pseudo-tty, but it shouldn't matter)
>	telnet sends \r\n through its tcp stream to the vax
>	the vax should convert \r\n to whatever it wants for EOL

What if the program on the VAX wants to see the raw characters that
the user typed, which happens in programs such as EMACS?  This means
that if the user types CR it will get translated into the VAX's EOL
sequence, and the program may not see the CR that the user typed.
Your scenario only works if the remote system is in line-at-a-time
mode.

The reason for all the confusion that the TELNET spec has caused is
that NETASCII is used for more than terminal emulation.  It is used in
FTP, for example, to support the control connection and text-mode file
transfers.  In these cases, things like End-of-Line have much more
obvious meaning, or at least the need for a standard representation is
obvious (some systems use a character sequence to indicate newline,
others use a record structure).  In terminal emulation, whether the
RETURN key indicates End-of-Line is totally context dependent.  In
EMACS I can map any key to any operation, and I don't want the network
to transform my keyboard for me.

---
Barry Margolin
Thinking Machines Corp.

barmar@think.com
seismo!think!barmar

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10-Aug-87 18:34:04 EDT
From:      titley@btnix.axion.bt.co.uk (Nigel Titley)
To:        comp.protocols.tcp-ip
Subject:   Re: fyi Wollongong TCP/IP for VAX/VMS - Reply to Mark Crispin

The latest release of Woolongong TCP/IP may  well be  bug free  but at  5000
pounds per VaxStation (the price we  were quoted  by GEC  who distribute  it
over here in the UK), it's not likely that we're going for it in a hurry.

For comparison the VaxStation sells for about 4000 pounds.
-- 
Email: NTitley@axion.bt.co.uk
Snail: British Telecom Research labs, Martlesham Heath, Ipswich, Suffolk, UK
"I do not care what happens now: I have seen dragons on the wings of morning"

-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10-Aug-87 20:15:10 EDT
From:      chris@gargoyle.UChicago.EDU (Chris Johnston)
To:        comp.protocols.tcp-ip
Subject:   Re:  How do you break up a B class number?

> [paraphrased] we intend to put around 1000 hosts on our backbone.

This has got to be a big lose.  I can think of all kinds of
problems...  And never mind whether or not one segment can support
all that traffic.

Each of the hosts connected to our backbone is a gateway.
Our backbone is implemented with fiber optics rather than coax.

By isolating the major segments of our net behind gateways, we
isolate broken subnets from the rest of the world.  Subnets get
broken in an amazing number of ways.  Electrician/plumber/carpenter
walks near the cable.  Professor unplugs the two thin ethernet cables
from the back of his workstation to rearrange his furniture (no thin
coax in this dept.)  Technician makes a lousy tap and shorts out the
segment.  Technician disconnects the 50 ohm terminator to put an
oscilloscope on the cable (!!!).

The fiber discourages people from making unauthorized taps and is
small enough to be secured out of the way of most harm.

Breaking the net into reasonably small segments is a major debugging
assist.

Of course we are limited to a single protocol (TCP/IP), but since we
want to talk to the rest of the planet we have no choice.  And one
can always pull another pair of fiber and run other protocols on it.

cj

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 Aug 87 14:14 IST
From:      Hank Nussbacher <HANK%TAUNIVM.BITNET@wiscvm.wisc.edu>
To:        <tcp-ip@sri-nic.ARPA>
Subject:   VMS and X.25
I have been looking at various VMS and microVMS solutions for Tcp/Ip
(Excelan, Interlan-Micom, Wollongong, SRI, Hyperlink, etc.) and all
of them assume an Ethernet.  How do sites connect lone VMS systems that
are geographically scattered over many kilometers?  The expensive solution
is to build a 1 meter Ethernet, buy a bridge and connect that way.  Do any
of these systems handle X.25?  What h/w do you need to buy?  Will the
Excelan and Interlan solutions work with an X.25 card or can an X.25
solution only be handled by a strictly software implementation (like
Wollongong or Hyperlink)?  Is there a way to do it with a leased line
without Ethernet or a bridge?

Thanks,
Hank

P.S. Plz send all replies directly to me.
-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10-Aug-87 22:24:21 EDT
From:      roy@phri.UUCP (Roy Smith)
To:        comp.protocols.tcp-ip
Subject:   Blue Book

I keep seeing references to "The Blue Book".  What, exactly, is that?  I
have a small (about the size of the 11/45 hardware manual) blue-covered
paperback book that DEC put out a few years back called something like
"Introduction to Local Area Networks".  Is that "The Blue Book"?
-- 
Roy Smith, {allegra,cmcl2,philabs}!phri!roy
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10-Aug-87 22:58:00 EDT
From:      BEAME@MCMASTER.BITNET
To:        comp.protocols.tcp-ip
Subject:   Re: TELNET <CR> <LF>


   When I was converting my PC VT100 emulator to run TELNET TCP/IP, I found
myself with a problem. My emulator allows the user to define ANY key to
mean ANYTHING. Therefore the big key with the arrow ( <-- ) on it did not
always mean the End-Of-Line character. What should I send when it was hit ?

   Though it violated the spec. I decided not to have an EOL key, but to send
exactly what the user requested when he defined the keyboard. The normal
mapping had <CR> go to <CR> and <LF> go to <LF>, no conversion was done.

GUESS WHAT !!!! When running to BSD 4.2/4.3, TWG, Ultrix 1.2, KNET and
Bridge CS/100's to VMS vaxen and an IBM 7171, EVERYTHING worked. The VMS
vax recognised the <CR> as a <RETURN> on a terminal and the <LF> as
delete the last word. BSD and Ultrix had no problems in determining what
was meant by the user.

Could this not be an interm solution till all is well (assuming all is not
considered well now) ?

     Carl Beame
     BEAME@MCMASTER.BITNET

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 Aug 87 22:58 EDT
From:      <BEAME%MCMASTER.BITNET@wiscvm.wisc.edu>
To:        tcp-ip@sri-nic.arpa
Subject:   Re: TELNET <CR> <LF>

   When I was converting my PC VT100 emulator to run TELNET TCP/IP, I found
myself with a problem. My emulator allows the user to define ANY key to
mean ANYTHING. Therefore the big key with the arrow ( <-- ) on it did not
always mean the End-Of-Line character. What should I send when it was hit ?

   Though it violated the spec. I decided not to have an EOL key, but to send
exactly what the user requested when he defined the keyboard. The normal
mapping had <CR> go to <CR> and <LF> go to <LF>, no conversion was done.

GUESS WHAT !!!! When running to BSD 4.2/4.3, TWG, Ultrix 1.2, KNET and
Bridge CS/100's to VMS vaxen and an IBM 7171, EVERYTHING worked. The VMS
vax recognised the <CR> as a <RETURN> on a terminal and the <LF> as
delete the last word. BSD and Ultrix had no problems in determining what
was meant by the user.

Could this not be an interm solution till all is well (assuming all is not
considered well now) ?

     Carl Beame
     BEAME@MCMASTER.BITNET
-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10-Aug-87 23:07:23 EDT
From:      sy.Ken@CU20B.COLUMBIA.EDU (Ken Rossman)
To:        comp.protocols.tcp-ip
Subject:   Re: IBM TCP.


  Herewith the DECnet Ethernet address for node 19.53, aka 19509::

  AA-00-03-01-10-E7

I'm afraid I fail to see where you get AA-00-03-01-10-E7 from 19.53.

First of all, the DECnet-transformed ethernet address should start with
AA-00-04-00.  Secondly, the last two octets of the DECnet/ethernet address
is the 16 bit DECnet node number, which consists of 6 high order bits of
area, and 10 low order bits of node number.  The bytes are swapped also.

So in the above example, if you take the last two bytes, 10 and E7, swap
them to get E710, and then break them down to 6 and 10 bit groups, you get:

    111001  1100010000
    (area)  (node num)

or, node 57.784.

This ethernet address was probably still the original hardware address
before DECnet got ahold of it and mangled it.  /Ken
-------

-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10-Aug-87 23:17:13 EDT
From:      sy.Ken@CU20B.COLUMBIA.EDU (Ken Rossman)
To:        comp.protocols.tcp-ip
Subject:   Re: IBM TCP. Really DECnet and Ethernet addresses


	"A station's physical address should be distinct from the
	physical address of any other station on @i(any) Ethernet."

  The italics are in the book.  Time marches on... standards change...

It would seem to me that it would be hopelessly difficult to try to
administer a flat global set of ethernet addresses, and that some sort of
mechanism, such as the global/local bits at the beginning would have to
exist.  In any case, regardless of how a spec says it SHOULD be, the real
world appears to be allocating blocks of ethernet addresses to vendors to
be used as they (or their customers) see fit.

Along slightly different lines, I fail to see how the global ethernet
addressing scheme, whether managed as a flat address space or in some
hierarchical fashion, hasn't blown up yet.  I mean there just aren't that
many addresses available.  Just as an isolated example, what happens to
ethernet addresses on failing boards?  We've probably had the ethernet
board on one of our -20's replaced three times already.  Am I to believe
that DEC Field Service records these hardware addresses, and when bad
boards come back that can't be repaired, they tell some global address
administrator that this particular hardware address has now been freed and
can be used again?

/Ken
-------

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11-Aug-87 00:00:01 EDT
From:      A.Eric@GSB-HOW.STANFORD.EDU (Eric M. Berg)
To:        comp.protocols.tcp-ip
Subject:   Mailing to DEC Easynet

[My apologies for posting this to the entire list, but the return-address on
the original message (umnd-cs!umn-cs!haque@ucbvax.Berkeley.EDU) didn't work.]


DEC's internal network (called "Easynet") is connected to the Internet via
host DECWRL.DEC.COM (which is also a UUCP backbone node).  The syntax is
    user%host.dec@decwrl.dec.com

You need to get the name of the Easynet host, and the user-name of the person
you want.  (Often user-names seem to consist of the first two character of
the person's first name appended to their last name... so I'd be "BergEr".)

It's helpful to know that DEC Easynet nodes seem to have two different names
each: a DECnet node name, and an internet-style name.  So, for example, most
of the Santa Clara office sales people have accounts on "USWRSL.DEC.COM"
("US Western Region SaLes", as close as I can guess), which is also known
as "RHEA" (DECnet node name).

You can try sending mail to Postmaster@DECWRL.DEC.COM... I've found the people
there to be very helpful in sorting this stuff out.

						Eric M. Berg
						Computer Facility
						Graduate School of Business
						Stanford University
-------
-------

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11-Aug-87 04:21:04 EDT
From:      JTW@XX.LCS.MIT.EDU (John T. Wroclawski)
To:        comp.protocols.tcp-ip
Subject:   Re: telnet CR processing, bridge comm servers and TWG telnet

Summary: Chuck Hedrick's recent letter hit the nail on the head.

    From: barmar@think.com (Barry Margolin)
    Subject: Re: telnet CR processing, bridge comm servers and TWG telnet

    In article <109@quick.UUCP> srg@quick.UUCP (Spencer Garrett) writes:
    >	You hit <RETURN>
    >	The Bridge box sends \r\n

    You said this twice in your message without justifying it.  The key is
    labeled RETURN, which is generally taken to be a synonym for CR. The
    TELNET spec says that CR should be represented in NETASCII as CRNUL.
    Why should the Bridge box assume that CR is NEWLINE?

Because it is the character most often sent by the key that most
people using terminals likely to be hooked to Bridge boxes use for
EOL, and you have to have some way to send a NEWLINE.

However, it doesn't really matter -what- the bridge box sends. The only
thing that matters is that the terminal<->NETASCII<->machine transformation
be invisible. 

For unix-like systems this is easily achieved by having the server telnet
translate incoming CR-LF and CR-NUL to CR, and incoming LF to LF. This
result is then stuffed into the PTY, where normal terminal processing
(CRMOD) takes care of the rest, including your objection below. (Which
-is- a problem if CR-LF translates to LF, as Spencer suggested.)

    >	telnetd converts \r\n to \n and feeds it to the pty
    >	telnet reads \n from its tty (pseudo-tty, but it shouldn't matter)
    >	telnet sends \r\n through its tcp stream to the vax
    >	the vax should convert \r\n to whatever it wants for EOL

    What if the program on the VAX wants to see the raw characters that
    the user typed, which happens in programs such as EMACS?...

-------

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11-Aug-87 08:56:00 EDT
From:      SYSTEM@CRNLNS.BITNET
To:        comp.protocols.tcp-ip
Subject:   DECnet Ethernet interface addresses (was Re: IBM TCP)

Ken,

In message <12325520704.139.SY.KEN@CU20B.COLUMBIA.EDU>
you commented:

>I'm afraid I fail to see where you get AA-00-03-01-10-E7 from 19.53.
>...
>or, node 57.784.

Well, I'm afraid I didn't get it: DECnet did. I guess it doesn't
use your algorithm.

Herewith the Ethernet address used by the same node with the same
hardware interface after I changed its address to be 43.298
= 44330 decimal (1024*43+298).

(We are in the process of vacating area 19 so someone else can use it.)

The following report was generated by the command
"MCR NCP SHOW KNOWN LINE CHARACTERISTICS"

Known Line Volatile Characteristics as of 11-AUG-1987 08:38:42

Line = UNA-0

Receive buffers          = 6
Controller               = normal
Protocol                 = Ethernet
Service timer            = 4000
Hardware address         = AA-00-03-01-1D-E7
UNA device buffer size   = 1498

I hope this helps.

Selden E. Ball, Jr.
(Wilson Lab's network and system manager)

Cornell University                 NYNEX: +1-607-255-0688
Laboratory of Nuclear Studies     BITNET: SYSTEM@CRNLNS
Wilson Synchrotron Lab              ARPA: SYSTEM%CRNLNS.BITNET@WISCVM.WISC.EDU
Judd Falls & Dryden Road          PHYSnet/HEPnet/SPAN:
Ithaca, NY, USA  14853             LNS61::SYSTEM = 44283::SYSTEM (node 43.251)

-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Aug 87 08:56 EDT
From:      <SYSTEM%CRNLNS.BITNET@wiscvm.wisc.edu>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   DECnet Ethernet interface addresses (was Re: IBM TCP)
Ken,

In message <12325520704.139.SY.KEN@CU20B.COLUMBIA.EDU>
you commented:

>I'm afraid I fail to see where you get AA-00-03-01-10-E7 from 19.53.
>...
>or, node 57.784.

Well, I'm afraid I didn't get it: DECnet did. I guess it doesn't
use your algorithm.

Herewith the Ethernet address used by the same node with the same
hardware interface after I changed its address to be 43.298
= 44330 decimal (1024*43+298).

(We are in the process of vacating area 19 so someone else can use it.)

The following report was generated by the command
"MCR NCP SHOW KNOWN LINE CHARACTERISTICS"

Known Line Volatile Characteristics as of 11-AUG-1987 08:38:42

Line = UNA-0

Receive buffers          = 6
Controller               = normal
Protocol                 = Ethernet
Service timer            = 4000
Hardware address         = AA-00-03-01-1D-E7
UNA device buffer size   = 1498

I hope this helps.

Selden E. Ball, Jr.
(Wilson Lab's network and system manager)

Cornell University                 NYNEX: +1-607-255-0688
Laboratory of Nuclear Studies     BITNET: SYSTEM@CRNLNS
Wilson Synchrotron Lab              ARPA: SYSTEM%CRNLNS.BITNET@WISCVM.WISC.EDU
Judd Falls & Dryden Road          PHYSnet/HEPnet/SPAN:
Ithaca, NY, USA  14853             LNS61::SYSTEM = 44283::SYSTEM (node 43.251)
-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      11 Aug 87 13:46:00 PST
From:      <art@acc.arpa>
To:        "sy.ken" <sy.ken@cu20b.columbia.edu>
Cc:        tcp-ip@sri-nic.arpa,art
Subject:   Ethernet Address Space

>It would seem to me that it would be hopelessly difficult to try to
>administer a flat global set of ethernet addresses, and that some sort of
>mechanism, such as the global/local bits at the beginning would have to
>exist.  In any case, regardless of how a spec says it SHOULD be, the real
>world appears to be allocating blocks of ethernet addresses to vendors to
>be used as they (or their customers) see fit.

Vendors are ASSIGNED blocks of addresses which they are responsible for
assigning to their interface boards.  When a block is exhausted, another
can be acquired (from Xerox originally, IEEE now).  DEC is one of the few
I know of that has more than on assigned block (SUN probably does by now).

>Along slightly different lines, I fail to see how the global ethernet
>addressing scheme, whether managed as a flat address space or in some
>hierarchical fashion, hasn't blown up yet.  I mean there just aren't that
>many addresses available.  Just as an isolated example, what happens to
>ethernet addresses on failing boards?  We've probably had the ethernet
>board on one of our -20's replaced three times already.  Am I to believe
>that DEC Field Service records these hardware addresses, and when bad
>boards come back that can't be repaired, they tell some global address
>administrator that this particular hardware address has now been freed and
>can be used again?

I don't think that this is a problem yet.  The Ethernet addresses are 48 bits
long, minus one or two for format flags.  This still leaves roughly
64 TRILLION possibilities.  Even if the address space is only 0.01% utilized,
that leaves roughly 6 BILLION Ethernet interfaces.

						Art Berggreen
						art@acc.arpa

------
-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11-Aug-87 09:51:33 EDT
From:      kluger@roundhouse.UUCP (Larry Kluger Sun Europe)
To:        comp.protocols.tcp-ip
Subject:   Ethernet addresses

Hi,

I've been watching this discussion go for a couple days now and have
found the mis-communications between people of this distribution list
(who are all communications 'experts') quite interesting.

Let me take a whack at a few points.

First, brief personal background: I was in charge of the internetwork
routing software for XNS at Xerox Palo Alto from mid '81 through '86.
I didn't design the stuff, Yogen Dalal, Hal Murray, Dave Boggs, Larry Garlick,
Alan Freier, and others did that. But I had lots of discussions with
those folks over the years on the subject of "why it was done that way."

----------

First, addressing uniqueness. Alto's used the 3 MBit Ethernet which had 
8 bit addressing at the link level. Everytime you installed an Alto, the
tech had to open the machine and futz with the 8 jumpers which set the
binary address to be 0-255. Except that it couldn't be either 0 or 255
for various reasons.

It was decided that this was a real pain. And so in the Dec/Intel/Xerox
Ethernet spec, 48 bits are used for the link level addressing.

Let's be clear about the functionality that is desired: the idea is that
people would be able to purchase a computer, plug it into the "Information
Outlet" and be all set. No jumpers, no configuration, no nothing. Any magic
bits can be taken care of by administrators at a central location.

Through the power of broadcasting and multicasting, I claim that you NEVER
need to type in special numbers at the keyboard of your new computer. All
of that can and should be done over the network.

What is now known as ARP and RARP play a big part in that of course.

Unfortunately, DEC decided to do it their way--you have to tell
the DecNet machines their node and area, then they change their Ethernet
address as was discussed, etc. Put me down as someone who doesn't like or
understand Dec's methodology in this regard. But remember that I work
for a competitor of Dec's, namely Sun Microsystems. I'm encouraged by the 
messages which indicate that Dec may change this in the next release
Phase of DecNet.

------------

"Having globally unique addresses can really mess up MAC level bridges."
I found that mail message interesting because a) the writer raised a very valid
point that I hadn't thought of before and b) the writer then went on to
suggest the WRONG (I feel) solution to the problem. I feel that the correct
answer is to not use Mac-level bridges. I don't really want to bring back
the bridge vs anti-bridge discussions, but I will make the comment that
I'm sure that no one in the late 70's and early 80's who was working
on the Ethernet spec ever thought that people would actually build boxes
that tried to see every packet, do the 'right' thing with it, and then 
try to make the whole affair invisible to the source and destination
machines. Why don't people use internetworking for their internetworks?

--------------

Assigning Ethernet addresses. When I left Xerox in March of 1986, 
all 'magic number' assignments were still be handled by Xerox. This
included type numbers at the Ethernet level, 48 bit Ethernet
source/destination, XNS network numbers, etc.

You can reach those people at "Network Administration Office, Xerox Corp,
3333 Coyote Hill Road, Palo Alto CA 94304, USA"

AA-00-04 was assigned to Digital.
So were some other blocks. Digital uses the other blocks when burning
proms for their machines.
Xerox gave itself several blocks also. One interesting block they gave
themselves is the 00-00-00 block. This is used with old Dolphins. 
There's an interesting story there, ask me about it (in person) some time.

----------------------

Someone asked if 48 bits is enough. The short answer is yes. For more
information, see the paper by Bob Printis. My copy is at home so I can't
give you the full citation. Bob presented it at a conference in Mexico City
in the early 80's. The paper explains why 48 bits is enough.

With respect to the question about manufacturers 'using up' the numbers
through various bad practices, two comments:

a) Manufacturers are asked to use the 48 bit numbers that they are assigned
'densely.' They are NOT to use them as serial numbers, etc. Most manufacturers
are pretty good about this. If a manufacturer wants, Xerox will even sell
them a batch of id proms with the ids burned in the proms in sequential
order. (At least that's the idea...)

b) It is in manufacturers' interest to swap the id prom with the new and
old FRU (Field Replaceable Unit) (usually circuit board) when fixing their
computers. Because 1) it's the 'right' thing to do and 2) if the manufacturer
has their computer system set up so that *everything* depends on the 48-bit
number (remember that this is the 'right' thing to do) then the manufacturer
wants to save their customers the pain of changing anything merely because
some hardware failed. Somewhere there's even a recommendation that 
manufacturers put the id prom in a socket rather than soldering it to the
board for EXACTLY this reason.

By the way, Sun Microsystems instructs its service engineers to swap 
the ID proms when replacing FRU's that contain ID proms. If Dec doesn't
do this than that's their problem (and their customers...). But my guess
is that the Dec people really are swapping the proms, it might not have
been noticed since it doesn't take much time to do.

-------------

Version of the Ethernet spec. The current version is Version 2.0. Dated
November, 1982. Copies of version 1 should be treasured, but not referred
to.

"Local addresses" This is not part of the Ethernet spec, neither version 1
or 2. I believe that it was added by the IEEE 802.2/802.3 committees in 
their infinite wisdom. I don't know what the rationale is, but in any
case I don't agree with it. People who want to have to tamper
with every single workstation that is added to a site (rather than
changing one or two mapping tables somewhere) should not be allowed
out of their computer rooms.

Think about a common electric typewriter--the vendor supplies it, it is
placed on the user's desk, plugged in, and away you go. The idea
of Ethernet was to extend that simple 'plug and play' model to 
comunicating computers.

Regards,

Larry Kluger
European Data Communications Consultant
Sun Microsystems Europe

lkluger@sun.com

-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11-Aug-87 10:22:33 EDT
From:      ehrlich@psuvax1.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: Blue Book

In article <2837@phri.UUCP> roy@phri.UUCP (Roy Smith) writes:
>I keep seeing references to "The Blue Book".  What, exactly, is that?  I

The "Blue Book" is the ethernet spcefication published by DEC, Intel,
and XEROX.  It's correct title is "The Ethernet; A Local Area Network,
Data Link Layer and Physical Layer Specifications" The latest copy I
have is dated November 1982 and reflects version 2.0 of the
specification.

-- 
--Dan Ehrlich <ehrlich@psuvax1.{psu.edu,bitnet,uucp}>
The Pennsylvania State University, Computer Science Department
333 Whitmore Laboratory, University Park, PA   16802
+1 814 863 1142

-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      11 Aug 87 06:34:10 GMT
From:      soliloquy.rutgers.edu!dpz@RUTGERS.EDU  (David P. Zimmerman)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: RFS vs NFS
In article <929@soliloquy.rutgers.edu> I blurted:

> > The claim of statelessness should not be taken too literally.  When one
> ...
> > before the crash.  Talk about some confused clients...
> 
> Sun's ND (one of the weirdest beasts around) isn't stateless, you
> can't use that as an example in this case.

And of course he wasn't using it as an example.  Sorry about that.
What he was decribing sounded like the typical ND problem of modifying
a client's root partition on the server while the client was still up,
and I misinterpreted his statement as meaning that.  (ND still rots,
though.  At least we don't have to worry about an ND /pub here
anymore...)

						dpz
-- 
David P. Zimmerman           rutgers!dpz           dpz@rutgers.edu
-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11-Aug-87 10:38:00 EDT
From:      DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer)
To:        comp.protocols.tcp-ip
Subject:   Re: IBM TCP. Really DECnet and Ethernet addresses

There are a lot more Ethernet addresses than Internet addresses, and I
don't hear people screaming (yet) that we're running out of Internet
addresses.  (I do remember screaming that there weren't enough class A
subnets, and later screaming that we had to be careful about doling out
class B and C addresses because of fixed-size non-replacable tables in
some older gateway implementations.  Anyway...)  The V1.0 Ethernet
allowed for 2^23 vendors.  That's 8 million vendors.  Each vendor gets
2^24 addresses.  That's 16 million addresses.  It's conceivable that a
vendor could run out of addresses, and my solution would be to give the
vendor another (or several more) chunks of 2^24 addresses.  Even if
every person on the planet (about 2^32 people) had 64 machines (2^6) and
got a new address for each machine every year, the Ethernet address
space (2^47) allows for 2^(47-32-6) = 2^9 = 512 years of such
(farfetched) activity.  This is why the addressing hasn't "blown up
yet," to use your phrase.  There is therefore no need to recycle
hardware addresses if a particular board (e.g., your DEC-20's) is
unfixable.

As for your DEC-20 board, replacing a board and/or changing an Ethernet
hardware address for a host works pretty well if you use a
dynamic protocol->hardware address translation mechanism such as ARP.
The minor problem being the transition time until the hosts learn of the
new address, and this problem is discussed in the RFC.

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11-Aug-87 11:22:49 EDT
From:      PADLIPSKY@A.ISI.EDU (Michael Padlipsky)
To:        comp.protocols.tcp-ip
Subject:   Re: No echo from the NIC

OH DEAR!!!!!

I'm even more appalled to report on the resolution of yesterday's
mystery about the "My NCP Costs $500 a Day" RFC:  Through the good
offices of Marlyn Johnson at the NIC, I've learned that there was
indeed such an RFC (425, actually) but the reason I didn't spot it
was that I was looking for ones by me and it (gasp, shudder, eek)
wasn't by me after all.  Could have sworn if was one of mine, but
it turns out to have been by Bob Bressler--and addresses the general
problem of too many Hosts having gotten into the habit even then
(late '72) of doing "surveys," "probes," and the like.  Oh, the 
forgetfulness of Early Middle Age....

abashed cheers, map
-------

-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      11 Aug 1987 11:22:49 EDT
From:      Michael Padlipsky <PADLIPSKY@A.ISI.EDU>
To:        Ken Pogran <pogran@CCQ.BBN.COM>
Cc:        "GBURG::ENGER" <enger%gburg.decnet@BLUTO.SCC.COM>, "tcp-ip" <tcp-ip@SRI-NIC.ARPA>, enger@BLUTO.SCC.COM
Subject:   Re: No echo from the NIC
OH DEAR!!!!!

I'm even more appalled to report on the resolution of yesterday's
mystery about the "My NCP Costs $500 a Day" RFC:  Through the good
offices of Marlyn Johnson at the NIC, I've learned that there was
indeed such an RFC (425, actually) but the reason I didn't spot it
was that I was looking for ones by me and it (gasp, shudder, eek)
wasn't by me after all.  Could have sworn if was one of mine, but
it turns out to have been by Bob Bressler--and addresses the general
problem of too many Hosts having gotten into the habit even then
(late '72) of doing "surveys," "probes," and the like.  Oh, the 
forgetfulness of Early Middle Age....

abashed cheers, map
-------
-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11-Aug-87 13:00:22 EDT
From:      KASHTAN@IU.AI.SRI.COM (David L. Kashtan)
To:        comp.protocols.tcp-ip
Subject:   Re:      VMS and X.25


	> I have been looking at various VMS and microVMS solutions for Tcp/Ip
	> (Excelan, Interlan-Micom, Wollongong, SRI, Hyperlink, etc.) and all
	> of them assume an Ethernet....

I cannot speak for the rest of the VMS TCP implementations but I do know
that SRI's (and probably Wollongong's) support many more devices than just
Ethernet.  You can get TCP over X.25 service using the ACC 5250/6250 board,
which is supported by SRI's MultiNet.  There are other possibilities as
well: DMR-11s come to mind.
David
-------

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11-Aug-87 13:28:54 EDT
From:      jkrey@AKAMAI.ISI.EDU (Joyce Reynolds)
To:        comp.protocols.tcp-ip
Subject:   Re: No echo from the NIC

Dear Interested Onlookers,

re: RFC 1012 and the "But my NCP costs $500 a day..."

Please see page 28 in RFC 1012 for the RFC...

425 - Bressler, Bob, "But my NCP costs $500 a day..", RFC 425
(NIC 13010), BBN, 19 December 1972.

Joyce Reynolds

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11-Aug-87 13:49:42 EDT
From:      chris@GYRE.UMD.EDU (Chris Torek)
To:        comp.protocols.tcp-ip
Subject:   Re: telnet CR processing, bridge comm servers and TWG telnet

Why are things always more complicated than they need to be?

Let us see what happens if we break this down carefully.  First, telnet
seems to assume that there is a User on a Terminal (possibly a Printing
Terminal) who is connected, either directly or via modem, to a Host.
This Host is connected to another Host via the Internet.  Let us name
these hosts to avoid confusion: the first will be Tachost, the second
Usefulhost.

Now as to cases:

Usefulhost can try to print a line to User.  To do so, it sends
characters to Tachost, and then it sends an End Of Line.  What is this
End Of Line?  It seems fairly well agreed that it is a CR plus an LF.
To print this, should Usefulhost send <CR><NUL><LF> or just <CR><LF>?
Either should work, but the latter should be preferred.  Tachost must
arrange for either to produce the appropriate printhead or cursor
motion.

Usefulhost can also try to do fancy printhead motion (if our User is on
a Printing Terminal), namely, `go back to the beginning of the line and
get ready to overstrike' or `go down one line'; for these it should
send <CR><NUL> and <LF> respectively.  It is obvious that <CR><NUL><LF>
will move the printhead to the beginning of a new line, though possibly
inefficiently, which is why we say <CR><LF> is preferred.

Now on the other hand, User may be trying to send a line to Usefulhost.
Here the situation is murkier.  User pushes keys for characters; upon
these we agree:  they are just plain ASCII.  (Let us not consider
binary EBCDIC, please!)  But then User pushes a key marked ENTER.  Or
is it marked RETURN?  Maybe LINE FEED?  Or perhaps even NEWLINE.  Just
what key *is* this, anyway?

I cannot speak for everyone, but all *my* terminals have a great big
key marked RETURN.  It sends <CR>.  They also have an ordinary sized
key marked LINE FEED, and it sends <LF>.  But apparently there is at
least one Tachost that has different terminals, with keys marked
ENTER that send <CR><LF>.

The clear, obvious solution is to have Tachost send <CR> when a User
types RETURN, <LF> when a User types LINE FEED, and <CR> when a user
pushes an ENTER key that sends <CR><LF>.  Terminals with just one big
ENTER key thus cannot send <LF>.  Well, that is natural since they have
no key for it.  As long as the terminal has separate keys, though, it
should be Tachost's job to send to Usefulhost exactly that key which
was typed.

Alas, telnet does not use the clear, obvious solution.  It imposes on a
User the very same protocol used for making a Terminal or Printer work.
This is odd, for Users are not at all like Terminals and Printers, but
we are stuck with it.  At least it is symmetric---or is it?

If Tachost can easily tell which key User typed, *I* say it should send
that very key to Usefulhost.  So (since we have this extra protocol in
the way) let us define that Tachost is to send either <CR><NUL> or
<CR><LF> (it should not matter which) when User types RETURN, and <LF>
when User types LINE FEED.  If User types ENTER and Tachost cannot tell
which was meant, let it again send either <CR><NUL> or <CR><LF>.

Note that in the Tachost->Usefulhost path, <CR><LF> means RETURN, while
on the Usefulhost->Tachost path, <CR><LF> means NEW LINE.  This is---
alas!---not symmetric, but is clearly necessary since many Tachosts
already send <CR><LF> when a User hits RETURN.  Note also that
<CR><NUL> is useless, since it means the same thing as <CR><LF>;
nonetheless, it must be retained for compatibility, since other
Tachosts already send <CR><NUL> when a User hits RETURN.

Summary:  End host should send <CR><LF> for NEW LINE, <CR><NUL> for
cursor-to-beginning-of-line, <LF> for cursor-down-without-return.
Intermediate host should send <CR><LF> or <CR><NUL> for RETURN, <LF>
for LINE FEED.  Neither host should ever send <CR> without immediately
sending either <LF> or <NUL>.

Chris

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11-Aug-87 15:49:00 EDT
From:      DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer)
To:        comp.protocols.tcp-ip
Subject:   Blue Book


    Date: 11 Aug 87 02:24:21 GMT
    From: phri!roy@nyu.arpa  (Roy Smith)

    I keep seeing references to "The Blue Book".  What, exactly, is that?  I
    have a small (about the size of the 11/45 hardware manual) blue-covered
    paperback book that DEC put out a few years back called something like
    "Introduction to Local Area Networks".  Is that "The Blue Book"?
    -- 
    Roy Smith, {allegra,cmcl2,philabs}!phri!roy
    System Administrator, Public Health Research Institute
    455 First Avenue, New York, NY 10016

It's

			      The Ethernet

			  A Local Area Network

			    Data Link Layer
				  and
			     Physical Layer
			     Specifications


	DEC's			Intel's			Xerox's
	logo			logo			logo

	addresses......	for............	the............	above

			      Version 1.0

			   September 30, 1980

has a blue cover and is 8.5"x11".  I considered it the Ethernet Bible,
but I'm apparently in error since there have been changes.

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      11 Aug 87 19:02:33 PDT (Tuesday)
From:      Rich <RMRichardson.PA@Xerox.COM>
To:        Ken Rossman <sy.Ken@CU20B.COLUMBIA.EDU>, David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Cc:        Adam Hamilton <mcvax!ukc!its63b!adam@SEISMO.CSS.GOV>, tcp-ip@SRI-NIC.ARPA, RMRichardson.PA@Xerox.COM
Subject:   Re: IBM TCP. Really DECnet and Ethernet addresses
>I guess I'm hopelessly out of date.  My copy of the Blue Book is Version
>1.0, Sepetmber 30, 1980.  In it, in section 6.2.1 on page 21, there is
>no mention of this second bit being for local/global administration.  In
>fact, of the physical address it says
>	"A station's physical address should be distinct from the
>	physical address of any other station on @i(any) Ethernet."
>The italics are in the book.  Time marches on... standards change...

I don't have a copy of the blue book, but the relevant section in IEEE 802.3 is 3.2.3 (with Fig 3-2) on pages 24, 25 of the IEEE book (green cover).  


> Along slightly different lines, I fail to see how the global 
> ethernet addressing scheme, whether managed as a flat address space
> or in some hierarchical fashion, hasn't blown up yet.  I mean there
> just aren't that many addresses available.  Just as an isolated 
> example, what happens to ethernet addresses on failing boards?  
> We've probably had the ethernet board on one of our -20's replaced 
> three times already.  Am I to believe that DEC Field Service 
> records these hardware addresses, and when bad boards come back 
> that can't be repaired, they tell some global address administrator
> that this particular hardware address has now been freed and can be
> used again?

Given that 2 of the 48 bits are used by the "flags," that leaves 2**46 addresses for ethernet devices.  This is a large number that is hard to get hold of until one reduces it to reasonable.  Conversion to a power of ten is a start: 7.036874e+13.  Even 10**13 is a very large number to get hold of; lets suppose we can produce one thousand devices every second, round the clock, until the space is full.  7.036874e+13, /60 secs/min, /60 min/hour, /24 hours/day, and /365.25 days/year.  2229.851 years!  

Even the space allowed for a single manufacturer is 2**24 or about 16 million addresses.  (And of course if some manufacturer fills out that space, the IEEE can allocate a second block of 16 million. :-)  

I don't know how DEC Field Service takes care of the problem of bad boards, but when we have to change the relevant board in one of the D-machines around here, we pull the PROM which contains the ethernet ID out of the old board and stick it in the replacement so our machine is as it always was to the ethernet.  Only if you break the PROM do you get a new number and go through the pain of re-registering your machine on the net.  


Rich
-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11-Aug-87 16:24:35 EDT
From:      ehrlich@psuvax1.psu.edu (Dan Ehrlich)
To:        comp.protocols.tcp-ip,comp.unix.wizards,comp.bugs.4bsd
Subject:   Trouble speaking SMTP to TOPS 20 (TWENEX) hosts

My memory is fuzzy as to if this problem has been reported before or
not.  I vaguely remeber seeing something like this but cannot find
anything in our old news files, so please excuse me if this is old
hat.

The VAXen here are running BSD 4.3 UNIX with all of the patches posted
to comp.bugs.4bsd.ucb-fixes applied.  Most of the time when we try to
speak SMTP to a TOPS 20 (TWENEX) host sendmail ends up deffering with a
"Bad file number" status.  This situation never seems to correct itself
and eventually the mail is returned to the originator.  If my memory is
correct on this and a fix has been posted for it I would appreciate
getting a copy from anyone who has it.

Thanks in advance.

-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      11 Aug 87 13:45:02 GMT
From:      super.upenn.edu!operations.dccs.upenn.edu!shaffer@RUTGERS.EDU  (Earl Shaffer)
To:        tcp-ip@sri-nic.arpa
Subject:   Wollongong WIN/TCP 3.1?
I have heard rumors about 3.1 coming out.  I think there
is an address error that was found in 3.0.  Does anyone
know more about this?




==============================================================================
Earl Shaffer - University of Pennsylvania - Data Communications Department
"Time was invented so that everything wouldn't happen at once." Steven Wright
==============================================================================
-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11-Aug-87 17:46:00 EDT
From:      art@ACC.ARPA
To:        comp.protocols.tcp-ip
Subject:   Ethernet Address Space


>It would seem to me that it would be hopelessly difficult to try to
>administer a flat global set of ethernet addresses, and that some sort of
>mechanism, such as the global/local bits at the beginning would have to
>exist.  In any case, regardless of how a spec says it SHOULD be, the real
>world appears to be allocating blocks of ethernet addresses to vendors to
>be used as they (or their customers) see fit.

Vendors are ASSIGNED blocks of addresses which they are responsible for
assigning to their interface boards.  When a block is exhausted, another
can be acquired (from Xerox originally, IEEE now).  DEC is one of the few
I know of that has more than on assigned block (SUN probably does by now).

>Along slightly different lines, I fail to see how the global ethernet
>addressing scheme, whether managed as a flat address space or in some
>hierarchical fashion, hasn't blown up yet.  I mean there just aren't that
>many addresses available.  Just as an isolated example, what happens to
>ethernet addresses on failing boards?  We've probably had the ethernet
>board on one of our -20's replaced three times already.  Am I to believe
>that DEC Field Service records these hardware addresses, and when bad
>boards come back that can't be repaired, they tell some global address
>administrator that this particular hardware address has now been freed and
>can be used again?

I don't think that this is a problem yet.  The Ethernet addresses are 48 bits
long, minus one or two for format flags.  This still leaves roughly
64 TRILLION possibilities.  Even if the address space is only 0.01% utilized,
that leaves roughly 6 BILLION Ethernet interfaces.

						Art Berggreen
						art@acc.arpa

------

-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11-Aug-87 18:29:21 EDT
From:      geof@apolling.UUCP (Geof Cooper)
To:        comp.protocols.tcp-ip
Subject:   Re: Blue Book


 >      I keep seeing references to "The Blue Book".  What, exactly, is that?

The Ethernet
A Local Area Network
Data Link Layer and Physical Layer Specifications

DEC, Intel, Xerox (all three logo's on the cover)

Version 2.0
November, 1982

I got mine from Xerox.  The address given for orders is:

    Xerox Corporation
    Office Systems Division
    Ethernet Literature Department
    3450 Hillview Avenue
    Palo Alto, CA 94304

There is a net-mail address that would translate to
"OSD-Pubs.pa@Xerox.com" these days.  You can try that.
The phone number listed is 415 494 5886.

I suspect that these days the XNS institute handles
such requests.

- Geof

PS: The cover IS blue on version 2.  The cover of version 1 was gray
    with a blue stripe.

-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11-Aug-87 18:55:39 EDT
From:      chris@gargoyle.UChicago.EDU (Chris Johnston)
To:        comp.protocols.tcp-ip,comp.unix.wizards,comp.bugs.4bsd
Subject:   Re: Trouble speaking SMTP to TOPS 20 (TWENEX) hosts


Hi Dan,

In order to get sendmail to speak smtp with a Dec-20
you have tell sendmail to use <cr><lf>.  (use the E flag)

From sendmail.cf

Mtcp,	P=[IPC], F=mDFMueXLC, S=14, R=24, A=IPC $h, E=\r\n
Mtcpld,	P=[IPC], F=mDFMueXLC, S=17, R=27, A=IPC $h, E=\r\n

cj

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11-Aug-87 21:50:54 EDT
From:      jch@OMNIGATE.CLARKSON.EDU (Jeffrey C Honig)
To:        comp.protocols.tcp-ip
Subject:   Re: DECnet Ethernet interface addresses (was Re: IBM TCP)


>>I'm afraid I fail to see where you get AA-00-03-01-10-E7 from 19.53.
>>...
>>or, node 57.784.
>
>Well, I'm afraid I didn't get it: DECnet did. I guess it doesn't
>use your algorithm.

Actually, it does.

>Hardware address         = AA-00-03-01-1D-E7

What your 'ncp show line una-0 char' report is showing you is the
hardware ethernet address before DECnet changes it.  Try looking
at an Ethernet monitor.  If you are running TCP/IP on that host
they try looking in the ARP cache of another host or router on that
network for the Ethernet address that is actually being used.

Jeff

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Aug 87 21:50:54 EDT
From:      Jeffrey C Honig <jch@omnigate.clarkson.edu>
To:        SYSTEM%CRNLNS.BITNET@wiscvm.wisc.edu
Cc:        TCP-IP@sri-nic.arpa
Subject:   Re: DECnet Ethernet interface addresses (was Re: IBM TCP)

>>I'm afraid I fail to see where you get AA-00-03-01-10-E7 from 19.53.
>>...
>>or, node 57.784.
>
>Well, I'm afraid I didn't get it: DECnet did. I guess it doesn't
>use your algorithm.

Actually, it does.

>Hardware address         = AA-00-03-01-1D-E7

What your 'ncp show line una-0 char' report is showing you is the
hardware ethernet address before DECnet changes it.  Try looking
at an Ethernet monitor.  If you are running TCP/IP on that host
they try looking in the ARP cache of another host or router on that
network for the Ethernet address that is actually being used.

Jeff
-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11-Aug-87 23:23:48 EDT
From:      karels%okeeffe@UCBVAX.BERKELEY.EDU (Mike Karels)
To:        comp.protocols.tcp-ip
Subject:   Re: Telnet, <CR><LF>, etc.

Hey, folks, this discussion on telnet has gone much too far, and far astray.
Let me summarize the actual problem, which is quite minor, its effect
and the proposed modification to mitigate its effect.

First, let me remind people that a real problem exists ONLY in the following
circumstance: when a user connects by telnet from a host of a certain type
(including Bridge terminal servers) to a 4.3BSD host, and THEN runs a program
such as telnet that runs in character mode that distinguishes between <CR>
and <LF>.  This includes trying to telnet (or tip) from the 4.3BSD host
to some other host that distinguishes between <CR> and <LF>.  The problem
occurs if the originating host sends <CR><LF> when it receives a return
from the terminal, and has no option to send <CR><NUL> instead.  With such
a combination of hosts and operations, an interoperability problem exists.
In all other situations, things work correctly.  All of the implementations
involved are following the specification.

There is a simple, straightforward patch to the 4.3BSD telnet server
that mitigates this problem.  While I agree with Greg Minshall's
excellent summary of the 4.3BSD telnet implementation and rationale,
we have both agreed that changing the telnet server in a pragmatic way
will avoid this problem.  An "official" Berkeley bug fix for 4.3 telnetd
will be sent to the tcp-ip list soon and to the Usenet news group set up
for official Berkeley fixes (comp.bugs.4bsd.ucb-fixes).  

I think that the lessons learned are that

(1) protocol specifications that allow options for behavior may allow
correct implementations that fail to interoperate (no big news here),
and

(2) the Telnet specification has some problems, especially in the area
of character at a time mode versus line at a time mode (see Greg's
excellent discussion), and it may need to specify different behavior
in the server-to-client and client-to-server directions.

		Mike

-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      11 Aug 87 19:34:00 GMT
From:      m2c!ulowell!apollo!rees@bu-cs.bu.edu  (Jim Rees)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: RFS vs NFS

    Sun's ND (one of the weirdest beasts around) isn't stateless, you
    can't use that as an example in this case.

I don't think he was talking ND.  NFS clients will get confused if the
server's handles change, which they will if you mkfs and restore.
The handles are some combination of inode number, device number, and
sequence number.

Some of this confusion could be lessened if you could guarantee that
handles will never get re-used.  This is the approach we took in our
NFS server.  Instead of inode numbers, objects are named by UID.  The
UID (Unique ID) is a combination of node number and timestamp, and is
guaranteed unique, even if you mkfs and restore.  We didn't invent the
idea, it's a commonly used technique in more modern (than Unix) operating
systems.  With UIDs for handles, the clients at least don't mistake
new objects for old ones, although they still can't find the ones they
want.

You could argue that this is correct behavior anyway, since when the
files come back in off of tape, they probably aren't the same as they
were immediately before the crash.
-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12-Aug-87 00:01:03 EDT
From:      melohn@SUN.COM (Bill Melohn)
To:        comp.protocols.tcp-ip
Subject:   Re: Mailing to DEC Easynet

In article <12325530286.154.A.ERIC@GSB-HOW.Stanford.EDU> A.Eric@GSB-HOW.STANFORD.EDU (Eric M. Berg) writes:
>It's helpful to know that DEC Easynet nodes seem to have two different names
>each: a DECnet node name, and an internet-style name.  So, for example, most
>of the Santa Clara office sales people have accounts on "USWRSL.DEC.COM"
>("US Western Region SaLes", as close as I can guess), which is also known
>as "RHEA" (DECnet node name).


This is done (no suprise) by using the domain name server, which has
an MX record defined for all of the valid DECNET node names in the DEC
Enet. From the outside, you should be able to get to any DEC Enet node
by sending to <username>@<dec node name>.dec.com, assuming you run the
nameserver.  The node RHEA is merely a forwarding node in the internal
chain between DECWRL and the rest of the DEC Enet.

Domain names; there not just for IP anymore..

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 Aug 87 02:18
From:      John Laws (on UK.MOD.RSRE) <LAWS%rsre.mod.uk@Cs.Ucl.AC.UK>
To:        Roy Smith <@Cs.Ucl.AC.UK:phri!roy@nyu.arpa>
Cc:        tcp-ip <@Cs.Ucl.AC.UK:tcp-ip@sri-nic.arpa>
Subject:   Re: Blue Book
Roy,
 
The Blue Book I know about is 'Network Independent File Transfer
Protocol'. This is one of a series of protocols in the Rainbow Book
series developed within the UK Joint Academic Network (JANET) more
than 10 years ago. Red is Remote Job Entry, Green is Terminal, Grey is
Mail.
 
John Laws
-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      12 Aug 1987 07:11-PDT
From:      STJOHNS@SRI-NIC.ARPA
To:        heker@JVNCA.CSC.ORG
Cc:        HANK%TAUNIVM.BITNET@WISCVM.WISC.EDU, KASHTAN@IU.AI.SRI.COM, tcp-ip@SRI-NIC.ARPA
Subject:   Re:      VMS and X.25
Sergio,  the  IETF  would  like to take you up on your offer of a
place to hold an IETF meeting.  The schedule we are  looking  for
is  to  have  a  meeting at JVNC in late april/early may of 1988.
Would this be possible for JVNC?  Can you give me  some  idea  of
the  number/sizes  of  conference  rooms available and how far in
advance we have to book them>?  Thanks!  Mike
-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      12 Aug 1987 07:12-PDT
From:      STJOHNS@SRI-NIC.ARPA
To:        heker@JVNCA.CSC.ORG
Cc:        HANK%TAUNIVM.BITNET@WISCVM.WISC.EDU, KASHTAN@IU.AI.SRI.COM, tcp-ip@SRI-NIC.ARPA
Subject:   Re:      VMS and X.25
Apologies, that one got away from me.  *sigh* Mike
-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12-Aug-87 05:18:00 EDT
From:      LAWS@rsre.mod.UK (John Laws, on UK.MOD.RSRE)
To:        comp.protocols.tcp-ip
Subject:   Re: Blue Book

Roy,
 
The Blue Book I know about is 'Network Independent File Transfer
Protocol'. This is one of a series of protocols in the Rainbow Book
series developed within the UK Joint Academic Network (JANET) more
than 10 years ago. Red is Remote Job Entry, Green is Terminal, Grey is
Mail.
 
John Laws

-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      12 Aug 87 04:22:13 GMT
From:      amdahl!unixprt!monkey@ames.arpa  (Monkey Face@unixprt)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: RFS vs NFS
> The claim of statelessness should not be taken too literally.  When one
> of our disks got trashed (@*#% Xylogics!), we did the "obvious" thing -
> we took the server down, created the filesystem afresh, restored all of
> the backup tapes, and then let the clients continue where they left off
> before the crash.  Talk about some confused clients...
> "Stateless" only means that the state is kept on disk rather than RAM.
Also, NFS is implemented in a stateless manner, but the other network
services that are provided are very state-full.  Since NFS is really just
a 'base' for file system services, extensions via servers et al, are and
will continue to be state-full (i.e file locking).  Several other network
services will be state-full also.
The above example is an interesting case when this approach falls a little
short, although in general, for short periods of 'failure' it is very
appropriate.
-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12-Aug-87 08:48:47 EDT
From:      heker@JVNCA.CSC.ORG (Sergio Heker)
To:        comp.protocols.tcp-ip
Subject:   Re:      VMS and X.25

Hank,

Wollongong definitely supports DMR11s ( we used to have 4 DMRs and a DEUNA 
on a VAX8600/VMS/WIMVX ), and I think you can connect an ACC/X.25 board to
it as well.

					-- Sergio

-----------------------------------------------------------------------------
Sergio Heker				tel:	(609) 520-2000
Internet: "heker@jvnca.csc.org"		Bitnet:	"heker@jvnc"
JOHN VON NEUMANN NATIONAL SUPERCOMPUTER CENTER, JVNCnet Network Manager
-----------------------------------------------------------------------------

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12-Aug-87 08:58:56 EDT
From:      robert@pvab.UUCP (Robert Claeson)
To:        comp.protocols.tcp-ip
Subject:   NFS for SCO Xenix

Is there a NFS implementation for IBM AT's running SCO Xenix System V?
I know of Excelan's ethernet card and tcp/ip software, but there is no
NFS (what I know, at least).

-- 
SNAIL:	Robert Claeson, PVAB, P.O. Box 4040, S-171 04 Solna, Sweden
UUCP:	{seismo,mcvax,munnari}!enea!pvab!robert
ARPA:	enea!pvab!robert@seismo.arpa

-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12-Aug-87 10:06:46 EDT
From:      ron@TOPAZ.RUTGERS.EDU (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re: telnet CR processing, bridge comm servers and TWG telnet

The main problem we've found with the blasted BRIDGE boxes is
that they insist on negotiating BINARY mode when you open the
connection.  This screws up all kinds of things.  You really want
the NVT mapping when dealing with dissimilar machine/terminal
types.

-Ron

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12-Aug-87 10:11:00 EDT
From:      STJOHNS@SRI-NIC.ARPA
To:        comp.protocols.tcp-ip
Subject:   Re:      VMS and X.25

Sergio,  the  IETF  would  like to take you up on your offer of a
place to hold an IETF meeting.  The schedule we are  looking  for
is  to  have  a  meeting at JVNC in late april/early may of 1988.
Would this be possible for JVNC?  Can you give me  some  idea  of
the  number/sizes  of  conference  rooms available and how far in
advance we have to book them>?  Thanks!  Mike

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12-Aug-87 10:12:00 EDT
From:      STJOHNS@SRI-NIC.ARPA
To:        comp.protocols.tcp-ip
Subject:   Re:      VMS and X.25

Apologies, that one got away from me.  *sigh* Mike

-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 Aug 87 16:27 PDT
From:      Kevin Carosso <@YMIR.BITNET:KVC@ENGVAX.SCG.HAC.COM>
To:        tcp-ip@sri-nic.ARPA
Subject:   DEC Ethernet addresses
For VMS DECnet (using NCP):

to show the ethernet controller's hardware address:

---------------------------------------------------------------------
NCP> SHOW LINE UNA-0 CHARACTERISTICS
Line Volatile Characteristics as of 12-AUG-1987 16:06:40

Line = UNA-0

Receive buffers          = 6
Controller               = normal
Protocol                 = Ethernet
Service timer            = 4000
Hardware address         = 08-00-2B-05-D3-E3
Device buffer size       = 1498
---------------------------------------------------------------------


to show the ethernet controller's current address as set by DECNet:

---------------------------------------------------------------------
NCP> SHOW EXECUTOR STATUS
Node Volatile Status as of 12-AUG-1987 16:06:10

Executor node = 45.9 (ENGVAX)

State                    = on
Physical address         = AA-00-04-00-09-B4
---------------------------------------------------------------------

This is the one generated by DECnet from the node number via the
scheme: (area * 1024) + node = last_two_bytes

There seems to have been some confusion on these issues.

Also, I've noted that my DELUA controller and the DESVA controller in a
VAXstation-2000 have hardware addresses assigned in the group 08-00-2B.
I guess DEC got more than the AA-00-00 through AA-00-04 range.

        /Kevin Carosso                     kvc@engvax.scg.hac.com
         Hughes Aircraft Co.               kvc%engvax@oberon.usc.edu
-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12-Aug-87 14:40:53 EDT
From:      ROODE@BIONET-20.ARPA (David Roode)
To:        comp.protocols.tcp-ip
Subject:   Re: SMTP question

One reason not to expand SMTP to provide for 8 bit ASCII
is that there are a goodly number of obscure computer
made by a company called IBM that are probably already
internally converting 7 bit ASCII into 8 bit EBCDIC.
Who knows what would happen to information encoded into
the ASCII parity bit when transmission to one of these
guys were attempted.  Some of them are still sending
mail messages to each other by pretending to punch
cards on each others' virtual card punch.  Not to poke fun,
this is just an example of the sort of baggage that accumulates
when one is in business for 40 years or more, give or take
a few years, in a field beset by technological advances.
It's a miracle that ASCII itself is acceptable in
the international community, and  I am sure there are some
problems with that--going through international
mail gateways to other countries' research mail networks
would engender problems for 8 bit ASCII, I suspect.
-------

-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12-Aug-87 19:27:00 EDT
From:      KVC@ENGVAX.SCG.HAC.COM (Kevin Carosso)
To:        comp.protocols.tcp-ip
Subject:   DEC Ethernet addresses

For VMS DECnet (using NCP):

to show the ethernet controller's hardware address:

---------------------------------------------------------------------
NCP> SHOW LINE UNA-0 CHARACTERISTICS
Line Volatile Characteristics as of 12-AUG-1987 16:06:40

Line = UNA-0

Receive buffers          = 6
Controller               = normal
Protocol                 = Ethernet
Service timer            = 4000
Hardware address         = 08-00-2B-05-D3-E3
Device buffer size       = 1498
---------------------------------------------------------------------


to show the ethernet controller's current address as set by DECNet:

---------------------------------------------------------------------
NCP> SHOW EXECUTOR STATUS
Node Volatile Status as of 12-AUG-1987 16:06:10

Executor node = 45.9 (ENGVAX)

State                    = on
Physical address         = AA-00-04-00-09-B4
---------------------------------------------------------------------

This is the one generated by DECnet from the node number via the
scheme: (area * 1024) + node = last_two_bytes

There seems to have been some confusion on these issues.

Also, I've noted that my DELUA controller and the DESVA controller in a
VAXstation-2000 have hardware addresses assigned in the group 08-00-2B.
I guess DEC got more than the AA-00-00 through AA-00-04 range.

        /Kevin Carosso                     kvc@engvax.scg.hac.com
         Hughes Aircraft Co.               kvc%engvax@oberon.usc.edu

-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12-Aug-87 20:42:25 EDT
From:      jlarson.pa@XEROX.COM
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet addresses


    " Assigning Ethernet addresses. When I left Xerox in March of 1986,
      all 'magic number' assignments were still be handled by Xerox..."
     
Ethernet 48-bit address blocks (IEEE 802 "48-bit Globally/Universal
Assigned Addresses") are now assigned by the IEEE Standards Office
rather than Xerox.    

Contact the IEEE Standards Office, (212) 705-7092, for more information.

John

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12-Aug-87 23:26:56 EDT
From:      sy.Ken@CU20B.COLUMBIA.EDU (Ken Rossman)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet Address Space

OK, I said a really stupid thing, I admit it.  Now you guys can quit
beating me to death about how many available ethernet addresses there
are.  I guess, without thinking about it at all, glancing at a 6 field
hex number, it just doesn't look all that large...

Put it to rest already.  /Ken
-------

-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13-Aug-87 05:49:46 EDT
From:      ROODE@BIONET-20.ARPA (David Roode)
To:        comp.protocols.tcp-ip
Subject:   Re: TAC "noise"

The CompuServe Network added an option to their 'TAC' to vary the
timing of bits or number of stop bits, apparently just
to address the type of problem you hypothesize might be what
Frank is seeing on TAC's.  I believe it was just to send an extra stop
bit.
-------

-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13-Aug-87 10:31:26 EDT
From:      cain@EDN-UNIX.ARPA (Edward A. Cain)
To:        comp.protocols.tcp-ip
Subject:   ethernet multicast

Is there a commercial product (gateway) which supports ethernet multicast?
Needs to take an IP datagram from Arpanet, recongize that the IP address
is really a group address, and multicast it onto an ethernet.

Ed Cain

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      13 Aug 1987 10:31:26 EDT
From:      Edward A. Cain <cain@EDN-UNIX.ARPA>
To:        tcp-ip@sri-nic.arpa
Cc:        Leiden@mit-multics.arpa
Subject:   ethernet multicast
Is there a commercial product (gateway) which supports ethernet multicast?
Needs to take an IP datagram from Arpanet, recongize that the IP address
is really a group address, and multicast it onto an ethernet.

Ed Cain


-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13-Aug-87 14:06:00 EDT
From:      WRK.CECOM@CECOM-1.ARPA (Bill.King@SRI-NIC.ARPA, Directorate of Information Management)
To:        comp.protocols.tcp-ip
Subject:   DDN Node Location

I have what perhaps is a rather dumb question for this forum, but would 
sincerely like some opinions.  We are about to relocate our computer room and 
at the same time, relocate and upgrade our PSN.  Given the choice (which we do 
have) of locating the PSN adjacent to the telephone switching center (and all 
incoming trunks) or adjacent to the host computers (eventually a gateway) 
connected to it, which is preferable and why?

Your assistance appreciated.

Bill King
Ft. Monmouth, NJ
KING@CECOM-1.ARPA

-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      13 Aug 87 12:52:00 GMT
From:      apollo!rees@eddie.mit.edu  (Jim Rees)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: RFS vs NFS

    Actually, I like to think of it as RFS using volatile state, and NFS
    using permanent state (i.e., disk).  In order to permit the simple
    recovery that NFS aspires to, you have to store data on disk that
    will survive a failure so that a client can do correct cache
    invalidation.  This NFS does, and it completes all writes prior to
    acknowledging a write to a client.  In view of these requirements,
    I feel that the term "stateless" without qualification is incorrect.

Well... I guess so, but if you take that interpretation, you could also
argue that no server is ever stateless, because the data in the files
represents state, too.  In this context, when I say "server state," I
mean some information held by the server about connections with the
clients.  The server "knows" that node X has file "foo" open for reading.
NFS does not keep this kind of information around, not even on disk,
except maybe as an optimization.
-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      13 Aug 87 14:39:13 GMT
From:      nsc!unixprt!monkey@decwrl.dec.com  (Monkey Face@unixprt)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: RFS vs NFS
In article <4993@felix.UUCP>, martin@felix.UUCP (Martin McKendry) writes:
> Actually, I like to think of it as RFS using volatile state, and NFS
> using permanent state (i.e., disk).  In order to permit the simple
> recovery that NFS aspires to, you have to store data on disk that
> will survive a failure so that a client can do correct cache
> invalidation.  This NFS does, and it completes all writes prior to
> acknowledging a write to a client.  In view of these requirements,
> I feel that the term "stateless" without qualification is incorrect.
> --
> 	Martin S. McKendry
> 	{hplabs,trwrb}!felix!martin
The "stateless" term does not really refer to the 'write through' 
characteristic of NFS, but to the fact that the 'server' does not
maintain 'state' related to currently opened files by 'clients'.
The client has a 'handle' for a file that can always be recognized
by the server and maintains local state as to 'offset', etc.  
The server may have to 're-open' that file (if all
local users are not using it) each time a request to access that
file from a client arrives.  This allows the server to go down and
come back up whilst the client can use the same 'handle' and local
state information to continue to access the file as if the server
had not gone down.
RFS on the other hand does keep state at the server and client, therefore
if the server dies, so does current 'access' to any of its files.
-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      14 Aug 87 01:18:11 GMT
From:      topaz.rutgers.edu!ron@RUTGERS.EDU  (Ron Natalie)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: RFS vs NFS
The one major piece of statelessness that Sun did that I wish they hadn't
is that they do not keep track of the fact that the server they were
referencing is down.  It would seem to be a trivial modification to
notice when the server dies, and then invalidate requests for the mounted
disk until they get some indication (periodic pinging or whatever) that
the dead machine has come back to life.

-Ron
-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      14 Aug 87 11:00:00 PDT
From:      "Jerry Scott" <jerry@twg.arpa>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Cc:        <mullen@nrl-css.arpa>
Subject:   RE: Ethernet problems induced by bogus ICMP Address Mask Reply

On date, 8 Aug 87, Preston Mullen <mullen@nrl-css.arpa> wrote:

>>==> Potential users of Wollongong 3.0 software should get a fix from
>>Wollongong before running 3.0 on a network where a machine might
>>broadcast an ICMP address mask request.

A fix may be obtained for this problem by using anonymous ftp to
host twg.arpa (26.5.0.73) and obtaining image ip_icmp.o.  The file
is in binary/record format and should be transferred from a Wollongong
host running either release 2.3 or 3.0.

Also, image named472.sav, can be obtained at this time.  This is
the new version of the bind name server from D. Kingston, et al.
The image is in VMS Backup format and should be obtained using
binary/record mode from a Wollongong host.

Regards,

Jerry Scott
------
-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14-Aug-87 14:00:00 EDT
From:      jerry@twg.arpa ("Jerry Scott")
To:        comp.protocols.tcp-ip
Subject:   RE: Ethernet problems induced by bogus ICMP Address Mask Reply


On date, 8 Aug 87, Preston Mullen <mullen@nrl-css.arpa> wrote:

>>==> Potential users of Wollongong 3.0 software should get a fix from
>>Wollongong before running 3.0 on a network where a machine might
>>broadcast an ICMP address mask request.

A fix may be obtained for this problem by using anonymous ftp to
host twg.arpa (26.5.0.73) and obtaining image ip_icmp.o.  The file
is in binary/record format and should be transferred from a Wollongong
host running either release 2.3 or 3.0.

Also, image named472.sav, can be obtained at this time.  This is
the new version of the bind name server from D. Kingston, et al.
The image is in VMS Backup format and should be obtained using
binary/record mode from a Wollongong host.

Regards,

Jerry Scott
------

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      Sat, 15-Aug-87 01:09:53 EDT
From:      mouse@mcgill-vision.UUCP (der Mouse)
To:        comp.protocols.tcp-ip
Subject:   Re: ethernet interface perversity

In article <8708050046.AA07011@ucbvax.Berkeley.EDU>, JOHNSON@NUHUB.ACS.NORTHEASTERN.EDU ("I am only an egg.") writes:
> We did some experimentation with our various ethernet interfaces and
> discovered that something which was hinted at in many of the
> responses seems to be true.  The ethernet interfaces we have will
> each respond to only one internet number at a time.

If this is so it is a software problem.  I can see no reason why UNIX
(say) couldn't be set up to respond to ARP requests for more than one
IP address per interface.  The reason you need a gateway node is that
the software is not currently set up to do this, and thus you need
either a gateway or some serious low-level network code hacking to
allow multiple IP addresses per interface, or alternatively multiple
pseudo-interfaces which all send their packets out on the same physical
interface.

In other words - yes, it will work to have multiple IP networks on the
same cable.  However, you need either a gateway or some
currently-nonexistent software.

					der Mouse

				(mouse@mcgill-vision.uucp)

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      14 Aug 87 21:54:22 GMT
From:      amdcad!amd!intelca!oliveb!felix!martin@ucbvax.Berkeley.EDU  (Martin McKendry)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: RFS vs NFS
I wrote
>
>    Actually, I like to think of it as RFS using volatile state, and NFS
>    using permanent state (i.e., disk).  In order to permit the simple
>    recovery that NFS aspires to, you have to store data on disk that
>    will survive a failure so that a client can do correct cache
>    invalidation.  This NFS does, and it completes all writes prior to
>    acknowledging a write to a client.  In view of these requirements,
>    I feel that the term "stateless" without qualification is incorrect.
>

Jim Rees (rees@apollo.uucp) responded:

>Well... I guess so, but if you take that interpretation, you could also
>argue that no server is ever stateless, because the data in the files
>represents state, too. 

My comments were probably less than precise.  I'm actually getting at 
terminology and commonly drawn inferences.  I would be happy to go with
the position that no server is ever stateless.  After all, state is what
consistency is all about, and consistency is a (if not _the_) major
problem in a distributed file system.  I just object to the terminology:
a "stateless" file system sounds like one that doesn't store anything!  
I also object to the common perception that "stateless" is somehow "better".
Consider what you can do if you are not "stateless":

Our FileNet filesystem is "stateful"; we maintain a list with each inode of
who is using it.  This allowed us to implement a fairly sophisticated
caching mechanism.  The mechanism allows us to cache both data blocks
and inodes -- opens, closes, reads, and some writes can happen without
any communication between a client and the server storing a file. Basically,
the site that stores a file notifies clients if it changes.  If a file
changes a lot, (relative to the number of read accesses) we switch
modes (all sites using the file notified) so that 
clients take responsibility for asking the server if there have been changes.
Our experience so far (we are currently in quality assurance) is that it 
is very rare that this pays off.  On our basic applications
we are seeing hit ratios on the inode cache of 75-85% for opens.  Only
closes that change a file have to contact the server -- over 98% don't.
Total message traffic due to the file system is down over 50% in many cases.
I'd rather use a standard filesystem protocol and mechanism (I have spent
considerable time trying to do this).  However, we build a tightly-coupled 
system with a very centralized view.  Sophisticated caching is 
essential to supporting large numbers of workstations. You can't do that
if you don't maintain some kind of "connection state" that tells a server
who has a file cached.  So "statelessness" is not a universal panacea.

Nonetheless, there are many people around (FileNet included) who believe
that there is something inherently 'better' about being stateless
(as defined by Sun).  But there is no free lunch.  The price of Sun's
stateless approach is that preservation of consistency of the file system
requires that clients interrogate the server to confirm currency of cached
entries, *whether or not those entries have changed*.   This slows down
the client and it loads the server, thus contributing to the limits on its 
capacity.  It may not worry you now, but when you have much larger
workstation memories, and you have all the data you need locally, you are
not going to be pleased at constantly having to interrogate a server
before you can use the data.  I'd like to see more understanding of these
issues.  There are many advantages to Sun's approach.  There are also
limitations.  Like not being able to implement exclusive locking in the
file system. (Of course, the v-node mechanism reduces this need, but that
moves work to the server, which is already overloaded...etc...)

Jim Rees (rees@apollo.uucp) also said:
>	 In this context, when I say "server state," I
>mean some information held by the server about connections with the
>clients.  The server "knows" that node X has file "foo" open for reading.
>NFS does not keep this kind of information around, not even on disk,
>except maybe as an optimization.

The main reasons we keep this data at the server are a) for cache
invalidation, and b) to manage exclusive locking.    Sun let the
client worry about invalidation, and they don't do exclusive locking.
Given that the semantics of NFS don't require it to be "stateful",
I don't see why being "stateless" gets such a billing as a wonderful 
feature.  I don't know if RFS supports exclusive locking.  Their
caching is pretty disgusting, but it does require that the server
contact clients.

Mr/Ms Face [monkey@unixprt.UUCP (Monkey Face@unixprt)] also responded:

>The "stateless" term does not really refer to the 'write through' 
>characteristic of NFS, but to the fact that the 'server' does not
>maintain 'state' related to currently opened files by 'clients'.

From the Usenix (86?) paper on NFS:
    "Because the NFS is stateless,, when servicing an NFS request
     it must commit any modified data to stable storage before
     returning results."

Here, they are including as one of the properties of statelessness
the ease with which a client can recover from a server failure.
If you don't feel that this is a required property (e.g., the
client could detect it and do clean up), then your comment is
correct.  This property and the lack of per-client data stored
at the server do seem to be separable issues.  We don't do 
write-through on our system, but conceivably we could do it
to simplify client recovery even though we are not "stateless".

These issues are complex, and the tradeoffs are too.  I'm not
claiming that there are any universal answers.  But I'm interested
in discussing the tradeoffs.

--
Martin S. McKendry;	FileNet Corp	{hplabs,trwrb}!felix!martin
Get in on the ground floor: Buy FileNet stock now!
-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      Sat, 15-Aug-87 19:41:18 EDT
From:      martillo@athena.mit.edu (Yakim Martillo)
To:        comp.protocols.tcp-ip
Subject:   Re: ethernet multicast

In article <8708131534.AA14351@ucbvax.Berkeley.EDU> cain@EDN-UNIX.ARPA (Edward A. Cain) writes:
>Is there a commercial product (gateway) which supports ethernet multicast?
>Needs to take an IP datagram from Arpanet, recongize that the IP address
>is really a group address, and multicast it onto an ethernet.
 
>Ed Cain

I believe that for hosts directly connected to an IMP via 1822 IP
addresses uniquely identified the IMP interface to which a host is
connected.  The unique mapping of hardware interface to IP address is
quite natural in this case.  When TCP/IP moved onto ethernet, the
mapping of IP address to physical interface was maintained though for
a multihomed host with a separated IP address on each network (of any
type of communications subnet) there should be no problem with
handling an IP packet on any interface with any IP address as long as
IP processing is done in the host or as long as the communications
controllers can communicate with one another over the backplane as is
possible with DEC machines.  Also when people began putting PCs onto
ethernets, dynamically assigning IP addresses to PCs seems to be quite
reasonable.   Further when ISDN interfaces become available,
dynamically assigning IP addresses to sets of switched physical or
virtual circuits will probably make sense (especially for certain
cases of security).  Thus my questions are:

	Is there such a thing as an IP *group* address and if
	there is what is it used for?

	Next if there are IP group addresses how do they work
	in an internetting environment.

	If there are IP group addresses, does it make any sense to
	map them to ethernet multicast addresses (which I guess would
	be assigned to groups of hosts dynamically) and if it does how
	would one go about handling multinetwork IP group addresses
	for which multicasting would be clearly insufficient.

-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      Sat, 15-Aug-87 21:29:00 EDT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: ethernet multicast

You should look into host group multicast - see Bob Braden or the
RFCs for details.

Vint Cerf

-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      Sun, 16-Aug-87 00:14:52 EDT
From:      postel@ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: ethernet multicast


See RFCs 966 and 988.

--jon.
	

-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      Sun, 16-Aug-87 10:15:02 EDT
From:      jan@swivax.UUCP (Jan Wielemaker)
To:        comp.protocols.tcp-ip
Subject:   bridge on sun (cr/lf)

We have a Bridge CS/100 terminal multiplexer  and  a  SUN  Unix  network
running  SunUnix 3.2.  When I connect via the Bridge all CR's are mapped
on LF's, even with the driver in 'nl' mode.  Probably the telnet  daemon
is  doing  this, but it is very anoying with Emacs editors!  Who knows a
fix for this?

Thanks --- Jan

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      16 Aug 87 09:01:10 GMT
From:      gorodish!guy@sun.com  (Guy Harris)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: RFS vs NFS
> The price of Sun's stateless approach is that preservation of consistency
> of the file system requires that clients interrogate the server to confirm
> currency of cached entries, *whether or not those entries have changed*.

Or that you have timeouts on the cached data, which is the way SunOS does it
(and the way NFS implementations derived from the Sun implementation, which
probably includes most UNIX NFS implementations, would most likely do it).
Also, (on SunOS, at least) if you do byte-span locking on a file, the caching
on data for that file is turned off, so that it goes back to the server on
every "read".

> The main reasons we keep this data at the server are a) for cache
> invalidation, and b) to manage exclusive locking.    Sun let the
> client worry about invalidation, and they don't do exclusive locking.

If by "locking" you are referring either to BSD-style file locking or
Bass/POSIX/S5-style byte-span locking, we most definitely *do* have exclusive
locking (Bass/POSIX/S5-style), we just don't do it using the NFS protocol!
There is no reason to tie all of your file-system operations to the NFS
protocol.

RFS also supports Bass/POSIX/S5-style locking.
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com
-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      16 Aug 87 09:11:33 GMT
From:      gorodish!guy@sun.com  (Guy Harris)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: RFS vs NFS
> The client has a 'handle' for a file that can always be recognized
> by the server and maintains local state as to 'offset', etc.  

If by that you mean that a file handle contains the current offset in the file
as used for I/O operations, a file handle contains no such thing.  In SunOS,
the file handle for a UNIX file contains a unique identifier for the file, made
out of a file system ID and a file ID containing the i-number and generation
count, and that's it.

The current I/O offset is maintained by the client for each open instance of a
file; if the client crashes, this data is obviously of no interest (since all
the processes that have the file open have gone away), so it gets thrown away.
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com
-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      16 Aug 87 16:15:42 GMT
From:      mtune!whuts!homxb!houxa!mel1@RUTGERS.EDU  (M.HAAS)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: RFS vs NFS
Would someone please post a note explaining all this?  What is
statelessness?  Is it good or bad?  Why would someone care?

I think the original posting asked for an explination of the
differences between RFS and NFS.  A good question, worth answering.
But, please in English and please in terms of a user, or
administrator, or purchaser, too.  (As well as academics.)

   Thanks,
     Mel Haas  ,  odyssey!mel

P.S. Can someone please expand this discussion to include a user's
(and/or administrator's) perspective on NFS vs RFS vs NewCastle vs
rcp-rsh-rlogin?  Particularly, which can co-exist on the network?
Which take up the most resources?  the most administration?  Which
are easiest to use?   Which presents the least pain at malfunction
time?  etc?   Thanks.
-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      Sun, 16-Aug-87 23:41:48 EDT
From:      bzs@BU-CS.BU.EDU (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   Re: NFS vs The World


The technical discussions are interesting in regards to things like
statelessness vs statefulness etc.

What the casual or more product oriented person needs to know is:

1. NFS has been delivered in production systems for years now, it
works.

2. NFS is now widely available from vendors for heterogeneous networks
running on many different machines compatibly.

3. NFS uses the Internet protocol suite for its lower layers, by and
large your knowledge and current investment in internet hardware and
software will help you set up and maintain an NFS network.

None of the above is really true about RFS (except that it's probably
available on some very small set of machines from one vendor.) By and
large it's vaporware in its promises to be a widely available
heterogeneous product and its implementation on a non-internet
standard makes it harder to see what its potential utility is (you
want to become a 3Bnet expert on Starlan twisted pair? why?)

Let's put it this way, at Boston University we run a lot of NFS sites
in different depts. We've been using it to share single copies of
things like font directories, software and source distributions, data
bases and network news all over campus and to combine clusters of
machines into one single environment where users maintain one home
directory wherever they log in. RFS can do all this in theory but
you'll have to settle on a very limited (1?) set of machine types,
it's the old tail wagging the dog. NFS works, we've had it in
production for over a year and the NFS community here just grows and
grows.

Like I said, technical discussions interest me also, but as far as I
can see there is a standard in heterogeneous network file systems: NFS.
And about 100 vendors agree with me.

RFS may have its pluses but in terms of being a viable product it strikes
me as being too little too late.

	-Barry Shein, Boston University

-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      Mon, 17-Aug-87 00:33:36 EDT
From:      hedrick@TOPAZ.RUTGERS.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: RFS vs NFS

The distinction involved in "statelessness" is how much "state
information" is kept around by file servers about who is using them.
If the protocol requires the server to keep control information about
each user, then if the server goes down and is rebooted, the clients
will not be able to continue.  State information is also needed in
order to remember who has what file locked.  When it is said that NFS
is stateless, what this means is that in principle a given request can
be processed without any reference to any previous requests, or any
side effects created by such previous requests.  The advantage of this
approach is that clients and servers can randomly crash and come up,
or be rebooted, and no special action is needed to keep the network
file system consistent.  The previous discussion points out that this
distinction is at best a slippery one.  What a client sees most
certainly does depend upon the state of the file system: that's the
whole point of doing a remote access, after all.  As somebody
mentioned, if you dump and restore a file system, all your files have
new inode numbers, and all the clients are going to have to restart
whatever they are doing.  (This situation will be detected by NFS if
you do things correctly.  However recovery will require you to kill
all the processes that are using the file system remotely, umount it
and then mount it again.)  However except for things that completely
rebuild a file system, NFS in practice does recover from crashes and
reboots.  The only operational problems we have seen with it are that
when a server is down, its clients have a tendency to behave badly in
various ways, even when what they are doing does not really require
that particular server.  This does not seem to have anything to do
with the NFS protocol per se, but is an implementation issue.  (In
general that situation is improving release by release.)  People
around here have gotten started typing "df &", just to avoid having
our jobs hang if any servers are down.  (To be fair, this is largely
because of machines running out of date NFS implementations.  On
a Sun, you can eventually get out of df in this situation, though it
is still annoying.)

File locking is handled by a separate lock daemon, which is not part
of NFS, though it is implemented using similar mechanisms.  File
locking obviously involves state information.  The server has to
remember that the file is locked across crashes.  It also has to have
a way to get rid of the lock if the client crashes.  Sun uses two
daemons, lockd and statd, to keep track of things.  Statd seems to be
responsible for keeping track of what machines are up, and
reestablishing connections after a crash and reload.  It uses a set of
disk directories that contain hosts that it is to monitor and hosts
that it is to notify when it comes up after a crash.  Like NFS, there
don't seem to be any administrative tools involved in maintaining or
restoring consistency to the locking system.  However I do recall one
time where we had to do some manual cleanup after permanently removing
a machine.  I suspect statd had been told to keep track of the
machine.  There was no big damage, just an ocassional console error
message we wanted to get rid of.

There are no adminstrative issues involved with maintaining NFS per
se.  However you certainly do want to think carefully about what
machines mount what disks, and what attributes you will use (e.g.
readonly and whether root access is preserved across the network).
Our primary planning problem is setting things up so that we don't
have every machine having to mount every other disk in the world.

I make no comparisons with other remote file system protocols, since I
don't know them.  You can imagine protocols that would keep internal
state information about every file that is open, and which would leave
the world in a horribly inconsistent state after a crash and reload.
But whether any such things actually exist, I couldn't say.  The only
bad examples Sun pointed to back when they introduced NFS had to do
with file locking.  But locking is a special situation, where even Sun
maintains state information.

-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      Mon, 17-Aug-87 11:31:30 EDT
From:      marantz@aramis.rutgers.edu (Roy Marantz)
To:        comp.protocols.misc,comp.protocols.tcp-ip,comp.dcom.lans
Subject:   wanted: software to talk to a HP 4972


Does anyone have any software that will talk (from a regular computer,
say a Sun or a Vax) to a HP 4972 lan protocol analyzer?  I have
documentation on the protocol, but would like to avoid having to
implement it if I can.  (I'm just basically lazy :-)  I want to be
able to get data files from the analyzer and maybe be anble to send a
node-ethernet list to it.  I'd also really like to the source to the
program. 

I'd also be real interested in any code that will talk DDCMP from a
non DEC machine. (i.e. a Sun or Pyramid)  That would be a good start
for writing this "comm" package.

Thanks for any and all assistance and please respond directly to me.
I'll summarize and repost if there is interest.

Roy

-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      Mon, 17-Aug-87 12:50:38 EDT
From:      braden@ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: ethernet multicast


	
		Is there such a thing as an IP *group* address and if
		there is what is it used for?
	
		Next if there are IP group addresses how do they work
		in an internetting environment.
	
		If there are IP group addresses, does it make any sense to
		map them to ethernet multicast addresses (which I guess would
		be assigned to groups of hosts dynamically) and if it does how
		would one go about handling multinetwork IP group addresses
		for which multicasting would be clearly insufficient.
	
Please see RFC988 for the definition of IP group addresses.  Although it
is not yet an Internet standard, it is likely to become one soon. 
Experimental implementations for 4.3BSD are available, as previously
announced on this list.

   Bob Braden
   

-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      Mon, 17-Aug-87 14:52:40 EDT
From:      minshall@OPAL.BERKELEY.EDU
To:        comp.protocols.tcp-ip
Subject:   Beta test version of tn3270 available.

A beta test version of release 3 of tn3270 is now available.

Tn3270 is a program which allows users to login from Unix machines or (with
this release) MSDOS machines to an IBM mainframe (running VM/CMS or MVS)
and interact with the IBM machine in full-screen mode.

The beta test version may be acquired via anonymous ftp to host
arpa.berkeley.edu (10.0.0.78).  The file is in directory pub.  This
distribution is very large.  The file tn3270.tar is a bit over 700Kbytes;
there is a compress(1) file tn3270.tar.Z which is a bit over 300Kbytes.

    For people who cannot access arpa.berkeley.edu via the arpanet, I will
    be willing to produce a limited number of copies of the distribution
    on an AT style, 1.2MByte, High Capacity diskette.  Send me the diskette,
    along with what you would like, and I will attempt to create a diskette
    to send you back.  Please note that possibly the result of your sending
    me a diskette MAY be our sending you a form to fill out (this will happen
    if our software distribution group takes over the filling of orders; this
    will also likely involve a small, $50 or $100, distribution fee).

Following is a short blurb on what is neat about the new version.  However,
I should mention who might be interested:  1) Vendors implementing tn3270
(since this version has more features and should be easier to port), 2)
People who want a free (and more-or-less unsupported) tn3270 for MSDOS,
3) People who need Yale-style graphics to work correctly.  There is
follow-on work planned to implement a native X version and, within that
version, to do IBM 3179G-style graphics.  Because of this follow-on work,
I'm not sure (at the moment) whether we will polish up this beta release,
or go directly to an enhanced-function release.

If you are a beta test site, please let me know of both good and bad
experiences.

Greg Minshall
CFC
275 Evans Hall
UC Berkeley, CA  94720

(415)642-0530

minshall@berkeley.edu
--------
ps - the telnet.c distributed with this release has some bug fixes for
	binary mode, and allows the user to decide whether <CR><NUL> or
	<CR><LF> should be sent over a non-3270 connection when the
	user types carriage-return.


-----------
New versions of the tn3270 and mset commands, used to logon to CMS from
unix, are now available.

New features are:

	o	Error messages, in English, overlay a portion of the
		screen when the user types an erroneous entry (invalid
		control sequence, attempt to enter data in an "input
		disallowed" field, etc.).

	o	Ability to "escape to shell".  This, by itself, is
		mostly useful in an MS-DOS (or non-BSD) system.

	o	An Application Programming Interface (API).  This allows
		programs, running under Unix or MS-DOS, to read and
		write the 3270 screen, and to send keystrokes (3270)
		to tn3270.  This makes use of the "escape to shell"
		feature.  Included in the (beta) distribution is a
		program which uses the API to receive files sent from
		the IBM host (we don't supply the IBM side at this point,
		and the rather stupid protocol is likely to change in
		the future).

	o	Yale ASCII/7171/4994 "transparent" mode should now
		be fully implemented.  SAS-Graph, for example,
		supports doing graphics to TEK terminals over
		this interface.  Locally, we use the X windowing
		system terminal emulator (xterm), which provides
		some TEK emulation, to display SAS-Graph graphics
		on our workstations.

	o	Mset now prints out program function (PF) keys in
		numerical order.

	o	Various bugs have been fixed.

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      Mon, 17-Aug-87 18:56:59 EDT
From:      karn@JUPITER.BELLCORE.COM (Phil R. Karn)
To:        comp.protocols.tcp-ip
Subject:   (none)

I'm curious to know if any thought has been given to providing subnet
broadcasting or multicasting in the ARPANET. By this, I mean allowing a host
connected to an ARPANET IMP to send a special 1822 message that is received
by some or all of the other hosts on the ARPANET.  The feature could be
implemented within the PSNs through flooding a la USENET.

Such a feature might be very useful to support IP routing algorithms.  The
gateways could broadcast information to each other much as they do now on
Ethernet (though hopefully something better than RIP would be used!) As I
understand it, this would make the "Core Gateway" notion unnecessary.

It seems to me that if the users of a subnetwork need a broadcast facility,
it should be more efficient to implement it within the subnet.  The only way
the users can simulate it is by sending out "bulk mail", congesting links
with multiple identical messages with different destinations.  With subnet
flooding, however, each link would have to be traversed only once.

Comments?

Phil

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      Mon, 17-Aug-87 20:07:53 EDT
From:      karn@JUPITER.BELLCORE.COM (Phil R. Karn)
To:        comp.protocols.tcp-ip
Subject:   Generalized Subnetting

The recent discussion about varying subnet sizes was interesting. I have
implemented a "generalized subnetting" scheme in my own IP routing code that
handles this and many similar problems quite well.

Basically, I completely ignore the usual rules that distinguish class A, B
and C addresses. Instead I keep an explicit subnet mask with each entry in
the routing table. (Actually, I use integers between 0 and 32, but the
semantics are the same). When a packet is to be routed, I search the routing
table for the "best" match under control of the mask.  That is, if my
routing table contains

target		width	interface	gateway
128.96.33.101	32	sl0
128.96		16	ec0
0		0	ec0		128.96.41.1

and I present the address 128.96.33.101, all three entries match. In this
case, I select the entry with the greatest width, i.e., the first one.  Note
that the last entry always matches every address; it is the default route.
The first one is a host-specific entry, matching only one IP address.

Note that the routing table points to an INTERFACE name, not a gateway
address. The gateway field is optional. It is filled in only if the target
is to be reached through a gateway on a multiple access subnet, in which
case the gateway field is passed down to the subnet driver for translation
into a subnet address.  If the gateway field is null, the subnet driver is
given the target IP address for translation; this would be done if the
target is directly on the same subnet.  If the subnet is a point-to-point
link, the gateway address field is ignored altogether since the subnet
has no need for link level addresses.

With this scheme you can construct a completely arbitrary internet out of
ad-hoc point-to-point links, incompletely connected broadcast subnets (e.g.,
amateur packet radio), partitioned networks as well as "real" subnets like
Ethernets without filling up your routing table with lots of host-specific
entries. You can "bunch up" address groups that begin with a common bit
pattern, regardless of whether they are really all hosts on the same subnet,
or you can split off one or more hosts that are behind a point-to-point
link, for example. It works very well.

Phil

-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 87 22:05:07 GMT
From:      amdcad!amd!intelca!oliveb!felix!martin@ucbvax.Berkeley.EDU  (Martin McKendry)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: RFS vs NFS
In article <25738@sun.uucp> guy%gorodish@Sun.COM (Guy Harris) writes:

>There is no reason to tie all of your file-system operations to the NFS
>protocol.

Hang on a minute mate.  If all the file system isn't in NFS, what is NFS?
A piece of the file system?  As in, "part of our file system is stateless".
If, in order to implement the entire file system, you have to access
components that are not stateless, then isn't it incorrect to say that
the file system is stateless?

(Asbestos suit on)



--
Martin S. McKendry;	FileNet Corp	{hplabs,trwrb}!felix!martin
Get in on the ground floor: Buy FileNet stock now!
-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 1987 11:01:46 CDT
From:      Link Verstegen@GUNTER-ADAM.ARPA
To:        tcp-ip@SRI-NIC.ARPA
Cc:        LINK@GUNTER-ADAM.ARPA
Subject:   Hosts and Gateways

I'm trying to get some information on the exact process used to get a 
gateway up on the net.  We want to do some testing of a pair of EGP
gateways using two ports on loan from another program.  What are the
steps we need to take to bring the hosts down, bring the gateways up,
notify the core gateways that they're alive, and then get the hosts back
up and running?

	It's my understanding that there are some administrative steps
missing in the above description of what we want to do, but no one I've
talked to has the right answers.  Any help you can give me would be
greatly appreciated.


		    /|                  /|
===================/ |=================/ |===================
 Link N. Verstegen                     Link@Gunter-ADAM.ARPA
 Computer Systems/Network Engineer
 HQ SSC/PRAIT                            (205)279-5151
 Gunter AFS, AL  36114-6343                AV 446-5151

-------
-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      Tue, 18-Aug-87 11:54:26 EDT
From:      ron@TOPAZ.RUTGERS.EDU (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re: TAC "noise"

Yes, you can send an extra stop bit, and then expect not to receive two
and things will work OK, but you can not reliably deal with 7-bit No parity
(a 9 bit frame) when you are expecing 8 bit,no-parity or 7-bit,parity
(10 bit frames).

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      Tue, 18-Aug-87 12:01:46 EDT
From:      Link.Verstegen@GUNTER-ADAM.ARPA
To:        comp.protocols.tcp-ip
Subject:   Hosts and Gateways


I'm trying to get some information on the exact process used to get a 
gateway up on the net.  We want to do some testing of a pair of EGP
gateways using two ports on loan from another program.  What are the
steps we need to take to bring the hosts down, bring the gateways up,
notify the core gateways that they're alive, and then get the hosts back
up and running?

	It's my understanding that there are some administrative steps
missing in the above description of what we want to do, but no one I've
talked to has the right answers.  Any help you can give me would be
greatly appreciated.


		    /|                  /|
===================/ |=================/ |===================
 Link N. Verstegen                     Link@Gunter-ADAM.ARPA
 Computer Systems/Network Engineer
 HQ SSC/PRAIT                            (205)279-5151
 Gunter AFS, AL  36114-6343                AV 446-5151

-------

-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      Tue, 18-Aug-87 14:43:33 EDT
From:      dave@rosevax.Rosemount.COM (David R. Marquardt)
To:        comp.protocols.tcp-ip
Subject:   Re: bridge on sun (cr/lf)

In article <378@swivax.UUCP> jan@swivax.UUCP (Jan Wielemaker) writes:
>We have a Bridge CS/100 terminal multiplexer  and  a  SUN  Unix  network
>running  SunUnix 3.2.  When I connect via the Bridge all CR's are mapped
>on LF's, even with the driver in 'nl' mode.  Probably the telnet  daemon
>is  doing  this, but it is very anoying with Emacs editors!  Who knows a
>fix for this?

We just upgraded to SunOS 3.4, and this fixed the problem.

	Dave

-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      Tue, 18-Aug-87 16:33:08 EDT
From:      phil@amdcad.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: Blue Book

In article <8708112229.AA00510@apolling.imagen.uucp> geof@apolling.UUCP (Geof Cooper) writes:
>
>PS: The cover IS blue on version 2.  The cover of version 1 was gray
>    with a blue stripe.

Hm, my version 1.0 is all blue. So is my 2.0, but a different tint.  I
got them from the Xerox office in Sunnyvale, which used to be Shugart
facilities. But that's not the reason for this article.

I heard there was a mistake in the example transceiver cable receiver
circuit which was never fixed. I must say I can't understand why the
data valid signal is fed back to those two line termination resistors
(39 ohms). Any comments?

-- 
I speak for myself, not the company.

Phil Ngai, {ucbvax,decwrl,allegra}!amdcad!phil or amdcad!phil@decwrl.dec.com

-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      Tue, 18-Aug-87 17:15:21 EDT
From:      chuck@excelan.UUCP (Chuck Kollars, )
To:        comp.protocols.tcp-ip
Subject:   posting for moderated news group protocols.tcp-ip

Subject: 2 IP's on 1 LAN
Keywords: TCP-IP Vitalink MAC-Bridge Ethernet

The need to have 2 logically separate IP networks on a single
datalink (specifically, an Ethernet LAN) for administrative reasons 
has arisen.  
 [Examples:
   a) Some nodes on a LAN have officially assigned IP addresses 
      because they sometimes interoperate with another network.  To
      conserve IP addresses, other nodes on the same LAN are assigned 
      IP addresses from a separate address space.  
   b) Two networks which are geographically separated, and which have
      been administered separately, are now being connected by a
      Vitalink datalink-level MAC-bridge.]  

Based on experience with similar situations, is the best course of 
action to:
  1) Modify the IP routing algorithm in each node to understand the
     notion of a "direct" route.  

  2) Reassign IP addresses so that all nodes have the same IP network
     number.  

  3) Install separate devices which act as fake gateways.  

  4) Other

--------------------------------------------------------------------
Chuck Kollars   - address for direct mail responses:  
  arpa:  mtxinu!excelan!chuck@ucbvax.berkeley.edu
  uucp:  ...ucbvax!mtxinu!excelan!chuck

-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      Tue, 18-Aug-87 19:40:14 EDT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Generalized Subnetting

Phil,

You have described the scheme used in the intrepid fuzzballs, although those
animals use a full 32-bit mask to allow arbitrary field geometries. The
problem is that the scheme is not particularly fast and is hard to hash.
The solution may be an algorithm that quickly turns a description such
as yours into a partition of the 32-bit space which can be hashed and
used in a match-once fashion.

The fuzzscheme, now indigenous to the NSFNET Backbone, provides a hand way
to build ARPANET tunnels through other nets, which has been found a handy
feature during times when routing is otherwise broken.

Dave

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 87 18:35:52 GMT
From:      gorodish!guy@sun.com  (Guy Harris)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: RFS vs NFS
> Hang on a minute mate.  If all the file system isn't in NFS, what is NFS?
> A piece of the file system?  As in, "part of our file system is stateless".
> If, in order to implement the entire file system, you have to access
> components that are not stateless, then isn't it incorrect to say that
> the file system is stateless?

It depends on your definition of "file system".  All the functions necessary
for opening, reading, writing, getting the status of, ... files are in NFS.
None of the functions necessary for locking regions of files are in NFS.

NFS isn't a file system; it's an RPC-based mechanism for performing certain
operations on remote file systems.  Its semantics match the UNIX file system
better than they match those of other file systems, but it is used for other
file system types, e.g. MS-DOS.  Applications running on a machine with NFS
generally don't use NFS, they use the native OS's file manipulation operations.
Some of those map to NFS operations, or to sets of NFS operations, some don't.
For example, a UNIX "open" will map to a series of NFS "lookup" operations, and
some other operations; a "read" will map to one or more NFS "read" operations,
if the data to be read isn't in the buffer cache.  However, an "fcntl" call to
lock a file will map to a lock manager RPC call, not to any NFS RPC calls.

If you are using file or record locking, then no, the file system that the
application sees is not stateless, since that file system is implemented both
by the NFS and by the lock manager.  If you are not using file or record
locking, then the file system the the application sees is stateless.
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com
-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      Tue, 18-Aug-87 23:04:14 EDT
From:      karn@FALINE.BELLCORE.COM.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re:  Generalized Subnetting

I thought this probably wasn't original, but I'm glad to see somebody
else considers it worthwhile.

I too was concerned about the speed of the algorithm. I originally
implemented it in a totally brute-force fashion. A "for" loop searches
the hash table 32 times starting with the widest possible mask and
working down until it hits a match.  I assumed I would have to place a
cache on top of this to get decent performance.  To my delight, however,
I discovered that going all the way down to the default entry still took
only 6 milliseconds -- on a Taiwanese PC/XT turbo clone! Given the
channel speeds involved in the environment I wrote my software for, I
didn't consider further optimization to be a high priority task.

Sometimes brute force is good enough...

Phil

-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19-Aug-87 06:07:11 EDT
From:      ben@cernvax.UUCP (ben)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP for Motorola RMS68K O/S ??


I'm not sure this went out correctly last week, so am resending: forgive me
if it did.....

We are looking for possible TCP/IP implementations for 68K systems running
the Motorola RMS68k operating system. We are interested both in the case where
all of the protocols and utilities run on the 68K, or where an intelligent
board is used, e.g. Excelan, CMC, etc. (for VME-based systems). A big bonus
would be the additional availability of (at least client) NFS.

-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19-Aug-87 10:10:05 EDT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Generalized Subnetting

Phil,

Well, brute force is not enough when there are 270 vanilla IP entries in
the table, not to mention subnets, tunnels and crooked passageways. A
gateway popping 6 ms per packet (133 packet/s) is probably too slow for
any trunkline use. In my experience the depth of search is seldom more
than three, one for the martian filter, one for the subnet and one for
the net. Tunnels and defaults add another one each, but these are seldom
used. With fuzzballs type-of-service adds another level for each TOS
combination and an alternate-routing feature (fallback) adds another. With
these last the tables get so intricate and delicate that I hesitate to
use them outside the lab. This is where we need some clever algorithmic
translation between the handy descriptions you and I are using and the
actual table structure/cache that drives the routing function.

Dave

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19-Aug-87 14:09:52 EDT
From:      isns01@ms3.UUCP (Jim Chappell)
To:        comp.sources.wanted,comp.protocols.tcp-ip
Subject:   Wanted -- 4.2 BSD Exterior Gateway Protocol

We need the source to EGP.  We can't upgrade to 4.3 BSD because
our Office System Vendor, CCI, says they won't support their product
under 4.3.  We have a 4.2 BSD license.

Thanks,
-- 
Jim Chappell               UUCP: ...!umd5!vrdxhq!ms3!jrc 
ISN Corp.  (703) 979-8900  ARPA: jrc@hios-pent
1235A Jeff Davis Hwy, Suite 220
Arlington, Va 22202

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19-Aug-87 14:16:16 EDT
From:      ron@TOPAZ.RUTGERS.EDU (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re:  DDN Node Location

It's best to have the node closer to the computer that it serves.
The lines are cheaper to run (just plain ol' telephone wire) to
the node than it is to extend the cables between the hosts and the
node.  Since the trunks are already on modems, rerouting the wire
is not a big effort.  Extending the cables to the hosts would require
running larger cables for short distances or the purchase of modems
(for X.25 and HDH) or ECU's and Modems (for LH/DH) that would not
ordinarily be necessary.

The idea of a distributed packet switch network is to put the switches
near the end points not to centrally locate them.

-Ron

-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19-Aug-87 16:15:43 EDT
From:      spp@zion.berkeley.edu (Steve Pope)
To:        comp.protocols.tcp-ip
Subject:   SLIP

I've seen references here and there to "SLIP", which I believe
stands for "Serial Link Internet Protocol".  It is used,
I understand, to run IP links over duplex serial lines or modems.

Can anyone tell me a little more about SLIP?
Thanks in advance.

steve pope

-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19-Aug-87 21:47:51 EDT
From:      wcs@ho95e.ATT.COM (Bill.Stewart)
To:        news.groups,comp.protocols.tcp-ip
Subject:   Does comp.protocols.iso exist?


In article <1510@hou2d.UUCP> n2dsy@hou2d.UUCP (J.BEATTIE) writes:
:I guess this is a relatively new newsgroup...my system 
:doesn't seem to have any items listed.

I never got a newgroup message, but I remember some discussion a couple
months ago.  Was the group ever approved?  Is it part of inet?
-- 
#				Thanks;
# Bill Stewart, AT&T Bell Labs 2G218, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs

-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      Thu, 20-Aug-87 09:34:32 EDT
From:      kzm@ACC-SB-UNIX.ARPA (Keith McCloghrie)
To:        comp.protocols.tcp-ip
Subject:   Re: Broadcast/Multicast on ARPANET

Phil,

You point out a number of the ways in which the capability of
providing subnet broadcasting or multicasting in the ARPANET could
be very useful.  I agree.  However, I suggest that there would need
to be some safeguards installed to prevent the ARPANET from becoming
susceptible to the kind of meltdowns which occur in LANs when this
capability is abused.  The absence of this capability in the wide-area
currently provides a firebreak between LAN-subnet clusters, to prevent
a meltdown from encompassing the whole internet.

Possible safeguards could include : only administratively-authorized 
Host-ports should have this capability and even the Hosts connected
to those should be required to prove that abuse will not occur;
restrictions on the types of packets/destination-addresses which
are to be forwarded by gateways using this capability.  Maybe,
only multicasting should be supported (not broadcasting) ?

Keith.

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      Thu, 20-Aug-87 15:47:14 EDT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   DELUA interface driver needed

I need a 4.3BSD DELUA driver.  The DEUNA we use currently wedges.
As I understand it, there is no software in the world which will make
it work any better.  So its time to trade up.

-Phil Wood, (cpw@lanl.gov)

-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      Thu, 20-Aug-87 16:23:23 EDT
From:      gil@ablnc.ATT.COM (Gil Widdowson)
To:        comp.protocols.tcp-ip,comp.protocols.misc
Subject:   Using sockets select(3) function

I have been trying to use the select(3w) function to
handle I/O on multiple datagram and virtual circuit fds.
This is on a UTS system running Wollongong's TCP/IP.
The general application I am trying to upgrade has
been running under sockets on this machine for
about a year using alarms to do polling.

All fds were set to O_NDELAY after they were created.

What I wanted to do was set up my fd masks and count
and call select() with the time struct pointer set to
NULL so it would pend until data came it. Well it just
pended forever. So I figured that I misread the intent,
and tried setting the time structure so it returned once
a second. When it returned it always returned zero, and
the masks were all zero. Stepping through in sdb() and
forcing the code out of my pend loop, I always found the
data that I knew was there. Am I doing something fundamentally
wrong? ( I get same results on AT&T 3Bs which also run
Wollongong port). A working scrap of code would be greatly
appreciated.

Thanks,

Gil Widdowson AT&T DP&CT Maitland FL (305) 660-6123
{ihnp4, moss} abfli!utiprod!gil

-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21-Aug-87 02:33:39 EDT
From:      cracraft@venera.isi.edu (Stuart Cracraft)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   looping telnetd bug

Has anyone out there in netland encountered the mysterious
looping telnetd bug? (the /etc/telnetd daemon).

The first sign seems to be a telnetd process chewing up hours
of cpu. Just wondered if someone else noticed it too.

	Stuart

-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21-Aug-87 05:34:33 EDT
From:      baard%vax.elab.unit.uninett@TOR.NTA.NO (baard w torustad)
To:        comp.protocols.tcp-ip
Subject:   tcp-ip for xenix on sperry pc

i am looking for tcp-ip software for xenix on sperry personal computer.
to which i can add my own link-layer protocol.  (... for the B-channels
on an ISDNetwork.)

public domain or commercial.

Baard Torustad, (baard%vax.elab.unit.uninett@nta-vax.arlook

-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      21 Aug 87 11:09:00 PST
From:      <art@acc.arpa>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Cc:        ietf@gateway.mitre.org,art
Subject:   TCP SRTT

I implemented the SRTT algoritm posted by Van Jacobsen a while back.
This is the one that accumulates both a smoothed round trip time estimate
(SRTT) and also a smoothed variance estimate (which I call SRTV).  The
retransmit timer is set to: (SRTT + 2*SRTV)*rxmt_backoff_factor.

This has greatly improved the behavior of TCP over low speed links
(4800-9600 baud), while showing no noticable effect over Ethernet.
Using the standard SRTT algorithm, I was seeing as low as 10% link
utilization because of spurious retransmissions.  The new algorithm
is giving over 90% link utilization.

I would recommend others consider using this algoritm if there TCP
ever uses a path with large delay variance (such as low speed lines
or Arpa Internet).
					Art Berggreen
					art@acc.arpa

------
-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21-Aug-87 11:05:32 EDT
From:      templin@DECVAX.DEC.COM (Fred Templin)
To:        comp.protocols.tcp-ip
Subject:   Re:  DELUA interface driver needed

Hi!

The DELUA should be plug-compatible with the 4.3BSD if_de.c driver. I work
with the ULTRIX network drivers, and the only change we've made for DELUA's
is a check in the "deprobe" routine to make sure the board has passed power-
up self test before forcing an interrupt. I don't believe this is done in the
4.3BSD driver, but I really don't see this as being a problem. I'd suggest
just having field service install the DELUA and reboot (but, of course, I
can't be held responsible!) 

Fred L. Templin

( templin@decvax.dec.com )

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21-Aug-87 15:09:00 EDT
From:      art@ACC.ARPA
To:        comp.protocols.tcp-ip
Subject:   TCP SRTT


I implemented the SRTT algoritm posted by Van Jacobsen a while back.
This is the one that accumulates both a smoothed round trip time estimate
(SRTT) and also a smoothed variance estimate (which I call SRTV).  The
retransmit timer is set to: (SRTT + 2*SRTV)*rxmt_backoff_factor.

This has greatly improved the behavior of TCP over low speed links
(4800-9600 baud), while showing no noticable effect over Ethernet.
Using the standard SRTT algorithm, I was seeing as low as 10% link
utilization because of spurious retransmissions.  The new algorithm
is giving over 90% link utilization.

I would recommend others consider using this algoritm if there TCP
ever uses a path with large delay variance (such as low speed lines
or Arpa Internet).
					Art Berggreen
					art@acc.arpa

------

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21-Aug-87 15:20:17 EDT
From:      karels%okeeffe@UCBVAX.BERKELEY.EDU (Mike Karels)
To:        comp.protocols.tcp-ip
Subject:   Re: DELUA interface driver needed

Here are the changes Donn Seeley put into the 4.3 driver to wait
for self test to complete on DELUA's.  As Fred Templin says, there
really shouldn't be any change required to the DEUNA driver for
use with the DELUA, but the self-test may take longer than the 4.3
driver will wait.

		Mike

*** /nbsd/sys/vaxif/if_de.c	Thu Jun  5 17:02:59 1986
--- if_de.c	Fri Jul 18 17:48:29 1986
***************
*** 5,7 ****
   *
!  *	@(#)if_de.c	7.1 (Berkeley) 6/5/86
   */
--- 5,7 ----
   *
!  *	@(#)if_de.c	7.2 (Berkeley) 7/18/86
   */
***************
*** 125,126 ****
--- 125,142 ----
  
+ 	/*
+ 	 * Make sure self-test is finished before we screw with the board.
+ 	 * Self-test on a DELUA can take 15 seconds (argh).
+ 	 */
+ 	for (i = 0;
+ 	     i < 160 &&
+ 	     (addr->pcsr0 & PCSR0_FATI) == 0 &&
+ 	     (addr->pcsr1 & PCSR1_STMASK) == STAT_RESET;
+ 	     ++i)
+ 		DELAY(100000);
+ 	if ((addr->pcsr0 & PCSR0_FATI) != 0 ||
+ 	    (addr->pcsr1 & PCSR1_STMASK) != STAT_READY)
+ 		return(0);
+ 
+ 	addr->pcsr0 = 0;
+ 	DELAY(100);
  	addr->pcsr0 = PCSR0_RSET;
***************
*** 148,149 ****
--- 164,166 ----
  	register struct dedevice *addr = (struct dedevice *)ui->ui_addr;
+ 	int csr1;
  
***************
*** 155,156 ****
--- 172,186 ----
  	/*
+ 	 * What kind of a board is this?
+ 	 * The error bits 4-6 in pcsr1 are a device id as long as
+ 	 * the high byte is zero.
+ 	 */
+ 	csr1 = addr->pcsr1;
+ 	if (csr1 & 0xff60)
+ 		printf("de%d: broken\n", ui->ui_unit);
+ 	else if (csr1 & 0x10)
+ 		printf("de%d: delua\n", ui->ui_unit);
+ 	else
+ 		printf("de%d: deuna\n", ui->ui_unit);
+ 
+ 	/*
  	 * Reset the board and temporarily map
***************
*** 158,159 ****
--- 188,191 ----
  	 */
+ 	addr->pcsr0 = 0;		/* reset INTE */
+ 	DELAY(100);
  	addr->pcsr0 = PCSR0_RSET;
***************
*** 247,248 ****
--- 279,282 ----
  	addr->pcsr3 = (incaddr >> 16) & 0x3;
+ 	addr->pclow = 0;	/* reset INTE */
+ 	DELAY(100);
  	addr->pclow = CMD_GETPCBB;
***************
*** 298,301 ****
  	ds->ds_if.if_flags |= IFF_RUNNING;
- 	destart(unit);				/* queue output packets */
  	addr->pclow = PCSR0_INTE;		/* avoid interlock */
  	ds->ds_flags |= DSF_RUNNING;		/* need before de_setaddr */
--- 332,335 ----
  	ds->ds_if.if_flags |= IFF_RUNNING;
  	addr->pclow = PCSR0_INTE;		/* avoid interlock */
+ 	destart(unit);				/* queue output packets */
  	ds->ds_flags |= DSF_RUNNING;		/* need before de_setaddr */
***************
*** 741,742 ****
--- 775,779 ----
  		    ds->ds_flags & DSF_RUNNING) {
+ 			((struct dedevice *)
+ 			   (deinfo[ifp->if_unit]->ui_addr))->pclow = 0;
+ 			DELAY(100);
  			((struct dedevice *)

-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      Sat, 22-Aug-87 12:54:22 EDT
From:      robert@pvab.UUCP (Robert Claeson)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   NFS for PC's

We're about to incorporate most of our PC's into the Ethernet w/TCP-IP
we use for our UNIX machines. Since we use NFS on most computers, we think
it would be a good idea to use NFS on the PC's as well. Now there's PC/NFS
from Sun. Version 1.x is the one I've seen, but 2.x is released now. Rumours
has it that Pyramid also has a NFS implementation for PC's.

Which one should I use? The telnet in Sun's PC/NFS was almost useless. We
need support for national characters, ie we need to be able to remap the
keyboard in about the same way as SmarTerm 240. But maybe version 2.x is
better? Or maybe I should continue to use ST240 for terminal communication,
connected to a terminal server?

By the way, is it possible to use another telnet together with Sun's PC/NFS
and 3Com's EtherLink card? And is there only plain vt100 telnets for PC's?
I could have use for vt240 emulation.

Please respond me by e-mail, and I'll summarize the responses.
-- 
SNAIL:	Robert Claeson, PVAB, P.O. Box 4040, S-171 04 Solna, Sweden
UUCP:	{seismo,mcvax,munnari}!enea!pvab!robert
ARPA:	enea!pvab!robert@seismo.arpa

-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      Sat, 22-Aug-87 17:41:29 EDT
From:      mccall@iris.ucdavis.edu (Sam McCall)
To:        comp.protocols.tcp-ip
Subject:   in.named on SunOS3.4 and its friends

Has anyone had any success in getting things like telnet,
ftp, rlogin, and so forth to work with the nameserver under
SunOS 3.4?  I've tried taking 4.2BSD source and compiling
it on the suns with the resolver library, but it just doesn't
seem to work.

-sam

-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      Sun, 23-Aug-87 15:31:30 EDT
From:      percy@amdcad.AMD.COM (Percy Irani)
To:        comp.protocols.tcp-ip
Subject:   Sun routers...


We are seriously considering evaluation of Sun based IP routers
for our Ethernet. Does any one out (in the world) uses Sun routers
for connecting their Ethernet (TCP/IP)? [ I know Sun does!! ]

What about using them with DECNET sharing the same (leased phone) line?

Any other problems people have encountered using the Sun product 
(ala reliability, routing updates, size constraints etc.)

Does any one uses their software for network monitoring?

What does the rest of the world use for network monitoring *
  - for monitoring their TCP/IP based Ethernet (for the main backbone)
  - for monitoring lease line(s) for other internet connections 
    (lets assume all TCP/IP type connections).
  - Any public domain stuff?

  * monitoring = BIG WORD!! Like to know what other people do. There
    have been intresting articles in IEEE Network issues about them.
    Lets see whats being done in the world!

-- 
Ignorance is bliss but can be embarassing at times!

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      Mon, 24 Aug 87 08:36:27 -0400
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        amdcad!percy@ucbvax.berkeley.edu
Cc:        tcp-ip@sri-nic.ARPA
Subject:   network monitoring etc.

Percy,

    Yes, monitoring is a BIG WORD.  Network management (of which monitoring
is only a part) is even bigger.

    If you are interested in these problems, I suggest you join the
GWMON mailing list where most discussion of network management on
IP networks is held. (Regarding the name, it started as GateWay MONitoring,
and grew up).  Send requests to gwmon-request@sh.cs.net.

    You might also keep an eye out for next spring's issue of IEEE Network
which is devoted to Internetwork Management Protocols (and systems).

Craig
-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      Mon, 24-Aug-87 08:39:43 EDT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   network monitoring etc.


Percy,

    Yes, monitoring is a BIG WORD.  Network management (of which monitoring
is only a part) is even bigger.

    If you are interested in these problems, I suggest you join the
GWMON mailing list where most discussion of network management on
IP networks is held. (Regarding the name, it started as GateWay MONitoring,
and grew up).  Send requests to gwmon-request@sh.cs.net.

    You might also keep an eye out for next spring's issue of IEEE Network
which is devoted to Internetwork Management Protocols (and systems).

Craig

-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      Mon, 24-Aug-87 13:06:13 EDT
From:      kurt@hi.UUCP (Kurt Zeilenga)
To:        comp.protocols.tcp-ip
Subject:   Re: in.named on SunOS3.4 and its friends

In article <704@ucdavis.UUCP> mccall@iris.ucdavis.edu (Sam McCall) writes:
>Has anyone had any success in getting things like telnet,
>ftp, rlogin, and so forth to work with the nameserver under
>SunOS 3.4?  I've tried taking 4.2BSD source and compiling
>it on the suns with the resolver library, but it just doesn't
>seem to work.
>
>-sam

Assuming you got the named(8) running on your SUNs, and use YP,
just start up ypserv with a -i flag.  The YP server will then
use the named(8) to resolve any unknown request.  Your client
will not use named(8) directly, but via the YP server.

Good Luck.

-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      24 Aug 87 12:20:43 GMT
From:      mcvax!enea!tut!utacs!jaj@seismo.css.gov  (Jari J{ntti)
To:        tcp-ip@sri-nic.arpa
Subject:   NETBIOS over TCP/IP
Is there a free source for NETBIOS over TCP/IP -implementation? 

There are two vendors (of which I know) who offer commercial versions -- 
Ungermann-Bass and Excelan. Anybody know the origin of these two?

Jari Jantti
University of Tampere
Computing Center
FINLAND

JJANTTI@BITNET
-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      Mon, 24-Aug-87 18:15:07 EDT
From:      tower@bu-cs.BU.EDU (Leonard H. Tower Jr.)
To:        news.groups,comp.protocols.tcp-ip
Subject:   Re: Does comp.protocols.iso exist?


In article <1672@ho95e.ATT.COM> wcs@ho95e.UUCP (46133-Bill.Stewart,2G218,x0705,) writes:
 > In article <1510@hou2d.UUCP> n2dsy@hou2d.UUCP (J.BEATTIE) writes:
 > :I guess this is a relatively new newsgroup...my system 
 > :doesn't seem to have any items listed.
 > 
 > I never got a newgroup message, but I remember some discussion a couple
 > months ago.  Was the group ever approved?  Is it part of inet?
 > -- 
 > #				Thanks;
 > # Bill Stewart, AT&T Bell Labs 2G218, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs

comp.protocols.iso is an inet distribution newsgroup.  If all of
USENET wants it, just ask Eric Fair <usenet@ucbvax.berkeley.edu>.
Note that I am *NOT* conducting such a news group poll.  (Perhaps Bill
wants to?)

Followups directed to news.groups.  enjoy -len

PS: comp.protocols.iso is gated with the Internet mailing list (this
description is from ZELLICH's list-of-lists):

ISO@NRTC.NORTHROP.COM

   Discussion group focusing on the ISO protocol stack.  The list naturally 
   has some overlap with the ISODE list; contributors are urged to use the 
   appropriate list based on their topic of discussion.

   Archives are kept on the host NRTC-GREMLIN.NORTHROP.COM (128.99.0.17).  
   Use "anonymous" ftp to retrieve file "archive/iso.mbox" which represents 
   the current archives.

   All requests to be added to or deleted from this list, problems, 
   questions, etc., should be sent to ISO-Request@NRTC.NORTHROP.COM.

   Coordinator: Marshall T. Rose <MRose@NRTC-GREMLIN.NORTHROP.COM>
-- 
Len Tower, Distributed Systems Group, Boston University,
     111 Cummington Street, Boston, MA  02215, USA +1 (617) 353-2780
Home: 36 Porter Street, Somerville, MA  02143, USA +1 (617) 623-7739
UUCP: {}!harvard!bu-cs!tower		INTERNET:   tower@bu-cs.bu.edu

-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      25 Aug 87 10:22:34 GMT
From:      mcvax!cernvax!jmg@seismo.css.gov  (jmg)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: NETBIOS over TCP/IP
In article <497@utacs.UTA.FI> jaj@utacs.UUCP (Jari J{ntti) writes:
>Is there a free source for NETBIOS over TCP/IP -implementation? 
>There are two vendors (of which I know) who offer commercial versions -- 
>Ungermann-Bass and Excelan. Anybody know the origin of these two?

I don't know about U-B, but I am told that the Excelan product is not
yet conforming with RFC 1001/2.
Given the large number of mutually incompatible implementations of
NETBIOS already available, I hope that people wanting NETBIOS on TCP/IP
will wait for implementations matching these RFCs.
I certainly am going to wait.
-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      Tue, 25-Aug-87 15:19:42 EDT
From:      mckenzie@J.BBN.COM (Alex McKenzie)
To:        comp.protocols.tcp-ip
Subject:   "But my NCP costs $500 a day..."


I've been on vacation, or I would have provided the reference sooner.

The author was BBN employee Bob Bressler, not Mike.

The RFC number is 425.

  Regards,
  Alex
 

-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      Tue, 25 Aug 87 15:19:42 EDT
From:      Alex McKenzie <mckenzie@J.BBN.COM>
To:        Michael Padlipsky <PADLIPSKY@A.ISI.EDU>, pogran@J.BBN.COM
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   "But my NCP costs $500 a day..."

I've been on vacation, or I would have provided the reference sooner.

The author was BBN employee Bob Bressler, not Mike.

The RFC number is 425.

  Regards,
  Alex
 
-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      Tue, 25-Aug-87 16:44:27 EDT
From:      ecc@spice.cs.cmu.edu (Eric Cooper)
To:        comp.protocols.tcp-ip
Subject:   Are simultaneous TCP opens useful?

Can anyone defend the usefulness of allowing simultaneous active OPENs to
result in a single connection?  It seems to me that a pair of would-be
communicants cannot rely on this to succeed, since it would depend on the
relative time at which they give the OPEN command.

Suppose an implementation rejected incoming SYNs when in the SYN-SENT state,
instead of entering SYN-RECEIVED.  How could you ever observe that this
implementation is really nonconforming, and not just faster or slower?

Am I wrong? Does anyone have examples of applications that depend on this
feature?

					Eric Cooper (ecc@spice.cs.cmu.edu)
					Computer Science Department
					Carnegie Mellon University

-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      Tue, 25-Aug-87 19:04:10 EDT
From:      chris@GYRE.UMD.EDU (Chris Torek)
To:        comp.protocols.tcp-ip
Subject:   Re: ethernet interface perversity

(Apparently, someone wants a single Ethernet interface to respond to
ARP requests for several different Internet addresses.)  Jim O'Toole
did something like this under 4.2BSD, with an `IP magic' hook whereby
all IP packets for one IP address were forwarded to a user-level
program.  It takes about 15 minutes to figure out where and what to
write; we then had a user program that provided echo service a la
goonhilly-echo.arpa.

If all you want is for a 4.3 host to respond to multiple IP addresses,
this is even easier.  Configure some unused interface with the alternate
address:

	# ifconfig lo1 a.b.c.d		# or ifconfig sl1 a.b.c.d

Add it to your arp table:

	# arp -s a.b.c.d <your_ethernet_addr> pub

You should be set once the router picks up the address a.b.c.d from
interface sl0, or immediately if a.b.c.d is on the same `network'
as the 4.3 host as far as the sender is concerned.  I tested this,
and gyre (128.8.128.77) did respond to packets for 128.8.128.200.

-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      Tue, 25-Aug-87 22:50:42 EDT
From:      roy@phri.UUCP (Roy Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: ethernet interface perversity

In <862@mcgill-vision.UUCP> mouse@mcgill-vision.UUCP (der Mouse) writes:
# If this is so it is a software problem.  I can see no reason why UNIX (say)
# couldn't be set up to respond to ARP requests for more than one IP address
# per interface.

	The Kinetics KFPS Ethernet-to-AppleTalk bridge box (at least when
loaded with the Stanford KIP gateway code) is quite capable of responding to
multiple IP addresses using a single ethernet address.  If KIP can do it, I
don't see any reason why a UNIX kernel can't.
-- 
Roy Smith, {allegra,cmcl2,philabs}!phri!roy
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016

-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      Wed, 26-Aug-87 11:07:07 EDT
From:      jmr@philabs.Philips.Com (Joanne Mannarino)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   SUN 3.4 problems



In trying to upgrade our SUN 3/180 fileserver (named condor) to SUN UNIX
version 3.4 along with 11 diskless clients, I ran into some problems.  The
upgrade procedure on condor went fine.  I reconfigured the kernel for 3.4,
rebooted condor and still no problem.  Then I tried booting up all of the
diskless clients (one at a time) and then the headaches began.  

The booting process began with "requesting internet address" with the host
responding with the correct information (thus there is communication via our
Ethernet).  The problem began when the booting process got to the point for:

	starting rpc and net services: portmap router biod

The boot process then halts with the following error messages:

	server not responding
	RPC: program not registered
	mount retrying
		/usr
		/usr/condor

This will remain at this point until you either manually abort or power down
the unit.  At this point, any active workstation on the network (ie, SUNs
either connected to our other fileserver (which still runs 3.2) or
diskful SUNs sitting on the net)  displays a screenful of "ie0: no carrier"
and "Ethernet jammed" error messages.

I contacted SUN support immediately and after running tests to see if all of
the daemons that should be running were running, the conclusion was made by
SUN that the problem is somewhere within our Ethernet structure.  SUN said
that 3.4 includes major changes in the Ethernet drivers that don't correct
for possible problems in the network.  At this point SUN support referred me
to someone in their Data Communications support department.  After running
some net stats and sending them the data, I was told "your network looks ok".
BUT still we are having problems.

We've tried some different things to see if we could isolate the problem
(actually this was done before the fileserver upgrade, but we wrote it off as
being a network problem isolated to a particular laboratory).  We tried
running a diskful 3/160 as a server for a diskless 3/160 both running 3.4 and
we ran across the same problems.  It was suggested that we take both units
off of our main net and hook them up directly to their own mini net.  When
this was done, the problem went away, ie, the client came up running 3.4.

We have also tried changing the /etc/fstab on a client and "backgrounding"
the mount process.  This results in the client coming up in single user
mode.  Then after trying to manually mount a filesystem, I get the above
errors of "server not responding" and "mount retrying".

As an interim solution, we have kept the 3.4 enhancements (I didn't back out
of the upgrade) and are running a 3.2 kernel.  Everything seems fine, but this
still doesn't solve our problem.  

Some SUN reps claim that the problem is definitely with our network, others
say it's in the 3.4 software.  Anyone else experienced these symptoms when
upgrading to 3.4?  Any suggestions on what we should do now?

thanks in advance,
Joanne Mannarino


-- 
joanne mannarino				   seismo!philabs!jmr   
philips laboratories 				           or
(914)945-6008					 jmr@philabs.philips.com

-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      Wed, 26-Aug-87 14:08:16 EDT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   Suns, Symbolics, Celerities and Reverse ARP

Excuse if you already know about this problem.  But,
a recent release of software for the Celerity OS caused
a big headache here at LANL.  The symptom was Suns and
Symbolics machines could not boot or communicate because
they could not find out their internet addresses via RARP.
Or, rather, they found out a wrong address, namely 0.0.0.0.
This tidbit of information was provided by the Celerity RARP
handler.

I give credit to Celerity for finding out about the problem and
fixing it.  However, it took some sluthing with etherfind to figure
out who the culprit was on our part.  And, then finding the offending
piece of hardware, and then finding someone who would take responsibility
for it, and then calling up Celerity support.  Once we got that far
the fix was easy.  Run ifconfig with the -arp option, and wait for
the patch tapes in the mail.  The came the next day.

Phil Wood (cpw@lanl.gov)

-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      Wed, 26-Aug-87 14:20:28 EDT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   Broadcast Storms

This subject may have been discussed before.  But,
LANL was experiencing broadcast storms on an ethernet.
About 100 hosts on the ether would send a message back to
a lone Ultrix V2.0-1  (Microvax) system running the rwho daemon 
every few minutes.  It was broadcasting to 128.165.255.255 and all
these hosts were sending back some kind of arp to find out who the
guy was so they could probably send him some kind of response
(Connection refused?).

Anyhow, as in the problem with reverse arp responses of zero (a previous
missive) I spent some time tracking down the culprit.  Once I found
him, the fix was to terminate the rwho daemon (and remove entry from
the startup file).

Network management in a heterogeneous environment, anyone?

Phil Wood  (cpw@lanl.gov

-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      Wed, 26-Aug-87 17:17:00 EDT
From:      DCP@QUABBIN.SCRC.Symbolics.COM (David C. Plummer)
To:        comp.protocols.tcp-ip
Subject:   Suns, Symbolics, Celerities and Reverse ARP


    Date: Wed, 26 Aug 87 12:08:16 MDT
    From: cpw%sneezy@LANL.GOV (C. Philip Wood)

    Excuse if you already know about this problem.  But,
    a recent release of software for the Celerity OS caused
    a big headache here at LANL.  The symptom was Suns and
    Symbolics machines could not boot or communicate because
    they could not find out their internet addresses via RARP.

Point of information: The released Symbolics system does not use RARP at
all.  (It normally gets it's Internet address from the namespace object
for the host, which it finds from the chaos address, which is specified
in the boot file.)  I suspect the Symbolics systems couldn't boot for
some other reason, such as failing to get valid ARP responses from the
servers.

    Or, rather, they found out a wrong address, namely 0.0.0.0.
    This tidbit of information was provided by the Celerity RARP
    handler.

    I give credit to Celerity for finding out about the problem and
    fixing it.  However, it took some sluthing with etherfind to figure
    out who the culprit was on our part.  And, then finding the offending
    piece of hardware, and then finding someone who would take responsibility
    for it, and then calling up Celerity support.  Once we got that far
    the fix was easy.  Run ifconfig with the -arp option, and wait for
    the patch tapes in the mail.  The came the next day.

    Phil Wood (cpw@lanl.gov)

-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      Wed, 26-Aug-87 22:41:05 EDT
From:      hedrick@topaz.rutgers.EDU (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   Re: Sun routers...

Sun's Ethernet hardware is quite good.  There's no reason in principle
why a Sun couldn't be a very good IP gateway.  However there are some
practical things that make this less than optimal.

The versions of SunOS we have seen are based on 4.2.  In order to
avoid stability problems, gateways have to have much more careful
validation of packets than 4.2 does.  E.g. they have to recognize
every possible broadcast address format, and also refuse to forward
packets for invalid addresses (as opposed for example to sending ARP
requests for Martian addresses).  This is somewhat better in 4.3 than
4.2, but even 4.3 does not recognize all possible old and new style
broadcast addresses, nor as far as I can tell does it have a complete
Martian filter.  

We expect our gateways to do proxy ARP (for hosts that can't handle
subnets, and a few that can't even deal with routing).  This is not
present in 4.2, and as far as I know is not in 4.3 either.

We expect our gateways to be up all the time.  Normal timesharing
systems are taken down periodically for PM, software installation,
etc.  Our gateways (cisco) download software from a server.  Going to
a new release requires downtime of about 30 seconds.  Suns typically
require a good deal longer than this to bring up new releases.  Some
sites also take them down for backups, and now and then they crash
(though in honesty I'd have to say that our Suns are very stable).
I believe that the operational requirements of a gateway are at least
slightly inconsistent with those of a host.

If you are building a large or complex network, the vendors whose
business is making routers are likely to have better routing
technology than routed, to support a wider variety of media, (As an
example, we tried to interface our Sun to the Arpanet and found that
although 1822 interfaces existed, we couldn't find anyone who knew how
to get them.), and to be more aggressive about supporting new network
monitoring standards.

In the long run, there are going to be performance advantages.  At
the moment, Suns probably perform at least as well at connecting
Ethernets as the typical dedicated routers.

We have used Suns as gateways between major Ethernets and restricted
Ethernets containing only diskless Suns.  They perform very well at
this.  I'm sure we will continue to use Suns as gateways to one extent
or another.  However for large networks, those with complex
topologies, and those serving machines from many vendors (and with
buggy TCP implementations), I would recommend using a gateway from a
vendor that specializes in such things.

-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      Wed, 26-Aug-87 22:45:11 EDT
From:      sy.Ken@CU20B.COLUMBIA.EDU (Ken Rossman)
To:        comp.protocols.tcp-ip
Subject:   Re: Broadcast Storms

Please forgive my ignorance in these matters (I'm still pretty new to a lot
of this), but shouldn't the decision as to whether to address broadcasts
using an IP address like X.Y.255.255, as opposed to X.Y.0.0 be done by the
kernal and not some daemon (rwho)?  Again, I'm not clear on this, as I only
got part of an explanation of this awhile back, but isn't the X.Y.255.255
format an old style (obsolete?) broadcast format, and X.Y.0.0 the current
way to broadcast?  Or are they both valid but used differently?  /Ken
-------

-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      Wed, 26-Aug-87 23:39:09 EDT
From:      hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   Re: Broadcast Storms

Maybe we need to keep a collection of known causes of broadcast
storms, and send them to the list once a month.  Almost certainly what
is going on is that most of your machines are configured to expect
128.165.0.0 as a broadcast address (this would be the default for
4.2), and they have ipforwarding turned on.  Thus the 128.165.255.255
looks to them like an attempt to send a message to a host with this
address.  Since ipforwarding is on, they try to be nice and forward
the message.  Thus they ARP 128.165.255.255.  The real fix is to make
sure that every one of your machines has the stormproofing code in it
that I have posted several times.  (In brief,
 1) in ipintr, make sure that all possible broadcast addresses
	are recognized.
 2) in udp_input, fix the code that sends unreachables so that its
	test for broadcast addresses includes all possible addresses
 3) in ip_forward, when ipforwarding is off, discard the packet
	in all cases with no error message.  [4.3 has fixed this
	already, but not 4.2.]  Leave ipforwarding off except on
	actual gateways, and if you use Unix hosts as gateways,
	make sure that proper Martian filtering, etc., is done.
) However it is often impossible to modify the code on every one of
your machines.  In that case, a reasonable approach is to make sure
that every one of your machines agrees about the broadcast address.
4.2 systems will use net.0.0.  4.3 systems and Ultrix will default to
net.255.255, but allow an option -broadcast in ifconfig to set a
different address.  I suggest that you set your Ultrix machine to use
128.165.0.0 as its broadcast address.  This is a violation of the
standards, but it's better to have everyone on your network agree than
to have one lone machine be right.

I do not recommend rwho on big networks in any case.  But it should
not cause storms.  There are enough other uses of broadcasts that you
should make sure they are safe.  I would set the broadcast address to
128.165.0.0 and turn rwho back on.  Now use Etherfind on a Sun (or
netwatch on a PC, but if you have 100 machines on an Ethernet, it is
worth buying a Sun just to run Etherfind) and verify that you are not
seeing any ARP's for 128.165.0.0, nor any ICMP unreachables.  If you
see either of these, start tracking down the hosts one by one and
fixing them.

If you are using level 2 Bridges, you are asking for this sort of
thing.  In that case, you should do this sort of test periodically to
make sure no new problems have crept into your network.

If there are any hosts that insist on sending garbage in response to
broadcasts, isolate them from the rest of your network with a gateway.

-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27-Aug-87 00:42:00 EDT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Are simultaneous TCP opens useful?


Distributed systems with symmetric processes that automatically seek
to link to each other (no master/slave relationship) would use the
simul-OPEN style. It was designed into TCP for that purpose; I do not
know, however, whether any actual applications have made use of this
feature.

Vint

-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      27 Aug 87 09:07:00 PST
From:      <art@acc.arpa>
To:        "cerf" <cerf@a.isi.edu>
Cc:        tcp-ip@sri-nic.arpa
Subject:   Symetric TCP opens

>Distributed systems with symmetric processes that automatically seek
>to link to each other (no master/slave relationship) would use the
>simul-OPEN style. It was designed into TCP for that purpose; I do not
>know, however, whether any actual applications have made use of this
>feature.
>
>Vint

Vint,

We have developed systems that live on TCP/IP networks and communicate
with each other in a symetric peer fashion.  When one of these boxes
starts up, it attempts to open TCP connections with its peers.  The
connection attempt starts actively by sending SYNs.  If the remote
end doesn't respond, the TCP port goes into LISTEN, assuming that the
other end will eventually initiate the connection.

						Art Berggreen
						art@acc.arpa

------
-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27-Aug-87 05:22:21 EDT
From:      hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   Re: Broadcast Storms

X.Y.255.255 is the new form.  X.Y.0.0 is the old form.  Unfortunately
it is easier to convince new software to use the old than old software
to use the new.  So until everybody updates, it may be easiest to
stick with the old format.  The decision is in fact made in the
kernel, not rwho.  You use ifconfig to choose the broadcast address.
Ifconfig is a program that primarily does system calls to set up
various options in the kernel.

-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 Aug 87 09:43:38 -0400
From:      Robert Hinden <hinden@PARK-STREET.BBN.COM>
To:        CERF@A.ISI.EDU
Cc:        ecc@SPICE.CS.CMU.EDU, tcp-ip@SRI-NIC.ARPA, hinden@PARK-STREET.BBN.COM
Subject:   Re: Are simultaneous TCP opens useful?
Vint,

The only example I can think of is the Automated Network Management
(ANM) system.  It uses TCP as the base for its interprocess
communication which allows it processes to be easily distributed.

Bob
-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27-Aug-87 11:04:26 EDT
From:      hinden@PARK-STREET.BBN.COM.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: Are simultaneous TCP opens useful?

Vint,

The only example I can think of is the Automated Network Management
(ANM) system.  It uses TCP as the base for its interprocess
communication which allows it processes to be easily distributed.

Bob

-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27-Aug-87 11:24:52 EDT
From:      sy.Ken@CU20B.COLUMBIA.EDU (Ken Rossman)
To:        comp.protocols.tcp-ip
Subject:   Re: Broadcast Storms


  X.Y.255.255 is the new form.  X.Y.0.0 is the old form.  Unfortunately it
  is easier to convince new software to use the old than old software to
  use the new.  So until everybody updates, it may be easiest to stick with
  the old format.  The decision is in fact made in the kernel, not rwho.
  You use ifconfig to choose the broadcast address.  Ifconfig is a program
  that primarily does system calls to set up various options in the kernel.

I guess the reason I asked about this was because we've seen those
broadcast storms here a number of times, and so apparently have other
sites, yet in answer to this problem, folks keep saying the "fix" is to
kill the rwho daemon, as though rwho was directly responsible for net
storms.  Rwho is doing its job properly -- it's the kernal that's goofing
up.  Rwho ain't the only thing around that's gonna cause ARP broadcast
anyway, is it?  /Ken
-------

-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27-Aug-87 12:02:19 EDT
From:      sra@mitre-bedford.ARPA.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: NETBIOS over TCP/IP

I am under the impression that the new Bridge products implement
RFCs 1001 and 1002.  Of course they do not interoperate with other
netbios implementations yet as they are the first to announce it.

Stan Ames

-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27-Aug-87 13:07:00 EDT
From:      art@ACC.ARPA
To:        comp.protocols.tcp-ip
Subject:   Symetric TCP opens


>Distributed systems with symmetric processes that automatically seek
>to link to each other (no master/slave relationship) would use the
>simul-OPEN style. It was designed into TCP for that purpose; I do not
>know, however, whether any actual applications have made use of this
>feature.
>
>Vint

Vint,

We have developed systems that live on TCP/IP networks and communicate
with each other in a symetric peer fashion.  When one of these boxes
starts up, it attempts to open TCP connections with its peers.  The
connection attempt starts actively by sending SYNs.  If the remote
end doesn't respond, the TCP port goes into LISTEN, assuming that the
other end will eventually initiate the connection.

						Art Berggreen
						art@acc.arpa

------

-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27-Aug-87 14:49:22 EDT
From:      earle@jplopto.uucp (Greg Earle)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: SUN 3.4 problems

Joanne,
	Are you running YP?  Your boots are dying when it tries to do NFS
mounts; in order to do this there has to be an entry for the rpc.mountd
daemon in /etc/servers, so the program can be registered.  Trouble is,
when you install diskless clients, either /etc/servers or /etc/services
(or both) *do not get installed* on diskless clients.  If it is /etc/servers
and (I think) you do not run Yellow Pages, then the portmapper will not
be able to get the entry for the server, and it will emit the messages
you describe.
	I suggest you halt all your diskless clients, retry the 3.4 kernel on
`condor', then successively mount /dev/ndl[0-9?] onto /mnt, and do a
cp /etc/servers /mnt/etc/servers (and do /etc/services just to make sure).
Then unmount /mnt.  After you're all done, reboot the server with the 3.4
kernel, then try the client reboots again.  See what happens.

Just a thought,

	- Greg

	Greg Earle		earle@jplopto.JPL.NASA.GOV
	Sun Consulting		earle%jplopto@jpl-elroy.ARPA	[aka:]
	(Freelance -		earle%jplopto@elroy.JPL.NASA.GOV
	    write me)		...!cit-vax!elroy!smeagol!jplopto!earle

-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27-Aug-87 15:21:58 EDT
From:      hedrick@topaz.rutgers.edu (Charles Hedrick)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: SUN 3.4 problems

I claim no expertise in SunOS 3.4.  We are using 3.2 with
locally-added networking enhancements that put it somewhere between
3.3 and 3.4 in terms of functionality.  However from your results, it
sounds like Sun's diagnosis is right.  The fact that your hosts all
get "ie0: no carrier" or "Ethernet jammed" strongly indicates a
broadcast storm.  The fact that things work when you use a separate
Ethernet suggests that there is no error in your software or setup.
However it's not quite right to say that the problem is with your
"network".  The problem is not with the network itself, but with the
hosts on that network.  If all of the hosts on it are Suns, then Sun
can't entirely avoid blame.  3.4 is based on 4.3BSD's version of IP.
3.2 is based on 4.2BSD's version of IP.  Between 4.2 and 4.3, the
broadcast address was changed.  (The people who changed the standard
should be shot.  The amount of damage done to networks and the
reputation of IP due to inconsistent broadcast addresses is enormous.
By the way, this is not Berkeley's fault.  The standard actually
changed.)  Unfortunately, there are various bugs in 4.2 (and
presumably Sun 3.2), such that any disagreement over the broadcast
address can cause such a flurry of ICMP unreachables and ARP's that
the network becomes unusable.  The solution is going to depend upon
the particular set of machines on your network.  You have two choices:
find some broadcast address on which everyone can agree, or split the
network.  4.3-based systems allow you to set the broadcast address.
So do some 4.2-based systems that contain "4.3 enhancements".  This
includes Ultrix and Pyramid.  Unmodified 4.2 systems use net.0 as the
broadcast address.  E.g.  if your network number is 128.6, your
broadcast address is 128.6.0.0.  The new standard allows either
128.6.255.255 or 255.255.255.255.  If you are using subnets, things
get more complex.  4.2 didn't support subnets, but if you patched your
4.2 to do so, you will probably have ended up with a broadcast address
of net.subnet.0.  E.g. for us a typical one would be 128.6.4.0.  The
new standard, and 4.3, say that the correct broadcast address for a
subnetted network is 128.6.4.255.

One approach would be to tell your 4.3-based systems (i.e. your 
Sun 3.4 systems) to use the old broadcast address.  There should be
an option to ifconfig to do this.  What bothers me is that this
option may not take effect during the early stages of booting.
However the simplest thing to try would be to change the ifconfig
commands, normally present in /etc/rc or /etc/rc.boot to contain
the appropriate option.  Assuming you don't use subnets, this would
be something like
  ifconfig ie0 `/bin/hostname` up -trailers broadcast 128.6.0.0
Everything up to "broadcast" should be whatever your ifconfig command
is now.  It may be that the option is -broadcast.  You should use your
own net number in place of 128.6.0.0.  You must make this change to
/etc/rc.boot for every individual client partition.  This means you'll
have to bring up the clients one by one single-user or just mount the
partitions on the server, using /dev/ndlx (making sure that the
clients are not running at the time).  You might try this for a few
clients to see whether it fixes your problem, before doing it on
all of them.

In retrospect, Sun would probably have been better off distributing
3.4 with the old broadcast address as a default.  Once everyone had
upgraded to 3.4, the next release could safely move to the new
address, since 3.4 should (if it is properly implemented) accept
either.  At the very least the setup program should provide this as an
option.  (Of course I haven't seen 3.4 yet -- maybe it does.)

Other approaches to this problem are to fix all your existing systems
to accept the new address (which may be the best solution if you
have source to them -- we can give you the changes), or to put a
gateway between your 3.4 systems and everything else.  If you don't
have any other kind of gateway, you could add a second Ethernet board
to one of your servers and use it as a gateway.

Finally, if all of your systems are Suns, the simplest thing to do is
simply to upgrade them all at once.  Bring them all down, and then
bring them up one by one on 3.4.

-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27-Aug-87 17:48:26 EDT
From:      andre@nrc-ut.UUCP (Andre' Hut)
To:        comp.protocols.tcp-ip
Subject:   Re: Are simultaneous TCP opens useful?

In article <1261@spice.cs.cmu.edu> ecc@spice.cs.cmu.edu (Eric Cooper) writes:
>Can anyone defend the usefulness of allowing simultaneous active OPENs to
>result in a single connection?  It seems to me that a pair of would-be
>communicants cannot rely on this to succeed, since it would depend on the
>relative time at which they give the OPEN command.
>
>Suppose an implementation rejected incoming SYNs when in the SYN-SENT state,
>instead of entering SYN-RECEIVED.  How could you ever observe that this
>implementation is really nonconforming, and not just faster or slower?
>
>Am I wrong? Does anyone have examples of applications that depend on this
>feature?

yeah.. A pipe.  A TCP connection can be used as a pipe if it connects to
itself.  This sounds wierd, but it works, and its a guaranteed simultaneous
open.
-- 
-----------------------------------------------------------------------------
                sdcsvax-\         ihnp4-\
                         \               \
Andre' Hut              sdcrdcf!psivax!nrcvax!nrc-ut!andre
                         /              /        /
                hplabs--/ ucbvax!calma-/        /
				utah-gr!uplherc/
Network Research Corporation
923 Executive Park Dr. Suite C
Salt Lake City, Utah 84117
-----------------------------------------------------------------------------

-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27-Aug-87 18:07:12 EDT
From:      melohn@SUN.COM.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: Sun routers...

>The versions of SunOS we have seen are based on 4.2.  In order to
>avoid stability problems, gateways have to have much more careful
>validation of packets than 4.2 does.  E.g. they have to recognize
>every possible broadcast address format, and also refuse to forward
>packets for invalid addresses (as opposed for example to sending ARP
>requests for Martian addresses).  This is somewhat better in 4.3 than
>4.2, but even 4.3 does not recognize all possible old and new style
>broadcast addresses, nor as far as I can tell does it have a complete
>Martian filter.  

We have gradually introduced many 4.3 networking features into various
release of SunOS, beginning with SunOS 3.3. We plan to have all of
4.3 features in the next major release of SunOS. 

>
>We expect our gateways to do proxy ARP (for hosts that can't handle
>subnets, and a few that can't even deal with routing).  This is not
>present in 4.2, and as far as I know is not in 4.3 either.
>

Proxy ARP exists for Sun machines. If it is generally felt that
this is a hinderance to using Suns as internet gateways, we will look
into making it a supported part of the product.

>We expect our gateways to be up all the time.  Normal timesharing
>systems are taken down periodically for PM, software installation,
>etc.  Our gateways (cisco) download software from a server.  Going to
>a new release requires downtime of about 30 seconds.  Suns typically
>require a good deal longer than this to bring up new releases.  Some
>sites also take them down for backups, and now and then they crash
>(though in honesty I'd have to say that our Suns are very stable).
>I believe that the operational requirements of a gateway are at least
>slightly inconsistent with those of a host.

This is historically a reasonable arguement, especially when dealing
with large host systems that support timesharing or other loads.
Within our own internal network we have many dedicated gateway
machines with no local file system to backup whose uptime is regularly
measured in weeks. Our network is built mostly out of file server
machines with two ethernet interfaces; these are maintained by a
central support staff, and support both diskless clients and
internetworking connectivity. Having several gateways between each
network distributes the load and increases the redundancy if any
particular node fails.  A diskless Sun running as a dedicated network
server offers much the same network-loadable gateway capability as a
cisco box at approximetly the same cost, albeit both the client and
its server must be reliable. 

>
>If you are building a large or complex network, the vendors whose
>business is making routers are likely to have better routing
>technology than routed, to support a wider variety of media, (As an
>example, we tried to interface our Sun to the Arpanet and found that
>although 1822 interfaces existed, we couldn't find anyone who knew how
>to get them.), and to be more aggressive about supporting new network
>monitoring standards.

Here, I take strong exception to your statements! Pardon the
commercial, but I don't know of any gateway box vendor who supports
the range of media AND protocols that Sun currently supports. We run
IP over Ethernet, Token bus, and load-shared sync connections; we
offer gateways to DECnet, OSI, SNA, etc. We have had an DDN gateway
product for almost a year, supporting both 1822 and X.25.  We are
actively involved in both Internet and OSI protocol committees, and as
standards emerge that replace routed, EGP, and friends, we will have
products that implement those standards.

>
>In the long run, there are going to be performance advantages.  At
>the moment, Suns probably perform at least as well at connecting
>Ethernets as the typical dedicated routers.
>

Sun continues to be very agressive in delivering multiple MIPS at the
lowest cost per MIP in the business. The technology that brings forth
low cost high powered workstations can also be used just as
effectively for high speed internet gateways.

-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27-Aug-87 19:16:46 EDT
From:      melohn@SUN.COM (Bill Melohn)
To:        comp.protocols.tcp-ip
Subject:   Re: Sun routers...

>We expect our gateways to be up all the time.  Normal timesharing
>systems are taken down periodically for PM, software installation,
>etc.  Our gateways (cisco) download software from a server.  Going to
>a new release requires downtime of about 30 seconds.  Suns typically
>require a good deal longer than this to bring up new releases.  Some
>sites also take them down for backups, and now and then they crash
>(though in honesty I'd have to say that our Suns are very stable).
>I believe that the operational requirements of a gateway are at least
>slightly inconsistent with those of a host.

This is historically a reasonable arguement, especially when dealing
with large host systems that support timesharing or other loads.
Within our own internal network we have many dedicated gateway
machines with no local file system to backup whose uptime is regularly
measured in weeks. Our network is built mostly out of file server
machines with two ethernet interfaces; these are maintained by a
central support staff, and support both diskless clients and
internetworking connectivity. Having several gateways between each
network distributes the load and increases the redundancy if any
particular node fails.  A diskless Sun running as a dedicated network
server offers much the same network-loadable gateway capability as a
cisco box at approximetly the same cost, albeit both the client and
its server must be reliable. 

>
>If you are building a large or complex network, the vendors whose
>business is making routers are likely to have better routing
>technology than routed, to support a wider variety of media, (As an
>example, we tried to interface our Sun to the Arpanet and found that
>although 1822 interfaces existed, we couldn't find anyone who knew how
>to get them.), and to be more aggressive about supporting new network
>monitoring standards.

Here, I take strong exception to your statements! Pardon the
commercial, but I don't know of any gateway box vendor who supports
the range of media AND protocols that Sun currently supports. We run
IP over Ethernet, Token bus, and load-shared sync connections; we
offer gateways to DECnet, OSI, SNA, etc. We have had an DDN gateway
product for almost a year, supporting both 1822 and X.25.  We are
actively involved in both Internet and OSI protocol committees, and as
standards emerge that replace routed, EGP, and friends, we will have
products that implement those standards.

>
>In the long run, there are going to be performance advantages.  At
>the moment, Suns probably perform at least as well at connecting
>Ethernets as the typical dedicated routers.
>

Sun continues to be very agressive in delivering multiple MIPS at the
lowest cost per MIP in the business. The technology that brings forth
low cost high powered workstations can also be used just as
effectively for high speed internet gateways.

-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27-Aug-87 23:38:02 EDT
From:      Mills@UDEL.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re:  Are simultaneous TCP opens useful?

Vint,

The vintage Internet Message Protocol (RFC-759) uses, at least in
some implementations, port 45 for both source and destination. The
result is that it is readily possible that simultaneous connection
attempts can result in a single synchronized connection. This was considered
a feature.

Dave

-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      Fri, 28-Aug-87 00:54:01 EDT
From:      david@elroy.Jpl.Nasa.Gov (David Robinson)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: SUN 3.4 problems


It has been noted before by someone that SunOS 3.4 does
not check to see if the value of the ICMP mask
request is valid.  Supposedly Wollengong Win 3.0 for
VMS returns back a subnet address of 0x0000FFFF which then
causes the Suns to go into a broadcast storm.  You then must
disconnect the VMS Vaxen and reboot all Suns.

-- 
	David Robinson		elroy!david@csvax.caltech.edu     ARPA
				david@elroy.jpl.nasa.gov (new)
				seismo!cit-vax!elroy!david UUCP
Disclaimer: No one listens to me anyway!

-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      Fri, 28-Aug-87 01:06:05 EDT
From:      david@elroy.Jpl.Nasa.Gov (David Robinson)
To:        comp.protocols.tcp-ip
Subject:   Re: Broadcast Storms

In article <8708270922.AA06419@topaz.rutgers.edu>, hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick) writes:
> X.Y.255.255 is the new form.  X.Y.0.0 is the old form.  Unfortunately
> it is easier to convince new software to use the old than old software
> to use the new.  So until everybody updates, it may be easiest to
> stick with the old format. 
Agreed, until you have a net where 100% can understand new style
broadcasts you should leave it as the old style.

> The decision is in fact made in the
> kernel, not rwho.  You use ifconfig to choose the broadcast address.
> Ifconfig is a program that primarily does system calls to set up
> various options in the kernel.

WRONG!  All of the programs in the 4.3bsd distribution that broadcast
make an ioctl call to get the kernel broadcast address which is
set via /etc/ifconfig.  SunOS 3.[3-4] suffers from the fact that
none of their programs that broadcast check the kernel broadcast
address and insist on using old style 4.2bsd broadcasts.



-- 
	David Robinson		elroy!david@csvax.caltech.edu     ARPA
				david@elroy.jpl.nasa.gov (new)
				seismo!cit-vax!elroy!david UUCP
Disclaimer: No one listens to me anyway!

-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 1987 12:47-PDT
From:      Mike StJohns <StJohns@SRI-NIC.ARPA>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Where can I find SLIP server for 4.2/3?
The  subject  says  it all.  Is there a public domain SLIP server
for a 4.2 based system available anywhere?  I've got a  bunch  of
IBM  PCs  I  want  to  run  over  something called a CO-LAN (wire
replacement system).  Mike
-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 87 07:08:49 GMT
From:      bpa!sjuvax!bbanerje@burdvax.prc.unisys.com  (B. Banerjee)
To:        tcp-ip@sri-nic.arpa
Subject:   How do I turn on RARP handling.
Hi,

I've  been   adding  a  bunch   of  PC's  with   various  network
boards/software to our little local net. I'd like to turn on RARP
(if possible)  on one of our  Unix systems. Most of  the users of
these PC's will be regular users. I would like to be able to give
them  a diskette  and  have them  insert and  run  it (Just  like
wordstar or something).

At any rate, I figured that  I could centralise the management by
letting them get their internet addresses via RARP. Unfortunately
I can't seem  to find out how  to turn it on with  our Vax. We're
running BSD  4.3. In case it  makes a difference, we  also have a
Microvax running Ultrix  2.0 and a Sun 2 running  3.4 on the same
network (Well,  actually the  Sun is  waiting for  the Ethernet-2
board). So, turning it on for one of these is also a possibility.

I grepped through the sources,  the documentation, and the manual
pages.  The only  match I  found was  in trek(6),  which gave  me
``w\fRarp  drive''. Though  it  sounds like  fun,  I don't  think
that's what I want :-(

Thanks (in anticipation),

				Binayak Banerjee
		{allegra | astrovax | bpa | burdvax}!sjuvax!bbanerje
			bbanerje%sjuvax.sju.edu@relay.cs.net
-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      Fri, 28-Aug-87 11:27:31 EDT
From:      ron@TOPAZ.RUTGERS.EDU (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re:  Broadcast Storms

More than likely they were arping  because they were attempting
to forward the datagram.

-Ron

-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      Fri, 28-Aug-87 12:33:45 EDT
From:      geof@imagen.UUCP (Geof Cooper)
To:        comp.protocols.tcp-ip
Subject:   Re: Re: Sun routers...

Interdispersed with much stuff with which I have no problem, you write:

 >                         ..... Having several gateways between each
 > network distributes the load and increases the redundancy if any
 > particular node fails.....  

"Distributes the load"?  I know of no network standard that allows this
to happen.  It is a major failing of the Internet protocol suite that
redundant gateways improve the reliability of an internet, but don't
increase its capacity to handle traffic (not that other protocols such
as XNS or DECNET been more successful).

If you have accomplished this, can you let us all know how?

- Geof

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      Fri, 28-Aug-87 13:08:08 EDT
From:      SATZ@MATHOM.CISCO.COM (Greg Satz)
To:        comp.protocols.tcp-ip
Subject:   Re: Sun routers...

It seems the internet gateway market is heating (or flaming) up. Instead
of vendors showing off their features in a public forum like TCP-IP,
maybe an interested member of the community would be willing to chase
down the features and capabilities of the latest off-the-shelf products
from the gateway vendors and make them available. This may be more
beneficial to more people.

As an aside, it seems that the europeans have a show called "CeBIT
MultiNET, the new dimension in communication" where many vendors with
TCP-IP products get together and do what they do best -- interoperate.
Seems like a good idea to me.
-------

-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      Fri, 28-Aug-87 13:13:16 EDT
From:      randy@bcsaic.UUCP (Randy Groves)
To:        comp.protocols.tcp-ip
Subject:   Pointer to latest SLIP

Could somebody give me a pointer to the latest implementation of SLIP
that exists??  If there's a version for Ultrix 1.2 or 2.0 that would be
the best, but anything that will work with the fairly current 4.2/3 
would be fine.

Email only please.  If I get a lot of responses, I'll summarize to this
group.

Thanks much.

-- 
-randy groves - Boeing Advanced Technology Center
UUCP:	..!uw-beaver!uw-june!bcsaic!randy     USNail: Boeing Computer Services
CSNET:	randy@boeing.com		              PO Box 24346 M/S 7L-68
VOICE:	(206)865-3424				      Seattle, WA   98124

-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 87 17:51:00 PDT
From:      "Jerry Scott" <jerry@twg.arpa>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Cc:        <jmr@lll-lcc.arpa>
Subject:   RE: SUN 3.4 problems
I think your problem has to do with ICMP Mask Requests from your Sun 3.4.
In release 3.3 and 3.4, diskless suns starting asking the net for
network masks.  This is all well and good, but when you have hosts
on your net giving you the wrong answer...

There is a bug in 4.3BSD and (sorry to say) Wollongong's VAX/VMS release
3.0 networks that causes them to respond to ICMP Mask Requests with
the wrong answer (actually the answer is right but is not byte swapped
into network order before sent out onto the cable).

Anyway the fix for 4.3BSD is to modify the file netinet/ip_icmp.c
in routine icmp_input as follows:

CHANGE:
	case ICMP_MASKREQ:
		if (icmplen < ICMP_MASKLEN || (ia = ifptoia(ifp)) == 0)
			break;
		icp->icmp_type = ICMP_MASKREPLY;
		icp->icmp_mask = ia->ia_netmask;

TO:
	case ICMP_MASKREQ:
		if (icmplen < ICMP_MASKLEN || (ia = ifptoia(ifp)) == 0)
			break;
		icp->icmp_type = ICMP_MASKREPLY;
		icp->icmp_mask = htonl(ia->ia_netmask);

To fix your Wollongong host, use anonymous ftp from another Wollongong
VMS machine, set ftp transfer type to BINARY and transfer structure to
RECORD, and get file ip_icmp.o.

By the way, there is another work-around if you are familiar with
dealing with disk partitions for client hosts on your sun servers.
Get into the root partitions for the diskless hosts and modify
the /etc/rc.boot files to issue the "ifconfig" command properly,
for example:
	ifconfig ie0 192.5.36.4 ...  netmask 255.255.255.0

Hope this helps, I think this was discussed earlier but your message
shows the symptom from the sun's point of view.  I hope Sun support
is taking note of this.

Jerry Scott

------
-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      Fri, 28-Aug-87 15:47:00 EDT
From:      StJohns@SRI-NIC.ARPA (Mike StJohns)
To:        comp.protocols.tcp-ip
Subject:   Where can I find SLIP server for 4.2/3?

The  subject  says  it all.  Is there a public domain SLIP server
for a 4.2 based system available anywhere?  I've got a  bunch  of
IBM  PCs  I  want  to  run  over  something called a CO-LAN (wire
replacement system).  Mike

-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      Fri, 28-Aug-87 18:35:00 EDT
From:      LYNCH@A.ISI.EDU (Dan Lynch)
To:        comp.protocols.tcp-ip
Subject:   Re: Sun routers...


Greg,  The "good idea" you refer to (Europeans putting on a TCP/IP
interoperability show) is something that we are working on here in
the USA.  We are working with many dozens of vendors to construct
a permanent facility for demonstrating TCP/IP interoperability to 
the public.  It will be open daily and we have scheduled the opening
for January, 1988.  It will live at Techmart, next to the Santa Clara
Convention Center and should be an impressive activity.  It is called
the Connectivity Showcase and will be paid for by the vendors who
want to clearly demonstrate that their products run harmoniously
together.  Users will be able to come in and run demos between any
machines they wish to find out about.  If it really catches on
we wil be opening up additional sites in other US locations.

Dan
-------

-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 1987 18:35:00 EDT
From:      Dan Lynch <LYNCH@A.ISI.EDU>
To:        Greg Satz <SATZ@MATHOM.CISCO.COM>
Cc:        tcp-ip@SRI-NIC.ARPA, LYNCH@A.ISI.EDU
Subject:   Re: Sun routers...

Greg,  The "good idea" you refer to (Europeans putting on a TCP/IP
interoperability show) is something that we are working on here in
the USA.  We are working with many dozens of vendors to construct
a permanent facility for demonstrating TCP/IP interoperability to 
the public.  It will be open daily and we have scheduled the opening
for January, 1988.  It will live at Techmart, next to the Santa Clara
Convention Center and should be an impressive activity.  It is called
the Connectivity Showcase and will be paid for by the vendors who
want to clearly demonstrate that their products run harmoniously
together.  Users will be able to come in and run demos between any
machines they wish to find out about.  If it really catches on
we wil be opening up additional sites in other US locations.

Dan
-------
-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      Fri, 28-Aug-87 20:51:00 EDT
From:      jerry@TWG.ARPA ("Jerry Scott")
To:        comp.protocols.tcp-ip
Subject:   RE: SUN 3.4 problems

I think your problem has to do with ICMP Mask Requests from your Sun 3.4.
In release 3.3 and 3.4, diskless suns starting asking the net for
network masks.  This is all well and good, but when you have hosts
on your net giving you the wrong answer...

There is a bug in 4.3BSD and (sorry to say) Wollongong's VAX/VMS release
3.0 networks that causes them to respond to ICMP Mask Requests with
the wrong answer (actually the answer is right but is not byte swapped
into network order before sent out onto the cable).

Anyway the fix for 4.3BSD is to modify the file netinet/ip_icmp.c
in routine icmp_input as follows:

CHANGE:
	case ICMP_MASKREQ:
		if (icmplen < ICMP_MASKLEN || (ia = ifptoia(ifp)) == 0)
			break;
		icp->icmp_type = ICMP_MASKREPLY;
		icp->icmp_mask = ia->ia_netmask;

TO:
	case ICMP_MASKREQ:
		if (icmplen < ICMP_MASKLEN || (ia = ifptoia(ifp)) == 0)
			break;
		icp->icmp_type = ICMP_MASKREPLY;
		icp->icmp_mask = htonl(ia->ia_netmask);

To fix your Wollongong host, use anonymous ftp from another Wollongong
VMS machine, set ftp transfer type to BINARY and transfer structure to
RECORD, and get file ip_icmp.o.

By the way, there is another work-around if you are familiar with
dealing with disk partitions for client hosts on your sun servers.
Get into the root partitions for the diskless hosts and modify
the /etc/rc.boot files to issue the "ifconfig" command properly,
for example:
	ifconfig ie0 192.5.36.4 ...  netmask 255.255.255.0

Hope this helps, I think this was discussed earlier but your message
shows the symptom from the sun's point of view.  I hope Sun support
is taking note of this.

Jerry Scott

------

-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      Fri, 28-Aug-87 22:48:53 EDT
From:      percy@amdcad.AMD.COM (Percy Irani)
To:        comp.protocols.tcp-ip
Subject:   IBM's TCP-IP announcement..

Is there any one out there who has experience with the recent (!)
announcements by IBM regarding TCP-IP for VM/CMS, IBM-PC (using 8232). 
Any real users already? 

I attended a satellite presentation by IBM. It looks like 
Columbia University uses that. Any one from Columbia can 
comment?

Im specially intrested in things like 
	- speed
	- how close are they to standards :-)
	- how well does the product interface to things like the 
	  batch monitor to do remote batch submissions? etc...
	- Any monitoring capability (problem isolation?)
	- Can Sun make use of that for NFS etc...
	  i.e. can other products like NFS, Apollo's NCS etc
	  run with that? (may be this is a repeat of the standards
	  question I had earlier!)

Forum.... any comments?
-- 
Ignorance is bliss but can be embarassing at times!

-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      Sat, 29-Aug-87 01:44:43 EDT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  What are martian filters?

Doug,

A martian filter is designed to delete certain kinds of packet trash
at gateway interfaces between networks. Specifically, the trash consists
of "loopback" addresses 127.0.0.1 from malconfigured Unix hosts, "local
use" addresses (see latest Assigned Numbers RFCs) and broadcasts. See
RFC-1009 for further information.

Dave

-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 87 23:23:00 GMT
From:      uwmcsd1!marque!doug@unix.macc.wisc.edu  (harris)
To:        tcp-ip@sri-nic.arpa
Subject:   What are martian filters?
I like hitech talk such as "swamp" and "fuzzball" as much as the next
Ph. D., but I would appreciate a little explanation of "martian filter".
Is there an RFC to peruse?  or would some kind soul send mail, or
post an explanation?  I'm in the middle of writing code and setting
up some local gateways, and believe the notion is something I need
to be familiar with.

Thanks in advance.
uwvax!marque!doug
doug@mu.edu
-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      Sat, 29-Aug-87 06:37:00 EDT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Sun routers...


I had always hoped that the initiative taken by Dan Lynch with
his conferences, seminars and Tech Mart would lead to the kind
of joint demonstrations you suggest and which I agree are
generally more productive than indiscriminate flaming.

However, when there is real reason to flame, I am always glad
to find a few souls willing to brave the heckling of their
peers to holler about things that need fixing.

Vint Cerf

-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      Sat, 29-Aug-87 07:06:00 EDT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Are simultaneous TCP opens useful?


A bit of history:

In the earliest days of TCP design (1973-1974), we worked very
hard to make sure that self-simul-syn would work (sounds vaguely
self-abusive, doesn't it?).

Richard Karp (not the one at Berkeley, but the one now running
Reliable systems in Palo Alto) was a graduate student working
on one of the first TCP programs (in BCPL). We assured him that
the design really was intended to work on a self-connect but
I recall his astonishment when we tried it and it, indeed, worked
just as advertised.

Vint Cerf

-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      Sat, 29-Aug-87 13:39:31 EDT
From:      cyrus@hi.UUCP (Tait Cyrus)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: SUN 3.4 problems

In article <1615@briar.Philips.Com> jmr@philabs.Philips.Com (Joanne Mannarino) writes:
>
>
>In trying to upgrade our SUN 3/180 fileserver (named condor) to SUN UNIX
>version 3.4 along with 11 diskless clients, I ran into some problems.  The
> ...
>Ethernet).  The problem began when the booting process got to the point for:
>
>	starting rpc and net services: portmap router biod
>
>The boot process then halts with the following error messages:
>
>	server not responding
>	RPC: program not registered
>	mount retrying

Something that ?might? be causing some problems is that when a SUN client
boots, it determines its netmask from an ICMP (rfc 950) 'netmask request'.

At one point, here at the University of New Mexico, one of our SUN's
was configured with the WRONG netmask.  When we tried to boot our
diskless clients, they got the wrong netmask and were unable to talk
with the server.   Rebooting the server did not fix the problem because
it got the netmask from the partially booted clients.  We ended up
halting ALL of our SUN's, booting the servers with the correct netmask,
and THEN booting our clients.  

I don't know if this is your problem or not, but you might look into it.

-- 
    @__________@    W. Tait Cyrus   (505) 277-0806
   /|         /|    University of New Mexico
  / |        / |    Dept of EECE - Hypercube Project
 @__|_______@  |    Albuquerque, New Mexico 87131
 |  |       |  |
 |  |  hc   |  |    e-mail:
 |  @.......|..@       cyrus@hc.dspo.gov or
 | /        | /        seismo!unmvax!hi!cyrus
 @/_________@/

-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 1987 18:37-PDT
From:      STJOHNS@SRI-NIC.ARPA
To:        karels%okeeffe@UCBVAX.BERKELEY.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Where can I find SLIP server for 4.2/3?
Thanks  for all the responses.  To summarize: SLIP comes embedded
in 4.3.  A version for 4.2 is available  from  seismo.css.gov  or
from  mimsy.umd.edu.  (BTW, seismo didn't seem to have any public
access ftp  files  when  I  checked  last  night!)   PC  SLIP  is
available from SIMTEL20 or from MIT.  Mike
-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 87 22:45:00 PDT
From:      "Jerry Scott" <jerry@twg.arpa>
To:        "karels%okeeffe" <karels%okeeffe@berkeley.edu>
Cc:        <tcp-ip@sri-nic.arpa>
Subject:   RE: SUN 3.4 problems
Mike,
	I am told that I missed the posting of this latest 4.3 ICMP mask reply
bug by minutes before I posted my errant bug fix to the net.  Anyway,
I hope this solves the issue with the sun that caused this trading
of code changes.

I have included this latst fix and made it available via anonymous ftp
to host twg.arpa (26.5.0.73).  If you don't have arpa access call 
Wollongong support for the fix.  I think this fix is really only needed
by those sites with diskless suns running os 3.3 or 3.4.  Is this
true or are there other implementations using the ICMP MASKREQ
broadcast?

Thanks,
Jerry
------
-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      Sat, 29-Aug-87 20:16:48 EDT
From:      karels%okeeffe@UCBVAX.BERKELEY.EDU (Mike Karels)
To:        comp.protocols.tcp-ip
Subject:   Re: Where can I find SLIP server for 4.2/3?

I'm not sure what you mean by a SLIP server; the SLIP protocol for
the 4BSD side of a connection is included in 4.3 as if_sl.c.  It is
configured into a kernel with a line like
	pseudo-device	sl	4
in the system config file, where the number is the number of lines to support.
The lines are then set up with the programs slattach and ifconfig, each
of which have manual entries.  These programs are designed for more-or-less
static configurations, as they don't allow dialup use (very easily)
and don't do dynamic address assignment.  The original versions of slip
and slattach were written for 4.2BSD, and they are probably still available
somewhere.

Of course, you'll need a corresponding protocol module for the PC end,
along with IP/TCP support; if that's what you're asking for, I don't
know where to find it.

		Mike

-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      Sat, 29-Aug-87 20:24:02 EDT
From:      karels%okeeffe@UCBVAX.BERKELEY.EDU (Mike Karels)
To:        comp.protocols.tcp-ip
Subject:   Re: Sun routers...

Geof, the Berkeley/UNIX "routed" router (and other similar routing protocols)
choose among equal-cost routes semi-randomly.  Different hosts and gateways
may then choose different gateways for the same destination.  The same
is true for hosts that use one of several default gateways and then process
redirects from them; they'll either choose a suitable gateway, or be
redirected to that particular gateway's choice of next-hop router.
None of this manages carefully-equalized load balancing, but does tend
to spread out the load among multiple gateways.

		Mike

-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      Sat, 29-Aug-87 20:31:15 EDT
From:      karels%okeeffe@UCBVAX.BERKELEY.EDU (Mike Karels)
To:        comp.protocols.tcp-ip
Subject:   Re: SUN 3.4 problems

Jerry, sorry to say this, but your fix for ICMP MASK request handling
for 4.3 was incomplete; it was recently pointed out to me that wrong
mask was being returned.  Make that

	icp->icmp_mask = htonl(ia->ia_subnetmask);

The error was originally mine, of course.  (Watch out for those woodpeckers;
that makes three errors in two lines of code!  I guess that demonstrates
that 4.3 doesn't use mask requests when booting).

		Mike

-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      Sat, 29-Aug-87 21:37:00 EDT
From:      STJOHNS@SRI-NIC.ARPA
To:        comp.protocols.tcp-ip
Subject:   Re: Where can I find SLIP server for 4.2/3?

Thanks  for all the responses.  To summarize: SLIP comes embedded
in 4.3.  A version for 4.2 is available  from  seismo.css.gov  or
from  mimsy.umd.edu.  (BTW, seismo didn't seem to have any public
access ftp  files  when  I  checked  last  night!)   PC  SLIP  is
available from SIMTEL20 or from MIT.  Mike

-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      Sun, 30-Aug-87 00:36:31 EDT
From:      rick@SEISMO.CSS.GOV (Rick Adams)
To:        comp.protocols.tcp-ip
Subject:   Re:  Where can I find SLIP server for 4.2/3?


You can ftp the source code for SLIP from uunet.uu.net as the
file ~ftp/pub/sl.shar.Z

This file contains the code for 4.2bsd systems and Sun 3.X.  If you
have 4.3bsd, you already have SLIP (it is surprising how many people
ask this). It is known to run on vaxes and suns. It may run on other systems
depending on how much the vendor "fixed" that wasn't broken.

Note: SLIP is ONLY a device driver. You have to come up with
your own IP, TCP, ICMP, ETC

To answer the other popular question, no there is no RFC describing the
"protocol" (I hesitate to call it a protocol. Its a simple framing
scheme.)

---rick
f

-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      Sun, 30-Aug-87 01:45:00 EDT
From:      jerry@TWG.ARPA.UUCP
To:        comp.protocols.tcp-ip
Subject:   RE: SUN 3.4 problems

Mike,
	I am told that I missed the posting of this latest 4.3 ICMP mask reply
bug by minutes before I posted my errant bug fix to the net.  Anyway,
I hope this solves the issue with the sun that caused this trading
of code changes.

I have included this latst fix and made it available via anonymous ftp
to host twg.arpa (26.5.0.73).  If you don't have arpa access call 
Wollongong support for the fix.  I think this fix is really only needed
by those sites with diskless suns running os 3.3 or 3.4.  Is this
true or are there other implementations using the ICMP MASKREQ
broadcast?

Thanks,
Jerry
------

-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      Sun, 30-Aug-87 02:34:05 EDT
From:      phil@amdcad.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: Where can I find SLIP server for 4.2/3?

In article <8708300016.AA04771@okeeffe.Berkeley.EDU> karels%okeeffe@UCBVAX.BERKELEY.EDU (Mike Karels) writes:
>I'm not sure what you mean by a SLIP server; the SLIP protocol for
>the 4BSD side of a connection is included in 4.3 as if_sl.c.  It is
>configured into a kernel with a line like
>	pseudo-device	sl	4
>in the system config file, where the number is the number of lines to support.
>The lines are then set up with the programs slattach and ifconfig, each
>of which have manual entries.

This brings up a question I had. I hope it's not too stupid. Consider
a network with machines A, B, and C. B talks to A and C. A does not
talk to C except through B. B's /dev/ttyh0 goes to A. B's /dev/ttyh1
goes to C. I slattach ttyh0 and ttyh1. 

Now I want to ifconfig sl0 and sl1. How do I know which dstaddr to
associate with sl0 and which with sl1? Does it matter? If not, how
does the kernel know which tty line to send the packets down? 

The thing that confuses me is I would expect slattach to take a sl0 or
sl1 argument as well as a tty argument. But it doesn't. 

Also, do I have to do anything special to B to get it to forward
packets from A to C?
-- 
I speak for myself, not the company.

Phil Ngai, {ucbvax,decwrl,allegra}!amdcad!phil or amdcad!phil@decwrl.dec.com

-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      Sun, 30-Aug-87 14:45:37 EDT
From:      kre@munnari.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: Where can I find SLIP server for 4.2/3?

In article <18137@amdcad.AMD.COM>, phil@amdcad.AMD.COM (Phil Ngai) writes:
> Now I want to ifconfig sl0 and sl1. How do I know which dstaddr to
> associate with sl0 and which with sl1? Does it matter? If not, how
> does the kernel know which tty line to send the packets down? 

It matters, and this has been bugging me too.  The only way to
solve this currently is to run all the slattach's serially, which
means that if there's no carrier on the first (the remote end is
down when you're booting) the second doesn't happen until carrier
appears (who knows how long).

It happens that its trivial to fix this, with no major changes
to anything.  Rather than tell slattach which slN it should use,
we can just have it tell us which one it was assigned, then /etc/rc.local
can look like

	UNIT=`slattach ttyh0 9600`
	dstaddr $UNIT ...		# if needed
	ifconfig $UNIT ...

All the support needed for slattach to do this is there already, I'm
going to add the few lines needed (there will probably be a flag to
cause this behaviour for backward compatability) sometime very soon
now.  I'll post the diffs.

kre

-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      Sun, 30-Aug-87 20:34:37 EDT
From:      ddp+@ANDREW.CMU.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: Where can I find SLIP server for 4.2/3?

>PC  SLIP  is available from SIMTEL20 or from MIT.
Sorry Mike, but PC "SLIP" is not available from MIT.  The "slip" which MIT
distributes does not support the same framing scheme as the "slip" (SLIP)
available with 4.3bsd.  However, both the MIT slip and "SLIP" are included
with CMU-PCIP, available from me.  It is also supported by the KA9Q (Phil
Karn) PC IP package.

Drew

-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      Mon, 31-Aug-87 10:59:17 EDT
From:      beadel@oswego.UUCP (Edward F. Beadel, Jr.)
To:        comp.protocols.tcp-ip
Subject:   Re: Where can I find SLIP server for 4.2/3?

Mike Karels writes (among other things regarding SLIP):
>
>of which have manual entries.  These programs are designed for more-or-less
>static configurations, as they don't allow dialup use (very easily)
>and don't do dynamic address assignment.  The original versions of slip

	Does anybody know of a 4.3( or 4.2)bsd version that has been hacked
to allow dialup use? We are having "campus political problems" getting a 
dedicated 9600 baud line to another building that will connect through the
SUNY InterCampus Data Network to NYSERNet and thus to the INTERNET. However
we can buy a pair of 9600baud modems and dial up a phone that is right next
to our on campus SICDN port. Of course the 9600baud modems are more expensive,
however they seem to be the only way for now (sigh .......)
	We'd *LOVE* any help at this point since we don't have the time to
hack it ourselves at this point in time. (Most of our Systems Programming
effort is in beta 2.10 at present).

		Thanks,
		Ed

******************************************************************

Edward F. Beadel, Jr., Manager {seismo|decvax}!rochester\
Instructional Computing Center                   allegra !rocksvax!oswego!beadel
SUNY College at Oswego           {ihnp4|research|allegra}!warrior/
Oswego, NY  13126 (315)-341-3055       {allegra|watmath}!sunybcs/

-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      Mon, 31-Aug-87 11:24:10 EDT
From:      tung@mit-eddie.UUCP
To:        comp.os.vms,comp.protocols.tcp-ip
Subject:   Using CMU-TEK TCP-IP with NI1010A

Has anyone been able to make the CMU-TEK VMS TCP-IP (version 6.0 or higher)
to work with the NI1010A controller ? I understand the original Tektronix
software supports the Interlan NI1010A Unibus controller. But Carnegie-Mellon
University told me that they did not check their enhanced codes on any Interlan
boards. A local site has tried it without success.

Thank you for any information that you can provide.

- Thye-Lai Tung

-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      Mon, 31-Aug-87 13:33:58 EDT
From:      geof@apolling.UUCP (Geof Cooper)
To:        comp.protocols.tcp-ip
Subject:   Re: Re: Re: Sun routers...


 > This isn't exactly a failing of the standards, except maybe by
 > omission.....

Actually, I think it IS a failing of the standards (by the way,
some people misread my message -- I'm in favor of load sharing.
I want EVERYONE to do it).

Clearly, implementors have found ad hoc ways of achieving load
sharing.  We've seen three here (random choice, round robin,
choose the first response ("load-biased random"?)).

What are the implications of each to network congestion?  Network
reliability?  One implementor points out that the load-sharing
decision must not be made every packet.  How frequently is right?

How do the different schemes interact?  Are there some combinations
that make network congestion worse?

There are non-trivial issues of network congestion and performance
at stake.  A standard is supposed to address these by causing even
the most naive implementor to use a "good" technique.  The standard
also ensures that everyone addresses the problem.  There are certainly
gateways out there today (we have some) that don't support ANY ad-hoc
load sharing system.

So if we think that load-sharing is important (I do), and we know
that it is tricky (cf above questions) then this is exactly the
sort of thing the standards should address.

- Geof

-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 1987 17:09-PDT
From:      STJOHNS@SRI-NIC.ARPA
To:        hedrick@TOPAZ.RUTGERS.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: IP network numbers for networks not on the Internet
Umm...   sponsorship is needed if you are going to connect to the
DOD internet, whether you say so or not!

Attaching  without  the  proper  blessings  counts  as  theft  of
services.   Since  this is stealing from Uncle Sam, this tends to
get the attention of the FBI and  the  Secret  Service  (suprise,
they have jurisdiction!)

Mike
-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      Mon, 31-Aug-87 15:07:05 EDT
From:      hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   IP network numbers for networks not on the Internet

A couple of people indicated that they had had trouble getting network
numbers for networks that are not attached to the Internet.  I just
checked with the NIC.  Sue@sri-nic.arpa verified that they will give
out a network number to anyone who needs it.  Sponsorship is needed
only if you say that your network is to be connected to the
DDN-internet.  If you have had trouble in the past getting a number,
you might want to try again.  The NIC's mail address is
hostmaster@sri-nic.arpa.  Their phone number is 415-859-5539.

-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      Mon, 31-Aug-87 16:48:29 EDT
From:      minshall@OPAL.BERKELEY.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: tn3270 beta version bug

Tom,

	You reported a problem with the beta test version of tn3270, which
makes it fail using the CMS "note" command (in "input" mode).  The CMS "note"
command uses "fullread".  This is, by the way, a bad use of your network (since
it transfers the entire 3270 screen buffer to the host everytime an AID-
generating key is hit).  However, tn3270 was designed to support this mode.

	So, here is the fix.  The file is tn3270/api/ebc_disp.c.  The structure
being changed is the "disp_ebc" table (for translating display codes
to ebcdic.  The problem is that NULLs are being translated into 0xff's;
NULLs should be translated into NULLs.


6c6
< static char sccsid[] = "%W% (Berkeley) %G%";
---
> static char sccsid[] = "@(#)ebc_disp.c	3.2 (Berkeley) 8/31/87";
49c49
< /*00*/	0xff,	0xce,	0xcf,	0xdd,	0xde,	0xdf,	0xed,	0xee,
---
> /*00*/	0x00,	0xce,	0xcf,	0xdd,	0xde,	0xdf,	0xed,	0xee,
                  ^^

	Note that the tar files on arpa.berkeley.edu have been changed.

	Thanks again for the bug report.

Greg Minshall

-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      Mon, 31-Aug-87 18:47:00 EDT
From:      zeilenga@hc.dspo.gov (Kurt Zeilenga)
To:        comp.protocols.tcp-ip
Subject:   IP assigned protocol numbers

According to "Assigned Protocol Numbers," available from the NIC,
The gateway-to-gateway protocol, GGP, should be protocol 3.  When
looking thru the .h files on our system (SUN UNIX) I noticed that
GGP was using protocol number 2.  I checked other systems (other
BSD based systems), and they too were using protocol 2 for GGP.
Mmmm.

Comments?

	Kurt Zeilenga	 (zeilenga@hc.dspo.gov)

-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      Mon, 31-Aug-87 20:09:00 EDT
From:      STJOHNS@SRI-NIC.ARPA.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: IP network numbers for networks not on the Internet

Umm...   sponsorship is needed if you are going to connect to the
DOD internet, whether you say so or not!

Attaching  without  the  proper  blessings  counts  as  theft  of
services.   Since  this is stealing from Uncle Sam, this tends to
get the attention of the FBI and  the  Secret  Service  (suprise,
they have jurisdiction!)

Mike

-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      Mon, 31-Aug-87 20:32:18 EDT
From:      hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   Re: IP network numbers for networks not on the Internet

I certainly wasn't implying that people should attach to the Internet
without permission.  Rather, I was pointing out that whether your
application needs to get "blessed" depends upon what you say to the
question about whether you are going to connect to the DoD Internet.
One theory as to why people may have had trouble getting numbers is
that they inappropriately said that they intended to connect to the
Internet, for example because they didn't understand exactly what the
question meant.

END OF DOCUMENT