The 'Security Digest' Archives (TM)

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

ARCHIVE: TCP-IP Distribution List - Archives (1989)
DOCUMENT: TCP-IP Distribution List for November 1989 (444 messages, 224330 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1989/11.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      1 Nov 89 00:05:04 GMT
From:      craigb@hpldsla.HP.COM
To:        comp.protocols.tcp-ip
Subject:   Re: Is there TCP/IP for HP-3000 ?

> Hi all netlanders:
> 
> We are looking for an implementation of TCP/IP protocols
> for the HP-3000 computer systems.
> 

I have never used it but there is a TCP/IP package available from
Wollen Gong (sp?)  I understand that it is a good package.

> Any further help ont his is appreciated, thanks in advance.!!.
> 
> Ed

Hope this helps.

Craig Blackwood
Hewlett Packard
craigb@hpldsla.hp.com
----------

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      1 Nov 89 01:58:38 GMT
From:      heberlei@iris.ucdavis.edu (Todd)
To:        comp.protocols.tcp-ip
Subject:   Re: usernames as security hole

In article <1989Oct31.185203.2345@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>In article <5118@omepd.UUCP> merlyn@iwarp.intel.com (Randal Schwartz) writes:
>>Gaccckkk.  Blindingly direct and useful security hole.  If I can get a
>>list of usernames on your system, I can attack you sooooooooooo much
>>easier.
>
>Correction:  blindingly direct and useful security hole that is usually
>present regardless.  Except on seriously secretive systems, it is rarely
>difficult to compile a (partial) list of user names by other means.  The
>correct question is not "is this a security hole?" but "does this open
>a security hole any wider than it is already?".
>-- 
>A bit of tolerance is worth a  |     Henry Spencer at U of Toronto Zoology
>megabyte of flaming.           | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

In general, the more information a person has available on a system,
the easier it is for that person to penetrate the security.  This is
true for computers, places (like a military base or a lab), cars, etc.

I enjoy being able to use the openness of most systems.  For example,
by using the finger, I can check whether someone has logged in since I
sent them mail.  Thus I can tell whether that person has read my
mail.  Of course someone else can use this feature for destructive
purposes.

I remember a quote by a character, Lazarus Long, from one of Robert
Heinlein's books that goes something like this:
  "You can have freedom, or you can have security.  Don't count on
   having both at the same time."


Todd Heberlein

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      1 Nov 89 04:07:00 GMT
From:      GRZ049@DBNGMD21.BITNET (Willi Porten)
To:        comp.protocols.tcp-ip
Subject:   Re: TN3270 for Ultrix



> 		I remember from time to time seeing(and sending for that matter)requests for
>  info on porting TN3270 to SYS V or whatever, but I can't recall
> anyone ever talking about doing an Ultrix port. If anyone has any insight on
> this could you drop me a line?

You can get TN3270 via anonymous FTP from UCBARPA.BERKELEY.EDU
(128.32.130.11). The program is named /pub/tn3270.tar.Z.
It works fine with Ultrix.

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      1 Nov 89 06:58:57 GMT
From:      karl%awsoms@philapd.idca.tds.philips.nl (Karl Lovink)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   X.25 streams modules for TCP/IP

Does somebody has a X.25 pushable streams module for Unix System V
Release 3.2 which does address conversion between X.25 and Internet 
addresses.
This means that TCP/IP will run over X.25.
The modules I have is a lli interface to X.25 and the IP module.
So I need a arp for X25.

[ The signature is that of the "physical" sender, not that of the author. ]

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      Wed, 01 Nov 89 16:24:48 CST
From:      Buster Hale <CCBUSTER@VM.CC.OLEMISS.EDU>
To:        TCP-IP Distribution <TCP-IP@SRI-NIC.ARPA>
Subject:   TCP/IP for VAX
At the request of several departments on campus, I am trying to get infor-
mation on TCP/IP implementations for VAXes running VMS.  Could someone send
me vendor names and telephone numbers?  Thanks.

E.F. ("Buster") Hale, III, LL.M.  BITNET:   ccbuster@umsvm
Manager, Computing Services       INTERNET: ccbuster@vm.cc.olemiss.edu
The University of Mississippi     PHONE:    (601) 232-7206
Powers Hall #322                  FAX:      (601) 232-7180
University, MS.  38677
-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      1 Nov 89 10:40:23 GMT
From:      carlson@uxh.cso.uiuc.edu
To:        comp.protocols.tcp-ip
Subject:   Re: Changing subnet masks


>/* Oct 30, 1989 by mogul@decwrl.dec.com in comp.protocols.tcp-ip */
>P.S. If you want to use different subnet masks on different parts of
>your network for more than just a transition period, then you've
>entered the twilight zone of variable-width subnetting ...

Sound more like the universe of OSPF (Open Shortest Path First)
routing, which allows a more general concept of subnetting.
(Just finished the first ~30 pages of it.)
Has anybody actually implemeted OSPF?
It sounds stange to have a new protocol at THE SAME LEVEL at
TCP/UDP.
--------------------
Brad Carlson  <carlson@mrcnext.cso.uiuc.edu> or <brad-carlson@uiuc.edu>
University of Illinois -- Consultant -- NeXT guru -- Windows Programmer

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      1 Nov 89 10:40:23 GMT
From:      tcp-ip-relay@NIC.DDN.MIL
To:        comp.protocols.tcp-ip
Subject:   Re: Changing subnet masks

There was a session on routeing at Interop this year and
it sound like OSPF was being implemented right now.  I can't
remember who was doing it, but I can look that up in my notes.

                        Brian Holmes
                        CSC Operating Systems & Communications

SNAIL    : Wayne State University, 5925 Woodward, Detroit MI 48202 U.S.A.
BITNET   : BHOLMES@WAYNEST1
INTERNET : Brian_Holmes@UM.CC.UMICH.EDU
UUCP     : {UMIX|ITIVAX}!WAYNE-MTS!BRIAN_HOLMES
----------------------------Original message----------------------------
>Sound more like the universe of OSPF (Open Shortest Path First)
>routing, which allows a more general concept of subnetting.
>(Just finished the first ~30 pages of it.)
>Has anybody actually implemeted OSPF?
>It sounds stange to have a new protocol at THE SAME LEVEL at
>TCP/UDP.
>--------------------
>Brad Carlson  <carlson@mrcnext.cso.uiuc.edu> or <brad-carlson@uiuc.edu>
>University of Illinois -- Consultant -- NeXT guru -- Windows Programmer

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Nov 89 10:40:23 GMT
From:      tcp-ip-relay%NIC.DDN.MIL@CORNELLC.cit.cornell.edu
To:        Brian Holmes <BHOLMES@WAYNEST1>
Subject:   Re: Changing subnet masks
There was a session on routeing at Interop this year and
it sound like OSPF was being implemented right now.  I can't
remember who was doing it, but I can look that up in my notes.

                        Brian Holmes
                        CSC Operating Systems & Communications

SNAIL    : Wayne State University, 5925 Woodward, Detroit MI 48202 U.S.A.
BITNET   : BHOLMES@WAYNEST1
INTERNET : Brian_Holmes@UM.CC.UMICH.EDU
UUCP     : {UMIX|ITIVAX}!WAYNE-MTS!BRIAN_HOLMES
----------------------------Original message----------------------------
>Sound more like the universe of OSPF (Open Shortest Path First)
>routing, which allows a more general concept of subnetting.
>(Just finished the first ~30 pages of it.)
>Has anybody actually implemeted OSPF?
>It sounds stange to have a new protocol at THE SAME LEVEL at
>TCP/UDP.
>--------------------
>Brad Carlson  <carlson@mrcnext.cso.uiuc.edu> or <brad-carlson@uiuc.edu>
>University of Illinois -- Consultant -- NeXT guru -- Windows Programmer
-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      1 Nov 89 13:51:26 GMT
From:      hughes@silver.bacs.indiana.edu (larry hughes)
To:        comp.protocols.tcp-ip
Subject:   Re: How find port number

In article <595@nixpbe.UUCP> josef@peun11.uucp (Moellers) writes:
>Hi,
>
>I have a question regarding port numbers:
>
>I have a ("user level", i.e. one not using a well-known port)
>server running on one machine and a client on another machine.
>
>? How do I give a port number to the server avoiding clashes with other
>  servers (not using well-known ports)?
>
>? How do I relay the port number to the client(s) trying to contact
>  my server?

There's not an automatic method for doing this, unless someone
writes a "services" nameserver.  The best thing to do is either
(1) make the port number a command-lne parameter to the
executables, or (2) make the port number well-known by entering
it into /etc/services on each machine, and then have each program
do a getservbyname(3).

 //=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=\\
|| Larry J. Hughes, Senior Programmer ||  hughes@silver.bacs.indiana.edu   ||
||        Indiana University          ||                                   ||
||   University Computing Services    ||  "The person who knows everything ||
||    750 N. State Road 46 Bypass     ||     has a lot to learn."          ||
||      Bloomington, IN  47405        ||                                   ||
||         (812) 855-9255             ||  Disclaimer: See quote above.     ||
 \\=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=//

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      1 Nov 89 15:24:58 GMT
From:      todd@janus.UUCP (Todd Booth)
To:        comp.protocols.tcp-ip
Subject:   Re: Changing subnet masks

In article <1855@eric.mpr.ca>, parker@zaphod.mpr.ca (Ross Parker) writes:
> The $64,000 question is: do we need to change all subnet masks at the
> same time (which would be a *real* drag...), or can multiple subnet
> masks exist on the same network at the same time?

Go ahead and change one logical subnet at a time.  Keep in mind not all
vendors properly support subnets (I've got a call in regarding IBM's
PS/2 AIX software) so you should first perform your tests.  The reason
that multiple subnets can exist is the subnet mask is a local (host)
thing allowing a host to *see* ip packets.  MAKE SURE you change each
hosts broadcast address or all multiple logical subnets may see a single
hosts broadcast.

--todd booth
 

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      1 Nov 89 15:42:49 GMT
From:      todd@janus.UUCP (Todd Booth)
To:        comp.protocols.tcp-ip
Subject:   Re: Changing subnet masks

In article <1855@eric.mpr.ca>, parker@zaphod.mpr.ca (Ross Parker) writes:
> Any comments, help, suggestions, money :-) would be greatly appreciated.

Even if all your subnet masks don't use all 111's or 000's in the subnet
part, it is still possible to have subnet's that have the all 111's or
000's problems.  The way to avoid this is to verify that from each subnet's
viewpoint (each subnet bit set has a different viewpoint) that no other
subnets will conflict.

For example, we have a net 130.224.4.0 with a mask of 0xffffffc0 (6 bits host)
and another net 130.224.0.48 with a mask of 0xfffffff0 (4 bits host) and
when 130.224.0.49 does a broadcast (130.224.0.63) the 130.224.4.0 hosts
will see this!

We have also run into the problem that IBM's PS/2 AIX TCP/IP can't
understand how to route to the network 130.224.4.64 from a machine
130.224.4.1 with a mask of 0xffffffc0.

--todd booth

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      1 Nov 89 16:13:35 GMT
From:      bob@MorningStar.Com (Bob Sutterfield)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: X.25 streams modules for TCP/IP

In article <1602@ssp15.idca.tds.philips.nl> karl%awsoms@philapd.idca.tds.philips.nl (Karl Lovink) writes:
   So I need a arp for X25.

X.25 being a non-broadcast, point-to-point sort of beast, I doubt
you'll find such a thing.  Rather, most implementations (ours, for
instance) feature a hand-maintained table associating X.121 addresses
with IP addresses of those sites with which you expect to open virtual
circuits to carry IP packets.  This performs the same function
(mapping logical to "physical" address, where IP sees X.121 as a
physical address) as an ARP table.

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      1 Nov 89 16:32:08 GMT
From:      jimm@haddock.ima.isc.com (Jim McGrath)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: X.25 streams modules for TCP/IP

In article <1602@ssp15.idca.tds.philips.nl> karl%awsoms@philapd.idca.tds.philips.nl writes:
>Does somebody has a X.25 pushable streams module for Unix System V
>Release 3.2 which does address conversion between X.25 and Internet 
>addresses.
>This means that TCP/IP will run over X.25.
>The modules I have is a lli interface to X.25 and the IP module.
>So I need a arp for X25.
>
Sorry, I don't have what you want, but do have a few suggestions.  I
think you would be better off with two streams modules, an rfc 877
module under IP, and an X.25 module under the rfc 877 module.  This
gives you a cleaner interface in case you ever want to run raw X.25.
Also, the rfc 877 module will do the conversion between the
connectionless logical link interface, and the connection oriented
interface of X.25.  It would be rather ugly to add this to an X.25
module.

There is no such thing as arp for X.25.  There are two ways of
converting between Internet and X.121 (X.25) addresses.  The first is
the DDN model, and uses an algorithm for the conversion (refer to
Defense Data Network X.25 Host Interface Specification).  X.121
addresses in the public sector are assigned by the authority governing
a specific PSDN, so there is no convenient way of doing the
translation.  You might implement a table lookup for the conversion.

RFC 1009 (Requirements for Internet Gateways) provides lots of good
information, and I suggest reading that before proceding further.

Jim

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      1 Nov 89 18:22:00 GMT
From:      01696@AECLCR.BITNET (Chris Tanner)
To:        comp.protocols.tcp-ip
Subject:   LPD Documentation

Where can one locate documentation on the Line Printer Daemon (and related
products). I looked in a recent index of RFC's and couldn't find anything.

THanks for you help in advance.

Chris Tanner                01696@aeclcr.BITNET
Chalk River Nuclear labs

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      1 Nov 89 18:43:08 GMT
From:      rlfink@LBL.GOV (Robert L. Fink)
To:        comp.protocols.tcp-ip
Subject:   Re: private mib variables

hi there

Bob Fink
Lawrence Berkeley Laboratory
rlfink@lbl.gov  (415) 486-5692

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      1 Nov 89 19:15:07 GMT
From:      aggarwal@JVNCA.CSC.ORG (Vikas Aggarwal none)
To:        comp.protocols.tcp-ip
Subject:   Traceroute sources

Could someone point me towards the locations for source code for
"traceroute" ?? I have tried a couple of 'expected' sites but couldn't
find it there. 

Also, I believe that certain modifications have been done to the code
so that it can do 'third party' traceroute (from one remote machine
to another). Could someone comment on this ??

Lastly, any user comments on 'traceroute' ??From what I know, it is
best if used without "full dependablity". It generally gives a good
insight into which directions the packets are heading, but it is 
advisable NOT to expect the destination host to always respond.

Any comments ??

-vikas

=--=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-==-=-=
	JOHN VON NEUMANN NATIONAL SUPERCOMPUTER CENTER

INTERNET:  aggarwal@jvnca.csc.org
BITNET:    aggarwal@jvncc
UUCP:      rutgers!jvnca!aggarwal

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-===-=--=-=-=-====-=-=-==-=-=-=-=

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      1 Nov 89 22:24:48 GMT
From:      CCBUSTER@VM.CC.OLEMISS.EDU (Buster Hale)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP for VAX

At the request of several departments on campus, I am trying to get infor-
mation on TCP/IP implementations for VAXes running VMS.  Could someone send
me vendor names and telephone numbers?  Thanks.

E.F. ("Buster") Hale, III, LL.M.  BITNET:   ccbuster@umsvm
Manager, Computing Services       INTERNET: ccbuster@vm.cc.olemiss.edu
The University of Mississippi     PHONE:    (601) 232-7206
Powers Hall #322                  FAX:      (601) 232-7180
University, MS.  38677

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      1 Nov 89 23:53:55 GMT
From:      cs.utexas.edu!mailrus!cwjcc!cwns1!chet@tut.cis.ohio-state.edu  (Chet Ramey)
To:        tcp-ip@NIC.DDN.MIL
Subject:   Re: Where can i get a POP3 server for 4.3 BSD UNIX ?
In article <3469@puff.cs.wisc.edu> tannenba@garfield.cs.wisc.edu (Todd Tannenbaum) writes:

>I am trying to locate a POP3 (Post Office Protocol ver 3) server that will
>run on 4.3 BSD UNIX.  It is important to me to obtain version 3, NOT version
>2.

One is distributed as part of the MH-6.6 distribution.  It needs the MH
libraries, but not necessarily all the MH user interface programs.  I have
just built it for both IBM/4.3 BSD and Ultrix 3.0 in preparation for use
with Macintosh MH implementations; mail me for details. 

Chet Ramey

-- 
Chet Ramey				"How terrible is wisdom when it 
Network Services Group			 brings no profit to the wise."
Case Western Reserve University			-- Mephistopheles 
chet@ins.CWRU.Edu			
-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      2 Nov 89 01:37:26 GMT
From:      dricejb@drilex.UUCP (Craig Jackson drilex1)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet cabling book

In article <923@sunic.sunet.se> bygg@sunic.sunet.se (Johnny Eriksson) writes:
>In article <8910311903.AA03243@ucbvax.Berkeley.EDU> dave@CITI.UMICH.EDU
>  (Dave Bachmann) writes:
>> A book just came out called "Keeping the Link" that covers all sorts of
>> issues on Ethernet.  Very detailed.
>
>Sounds interesting.  You don't by any chance have any more information
>about it, such as ISBN number or name of author?

The full information is:

Keeping the Link
Ethernet Installation and Management
by Martin Nemzow
Publisher: McGraw-Hill
ISBN: 0-07-046302-6
Copyright 1988

Mini-Review: This book does cover a lot about cabling, but it contains
several important inaccuracies.  For example, he repeatedly indicates
that the cable impedance does not matter for thinwire, although he does
emphasize the need for 50-ohm terminators.  There were several other
misconceptions which I discovered on an initial scan of the book.

Other than those few problems, the book seems OK.  It talks quite a bit
about the physical side of Ethernet: putting on taps, using Time-Domain
Reflectometry, etc.

Disclaimer: I work for McGraw-Hill.  I bought this book for US$0.75 per
pound, at a sale of 'seconds' provided for company employees.
-- 
Craig Jackson
dricejb@drilex.dri.mgh.com
{bbn,ll-xn,axiom,redsox,atexnet,ka3ovk}!drilex!{dricej,dricejb}

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      2 Nov 89 02:31:38 GMT
From:      Lance_C_Norskog@cup.portal.com
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: X.25 streams modules for TCP/IP


We did it as one module which accepts LLI messages with IP addresses.
The module itself is loaded up with a table of IP/X.25 address pairs.
It places calls directly through the X.25 kernel services.

Looking back, it would be better to have a user-mode daemon which
handles this translation, and makes calls; this would be better
for problem tracing.

Lance Norskog
Sales Engineer
Streamlined Networks 415-659-1450

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      2 Nov 89 03:21:48 GMT
From:      doug@marque.mu.edu
To:        comp.protocols.tcp-ip
Subject:   Re: Sender-initiated file transfer and FTP

As has been mentioned, uuto/uupick implement over uucp a facility
similar to the BITNET file transfer.  Uucp itself can of course be
implemented over tcp, provided the machines at each end are satisifed
regarding machine names.  Or of course uuto, which is only a shell
script, could perform ftp "on its own".  The name conflict problem
is handled by creating directories as needed; so things sent to me
from various machines go to /usr/spool/uucppublic/receive/doug/MACHINE/...
The uuto script also arranges to have mail sent to the recipient when
the file arrives, which could certainly be handled with SMTP.

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      Thu, 02 Nov 89 15:54:22 EST
From:      bill gunshannon <702WFG%SCRVMSYS.BITNET@CORNELLC.cit.cornell.edu>
To:        tcp-ip@nic.ddn.mil
Subject:   3C523
Has anyone had any experiences using the 3COM 3C523 ethernet card??
I just installed 2 of them, 1 in a PS2 Model 70 and the other in a
PS2 Model 50.  I tried 2 different TCPIP packages: PC NFS and another
that uses the FTP Packet Drivers.  The result was the same in all cases.
The machine just hangs.  Dead in the water.  Can't even do the old
ctl-alt-del.  Have to shut it off and bring it back up cold.

Anybody got any suggestions to offer???

                                          bill gunshannon
                                       702WFG@SCRVMSYS.BITNET

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      2 Nov 89 11:33:35 GMT
From:      jst@cca.ucsf.edu (Joe Stong)
To:        comp.protocols.tcp-ip
Subject:   Re: Pilot Project: Hosts Table To Be Available Over Internet

How would this solution be:  instead of transferring host tables,
have a local site WITH the resolver routines make the gethostbyname()
function availiable via telnet?  I wrote a little server that gets
activated by inetd, reads a line from stdin, does a gethostbyname,
and writes the result to stdout and exits.  You telnet from another
machine to the assigned port number, enter the hostname and get
back the hostnumber.

Although, my understanding is that the resolver routines are PD and
availiable on ucbvax.berkeley.edu.  I had no problem compiling them
on a BSD VAX and linking programs with them.

Folks without sources could just do a little program like the above
server, link it with the PD resolver routines, and put script wrappers
around things like ftp, telnet, and whatever else needed nameservice.

If either of these small sources are interesting to folks, I'll post them.

Do people maintain listings of "nearest internet host to a uucp site
and paths to that uucp sites"?  (Figured out from the uucp maps, rather
than MX records, which I suspect are incomplete?)

	Joe Stong	jst@cca.ucsf.edu

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      2 Nov 89 13:00:36 GMT
From:      VSBENZI@WEIZMANN.BITNET (Benzi mizrahi)
To:        comp.protocols.tcp-ip
Subject:   TN3270 for HP

Hello all

 Can any one tell me please if there is public domain TN3270 for HP
 machines, and how can it be retrieved. (we can't use FTP to retrieve
 files from the Internet).
 Thanx in advance, Benzi

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      2 Nov 89 13:10:56 GMT
From:      karl@cheops.cis.ohio-state.edu (Karl Kleinpaste)
To:        comp.protocols.tcp-ip
Subject:   Re: Sender-initiated file transfer and FTP

I whipped this up in about 4 minutes this morning.  It does almost no
error checking, could take the destination in user@host.domain format
and then split the host.domain off, could stand enhancements to give
more explicit info about what remote directory to put a file in, could
accept a message from the user on stdin about what the file is good
for, etc, etc.  But it does the job.

--Karl

#!/bin/sh
#
# Send: a script for performing BITNET-style file-sending to a
# remote FTP'able site, and then dropping a short message to the
# intended recipient of its arrival.  A bit like uuto, too.
#
# Usage: send /file/name host.domain user
# Assumptions:
#	Both FTP and SMTP directly to host.domain work.
#	host.domain has a "pub" directory, in which things can be placed.
#
# Simplistic arg check.
if [ $# != 3 ]
then
	echo Usage: $0 /file/name host.domain user
	exit 1
fi
#
# Pick out the args as "normal" variables, just because I don't like
# dealing with them as positional items.
file=$1
rfile=`basename $file`
host=$2
u=$3
#
# Send the file.
ftp $host << EOF
send $file pub/$rfile
quit
EOF
#
# Now mail a short note to the recipient.
here=`hostname`
/usr/ucb/Mail -s "File arrival" $u@$host << END
$USER@$here has sent $file to you as $rfile in your anonymous FTP area.
END
#
exit 0

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      2 Nov 89 13:32:46 GMT
From:      aras@dr.uucp (Arne Asplem)
To:        comp.protocols.tcp-ip
Subject:   SLIP source wanted

A few weeks ago I posted an article in comp.sources.wanted, asking
for SLIP (Serial Line Internet Protocol) source, which I could port
to Motorola Delta boxes, running System V Release 3. There was a lot
of replies, but 90 % was other users interested in the same source,
the rest suggested looking at the ka9q package. I did - and the ka9q
package I received was actually an PC implementation, maybe used
for packet radio - but not suited to an SVR3 port !

Within a few weeks I have to start working on SLIP for the Delta boxes,
and since the ka9q is not suitable for porting, I have to write something
which looks like SLIP. Currently I only need Telnet, and socket-calls
to implement client/server based applications over a 9600 bps leased
line. (On of the computers is located in Oslo, and the other one in 
Stockholm). There will only be 2-3 computers on the network, so I actually
don't need the fancy IP routing.

If I don't succed to find a version of SLIP - I guess I start writing
my Serial Line Packet Protocol (SLPP - is this acronym used somewhere else ?)

Any suggestions, hints ???

  -- Arne

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      2 Nov 89 14:38:50 GMT
From:      a20@nikhefh.nikhef.nl (Marten Terpstra)
To:        comp.protocols.tcp-ip
Subject:   SNMP ...

Hi everyone,

	I'm looking for information on SNMP (Simple Network Management
Protocol). I already found the RFC's (1067,1098) on it , but I'm
more looking for information how the agents work. Specifically I'm
trying to find out what goes on when a question is asked. Who gets it ?
Who will answer it ? Can anyone ask anyone ? etc.etc.

If anyone has online information on this please e-mail it to me or
tell me where to find it.
Any other remarks, comments hints etc are very welcome.

Thanks,


-- 
Marten Terpstra                                  National Institute for Nuclear
Internet : terpstra@nikhef.nl 		                and High Energy Physics
Oldie-net: {....}mcsun!nikhefh!terpstra	      (NIKHEF-H), PO Box 41882, 1009 DB
Bitnet   : terpstra%nikhef.nl@hasara5.bitnet         Amsterdam, The Netherlands

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      2 Nov 89 15:10:29 GMT
From:      wallis@wsucsa.uucp
To:        comp.protocols.tcp-ip
Subject:   HELP with CMU TCP/IP


	Dear Netlanders:

	Does anyone out there in Netland use CMU TCP/IP for VAX/VMS for 
Internet networking.  I am looking for tips on NAMSRV and domain servers.
(one particular problem is suffix addition to local names, which should work
but does not seem to).

Thanks for your patience and time.  

			Tom Wallis

-- 
-------------------------------------------------------------------------------
Thomas Wallis                          BITNET: WALLIS@TWSUVAX
System Manager, Computer Science Dept. BITNET: TWWALLIS@TWSUVM
Wichita State University               UUCP: uunet!ncrlnk!ncrwic!wsucsa!wallis
Wichita, Ks.  67208 

DISCLAIMER: The opinions expressed here are my own, and do not reflect the
views of the Computer Science Department or Wichita State University.
-------------------------------------------------------------------------------

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      2 Nov 89 16:26:03 GMT
From:      brian@hfh.edu (Brian A. Wolfe)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP for Data General

I'm posting this for a friend, please email responses
to daveh@hfh.edu

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

Does anyone know of vendors that have TCP/IP packages 
for Data General AOS/VS computers? Something that
is reasonably fast (100kbytes/sec) and supports 
telnet, ftp and Berkeley Socket programming would be
desirable.

Thanks.

-- 
Brian Wolfe            Internet: brian@hfh.edu  BITNET: USERW18Y@UMICHUM
Systems Analyst        UUCP:     {rutgers,itivax,uunet}!sharkey!hfhrv!baw
Henry Ford Hospital    Voice:    (313)-876-7461
Detroit MI 48202       FAX:      (313)-875-0315

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      2 Nov 89 16:38:17 GMT
From:      ray3rd@ssc-vax.UUCP (Ray E. Saddler III)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet cabling book

In article <923@sunic.sunet.se>, bygg@sunic.sunet.se (Johnny Eriksson) writes:
> In article <8910311903.AA03243@ucbvax.Berkeley.EDU> dave@CITI.UMICH.EDU
>   (Dave Bachmann) writes:
> > A book just came out called "Keeping the Link" that covers all sorts of
> > issues on Ethernet.  Very detailed.
> 
> Sounds interesting.  You don't by any chance have any more information
> about it, such as ISBN number or name of author?

Keeping the link: Ethernet installation and management, 1988, 366pp
Publishers: McGraw-Hill
ISBN/ISSN:  0070463026
Subjects:   ETHERNET / Local area networks / Software (computers) /
            Hardware (computers) / Network management / Management
	    planning / Program debugging / Maintenance

ABSTRACT: Provides coverage of installation and continuous
maintenance of an Ethernet network, including hardware, software,


-- 
Ray E. Saddler III                 UseNet            ___ ___ ___ ___     ___
CAD System/Network Admin  uw-beaver!ssc-vax!ray3rd  /__//  //__  /  /\ //  _
P.O. Box 3999 m.s. 3R-05          PhoneNet         /__//__//__ _/_ /  //__/
Seattle, WA.  98124  USA      +1 206-657-2824      Missile Systems Division 

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      2 Nov 89 17:21:37 GMT
From:      moline@TRWIND.TRW.COM
To:        comp.protocols.tcp-ip
Subject:   tcp reference

here information about the tcp/ip book:

	Nemzow, Martin A.
	Keeping the link: ETHERNET Installation & Maintenance
	McGraw-Hill, 1988
	$39.95

i have no idea about this reference. i'm trying to locate a copy now.
anybody have a copy?

Daniel Molinelli
TRW Information Networks Division
INTERnet:	moline@trwind.trw.com
	

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      2 Nov 89 17:48:58 GMT
From:      brian@ucsd.Edu (Brian Kantor)
To:        news.software.nntp,comp.protocols.tcp-ip
Subject:   Suggested NNTP enhancements for user access control

Several people have sent me suggestions for enhancements to the NNTP
specification.  The NNTP BOF at InterOp didn't really happen, but I did
speak to a few people there about some of these ideas.

Some of the suggestions were for new features for retrieval (by
keywords, author, etc.).  I'd like to write about that some other time.

This note is about access control, primarily on user identification
and authentication.

My concept is to allow each site to implement the user news access
security that it wants.  In order to do that, what I've been trying to
dream up is a few simple non-restrictive additions to the NNTP
specification that would be flexible enough to accomodate a wide range
of security and identification schemes.

So what I propose as the distillation of the suggestions I've received
is:

We add a USER and PASS commands to the server's command list, each of
which has an unspecified parameter(s) field.

We add new response codes (with optional parameters)
	4xx  Insufficient user privilege
	3xx  [<keyfield>] send password
	3yy  [<keyfield>] do further authorization stuff
	2xx  [<keyfield>] user authorized

For example:
(> is from client, < is from server; don't believe the numbers)
<200 ucsd.edu NNTP service ready
>GROUP ucsd.secretstuff
 <488 insufficient user authorization
>USER <wombat,mohawk>
 <380 <l!1k3,2jh45> are your encryption keys
>PASS <OIhKJkhu898BY>
 <250 authorization accepted
>GROUP ucsd.secretstuff
etc

The idea is that the USER command can be required/supplied at any time,
and will return to the client
	a) a 2xx if you just believe it (e.g., for statistics gathering)
	b) a 3xx if a password is required for authentication
	c) a 3xx with encryption parameters if using crypto passwords
and of course any of the parameter fields can contain multiple
parameters (typically separated by commas).

In this way a site can demand user authentication as it may require; the
'do further' response can even be used to tell a client to go consult
a Kerberos server for tickets, or some crypto server if you want to have
news transferred in encrypted form.

Additionally, there'd be a NEWUSER command which would just return a
unique string (or an error code if not allowed).  It would be used by
news servers when there is no user-level access restriction but it is
desired to maintain user-specific data, such as readership measurement
and/or subscription information (as is kept in the current .newsrc).
This could be valuable when you have a bunch of Macs and PC reading news,
since those kinds of machines usually don't have any concept of logins,
but could maintain the userid string supplied at first connection.

In a vanilla Unix environment, the USER and PASS commands would probably
work just as those in the FTP do.  More or less security is a
site-specific implementation issue; I'm only trying to add enough to the
NNTP to allow people to do the things they want to do.

Another new command that has been suggested was
	CRYPTO [<parameters>]
which would instruct the news server that the client was expecting all
further transactions to be conducted in some encrypted way as specified
by the [optional] parameters.

Finally, I see adding two new values to the herald; right now there are
	200 sitename, posting ok
	201 sitename, no posting
and I would add
	20x sitename, user authorization required for commands
	20y sitename, newsfeed access only for you
or perhaps the right thing to do is to flush the '201' and replace it
with
	200 sitename <access keywords>
where <access keywords> are
	POST, XFER, USER, READ, PASS, etc
that would form a list of what access privileges this connection will
be allowed or demand.  It might be smart to keep these keywords unique
in their first letters to simplify parsing.  I suppose some really nifty
scheme of couples could be made:
	<:XFER;USER:XFER,READ;PASS:XFER,READ,POST>
(in this scenario, anyone can XFER, you have to specify a USER to read
articles, and you'd have to verify the USER with a PASSword in order to
post articles).  Probably this is too elaborate.

Comments on any of this stuff?
	- Brian

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      2 Nov 89 17:52:20 GMT
From:      gds@oahu.cs.ucla.edu (Greg Skinner)
To:        comp.protocols.tcp-ip
Subject:   Re: Lifetime of routes added by redirects

This is a protocol I once developed to address the "redirect" problem.

When the system boots, if the system is attached to broadcast
networks, it simply broadcasts for a gateway.  Once having found one,
that gateway becomes "default".  If the system isn't attached to a
broadcast network, it checks a (small) list of (likely) available
gateways (back then, it tried hosts on the same PSN), and makes the
default gateway the first one to respond.

There is a periodic message (like a ping) sent to the default, and
other gateways that have been installed through redirects.  (Note:
does not scale!  The messages should be very short and be sent with
exponential backoff.  Actually, I wish I'd thought of using lack of
ACK's on a TCP, but I had to consider the situation where I didn't
have ACK's to look for, e.g. with UDP.)  If no response is received
from the gateway after a timeout, the gateway is marked "dead" and
deleted from the table.  Note that the default gateway can be marked
dead as well, in which case the initial location protocol must be
restarted.

If I am getting redirects for my destination telling me to use another
gateway, I replace the old gateway with the new one.

I thought about using timers and aging some of the routes, but I
couldn't think of a good timeout period.  I came to the conclusion
back then that a route should be considered "good" until some higher
authority tells me that it isn't.

Personally, I don't like redirects much.  One thought is that if a
host is receiving redirects, then it could be considered a "peer" of
the gateway (ie. the gateway and host share the same set of reachable
networks through gateways attached to their joint local net).  This
leads me to believe that the host perhaps ought to receive routing
updates from this set of attached gateways, rather than redirects.
However there was (is?) strong opposition to including "hosts" as
targets of routing updates, because it increases the amount of traffic
sent on the local net, and the "host" isn't "routing" (ie. forwarding)
packets.

I recall this topic generated lots of heat the last time it was
raised.

--gregbo

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      2 Nov 89 17:59:49 GMT
From:      barns@GATEWAY.MITRE.ORG
To:        comp.protocols.tcp-ip
Subject:   Re: Pilot Project: Hosts Table To Be Available Over Internet

Aside from pragmatic concerns about host-table-only mailers, I think
there are other reasons why DCA cannot drop the host table completely
at the present stage of DNS implementation.

There appears to be an incompatibility between the DNS as it is
currently specified and implemented and the required operational
capabilities formally established by at least one military command.
Resolution requires either some software work or a change in the
requirement.  Both possibilities are plausible, but at this instant I
don't think there is any action in the works on either one.  In the
meantime, having a host table to fall back on makes the network service
relatively fail-soft under this particular scenario, should it ever
become real.

I'm not stating the specific problem here because there's a tiny but
nonzero chance that someone in the Pentagon would decide that it ought
to be classified.  I hope to get some assurances soon that this won't
happen, but for the moment, better safe than sorry.  The software work
I referred to is very simple in principle and would be upward
compatible and interoperable with what now exists; however, it may
bring to the surface some deficiencies in lower layer implementations,
thus creating a ripple effect of little fixes.  This would vary from
system to system.  If you have complete sources for everything in your
system and you are a skillful hacker, you could probably get healthy with
one or two days of work.

A different line of attack would be to limit who can get a host table.
There has been some off-the-cuff discussion of schemes for biasing the
distribution process to discourage its use, but as far as I know, this
is only coffee-room talk.  (One example of such a scheme is to require
a login or password to get to the master copy.  Many other schemes are
possible as well.)

Bill Barns / barns@gateway.mitre.org

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      Thu, 02 Nov 89 15:00:36 +0200
From:      Benzi mizrahi <VSBENZI%WEIZMANN.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@sri-nic.arpa
Subject:   TN3270 for HP
Hello all

 Can any one tell me please if there is public domain TN3270 for HP
 machines, and how can it be retrieved. (we can't use FTP to retrieve
 files from the Internet).
 Thanx in advance, Benzi
-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      2 Nov 89 18:42:27 GMT
From:      alexm@videovax.tv.tek.com (Alex Mitaru)
To:        comp.os.os9,comp.protocols.tcp-ip
Subject:   TCP/IP for os9 anyone?


  Does anyone know of any implementation of TCP/IP running under os9 ?
  Does anyone know of any sources of a TCP/IP implementation (public domain
  or not) that could be easily ported to an os9 environment ?

  Thank you, I would appreciate e-mail since I don't read these newsgroups.

  Alexandru Mitaru

  alexm@videovax.tv.tek.com

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      2 Nov 89 19:01:28 GMT
From:      geoff@USAFA.AF.MIL (Capt Geoff Mulligan)
To:        comp.protocols.tcp-ip
Subject:   Where can i get a POP3 server for 4.3 BSD UNIX ?

I would be very interested in looking at the code!

	geoff

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      2 Nov 89 19:30:54 GMT
From:      castor!ccjoan@ucdavis.ucdavis.edu  (Joan Gargano)
To:        tcp-ip@NIC.DDN.MIL
Subject:   Re: Where can i get a POP3 server for 4.3 BSD UNIX ?
In article <3469@puff.cs.wisc.edu> tannenba@garfield.cs.wisc.edu (Todd Tannenbaum) writes:
 
>I am trying to locate a POP3 (Post Office Protocol ver 3) server that will
>run on 4.3 BSD UNIX.

A POP3 server for 4.3 BSD UNIX is available via anonymous ftp from
ucdavis.edu, 128.120.2.1, in the dist directory.

Joan Gargano * Univ. of Calif., Davis, Computing Services * (916) 752-2591
Internet   jcgargano@ucdavis.ucdavis.edu
BITNET     jcgargano@ucdavis
UUCP       {ucbvax, lll-crg}!ucdavis!jcgargano
-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      2 Nov 89 19:49:30 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Pilot Project: Hosts Table To Be Available Over Internet

In article <2546@ucsfcca.ucsf.edu>, jst@cca.ucsf.edu (Joe Stong) writes:
> How would this solution be:  instead of transferring host tables,
> have a local site WITH the resolver routines make the gethostbyname()
> function availiable via telnet?  I wrote a little server that gets
> activated by inetd,...
> 	Joe Stong	jst@cca.ucsf.edu

How does this program, presumably run like `pgm target server` differ
from `nslookup target server`?  I just tried 
`nslookup okeefe.berkeley.edu ucbvax.berkeley.edu` from sgi.sgi.com,
and the right things happened over the intervening 5,000 miles

I assume that a version of nslookup is with the rest of the BSD source
on uunet, and on the unlisensed, network source tape from Berkeley.


Vernon Schryver
Silicon Graphics
vjs@sgi.com

(Yes, 5,000 miles.  Internet geodesics are not Euclidean great circles.
Perhaps something to do with black holes and gravitational lenses.)

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      2 Nov 89 19:59:25 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP for Data General

In article <1989Nov2.162603.10265@hfh.edu>, brian@hfh.edu (Brian A. Wolfe) writes:
> ...
> ....Something that
> is reasonably fast (100kbytes/sec) and supports 
> telnet, ftp and Berkeley Socket programming would be
> desirable.

I do not intend any insult to anyone or any machine, but "reasonably fast"
process-to-process TCP over ethernet in late 1989 is more like >900KBytes/sec.
Well, maybe "reasonably" means only >500KB/s.
I've been told even PC's get >>100KB/s.

Vernon Schryver
Silicon Graphics
vjs@sgi.com

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      2 Nov 89 20:54:22 GMT
From:      702WFG@SCRVMSYS.BITNET (bill gunshannon)
To:        comp.protocols.tcp-ip
Subject:   3C523

Has anyone had any experiences using the 3COM 3C523 ethernet card??
I just installed 2 of them, 1 in a PS2 Model 70 and the other in a
PS2 Model 50.  I tried 2 different TCPIP packages: PC NFS and another
that uses the FTP Packet Drivers.  The result was the same in all cases.
The machine just hangs.  Dead in the water.  Can't even do the old
ctl-alt-del.  Have to shut it off and bring it back up cold.

Anybody got any suggestions to offer???

                                          bill gunshannon
                                       702WFG@SCRVMSYS.BITNET

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      2 Nov 89 22:26:30 GMT
From:      hashem@mars.jpl.nasa.gov (Basil Hashem)
To:        comp.protocols.tcp-ip
Subject:   Multicasting on TCP/IP

In my terms, multicasting is the ability to distribute data packets
to a *selected* group of addresses on a network.

From my readings about TCP/IP, there seems to be only two distribution
mechanisms provided:  broadcast and point-to-point.

With consideration for network/CPU (over)loading, what is the most 
efficient way to achieve the functionality of a multicast on a
TCP/IP network?

Thanks for the response,

"Be X ellent to each other"
Basil Hashem                                   hashem@mars.jpl.nasa.gov
Jet Propulsion Laboratory                      (818)354-2936

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      2 Nov 89 22:59:14 GMT
From:      dan@ccnysci.UUCP (Dan Schlitt)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Comments wanted on ethernet book

Is "Designing and Implementing Ethernet Networks", 2nd Edition, by
Bill Hancock a worthwhile book to own?  Or is there some better book
covering the same material.  There are limits on the number of $30
books I can buy.

Thanks for the info.
-- 
Dan Schlitt                        Manager, Science Division Computer Facility
dan@sci.ccny.cuny.edu              City College of New York
dan@ccnysci.uucp                   New York, NY 10031
dan@ccnysci.bitnet                 (212)690-6868

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 89 00:38:50 GMT
From:      USERBAC@SFU.BITNET ("Bruce A. Cowan")
To:        comp.protocols.tcp-ip
Subject:   RFC 1116 Telnet Linemode Option

Is anyone out there actually implementing RFC 1116, in particular, a server
implementation?  I have an almost-completed client implementation and nothing
to test against.  Perhaps you could allow me access to your machine via the
Internet, or, better yet, you could give me a server implementation which
will run on UNIX V.3 (386/ix in particular).

Bruce A. Cowan        412-2150 West Broadway, Vancouver, BC, V6K 4L9
KEA Systems Ltd.      voice: (604) 732-7411  fax: (604) 732-0715
bruce_cowan@CC.SFU.CA

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 89 03:34:57 GMT
From:      RAF@CU.NIH.GOV ("Roger Fajman")
To:        comp.protocols.tcp-ip
Subject:   Re:  BITNET -- Internet capabilities

> BITNET-style file transfer is easily accomplished using FTP.  Many FTP
> servers support anonymous FTP, which generally restricts the user to a
> subset of the file system (on Unix it's generally a particular subtree, on
> TOPS-20 it's world-accessible directories).  Sender-initiated file transfer
> is done by using FTP to put the file into a directory to which anonymous
> FTP has write access, then sending mail to the recipient telling him the
> file's name.

That's better than nothing, but what percentage of Internet hosts
actually permit anonymous FTP users to put files?

Here's some nice things that I can do with file transfer on BITNET:

(1) Subscribe to a file or a package of files.  When the file is
changed, it automatically gets sent to me.  This is one of LISTSERV's
capabilities.

(2) Instead of having the file sent to me when it changes, I can get a
mail notification.  This is certainly possible on the Internet, but I'm
not aware of it being done in an automatic way.

(3) Have a file sent to many recipients.  This is another LISTSERV
capability, called Distribute.  It also cuts down on network traffic by
transmitting only one copy of the file between LISTSERV servers, which
then transmit it to nearby recipients.

P.S. - I do know about BFTP.  And I realize that the concept of
"nearby" is harder to define in the Internet, because of it's much more
dynamic topology and the fact that that sort of information isn't
generally available to hosts.

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      Fri, 03 Nov 89 11:16:34 EST
From:      bill gunshannon <702WFG%SCRVMSYS.BITNET@CORNELLC.cit.cornell.edu>
To:        tcp-ip@nic.ddn.mil
Subject:   PCSA
I have a faction here at the school who are pushing to get PCSA brought
in.  Does anyone know anything at all about this???  Will it adversely
affect the rest of my network??? I assume it is DECNET based but other
than that I no next to nothing about it.
I personally would rather not have it unless someone out there knows
of some reason why it could be the best thing since sliced bread.
I would rather keep my network as close to pure TCPIP as possible but
unfortunately I don't get to make the decisions, I only get to live with
them. :-(

                                          bill gunshannon
                                       702WFG@SCRVMSYS.BITNET

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 89 07:12:09 GMT
From:      johncw@gpu.utcs.utoronto.ca (Johnny Chee-Wah)
To:        comp.protocols.tcp-ip,comp.os.vms
Subject:   LAT TCP terminal servers

Currently interested in replacing a bunch of LAT
DECservers with LAT/TCP terminal servers. Have looked
at Hughes and Able products and would like to know
what else is available in the market.

Would appreciate any information.

johncw@gpu.utcs.utoronto.ca

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 89 07:16:57 GMT
From:      dell@Apple.COM (Thomas E. Dell)
To:        comp.protocols.tcp-ip
Subject:   Top level .int domain

There exists a top level .int domain, which I stumbled upon while
perusing DOMAINS.TXT - does anyone have any background on this INT-DOM?

This is unusual as I understood that the NIC was only planning to
create toplevel domains for countries, and then only for the standard
two-letter ISO abbreviation.

My suspicion is this is X.400 related. 

Mail to the administrative contact was not answered. The only motive
here is curiosity. Replies will be summarized for the common good.

                               Thomas Dell

dell@apple.com | My views should not be construed as Apple's.

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 89 07:58:32 GMT
From:      af%sei.ucl.ac.be@CUNYVM.CUNY.EDU ("Alain FONTAINE ", Postmaster - NAD)
To:        comp.protocols.tcp-ip
Subject:   Re: (none)

On Mon, 30 Oct 89 16:57:06 GMT Randal Schwartz said:
>However, modifying the proposal such that a "DIR" fails but "CWD"
>succeeds is a little better.  Then I at least have to work a bit at
>getting the user names. :-)

If you like security that much, you could also make CWD succeed all the time.
Files to non-existent userids would simply disappear into the friendly
local black hole.        :-)        /AF

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 89 09:55:43 GMT
From:      MKL@NIC.DDN.MIL (Mark Lottor)
To:        comp.protocols.tcp-ip
Subject:   Re: Top level .int domain

INT is a domain for international organizations.  It was created among
much debate with pressure from people who misunderstand the domain
system and the top-level organization.  A certain european
organization felt that registering under ORG implied ORG.US so they
wanted a different domain to go under.  Many people still have this
incorrect view of the top-level naming structure.  The people in INT
today certainly won't like using OSI protocols and naming conventions.
-------

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 89 15:50:00 CDT
From:      "Rick Watson" <ccaw001@utadnx.cc.utexas.edu>
To:        "tcp-ip" <tcp-ip@NIC.DDN.MIL>
Subject:   Telnet library ?
Some time ago, someone posted a library of routines to make
telnet connections.  Anyone know where it is available?

Rick Watson 
The University of Texas Computation Center, 512/471-3241
   internet: watson@utadnx.cc.utexas.edu     bitnet: watson@utadnx
   uucp:     ...!cs.utexas.edu!ut-emx!rick   span:   utspan::utadnx::watson



-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      Fri, 03 Nov 89 11:02:44 SET
From:      ESC1814%ESOC.BITNET@CUNYVM.CUNY.EDU
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: TCP/IP for Data General

> can get > 900 KBytes/s from TCP over Ethernet

Are we talking Bytes or Bits per second, and if it is bytes/sec
whose TCP are you using? Where can I get it?

I've noticed that PC's have pretty naff performance when talking
to kit such as Suns. Putting to the PC seems much slower than getting
from. Anyone any ideas on how to improve it?

Dave Stafford
Comms. Eng
European Space Agency
Darmstadt, W. Germany                     : Standard Disclaimer .. blah blah..
-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 89 12:25:13 GMT
From:      randall@uvaarpa.virginia.edu (Randall Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: 3C523

I recently tried to use NCSA Telnet/ftp in an IBM PS/2 55SX
with a 3COM 3C523 Ethernet card.  The combination locked up
the system every time so severely that the only recourse was
a cold reboot.  The same system does use the Ethernet card fine
with RAF software to connect to our VMS cluster, so I suspect the
NCSA driver for the 3C523 rather than the card itself.

By the way, if anyone knows of freely distributable software that
will let me have telnet/ftp on the combination of 55SX and 3C523,
I'd love to hear from you.

  Ran

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      Fri, 03 Nov 89 11:47:25 SET
From:      Dave Stafford <ESC1814%ESOC.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   FTP to Vax

Help,

During some FTP testing recently we ran into a problem sending largish files
(about 1 MByte) to several Vaxes (VMS 5.1-1 on an 8530)  using UCX V1.0 TCP/IP
software. There was no problems sending smaller files, but the transcript of
the session below is representative of the attempts on all of our Vaxes.

ftp> put skascii
200, PORT command okay.
150 Opening data connection for skascii (131.176.51.20,1076)
226 Transfer complete.
local: skascii remote: skascii
1000 bytes sent in 0.04 seconds (24 Kbytes/s)
ftp> put smascii
200, PORT command okay.
150 Opening data connection for smascii (131.176.51.20,1077)
netout: Bad file number
421 Service not available, remote server has closed connection
local: smascii remote: smascii
1000000 bytes sent in 10 seconds (95 Kbytes/s)
ftp> open ersrt
Connected to ersrt.

At this point the program hangs, and the FTP daemon on the Vax crashes.
The important bit here is that the FTP connect is comming from a Sun 3/160
running Os 4.0.3. Also successful transfer to the Vax has been made using other
implementations of TCP/IP eg. on a Gould.

So we reckon its the Sun, but does anyone know for certain?

Dave Stafford
European Space Operations Centre
Darmstadt, W. Germany
-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 89 12:50:38 GMT
From:      Chris.Rusbridge@levels.sait.edu.au (Chris Rusbridge)
To:        comp.protocols.tcp-ip
Subject:   Re:  BITNET -- Internet capabilities

In article <8910282012.AA20961@mimsy.UMD.EDU>, chris@CS.UMD.EDU (Chris 
Torek) writes:
> 	% ftp remotehost.biguniv.edu
> 	<greeting stuff>
> 	User: anonymous
> 	Password: me@here
> 	<restriction stuff>
> 	type image
> 	<image mode OK>
> 	put local-file incoming/remote-file
> 	<file goes across>
> 	quit
> 
> Now all we need is to write it up as an RFC (changing the `put
> local-file incoming/remote-file' sequence to a new `give' command, so
> that the `incoming/' can go away), and write a front end called `give'
> or whatever that does the above automatically.  

But there is a lot of unnecessary stuff the user has to know in the 
above: the username and password to be used, etc. They also _have_ to 
be able to login to this anonymous account. I'd rather that did not 
happen. Surely it's better to wrap up the whole package above like 
this:

	% sendfile local-file [-X rem-file] remuser@remhost.biguniv.edu

[where the -X stands for your choice of optional parameter allowing 
the sender to give the file a new name at the remote host.]

This sends the file to the remote spool directory, where remuser is
notified, and the file is stored for n days. 

That's how the ACSnet system works. There's a fetchfile version as 
well; works to get files from a remote site like anonymous ftp, but 
again you don't have to login.

Chris Rusbridge

Academic Computing Service Manager, SA Institute of Technology
ACSnet:		Chris.Rusbridge@levels.sait.oz [.au]
InfoPSI:	Chris.Rusbridge@sait.edu.au	(DTE 505282622004)
Phone: 		+61 8 343 3098  Fax: +61 8 349 6939  
Post: 		The Levels, SA 5095 Australia

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 89 13:00:44 GMT
From:      dricejb@drilex.UUCP (Craig Jackson drilex1)
To:        comp.protocols.tcp-ip
Subject:   Re: Sender-initiated file transfer and FTP

In article <9593@marque.mu.edu> doug@marque.mu.edu (Douglas Harris) writes:
>As has been mentioned, uuto/uupick implement over uucp a facility
>similar to the BITNET file transfer.  Uucp itself can of course be
>implemented over tcp, provided the machines at each end are satisifed
>regarding machine names.  Or of course uuto, which is only a shell
>script, could perform ftp "on its own".  The name conflict problem
>is handled by creating directories as needed; so things sent to me
>from various machines go to /usr/spool/uucppublic/receive/doug/MACHINE/...
>The uuto script also arranges to have mail sent to the recipient when
>the file arrives, which could certainly be handled with SMTP.

This is definitely true.  Actually uucp in general is a much closer
analogue to the RSCS protocols than to the services commonly available
over TCP/IP.  (Uucp is used over TCP/IP, but is really available only
to people with real Berkeley uucp, as far as I know.  I really don't know
if any commonly shipped versions of HDB have it, though.)

The remaining issue would be the security of the received files.  At least
under VM, only the recipient (or some sort of super-user, of course) can
examine the contents of the received files.  I suppose that FTP could
be told to store a file under the uid of the recipient, but not without
changes to the protocol (I think).  Also, that would create other problems
of quotas, disk charges, etc.  On VM, the spool area is separate; it can
be charged for or not at a site's discretion.
-- 
Craig Jackson
dricejb@drilex.dri.mgh.com
{bbn,ll-xn,axiom,redsox,atexnet,ka3ovk}!drilex!{dricej,dricejb}

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 89 13:31:48 GMT
From:      mep@AQUA.WHOI.EDU (Michael E. Pare)
To:        comp.protocols.tcp-ip
Subject:   Re:  3C523

We have several of them installed and use them with the NCSA_Telnet packet
driver and Novell.  The first question always comes down to whether or
not the software supports this board!?  Also, have you run the diagnostics
to ensure the software setup for the interrupts and I/O addressing has
been done properly?  If any one of these three issues is not right the
machine will hang as soon as you try to initiate the software.

Michael Pare, P.Eng.
Woods Hole Oceanographic Institution
Woods Hole, MA
mpare@aqua.whoi.edu

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      Fri, 03 Nov 89 18:53:24 EST
From:      Ravi Sinnarajah <RAVI%UMUC.BITNET@CORNELLC.cit.cornell.edu>
To:        "TCP/IP" <tcp-ip@nic.ddn.mil>
Subject:   Request for pointers on snmp implementations

*Greetings*


I have been requested by our network administrator, to obtain the the
snmp software avialable as public domain packages, the ones implemented
by MIT, CMU and NYSERNET.  I would like to know, whether they can be
retrieved via 'anonymous' ftp from any sites, and if they can not be
retrieved, then whom I should contact.

Thank You so much in advance for any help and/or information you may
provide me in this regard.


Sincerely Yours,
/Ravi.



From  the   V I R T U A L   Desk  of  ...,

+--------------------------------------------------------------------+
| Ravi Sinnarajah                        CREN:     Ravi@Umuc.Bitnet  |
| VM Systems Programmer,                 Internet: Ravi@Umuc.Umd.Edu |
| Internet Hosts(local) Contact and,     Voicenet: (301) 985-7170    |
| BITNET(local) Postmaster                                           |
| Academic Computing                                                 |
|                                                                    |
|    US Mail: University of Maryland - University College (UMUC)     |
|             University Boulevard at Adelphi Road                   |
|             College Park, Maryland, MD 20742-1615, U.S.A           |
+--------------------------------------------------------------------+
-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 89 14:15:32 GMT
From:      ESC1814@ESOC.BITNET
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP for Data General


> can get > 900 KBytes/s from TCP over Ethernet

Are we talking Bytes or Bits per second, and if it is bytes/sec
whose TCP are you using? Where can I get it?

I've noticed that PC's have pretty naff performance when talking
to kit such as Suns. Putting to the PC seems much slower than getting
from. Anyone any ideas on how to improve it?

Dave Stafford
Comms. Eng
European Space Agency
Darmstadt, W. Germany                     : Standard Disclaimer .. blah blah..

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 89 14:30:35 GMT
From:      mailrus!wuarchive!cs.utexas.edu!samsung!usc!henry.jpl.nasa.gov!elroy.jpl.nasa.gov!jpl-devvax!cyamamot@tut.cis.ohio-state.edu  (Cliff Yamamoto)
To:        tcp-ip@NIC.DDN.MIL
Subject:   Sun's silly TCP implementation
Greetings.  We've got a problem which seems to be related to Sun's
implementation of TCP/IP.

We are currently using a Proteon P4200 router between two Sun 3/260s.  One
Sun has a ProNET-80 Token Ring interface board installed which connects to
the P4200.  I will call this Sun-A.  The other Sun has its ethernet port
attached to a multi-port transceiver.  I will call this Sun-B.  The P4200 is
also attached to this multi-port transceiver.

We are running performance benchmarks using TCP/IP to determine the
throughput of the P4200.  Our tests mainly deal with transmission of data
from Sun-A to Sun-B.  The results thus far seem to indicate the P4200
provides a throughput of 1.6 Megabits per second.

However, when running this same test from Sun-B to a third Sun attached to
the multi-port, we obtain 2.8 Mbps over Ethernet.  This seemed to indicate
a deficiency in the router.

Yet, when I attached a Sniffer to the multi-port, I noted that in the tests
using the P4200, each frame only contained 512 bytes of actual data.  This
doesn't correspond to the 1024 bytes of data per frame when conducting the
second test.

I must conclude that Sun's TCP will automatically send the smallest size
of data permissable (512 bytes) when sending data to a host not located on
the same network.  The P4200 *IS* listed as a gateway in the routing tables
of both Sun-A and Sun-B.

I would appreciate if anyone could confirm this fallacy. It is my understanding
that it is the router's responsibility to fragment frames when forwarding
data between two different physical networks.  In this case, it appears the
Sun is performing the fragmentation for the router.  Unfortunately, Sun
is using the smallest size permissable which severly limits our throughput
when using the router.

Also by using the Sniffer, is it possible to see if TCP is truly using MSS
with the router.  If MSS is not being used, can this condition in the Sun be
corrected or overriden somehow?  Thanks in advance for any insight provided!

Regards,
Cliff Yamamoto
-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 89 16:16:34 GMT
From:      702WFG@SCRVMSYS.BITNET (bill gunshannon)
To:        comp.protocols.tcp-ip
Subject:   PCSA

I have a faction here at the school who are pushing to get PCSA brought
in.  Does anyone know anything at all about this???  Will it adversely
affect the rest of my network??? I assume it is DECNET based but other
than that I no next to nothing about it.
I personally would rather not have it unless someone out there knows
of some reason why it could be the best thing since sliced bread.
I would rather keep my network as close to pure TCPIP as possible but
unfortunately I don't get to make the decisions, I only get to live with
them. :-(

                                          bill gunshannon
                                       702WFG@SCRVMSYS.BITNET

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 89 16:35:00 GMT
From:      cs.utexas.edu!samsung!usc!trwind!venice!gay@tut.cis.ohio-state.edu  (lance gay)
To:        tcp-ip@NIC.DDN.MIL
Subject:   Problems with tn3270
I have built and am running version 4.1.1 of tn3270 on my Ultrix 3.0 VAX.
I got the software from UCBARPA.BERKELEY.EDU.  My problem is that after 
establishing a tn3270 session, the software aborts with a "Short count received
from host!" error message.

I have looked at the tn3270 source code but am none the wiser.  Could anyone
out there give me a hint about this error?  Do you think it is a problem on the
IBM end of the connection?

Lance Gay                                    Internet: gay@venice.sedd.trw.com
TRW Systems Engineering & Development Div.   Phone: 213-328-1892
Redondo Beach, CA  90278
-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 89 17:01:09 GMT
From:      nomann@rimfaxe.diku.dk (Ole Nomann Thomsen)
To:        comp.protocols.tcp-ip
Subject:   Timeout for telnet (Excelan / Xenix386) ??

Can anybody tell me if it is possible to make idle telnet connections
time out. (eg. after one hour). The system is (Excelan / Xenix386).

E-mail: nomann@rimfaxe.diku.dk (if it works - else nomann@diku.dk)

No disclaimer. I DO NOT like disclaimers. Definitely.

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 89 17:04:41 GMT
From:      ESC1814@ESOC.BITNET (Dave Stafford)
To:        comp.protocols.tcp-ip
Subject:   FTP to Vax


Help,

During some FTP testing recently we ran into a problem sending largish files
(about 1 MByte) to several Vaxes (VMS 5.1-1 on an 8530)  using UCX V1.0 TCP/IP
software. There was no problems sending smaller files, but the transcript of
the session below is representative of the attempts on all of our Vaxes.

ftp> put skascii
200, PORT command okay.
150 Opening data connection for skascii (131.176.51.20,1076)
226 Transfer complete.
local: skascii remote: skascii
1000 bytes sent in 0.04 seconds (24 Kbytes/s)
ftp> put smascii
200, PORT command okay.
150 Opening data connection for smascii (131.176.51.20,1077)
netout: Bad file number
421 Service not available, remote server has closed connection
local: smascii remote: smascii
1000000 bytes sent in 10 seconds (95 Kbytes/s)
ftp> open ersrt
Connected to ersrt.

At this point the program hangs, and the FTP daemon on the Vax crashes.
The important bit here is that the FTP connect is comming from a Sun 3/160
running Os 4.0.3. Also successful transfer to the Vax has been made using other
implementations of TCP/IP eg. on a Gould.

So we reckon its the Sun, but does anyone know for certain?

Dave Stafford
European Space Operations Centre
Darmstadt, W. Germany

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 89 17:15:13 GMT
From:      burdick@hpindda.HP.COM (Matt Burdick)
To:        comp.protocols.tcp-ip
Subject:   Re: TN3270 for HP

> Can any one tell me please if there is public domain TN3270 for HP
> machines, and how can it be retrieved. (we can't use FTP to retrieve
> files from the Internet).

I have a copy of tn3270 version 4.4.1 that will work for the series 300's.
I don't know if it would work for s800's, but it should only take minor
tweaking if anything.

I will mail the sources to Benzi.  If anyone else want it, please contact
me by email.

							-matt
-- 
Matt Burdick                    | Hewlett-Packard
burdick%hpda@hplabs.hp.com      | Technical Communications Lab  (IND/TCL)

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 89 17:18:08 GMT
From:      postel@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Top level .int domain

Thomas E. Dell:

The "INT" top level domain was created for international organization
(for example, CERN) that somehow could not accept the idea that "ORG"
could be used for organizations outside the US.

--jon.

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 89 17:24:32 GMT
From:      rick@UUNET.UU.NET (Rick Adams)
To:        comp.protocols.tcp-ip
Subject:   Re: Pilot Project: Hosts Table To Be Available Over Internet

It is an absolute sham to pretend that the 5% (lets be charitable) of
the internet hosts listed in the host table represent a useful number
of hosts to the MILNET users.

You do them a grave disservice by pretending that they can access other
internet sites in a normal matter.

If MILNET wants to stay in the dark, thats their business. However,
when you pretend that they can interoperate with the rest of the
Internet, you are wasting everyone's time.

Let's stop rationalizing things with the pathetic "operational needs"
refrain. Sites that are still using static host tables are not capable
of properly interoperating with the rest of the Internet. Let's stop
pretending otherwise.

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 89 17:57:03 GMT
From:      mentor.cc.purdue.edu!dls@purdue.edu  (David L Stevens)
To:        tcp-ip@NIC.DDN.MIL
Subject:   Re: Sun's silly TCP implementation

	This code comes from Berkeley, not Sun, and the reason making nonlocal
packets relatively small is a good idea is that it's less costly when a packet
is lost to resend a single 512 packet than to resend N fragments. Further,
since fragments cannot be selectively acknowledged, a relatively small % loss
can result in virtually every fragmented packet being lost. There was a paper
a few years back on this (from memory: "Fragmentation Considered Harmful in
Best Effort Delivery Networks"); I'm pretty sure one or more of the authors
reads this group, so maybe one will post the real reference.
	If the two nets involved are subnets, you can avoid this by using the
"subnetsarelocal" option. It's an ifdef ("SUBNETSARELOCAL") and a run-time
settable (via adb -k -w) variable in 4.3T and maybe earlier. If you're
binary-only and your objects did not have the ifdef compiled in, you're out
of luck, short of merging the current network sources with the rest of your
objects.
	If the net numbers are distinct, the Berkeley code strictly enforces
the 512 MSS through a gateway.
-- 
					+-DLS  (dls@mentor.cc.purdue.edu)
-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 89 18:04:02 GMT
From:      scw@ollie.SEAS.UCLA.EDU
To:        comp.protocols.tcp-ip
Subject:   Looking for traceroute

I'm looking for a pointer to either the source_to or author_of a program
for tracing routes taken by a packet (preferably a ICMP ECHO packet), rather
than reinvent the wheel.  Please reply via e-mail, I'll summarize to the net.
<scw>
-----
Stephen C. Woods; UCLA SEASNET; 2567 BH;LA CA 90024; (213)-825-8614
UUCP: ...!{ibmsupt,hao!cepu}!ollie}!scw ARPA:scw@{Ollie.,}SEAS.UCLA.EDU 

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 89 18:11:26 GMT
From:      gem.mps.ohio-state.edu!samsung!shadooby!mailrus!accuvax.nwu.edu!jln@tut.cis.ohio-state.edu  (John Norstad)
To:        tcp-ip@NIC.DDN.MIL
Subject:   Re: Where can i get a POP3 server for 4.3 BSD UNIX ?
In article <5794@ucdavis.ucdavis.edu> ccjoan@castor (Joan Gargano) writes:
>A POP3 server for 4.3 BSD UNIX is available via anonymous ftp from
>ucdavis.edu, 128.120.2.1, in the dist directory.

The POP server at ucdavis.edu is a POP2 server, not a POP3 server.

A POP3 server is available as part of the MH message handling system via
anonymous FTP from nigel.ee.udel.edu [128.175.2.18], in file
pub/mh-6.6.tar.Z.

MH is a very large system, of which the POP3 server is only a very small
part.  You have to do some fiddling to get it properly built and
installed.  Send me email if you would like details - I just finished
installing it on a SparcStation, and made some notes on the exact fiddling
I had to do.

John Norstad       Northwestern University     jln@acns.nwu.edu
-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 89 18:25:57 GMT
From:      greaves@maui.cs.ucla.edu (Mark Greaves)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet cabling book

While we're on the topic of Ethernet books, I thought I'd put in my
$.02: netlanders might want to take a look at DEC's Ethernet
Installation Guide.  It's a two volume set, with each volume is
spiral-bound and about 50 pages.  Volume 1 covers Ethernet site survey
and physical configuration techniques; Volume 2 is about actual
installation and testing.  They are *very* detailed about what they
cover, but a few caveats are in order:

	1.  The books only cover standard (thick) Ethernet and enough
		fiber-optic technique to work with DEC's fiber-optic
		Ethernet products (e.g. fiber-optic repeaters).  For
		Thinnet or twisted-pair, look elsewhere.

	2.  They are also exclusively concerned with DEC products
		(surprise!), but since their subject matter is
		physical design and installation, the lessons learned
		are pretty generally applicable.

	3.  There is no coverage of software or management issues.

I have found them to be useful in the past, both for writing up
contracts and for actually performing installations.  I had these
purchased when I was working for a small network installation company,
and I remeber the secretary saying that they were quite expensive.
So, before you invest in these you might ask your DEC salesperson to
let you look over a copy.  The DEC product numbers are EK-ETHV1-IN-003
and EK-ETHV2-IN-003.

I am in no way associated with DEC except as an owner of their
literature.

Mark Greaves

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 89 18:35:09 GMT
From:      gem.mps.ohio-state.edu!usc!merlin.usc.edu!girtab.usc.edu!cyamamot@tut.cis.ohio-state.edu  (Cliff Yamamoto)
To:        tcp-ip@NIC.DDN.MIL
Subject:   Re: Sun's silly TCP implementation
In article <4898@mentor.cc.purdue.edu> dls@mentor.cc.purdue.edu (David L Stevens) writes:
>
>	This code comes from Berkeley, not Sun, and the reason making nonlocal
>packets relatively small is a good idea is that it's less costly when a packet
>is lost to resend a single 512 packet than to resend N fragments.

I understand this reasoning.  However, when using a reliable network (such as
in our case using the ProNET-80), the probability of losing a packet is very
close to zero, thus retransmission rarely occurs.

>	If the net numbers are distinct, the Berkeley code strictly enforces
>the 512 MSS through a gateway.

I'd like to know which RFC describes this minimal MSS enforcement.  I have yet
to come across it!

>					+-DLS  (dls@mentor.cc.purdue.edu)

For those who have been following this topic thus far, I'd like to mention
that I have also run ftp tests while observing the Sniffer.  As expected,
when ftping thru the p4200 router, only 512 bytes of data per frame are
sent.  Using ftp between two Suns on the same multi-port via Ethernet results
in ftp sending 1024 bytes of data per frame.

Again, my understanding from the RFCs and Douglas Comer's book is that it is
the router's responsibility to fragment packets as necessary between two
dissimilar physical networks.  In our case, the Sun is doing the fragmenting
for the router.  Our local Sun rep. has not been too informative in this
matter.  Hopefully, someone out there knows something about this.

Regards,
Cliff Yamamoto

Jet Propulsion Labs.
4800 Oak Grove Drive
M/S 301-270X
Pasadena, Calif.  91109
(818) 354-1443
-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 89 19:10:22 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   RFC1063 possible deficiency

On reading RFC 1063 (IP MTU discovery options), it seems like a good idea,
but there's something missing.  There is no way to tell the other end
"your datagrams are frequently arriving fragmented, you should revise your
estimate of the MTU".  This crops up in several places.  For example, the
RFC warns against probing for MTU in response to fragmentation, because
it is the other end, not your end, that needs to revise its MTU estimate.

Actually, if the RFC's suggestions are followed on both ends, there is
one crude way of doing this.  The RFC does observe that an ICMP Time
Exceeded/Fragmentation Reassembly Timeout is the only message you can
get that indicates fragmentation of your datagrams.  So... deliberately
throw away one of the incoming fragments, resulting in an ICMP message
to the sender when reassembly of that datagram times out.  This seems
like a rather costly way of making the point, though.

Perhaps we need an Excessive Fragmentation Seen ICMP message?  Actually,
it might be better to have two:  Fragmentation Report, which says "of
the last M datagrams from you, N were fragmented", and Fragmentation
Report Request, which says "please send me a Fragmentation Report",
with an F.R. being sent either in response to an F.R.R. or when the
fragmentation of received datagrams seems excessive.  That way, the
mechanism can be used for both trouble reporting and link checking.

Has anybody ever investigated something like this?
-- 
A bit of tolerance is worth a  |     Henry Spencer at U of Toronto Zoology
megabyte of flaming.           | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 89 19:13:34 GMT
From:      mas@bridge2.ESD.3Com.COM (Mike Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: How do you string a thinnet?

In article <8910301951.AA28831@gaak.LCS.MIT.EDU> MAP@LCS.MIT.EDU (Michael A. Patton) writes:
>Date: 27 Oct 89 12:56:14 GMT
>From: eplrx7!mcneill@louie.udel.edu  (Keith McNeill)
>Subject: Re: How do you string a thinnet?
>To: tcp-ip@nic.ddn.mil
>
>Bernie Hoffstadt <cutter@cutsys.UUCP> asked:
>Now the $64k question: Is there a good reference for this kind of info.
>----------------

THE book -

ANSI/IEEE Standards for Local Area Networks:

   Carrier Sense Multiple Access with Collision Detection (CSMA/CD)
   Access Method and Physical Layer Specifications (with supplements)
   ISBN 1-55937-0130, SH12351 (1989)

   This includes 10Base2.  Anything else is second hand information.

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 89 19:17:13 GMT
From:      mentor.cc.purdue.edu!dls@purdue.edu  (David L Stevens)
To:        tcp-ip@NIC.DDN.MIL
Subject:   Re: Sun's silly TCP implementation

	I don't think it's optimal, either, and it's not in an RFC; it's an
engineering decision on the part of the Berkeley implementors. I agree with
their general reasoning because fragmentation (which the Sun is NOT doing) is
bad and avoiding it through choosing appropriate MSS's is. In other words,
if your reasoning is that Berkeley's implementation has a bug and that they
should rely on IP fragmentation to split long-haul packets, the consequence
is that your gain in throughput is a significant loss in response time and
increase in congestion for long haul nets. Since the long haul nets are
suffering more from congestion than local nets are suffering from lack of
throughput, I think they chose correctly.
	What you really want is a protocol or protocol extension that will
discover a maximal non-fragmenting value for the MSS, but of course, since
IP packet switches, the route and good MSS value may change during the course
of a connection.
	The problem is not trivial and quick fixes could make things worse,
which, of course, is why this solution and this problem are there.

	BTW, if the router throughput is what you want to measure, why not use
UDP or ICMP echo (ping)? You can make the packets the size you want without
worrying about TCP segmenting [not "fragmenting"] them at all.
-- 
					+-DLS  (dls@mentor.cc.purdue.edu)
-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 89 19:20:30 GMT
From:      scw@ollie.SEAS.UCLA.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for traceroute

Got it. (thanks gregbo).
Traceroute can be obtained from rtsg.ee.lbl.gov via anonymous FTP,
file is traceroute.tar.Z.  Author is Van Jacobson.  trace route requires
a kernel hack to run.
<scw>
-----
Stephen C. Woods; UCLA SEASNET; 2567 BH;LA CA 90024; (213)-825-8614
UUCP: ...!{ibmsupt,hao!cepu}!ollie}!scw ARPA:scw@{Ollie.,}SEAS.UCLA.EDU 

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 89 20:50:00 GMT
From:      ccaw001@UTADNX.CC.UTEXAS.EDU ("Rick Watson")
To:        comp.protocols.tcp-ip
Subject:   Telnet library ?

Some time ago, someone posted a library of routines to make
telnet connections.  Anyone know where it is available?

Rick Watson 
The University of Texas Computation Center, 512/471-3241
   internet: watson@utadnx.cc.utexas.edu     bitnet: watson@utadnx
   uucp:     ...!cs.utexas.edu!ut-emx!rick   span:   utspan::utadnx::watson

-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 89 20:52:40 GMT
From:      gem.mps.ohio-state.edu!usc!merlin.usc.edu!girtab.usc.edu!cyamamot@tut.cis.ohio-state.edu  (Cliff Yamamoto)
To:        tcp-ip@NIC.DDN.MIL
Subject:   Re: Sun's silly TCP implementation
In article <4900@mentor.cc.purdue.edu> dls@mentor.cc.purdue.edu (David L Stevens) writes:
>In other words,
>if your reasoning is that Berkeley's implementation has a bug and that they
>should rely on IP fragmentation to split long-haul packets, the consequence
>is that your gain in throughput is a significant loss in response time and
>increase in congestion for long haul nets. Since the long haul nets are
>suffering more from congestion than local nets are suffering from lack of
>throughput, I think they chose correctly.

I AM NOT disagreeing with you.  I realize this is a problem in *long haul*
nets.  However, in our application IN a *local* AND *isolated* net, we
require high throughput.  My only qualm with Sun's or Berkeley's implementation
is that this choice of using a small MSS is not user selectable.

>	BTW, if the router throughput is what you want to measure, why not use
>UDP or ICMP echo (ping)? You can make the packets the size you want without
>worrying about TCP segmenting [not "fragmenting"] them at all.
>
>					+-DLS  (dls@mentor.cc.purdue.edu)

I wish I could.  Our systems ALL run TCP and thus, this application must also
run TCP.  There is a debate going on, whether or not to use TCP or some
modified form of it.  However, we are more interested in whether or not the
Proteon router can provide the throughput necessary.  I realize this can be
accomplished using UDP, we have conducted such tests.  In this particular
case, though, we need empirical data using TCP through the router.  We are
in a bind as Proteon is aware of hardware problems in their router which we
are also experiencing.

The fact the TCP doesn't want to "cooperate" by using a larger MSS just
hampers our testing and introduces more variables into an already complex
test bed.

If this characteristic of using 576 octets for the MSS is a Berkeley 
implementation decision, WHERE can I find it documented?  This may be
necessary to provide justification for not shooting down Proteon's poor
throughput with it's router.

Regards,
Cliff Yamamoto
-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 89 21:46:34 GMT
From:      kasten@interlan.interlan.COM (Frank Kastenholz)
To:        comp.protocols.tcp-ip
Subject:   Re:  Ethernet cabling book


	From tcp-ip-RELAY@nic.ddn.mil Fri Nov  3 11:05:15 1989
	Received: by interlan.interlan.com (5.51/5.17)
		id AA00540; Fri, 3 Nov 89 11:05:08 EST
	Message-Id: <8911031605.AA00540@interlan.interlan.com>
	Received: from nic.ddn.mil by RELAY.CS.NET id aa07651; 3 Nov 89 3:21 EST
	Received: from citi.umich.edu by NIC.DDN.MIL with TCP; Tue, 31 Oct 89 03:23:52 PST
	From: Dave Bachmann <dave@citi.umich.edu>
	To: tcp-ip@NIC.DDN.MIL
	Date: 31 Oct 1989 06:24 EST
	Subject: Ethernet cabling book
	
	A book just came out called "Keeping the Link" that covers all sorts of issues
	on Ethernet.  Very detailed.
	
	Dave
	

This book was reviewed in the July issue of ConneXions, where it was panned.
I have not read it, but judging by the review it would not be a good
solution to the original question.

Cheers
Frank Kastenholz
Racal InterLan

The opinions expressed are alll mine - RI doesn't even know I said them.

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 89 22:58:16 GMT
From:      att!cbnewsh!tds@ucbvax.Berkeley.EDU  (antonio.desimone)
To:        tcp-ip@NIC.DDN.MIL
Subject:   Re: Sun's silly TCP implementation
From article <4900@mentor.cc.purdue.edu>, by dls@mentor.cc.purdue.edu (David L Stevens):
> 
> 	What you really want is a protocol or protocol extension that will
> discover a maximal non-fragmenting value for the MSS, but of course, since
> IP packet switches, the route and good MSS value may change during the course
> of a connection.

> 					+-DLS  (dls@mentor.cc.purdue.edu)

What's happening is that Sun's TCP is being as pessimistic as possible
about packets that go off the local net, and further it is being unwaveringly
pessimistic, at least for those without source code!

I know very little about the state of commercial TCP implemetations.
Can some of the experts out there respond to the obvious issues?
Is this kind of limitation on the TCP MSS universal in TCP implementations?
How do people who want to use a high-performance backbone between LANs
live with TCP implementations that have the same pessimistic bent as 
Sun's (or maybe as any BSD-derived TCP)?

-- 
Tony DeSimone
AT&T Bell Laboratories
Holmdel, NJ 07733
att!tds386e!tds
-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 89 23:10:26 GMT
From:      austins@violet.Berkeley.EDU  (Austin Shelton)
To:        tcp-ip@NIC.DDN.MIL
Subject:   BSD 4.3 POP3 Server Available
We have written a POP3 server that is integrated with 
the standard features of BSD 4.3 Unix.  In particular:

(1) It is spawned from inetd, rather than operating
continuously.

(2) It uses the /etc/passwd file for user authentication..

(3) It accesses /usr/spool/mail for the actual mail

(4) An XTND XMIT enables the server to send a mail message
using sendmail on behalf of the client.

(5) It uses syslog to log activity.

It has been tested successfully on BSD 4.3, Ultrix 2.3, and
SunOS 4.0 Unix.

It is available by anonymous ftp to lilac.Berkeley.EDU
(128.32.136.12) in the "/pub" directory as "popper.tar".
Included is a README file that explains how to install it.

Please send bug reports, etc. to me.

Austin Shelton
Data Communication and Network Services
University of California at Berkeley
-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 89 23:53:24 GMT
From:      RAVI@UMUC.BITNET (Ravi Sinnarajah)
To:        comp.protocols.tcp-ip
Subject:   Request for pointers on snmp implementations


*Greetings*


I have been requested by our network administrator, to obtain the the
snmp software avialable as public domain packages, the ones implemented
by MIT, CMU and NYSERNET.  I would like to know, whether they can be
retrieved via 'anonymous' ftp from any sites, and if they can not be
retrieved, then whom I should contact.

Thank You so much in advance for any help and/or information you may
provide me in this regard.


Sincerely Yours,
/Ravi.



From  the   V I R T U A L   Desk  of  ...,

+--------------------------------------------------------------------+
| Ravi Sinnarajah                        CREN:     Ravi@Umuc.Bitnet  |
| VM Systems Programmer,                 Internet: Ravi@Umuc.Umd.Edu |
| Internet Hosts(local) Contact and,     Voicenet: (301) 985-7170    |
| BITNET(local) Postmaster                                           |
| Academic Computing                                                 |
|                                                                    |
|    US Mail: University of Maryland - University College (UMUC)     |
|             University Boulevard at Adelphi Road                   |
|             College Park, Maryland, MD 20742-1615, U.S.A           |
 +--------------------------------------------------------------------+

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      4 Nov 89 00:21:00 GMT
From:      ljm@TWG.COM (Leo J McLaughlin)
To:        comp.protocols.tcp-ip
Subject:   TCP performance (Was TCP/IP for DG)


>> can get > 900 KBytes/s from TCP over Ethernet
 
>Are we talking Bytes or Bits per second, and if it is bytes/sec
>whose TCP are you using? Where can I get it?
 
>I've noticed that PC's have pretty naff performance when talking
>to kit such as Suns. Putting to the PC seems much slower than getting
>from. Anyone any ideas on how to improve it?

Increase TCP MSS to 1460, window size to 5840, burn any 3c500 you might find...

At this point we get over 300Kbytes/sec on FTPs from PC to PC,
the commercially available stuff on other hosts slows us down.
(admittedly, Vernon, we don't have a Silicon Graphics machine in house)

enjoy,
leo j mclaughlin iii
The Wollongong Group
ljm@twg.com

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      4 Nov 89 00:29:30 GMT
From:      meggers@orion.oac.uci.edu (mark eggers)
To:        comp.protocols.tcp-ip
Subject:   Vendors Guide for OSI

I know that the vendors guide for TCP/IP products is available for
anonymous FTP. Is there a similar one for OSI products ??

Thanks for any information.

/mde/

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      4 Nov 89 00:42:22 GMT
From:      bzs@world.std.com (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   OPEN BOOK INITIATIVE :: NEW MAILING LIST



		The Open Book Initiative Mailing List

The Open Book Initiative is being formed to make available freely
redistributable collections of information. There exists huge
collections of books, conference proceedings, reference material,
catalogues, etc. which can be freely shared. Some of it is in
machine-readable form, much of it isn't.

The purpose of the Open Book Initiative is to create a publicly
accessible repository for this information, a net-worker's library.

(A more complete description and original announcement is available.)

To bring people together in this effort two mailing lists have been
formed:

	openbook@world.std.com			General discussion
	openbook-announce@world.std.com		Announcements-only

To be added to either mailing list send to:

	Internet:	openbook-request@world.std.com
	UUCP:		{xylogics,uunet}!world!openbook-request

and specify which list you would like to be on (announce or
discussion.) If you don't specify I will put you on the discussion
list (all announcements will appear on the discussion list, you don't
need to be on both.)

There are already almost 100 people on the mailing list and it hasn't
been announced yet, given the interest it might take a few days to
keep up with changes until things settle down.

LARGE ORGANIZATIONS: I (and the networks) would appreciate if you would
set up local mail exploders for your organizations. Thank you!

        -Barry Shein

Software Tool & Die, Purveyors to the Trade         | bzs@world.std.com
1330 Beacon St, Brookline, MA 02146, (617) 739-0202 | {xylogics,uunet}world!bzs

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      4 Nov 89 03:25:42 GMT
From:      brock@brock.cs.unc.edu (J. Dean Brock)
To:        comp.protocols.tcp-ip
Subject:   SunOS 3.5 traceroute w/o kernel mods

I have a version of traceroute that runs under SunOS 3.5 using
the Sun NIT interface and doesn't require any kernel mods.
Nope, it won't run under SunOS 4.0, though I'll think about
converting it when we upgrade to 4.0.3 in a couple of weeks.

This traceroute hasn't been tested too much, but it's available
for anonymous FTP as ~ftp/pub/traceroute.tar.Z on dopey.cs.unc.edu.

P.S.  I've heard there may be something similar available from LBL.
If anyone knows about another NIT-based traceroute, send me mail.

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      4 Nov 1989 09:18-EST
From:      CERF@A.ISI.EDU
To:        cs.utexas.edu!wuarchive!wupost!dranet!sean@TUT.CIS.OHIO-STATE.EDU
Cc:        tcp-ip@NIC.DDN.MIL
Subject:   Re: MXing the world (was RE: New Host-Requirement RFCs)
Sean,

I don;t disagree with your observation that one can probably
never eliminate source-routing in its entirety. However, as
a long-time user of a broken User Agent (which relied on host
tables), I can say with confidence that it was a pleasure to
move to a user agent which had regular access to DNS information.
I was unable to respond conveniently to about 25% of the messages
that arrived using the older system.

Consequently, I think it would be helpful to pursue the goal of
outfitting as many systems as possible with reliable access to
DNS.

As to source routing specifically, it has always seemed to me
a problem to know which gateways to route through. Figuring
out ab initio how to route to a bitnet user has always been
awkward for me, at any rate. Once I memorized a likely
gateway/relay, they'd retire the darn thing, for instance.
Replying to a message received from a source routing sender
is a little easier, assuming, of course, that the relay is
known to DNS or is in your host table (sigh).

Vint Cerf
-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      4 Nov 1989 10:30-EST
From:      CERF@A.ISI.EDU
To:        dell@APPLE.COM
Cc:        tcp-ip@NIC.DDN.MIL
Subject:   Re: Top level .int domain
There were some organizations which felt themselves to be
international in nature and did not want to register under
any particular national rubric. So .INT was created
to accommodate.

Vint Cerf

p.s. the administrator is Mark Pullen at DARPA/ISTO.
-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      4 Nov 1989 11:14-EST
From:      CERF@A.ISI.EDU
To:        tcp-ip@NIC.DDN.MIL
Subject:   Re:  Pilot Project: Hosts Table To Be Available Over Internet
Phil,

I suspect the issue is not so much whether the proposed
host table service will help or not - it will certainly
help to some extent those hosts which have no satisfactory
access to DNS information. However, it would be a lot more
satisfying (to me, anyhow) if we could find a way to extend
some of the benefits of the DNS to sites which currently 
are achieving only partial ability to communicate because
of an inability to translate names to IP addresses.

Vint
-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      4 Nov 89 09:24:25 GMT
From:      phil@BRL.MIL (Phil Dykstra)
To:        comp.protocols.tcp-ip
Subject:   Re:  Pilot Project: Hosts Table To Be Available Over Internet

Rick,

Boy, you just can't quit slamming the MILNET can you.  BRL is a MILNET
site and was one of the first places on the InterNet to use the DNS.
And we can do one step better than beloved MX record hacks by having a
gateway that is smart enough to play the pseudo host BRL.MIL and throttle
mail to machines within.  We've got a few hundred hosts back here but
w.r.t. mail we could get by with advertising one and only one host to
the world (which would leave far less than 5% in a host table).

Anyway (flame off), yes we are unusual, and yes there are a lot of dinosaurs
on the MILNET, and yes, mail systems that can't use the DNS are BROKEN.
If a MILNET site can't answer your mail, just tell your users its because
they have a broken mailer and there's nothing you can do about it.  That
is after all, the truth.

One point of argument: if the host table is as useless as you claim,
then removing it wouldn't have any impact on such sites now would it?

- Phil

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      4 Nov 89 13:13:56 GMT
From:      eckert@immd4.informatik.uni-erlangen.de (Toerless Eckert)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: X.25 streams modules for TCP/IP

From article <15060@haddock.ima.isc.com>, by jimm@haddock.ima.isc.com (Jim McGrath):
> In article <1602@ssp15.idca.tds.philips.nl> karl%awsoms@philapd.idca.tds.philips.nl writes:
>>So I need a arp for X25.
>>
> There is no such thing as arp for X.25.  There are two ways of
> converting between Internet and X.121 (X.25) addresses.  The first is
> the DDN model, and uses an algorithm for the conversion (refer to
> Defense Data Network X.25 Host Interface Specification).  X.121
> addresses in the public sector are assigned by the authority governing
> a specific PSDN, so there is no convenient way of doing the
> translation.  You might implement a table lookup for the conversion.

The PDN routing group (of the IETF) is working on an arp
specification for X.121, together with other proposals for using
IP on public data networks, especially routing, international
reverse charging, and the like. The last meeting of the group was
last week, so i don't know what the status is, but i hope that
some of the specs are ready now.


Toerless Eckert X.400: <S=eckert;OU=informatik;P=uni-erlangen;A=dbp;C=de>
		RFC822: eckert@informatik.uni-erlangen.de
		UUCP:   {pyramid,unido}!fauern!eckert BITNET: tte@derrze0

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      4 Nov 89 13:48:22 GMT
From:      brian@ucsd.Edu (Brian Kantor)
To:        comp.protocols.tcp-ip
Subject:   NSFNET-RELAY.AC.UK down?

For the last week or so, UCSD.EDU has been unable to open SMTP
connections to host 'nsfnet-relay.ac.uk' (connections just time out),
but we can ping them and it looks like remote login on port 23 is
working ok.  Has anyone else noticed this happening from his site or
are we having an isolated problem?
	- Brian

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      4 Nov 89 13:51:16 GMT
From:      eckert@immd4.informatik.uni-erlangen.de (Toerless Eckert)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: X.25 streams modules for TCP/IP

From article <15060@haddock.ima.isc.com>, by jimm@haddock.ima.isc.com (Jim McGrath):
> In article <1602@ssp15.idca.tds.philips.nl> karl%awsoms@philapd.idca.tds.philips.nl writes:
>>So I need a arp for X25.
>>
> There is no such thing as arp for X.25.  There are two ways of
> converting between Internet and X.121 (X.25) addresses.  The first is
> the DDN model, and uses an algorithm for the conversion (refer to
> Defense Data Network X.25 Host Interface Specification).  X.121
> addresses in the public sector are assigned by the authority governing
> a specific PSDN, so there is no convenient way of doing the
> translation.  You might implement a table lookup for the conversion.

The PDN routing group (of the IETF) is working on an arp
specification for X.121, together with other proposals for using
IP on public data networks, especially routing, international
reverse charging, and the like. The last meeting of the group was
last week, so i don't know what the status is, but i hope that
some of the specs are ready now.

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      4 Nov 89 13:52:58 GMT
From:      mcsun!unido!tub!fauern!fauern!immd4.informatik.uni-erlangen.de!eckert@uunet.uu.net  (Toerless Eckert)
To:        tcp-ip@NIC.DDN.MIL
Subject:   Re: X.25 streams modules for TCP/IP
From article <15060@haddock.ima.isc.com>, by jimm@haddock.ima.isc.com (Jim McGrath):
> In article <1602@ssp15.idca.tds.philips.nl> karl%awsoms@philapd.idca.tds.philips.nl writes:
>>So I need a arp for X25.
>>
> There is no such thing as arp for X.25.  There are two ways of
> converting between Internet and X.121 (X.25) addresses.  The first is
> the DDN model, and uses an algorithm for the conversion (refer to
> Defense Data Network X.25 Host Interface Specification).  X.121
> addresses in the public sector are assigned by the authority governing
> a specific PSDN, so there is no convenient way of doing the
> translation.  You might implement a table lookup for the conversion.

The PDN routing group (of the IETF) is working on an arp
specification for X.121, together with other proposals for using
IP on public data networks, especially routing, international
reverse charging, and the like. The last meeting of the group was
last week, so i don't know what the status is, but i hope that
some of the specs are ready now.


Toerless Eckert X.400: <S=eckert;OU=informatik;P=uni-erlangen;A=dbp;C=de>
		RFC822: eckert@informatik.uni-erlangen.de
		UUCP:   {pyramid,unido}!fauern!eckert BITNET: tte@derrze0
-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      4 Nov 89 14:18:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: MXing the world (was RE: New Host-Requirement RFCs)

Sean,

I don;t disagree with your observation that one can probably
never eliminate source-routing in its entirety. However, as
a long-time user of a broken User Agent (which relied on host
tables), I can say with confidence that it was a pleasure to
move to a user agent which had regular access to DNS information.
I was unable to respond conveniently to about 25% of the messages
that arrived using the older system.

Consequently, I think it would be helpful to pursue the goal of
outfitting as many systems as possible with reliable access to
DNS.

As to source routing specifically, it has always seemed to me
a problem to know which gateways to route through. Figuring
out ab initio how to route to a bitnet user has always been
awkward for me, at any rate. Once I memorized a likely
gateway/relay, they'd retire the darn thing, for instance.
Replying to a message received from a source routing sender
is a little easier, assuming, of course, that the relay is
known to DNS or is in your host table (sigh).

Vint Cerf

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      4 Nov 89 15:20:25 GMT
From:      rick@UUNET.UU.NET (Rick Adams)
To:        comp.protocols.tcp-ip
Subject:   Re:  Pilot Project: Hosts Table To Be Available Over Internet

I DO tell people that MILNET sites have broken mailers. I DO it 
about 5 times per WEEK. The MILNET sites deny any problems.

The host tables allow the broekn MILNET sites to delude themselves
that they have usable systems.

The delusion must end.

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      4 Nov 89 15:30:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Top level .int domain

There were some organizations which felt themselves to be
international in nature and did not want to register under
any particular national rubric. So .INT was created
to accommodate.

Vint Cerf

p.s. the administrator is Mark Pullen at DARPA/ISTO.

-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      4 Nov 89 16:06:23 GMT
From:      cyamamot@girtab.usc.edu (Cliff Yamamoto)
To:        comp.protocols.tcp-ip,comp.unix.questions
Subject:   Can you fix (Re: Sun's silly TCP implementation)???

In article <12355@ulysses.homer.nj.att.com> smb@ulysses.homer.nj.att.com (Steven M. Bellovin) writes:
>In other words, the implementation is exactly conformant with the
>recommendation.
>
>Now, the choice of a better MTU would obviously help, and there is in fact
>work going on on a MTU discovery process.  But it's not here yet.

Now that this minimal MSS usage has been confirmed, does anyone know of a
workaround that can be done to override it?  Specifically, is there something
in the /sys directory or any other directory which can be modified such that
our Sun uses a MSS of our choice?  A solution which would globally affect all
applications (rsh, ftp, etc.) would be ideal.

Thanks in advance for any information.

Cliff Yamamoto

Jet Propulsion Laboratory
4800 Oak Grove Drive
M/S 301-270X
Pasadena, Calif.  91109
(818) 354-1443

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      4 Nov 89 16:14:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Pilot Project: Hosts Table To Be Available Over Internet

Phil,

I suspect the issue is not so much whether the proposed
host table service will help or not - it will certainly
help to some extent those hosts which have no satisfactory
access to DNS information. However, it would be a lot more
satisfying (to me, anyhow) if we could find a way to extend
some of the benefits of the DNS to sites which currently 
are achieving only partial ability to communicate because
of an inability to translate names to IP addresses.

Vint

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      4 Nov 89 20:26:12 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: Sun's silly TCP implementation

In article <6382@jpl-devvax.JPL.NASA.GOV> cyamamot@devvax.JPL.NASA.GOV (Cliff Yamamoto) writes:
>... It is my understanding
>that it is the router's responsibility to fragment frames when forwarding
>data between two different physical networks.  In this case, it appears the
>Sun is performing the fragmentation for the router...

Not quite; the Sun is setting its MTU low enough to avoid fragmentation.
Avoiding fragmentation is generally a Good Thing, as IP fragmentation has
several bad properties.  What is really wanted, for a combination of good
performance and robustness, is dynamic discovery of the proper MTU for a
path; in your case, the BSD algorithm Sun is using is overly conservative.

See RFC 1063 for an example of current thoughts on dynamic discovery
(which, unfortunately, isn't yet well enough understood to be a standard).
-- 
A bit of tolerance is worth a  |     Henry Spencer at U of Toronto Zoology
megabyte of flaming.           | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      4 Nov 89 20:56:39 GMT
From:      mike@jpl-devvax.JPL.NASA.GOV (Mike Tankenson)
To:        comp.protocols.tcp-ip
Subject:   Re: Can you fix (Re: Sun's silly TCP implementation)???

In article <6259@merlin.usc.edu> cyamamot@jpl-devvax.JPL.NASA.GOV (Cliff Yamamoto) writes:

>Now that this minimal MSS usage has been confirmed, does anyone know of a
>workaround that can be done to override it?  Specifically, is there something
>in the /sys directory or any other directory which can be modified such that
>our Sun uses a MSS of our choice?  A solution which would globally affect all
>applications (rsh, ftp, etc.) would be ideal.

Cliff, I think that one of the posters gave us a clue as to a possible
workaround.  *If* our Suns kernels are patchable via adb, and the symbol
tables are available, we can 'patch' a larger number into the kernel
variable.  I think he mentioned 'SUBNETSARELOCAL' in a header file, or if
we could find the actual symbol name, we can patch the thing.

If not, we are out of luck, since we have no source.

--mike
-- 
Mike Tankenson                      Telos/Jet Propulsion Laboratory/NASA
4800 Oak Grove Drive, Pasadena, CA.  91109           Mail Stop: 301-260a
Phone: (818) 354-1439
ARPA: mike@jpl-devvax.JPL.NASA.GOV  UUCP: seismo!cit-vax!jpl-devvax!mike

-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      5 Nov 89 00:21:18 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Sun's silly TCP implementation



		I don't think it's optimal, either, and it's not in an RFC; it's an
	engineering decision on the part of the Berkeley implementors. 
	
	
Please see Section 3.3.3 of RFC-1122, the lower-layer Host Requirements RFC.

   Bob Braden
   

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      5 Nov 89 02:15:40 GMT
From:      brnstnd@CS.YALE.EDU  (Dan Bernstein)
To:        tcp-ip@NIC.DDN.MIL
Subject:   Re: Pilot Project: Hosts Table To Be Available Over Internet
These are personal comments.

In article <8911031724.AA01224@uunet.uu.net> rick@UUNET.UU.NET (Rick Adams) writes:
> It is an absolute sham to pretend that the 5% (lets be charitable) of
> the internet hosts listed in the host table represent a useful number
> of hosts to the MILNET users.

The last official IETF count was 118,000. They estimate up to 150,000.
Our hosts table contains over 125,000. That's 5%?

> If MILNET wants to stay in the dark, thats their business. However,
> when you pretend that they can interoperate with the rest of the
> Internet, you are wasting everyone's time.

Wasting everyone's time---everyone except them (MILNET); except CERT;
except all the others who have good reasons for wanting the table.

---Dan
-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      5 Nov 89 05:08:42 GMT
From:      rick@uunet.uu.net  (Rick Adams)
To:        tcp-ip@NIC.DDN.MIL
Subject:   Re: Pilot Project: Hosts Table To Be Available Over Internet
MILNET sites are not going to use your table. They are going to
use the NICs tables which has about 5,000 hosts in it.

The sham remains. In general, MILNET users do not have full interoperabillity
with the rest of the Internet.

If you think the MILNET sites are going to use your host table over
the one the NIC provides, you are kidding yourself.
-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      5 Nov 89 05:10:12 GMT
From:      rick@uunet.uu.net  (Rick Adams)
To:        tcp-ip@NIC.DDN.MIL
Subject:   Re: Pilot Project: Hosts Table To Be Available Over Internet
In article <1872@yale-bulldog.yale.UUCP>, brnstnd@stealth.acf.nyu.edu (Dan Bernstein) writes:
> These are personal comments.
> 
> Wasting everyone's time---everyone except them (MILNET); except CERT;
> except all the others who have good reasons for wanting the table.


OK. I give up. What are these "good reasons" that seem to
elude everyone else. (Kludging broken software is not a good reason)
-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      5 Nov 89 10:40:25 GMT
From:      carlson@uxh.cso.uiuc.edu
To:        comp.protocols.tcp-ip
Subject:   Re: Pilot Project: Hosts Table To Be Av


I don't understand why it it is such a big deal to implement
DNS resolver routines.  If you can access the real Internet
(which is why you want host-lookup in the first place)
then you can access any DNS server for names outside of your domain.
(You are free to use a static table for your own machines if you want.)

The BSD4.3 routines for the DNS lookup (i.e. gethostbyname) take
under 3000 lines of code, and should compile without trouble.

---Possible objections----
You don't use BSD:  Replace/emulate send(), etc. with proper tcp/udp routines.
You don't have a C compiler: Get one, everybody else has one.

Your network programs access the file table directly:
	Hmm...is this the case with some of you out there?
	That is a tough one, especially if you don't have source code
	(and vendor has long since folded).
	I am tempted to say such programs are obsolete and deserve to
	die a natural death.  Maintaining _BACKWARDS_ compatability has
	its uses, but you can go too far.  E.g. does anybody today
	really give a damn that MSDOS could run CP/M binaries?
--------------------
Brad Carlson  <carlson@mrcnext.cso.uiuc.edu> or <brad-carlson@uiuc.edu>
University of Illinois -- Consultant -- NeXT guru -- Windows Programmer

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      5 Nov 89 10:40:27 GMT
From:      carlson@uxh.cso.uiuc.edu
To:        comp.protocols.tcp-ip
Subject:   Re: LPD Documentation


The the Berkeley lpr/lpd stuff is specific to Unix
and does not have an RFC or any other formal specification,
as far as I know.
The manuals and source code are all the documentation that exists. :-(
--------------------
Brad Carlson  <carlson@mrcnext.cso.uiuc.edu> or <brad-carlson@uiuc.edu>
University of Illinois -- Consultant -- NeXT guru -- Windows Programmer

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      6 Nov 1989 1:15-PST
From:      Steve Deering <deering@pescadero.stanford.edu>
To:        mailrus!wuarchive!cs.utexas.edu!samsung!usc!henry.jpl.nasa.gov!elroy.jpl.nasa.gov!jpl-devvax!cyamamot@tut.cis.ohio-state.edu  (Cliff Yamamoto)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Sun's silly TCP implementation
Sun's code is behaving correctly; it's your subject line that's silly.
See section 3.3.3 of RFC-1122, "Requirements for Internet Hosts --
Communications Layers".

Also read "Fragmentation Considered Harmful" by Kent and Mogul, Proc.
SIGCOMM '87, for a discussion of why the Sun behavior is the recommended
behavior and some proposals for protocol extensions to allow more
efficient behavior in the future.

Steve Deering
-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      5 Nov 89 17:18:49 GMT
From:      RAF@CU.NIH.GOV ("Roger Fajman")
To:        comp.protocols.tcp-ip
Subject:   Re:  MXing the world (was RE:  New Host-Requirement RFCs)

> As to source routing specifically, it has always seemed to me
> a problem to know which gateways to route through. Figuring
> out ab initio how to route to a bitnet user has always been
> awkward for me, at any rate. Once I memorized a likely
> gateway/relay, they'd retire the darn thing, for instance.
> Replying to a message received from a source routing sender
> is a little easier, assuming, of course, that the relay is
> known to DNS or is in your host table (sigh).

This is overstating considerably the number of changes that have
occurred, at least in the well known gateways.  Some years ago, WISCVM
did retire from the gateway business (the machine was shut down).
CUNYVM and some other places took over.  That was the last major
change.

You may not know that on the BITNET side, the user does not have to
know the name of the gateway.  At most sites, it's handled
automatically by the software.  Thus on the BITNET side, the change
from WISCVM was pretty transparent to users, as long as their system
administrators used up to date tables.  Of course, there were some
problems because not all did.

Obviously it was not all transparent to those sites that took over the
gateway function.  They deserve a lot of credit.

-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      6 Nov 89 00:04:00 WET DST
From:      "John" <laws@ccint1.rsre.mod.uk>
To:        "mkl" <mkl@nic.ddn.mil>
Cc:        "tcp-ip" <tcp-ip@nic.ddn.mil>
Subject:   Re: Top level .int domain
Mark,

The 'certain european organization' while based in Europe does in fact
represent North America as well and has a considerable number of USA staff.

John Laws

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      6 Nov 89 00:23:43 GMT
From:      daemon@watale.waterloo.edu (joejobber process)
To:        comp.protocols.tcp-ip
Subject:   Traceroute & SunOS 4.0.3

Does anyone have the patched kernel objects necessary to run traceroute
under SunOS 4.0.3 on either Sun3's or 4's (both would be fabulous).
I'm quite certain that a modified raw_ip.o is involved, but I'm not
sure if anything else is required.  Would it be possible that some kind
soul could make the patched objects available via anonymous ftp?

Thank you for your time.

Mike Adams (mdadams@surya.waterloo.edu || madams@sirius.uvic.ca)

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      6 Nov 89 02:25:22 GMT
From:      laws@CCINT1.RSRE.MOD.UK ("John")
To:        comp.protocols.tcp-ip
Subject:   Re: Top level .int domain

Mark,

The 'certain european organization' while based in Europe does in fact
represent North America as well and has a considerable number of USA staff.

John Laws

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      6 Nov 89 02:53:55 GMT
From:      RAF@CU.NIH.GOV ("Roger Fajman")
To:        comp.protocols.tcp-ip
Subject:   Re:  BITNET -- Internet capabilities

Regarding a BITNET, ACSnet, and UUCP style sender initiated file
transfer to a spool area, I wrote up a proposal for BITNET a while back
to extend BSMTP for file transfer.  BSMTP is Batch SMTP, an adaptation
of SMTP to a store and forward environment, and is already used for
mail in BITNET and the UUCP net.  Most of the same extensions could be
made just as well to SMTP (some are not needed for SMTP).  While RFC
821 limits SMTP to 7 data bits, there's no reason why SMTP over TCP
can't handle 8 data bits.  An advantage of this type of file transfer
is that it would permit files to pass through gateways, just as mail
does now.  Anyway, I'll be glad to email a copy of the proposal to
anyone interested.  Maybe there's enough interest to try to do an RFC.
Remember that the proposal currently is written from the perspective of
facilitating the implementation of domains on BITNET.

Roger Fajman
National Institutes of Health
RAF@NIHCU  (BITNET)
RAF@CU.NIH.GOV  (Internet)

-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      6 Nov 1989 11:47-PST
From:      Steve Deering <deering@pescadero.stanford.edu>
To:        hashem@mars.jpl.nasa.gov (Basil Hashem)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Multicasting on TCP/IP
> From: hashem@mars.jpl.nasa.gov (Basil Hashem)
>
> In my terms, multicasting is the ability to distribute data packets
> to a *selected* group of addresses on a network.
>
> From my readings about TCP/IP, there seems to be only two distribution
> mechanisms provided:  broadcast and point-to-point.
>
> With consideration for network/CPU (over)loading, what is the most 
> efficient way to achieve the functionality of a multicast on a
> TCP/IP network?

Basil,

Multicasting support was recently added to IP; see RFC-1112.

Currently, there are very few gateway implementations that support
Internet-wide multicast routing.  An experimental multicast routing
demon for 4.3bsd-based systems is available by anonymous FTP from
gregorio.stanford.edu; fetch the file vmtp-ip/ipmulticast.README.

Even without multicast gateways, the RFC-1112 multicast extensions
are useful for multicasting within a single network (e.g., using
Ethernet multicast addresses).

Steve Deering
-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      6 Nov 89 07:08:56 GMT
From:      jparnas@larouch.uucp (Jacob Parnas)
To:        comp.protocols.tcp-ip,comp.dcom.modems,comp.unix.wizards
Subject:   Van Jacobson SLIP w/ header compression...


Does anybody have this, or know where to get it.  We run SLIP a lot in my
department, and really suffer because we send the huge, uncompressed headers
for every character when running telnet/rlogin and other programs.  

Last I heard, it was supposed to be released "any day now" at the Baltimore
usenix.  It was running at the Febuary usenet and was promised "in a couple
weeks when everybody agrees on the spec."  That sounded reasonable in
Febuary, but having to wait 9 months for something this important is REALLY
ANNOYING.  

Does anybody know 

1.  If/where SLIP with header compression is available?

2.  What the status is of the new SLIP?

3.  Who can be contacted to get a beta test copy, or some version of tip with
    some header compression.

4.  Does it look like it is going to be several months before it is released?
    If so, I'd like to know so I know it is worth implementing some header
    compression.

Thank you very much for your help,

------------------------------------------------------------------------------
| Jacob M. Parnas                    | DISCLAIMER: The above message is from |
| IBM Thomas J. Watson Research Ctr. | me and is not from my employer.  IBM  |
| Arpanet: jparnas@ibm.com           | might completely disagree with me.    |
| Bitnet: jparnas@yktvmx.bitnet      \---------------------------------------|
| Home: ..!uunet!bywater!acheron!larouch!jparnas | Phone: (914) 945-1635     |
------------------------------------------------------------------------------

-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      6 Nov 89 09:15:00 GMT
From:      deering@PESCADERO.STANFORD.EDU (Steve Deering)
To:        comp.protocols.tcp-ip
Subject:   Re: Sun's silly TCP implementation

Sun's code is behaving correctly; it's your subject line that's silly.
See section 3.3.3 of RFC-1122, "Requirements for Internet Hosts --
Communications Layers".

Also read "Fragmentation Considered Harmful" by Kent and Mogul, Proc.
SIGCOMM '87, for a discussion of why the Sun behavior is the recommended
behavior and some proposals for protocol extensions to allow more
efficient behavior in the future.

Steve Deering

-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      Mon, 06 Nov 89 14:52:49 EST
From:      bill gunshannon <702WFG%SCRVMSYS.BITNET@CORNELLC.cit.cornell.edu>
To:        tcp-ip@nic.ddn.mil
Subject:   Re: POP3
I have seen a number of places where I can get a POP3 server.  Now can
anyone tell me where I can find a POP3 client??
Thank you.

                                          bill gunshannon
                                       702WFG@SCRVMSYS.BITNET

-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      6 Nov 89 10:47:13 GMT
From:      mtarrani@crash.cts.com (Mike Tarrani)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: Comments wanted on ethernet book

In article <3705@ccnysci.UUCP> dan@ccnysci.UUCP (Dan Schlitt) writes:
>Is "Designing and Implementing Ethernet Networks", 2nd Edition, by
>Bill Hancock a worthwhile book to own?  Or is there some better book
>covering the same material.  There are limits on the number of $30
>books I can buy.
>
>Thanks for the info.
>-- 
>Dan Schlitt                        Manager, Science Division Computer Facility
>dan@sci.ccny.cuny.edu              City College of New York
>dan@ccnysci.uucp                   New York, NY 10031
>dan@ccnysci.bitnet                 (212)690-6868

Hancock's book is poorly written (I found a few factual errors, many
spelling and grammatical errors); but, his writing style is lively.
I would NOT buy the book again.

The best book on Ethernet I have seen is called Keeping The Link: Ethernet
Installation & Management, McGraw-Hill, Martin Nemzow (ISBN: 0-07-046302-6).
Nemzow's book is well written, contains a wealth of material on every
aspect of Ethernet installation and management, and is a practical guide
(in my opinion.)


-- 
Mike Tarrani          crash!mtarrani@nosc.mil
Network Analyst       Network Engineering Technologies
                      San Diego, CA

-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6 Nov 89 16:33:17 EST
From:      Cliff Stallings <cliff@wsu-eng.eng.wayne.edu>
To:        tcp-ip@nic.ddn.mil
Subject:   print server
 
I have a network consisting of one sun-4, one sun-4, 2 pc's, 1 mac II running
mac os, and 1 mac II running a/ux.

All systems are connected via ethernet cards to tcp/ip based network.
 
I have a laser writer and an image writer which I would like to access from
all of my systems.  Can anyone help me?
 
   cliff@wsu-eng.eng.wayne.edu 
   
-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6 Nov 89 16:33:17 EST
From:      Cliff Stallings <cliff%WSU-ENG.ENG.WAYNE.EDU@CORNELLC.cit.cornell.edu>
To:        Brian Holmes <BHOLMES@WAYNEST1.BITNET>
Subject:   print server
I'm not that familar with Sun's, but if you can connect the printers
to a SUN or the Mac running AUX then run CAP which was written to
run under UNIX, then the Mac under OS could access the printers.
You could then run LPD on the Mac running AUX so the other machines
can also print on those printers.  FYI

                        Brian Holmes
                        CSC Operating Systems & Communications

SNAIL    : Wayne State University, 5925 Woodward, Detroit MI 48202 U.S.A.
BITNET   : BHOLMES@WAYNEST1
INTERNET : Brian_Holmes@UM.CC.UMICH.EDU
UUCP     : {UMIX|ITIVAX}!WAYNE-MTS!BRIAN_HOLMES
----------------------------Original message----------------------------
I have a network consisting of one sun-4, one sun-4, 2 pc's, 1 mac II running
mac os, and 1 mac II running a/ux.

All systems are connected via ethernet cards to tcp/ip based network.

I have a laser writer and an image writer which I would like to access from
all of my systems.  Can anyone help me?

   cliff@wsu-eng.eng.wayne.edu
-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      6 Nov 89 13:48:37 GMT
From:      mep@AQUA.WHOI.EDU (Michael E. Pare)
To:        comp.protocols.tcp-ip
Subject:   Re:  Sun's silly TCP implementation

You have to remember that a router has a lot of work to do on the packets
in order to be able to forward them.  They are only designed to have a
throughput of a few thousand packets per second (I can't remember the exact
figure), far less than a bridge (over 12000 packets per second), and
certainly far less than running two machines on the same net, whose biggest
restriction will be the machines themselves.

In terms of packet sizes, this is set when you first configure the Sun's
and has nothing to do with the p4200.  The p4200 will handle a packet the
size of the largest interface, which in this case is the Pronet 80 link,
and is about 2046 bytes.  You should be able to utilize 1500 byte packets
to match the ethernet restriction.  Try reconfiguring your Sun's to
negotiate a larger packet size.  

-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      6 Nov 89 15:17:00 GMT
From:      mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re: Pilot Project: Hosts Table To Be Available Over Internet

Gentlemen:

There seems to be a number of tacit assumptions in this discussion.

    1.	That MILNET sites--I assume we are only referring to those systems
	on Net 26 in the MIL domain--need the capability to interoperate
	with all other possible nodes on the Internet.

    2.  These MILNET sites must have host tables because they don't have
	the DNS capabilities.

    3.	That the will use either the NIC host tables or this new grandiose
	host table.

For the most part, there is no operational requirement for sites in the MIL
domain to interoperate with anything other than other MIL domain sites and
selected sites in the GOV domain.

Over, at least, the past three years all of the systems that I have installed
for the military have had full DNS capabilities.  The decision to use host
tables rather than DNS is a command or program decision.

Neither this new host table nor the NIC host table is likely to be used by
any of these sites.  The host tables used to will be developed specifically
to support the mission requirements of the command or program.

Merton

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      6 Nov 89 15:51:23 GMT
From:      bob@MorningStar.Com (Bob Sutterfield)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: X.25 streams modules for TCP/IP

In article <560@medusa.informatik.uni-erlangen.de> eckert@immd4.informatik.uni-erlangen.de (Toerless Eckert) writes:
   The PDN routing group (of the IETF)...

Would someone in that group please contact me?  I'd like to learn what
you're up to.  Thanks!

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      6 Nov 89 15:54:17 GMT
From:      bill@fedeva.UUCP (Bill Daniels)
To:        comp.protocols.tcp-ip,comp.os.vms
Subject:   Re: LAT TCP terminal servers

johncw@gpu.utcs.utoronto.ca (Johnny Chee-Wah) writes:

>Currently interested in replacing a bunch of LAT
>DECservers with LAT/TCP terminal servers. Have looked
>at Hughes and Able products and would like to know
>what else is available in the market.
 
>Would appreciate any information.
 
>johncw@gpu.utcs.utoronto.ca

We haven't bought anything yet, but have been looking around at this market.
We have found a couple of other vendors:  Datability (mixed mode seems to
be VAPOR at this time) at 800-DIAL-DSS offers the VISTA line of servers and
XYPLEX offers the MAXserver 1000 series.  They can be reached at 800-338-5316.

We are also interested in this mixed LAT,TCP/IP terminal server game.  Can
anyone make comments about the various vendors and any particular offerings
that they have worked with?
-- 
bill daniels
federal express, memphis, tn
{hplabs!csun,mit-eddie!premise}!fedeva!wrd3156

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      6 Nov 89 15:57:25 GMT
From:      cliff@WSU-ENG.ENG.WAYNE.EDU (Cliff Stallings)
To:        comp.protocols.tcp-ip
Subject:   please remove my name

Please, remove my name from the tcp-ip user group list...
 
 cliff@wsu-eng.eng.wayne.edu

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      6 Nov 89 16:15:44 GMT
From:      aggarwal@JVNCA.CSC.ORG (Vikas Aggarwal none)
To:        comp.protocols.tcp-ip
Subject:   NSFNET-RELAY.AC.UK down?


Brian,

>> For the last week or so, UCSD.EDU has been unable to open SMTP
>> connections to host 'nsfnet-relay.ac.uk' (connections just time out)...


I was checking over our 'netlog' and except for brief (max 2 hour) glitches
to UK in October, we have had no trouble with the link to nsfnet-relay.ac.uk

I have just tried connecting to the SMTP port on nsfnet-relay and have had
no problems (at least from JvNC). However, I will find out if there have
been any problems in the past week from our point of contact there.

If you have any further problems regarding this link, please contact 
'noc@nisc.jvnc.net' directly, and we will be glad to look into the
problem for you.

-vikas

=--=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-==-=-=
	JOHN VON NEUMANN NATIONAL SUPERCOMPUTER CENTER

INTERNET:  aggarwal@jvnca.csc.org
BITNET:    aggarwal@jvncc
UUCP:      rutgers!jvnca!aggarwal

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-===-=--=-=-=-====-=-=-==-=-=-=-=

-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      6 Nov 89 16:34:29 GMT
From:      stine@SPARTA.COM (Robert Havens Stine)
To:        comp.protocols.tcp-ip
Subject:   Re:  Traceroute sources

Vikas,

Traceroute is available via anonymous FTP from host ftp.ee.lbl.gov.
It's in file traceroute.tar.Z (so, be sure to flip to "binary" mode to
retrieve it).

There is a traceroute-like tool that can run on PCs, with the ka9q
tcp/ip package, called "hopcheck."  It's available via anonymous FTP
from windom.ucar.edu, in file hopcheck.tar.Z.  It's also available
from udavis.edu, in directories nethopexe and nethopsrc.

I've played with traceroute only a little.  The only caveat I have
found is that the "results" you see must be intrepreted in light of
various impelementation errors in intervening IP's (e.g., some IP's
don't decrement the TTL; some when sending a "TTL expired" msg, copy
the expired TTL from the outbound packet into the ICMP packet,
resulting in the ICMP datagram being dropped immediately).

Traceroute can be fascinating.  I was surprised to see how many hops
the average message traverses.  Also, the routes can be mysterious.
About a month ago, all traffic from my site to the NSFNet went by way
of a gateway at Moffet Field.

- Bob Stine

-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      6 Nov 89 16:43:49 GMT
From:      spurgeon@ut-emx.UUCP (Bud Spurgeon)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: Comments wanted on ethernet book

>In article <3705@ccnysci.UUCP> dan@ccnysci.UUCP (Dan Schlitt) writes:
>>Is "Designing and Implementing Ethernet Networks", 2nd Edition, by
>>Bill Hancock a worthwhile book to own?
>
>In article <655@crash.cts.com> mtarrani@crash.cts.com (Mike Tarrani) writes:
>Hancock's book is poorly written (I found a few factual errors, many
>spelling and grammatical errors); but, his writing style is lively.
>I would NOT buy the book again.
>
>The best book on Ethernet I have seen is called Keeping The Link: Ethernet
>Installation & Management, McGraw-Hill, Martin Nemzow (ISBN: 0-07-046302-6).
>Nemzow's book is well written, contains a wealth of material on every
>aspect of Ethernet installation and management, and is a practical guide
>(in my opinion.)

While I agree that there's a lot of material in Nemzow's book, and
that he covers a wide range of subjects, I can't agree that it's a
practical guide, since it contains so many errors.  Chapters 3, 4, and
5 especially have significant errors about Ethernet specifications and
technology, although other errors, such as his repeated assertion that
thin Ethernet runs on 75 ohm coax, are spread throughout the book.

In my opinion, Nemzow's book suffers from a severe lack of careful
editing and technical review.  The errors include the completely
strange, such as his assertion that the Ethernet 1024 node spec is due
to an address limitation of 10 bits, or that the Ethernet coaxial
cable types are RG-59, RG-225 and RG-50.  The errors also include
things that are just sloppy, such as varying assertions in the text
and in accompanying illustrations that thin Ethernet is 200 meters and
185 meters long, and that minimum thin Ethernet transceiver spacing is
1 meter or .5 meter.  In both cases the lower number is correct, but
how is the neophyte to know that?

It's unfortunate that Nemzow's book didn't get the review and the
editing it needed, since it contains quite a lot of material.  But the
large number of serious errors and inaccuracies makes it impossible
for me to recommend this book to anyone.

-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      6 Nov 89 16:59:12 GMT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   Re: Comments wanted on ethernet book

>The best book on Ethernet I have seen is called Keeping The Link: Ethernet
>Installation & Management, McGraw-Hill, Martin Nemzow (ISBN: 0-07-046302-6).

Have you read the Book Review section in ConneXions Vol. 3, No. 7, July 1989
by Charles Spurgeon?

The initial paragraph states:

"Keeping the link could be quite difficult if you follow the advice
given in this book.  The book contains serious errors of fact with
respect to Ethernet/802.3 standards.  For instatnce, almost all of the
thin Ethernet specifications given in the book are wrong.  The book
contains errors about higher level protocol usage as well, while other
advice given in the book is at variance with standard industry
practices.  ..."

It is consequently, "Not recommended".

Phil Wood

-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      6 Nov 89 18:43:30 GMT
From:      sblair@riacs.edu (Steven C. Blair)
To:        comp.protocols.tcp-ip
Subject:   Re: Can you fix (Re: Sun's silly TCP implementation)???


You can adb -w vmunix on a Sun and alter the following values for under
SUNOS4.X kernels:

adb -w vmunix
tcp_mss+0xac?		200
tcp_mss+0xbc?		200
(200=~512 byrtes/packet)
Folks, please be very careful when changing your values. 1514(400x)
is the maximum that friends of mine when I worked at Sun suggested
were the most effecient.

If you don't understand how to alter UNIX under adb, consult the RTFM
or ask someone who does understand it. You better be really sure what
you're doing(and make a /vmunix.BAK) just in case

from the twisted mind of:

-- 
Steven C. Blair		7651 Fairoaks Drive Pleasanton, Ca 94566
UNIX is me.........	(415) 426-0942 days and nights(*currently*)
sblair@riacs.edu	{sun, ucbvax, ames, decwrl}!riacs!sblair

-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      6 Nov 89 19:07:57 GMT
From:      cliff@WSU-ENG.ENG.WAYNE.EDU (Cliff Stallings)
To:        comp.protocols.tcp-ip
Subject:   please remove my name

Please, Please, Please....  remove my name cliff@wsu-eng.eng.wayne.edu
from the tcp-ip users group...

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      6 Nov 89 19:24:34 GMT
From:      guy@auspex.auspex.com (Guy Harris)
To:        comp.protocols.tcp-ip
Subject:   Re: Can you fix (Re: Sun's silly TCP implementation)???

>Cliff, I think that one of the posters gave us a clue as to a possible
>workaround.  *If* our Suns kernels are patchable via adb, and the symbol
>tables are available, we can 'patch' a larger number into the kernel
>variable.

According to the 4.3-tahoe source, the #define SUBNETSARELOCAL is used
only to initialize the variable "subnetsarelocal"; try patching that
variable, an "int" (i.e., 4 bytes, on most but not necessarily all UNIX
machines with the BSD networking code), to 1.  It appears in the SunOS
4.0 and 4.0.3 kernel on machines here; I can't speak for pre-4.0
releases of SunOS, nor for any other flavors of UNIX, or other operating
systems, that have picked up BSD networking code. 

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      6 Nov 89 19:35:23 GMT
From:      hughes@silver.bacs.indiana.edu (larry hughes)
To:        comp.protocols.tcp-ip
Subject:   Re: PCSA

In article <8911040522.AA22426@ucbvax.Berkeley.EDU> 702WFG@SCRVMSYS.BITNET (bill gunshannon) writes:
>I have a faction here at the school who are pushing to get PCSA brought
>in.  Does anyone know anything at all about this???  Will it adversely
>affect the rest of my network??? I assume it is DECNET based but other
>than that I no next to nothing about it.
>I personally would rather not have it unless someone out there knows
>of some reason why it could be the best thing since sliced bread.
>I would rather keep my network as close to pure TCPIP as possible but
>unfortunately I don't get to make the decisions, I only get to live with
>them. :-(
>
>                                          bill gunshannon
>                                       702WFG@SCRVMSYS.BITNET

We've experimented with PCSA here at IU.  I had it installed on one
of my machines for about 6 months, but haven't used it in well over
a year.  Since then, there've been several releases.

PCSA (Personal Computer Systems Architecture) does indeed run on
the DECnet suite of protocols.  Best throughput can be gotten when
accompanied with DEC's DEPCA proprietary ethernet card, but other
popular cards are supported (3COM, etc.).  The DEPCA also has a
mouse port, which permits you to use DEC's mouse as a Microsoft-
compatible mouse.

You can use any VAX/VMS machine, or a VAXmate (AT-clone) machine,
as server(s) (assuming you're properly licensed).

PCSA includes:

  o SETHOST to DECnet nodes (via LAT or CTERM protocols)
  o NETTIME to set your PC's date and time
  o NCP (network control program) for network management
  o NTU (network test utility)
  o NFT (network file transfer) - provides DCL-like commands
    for remote file access, such as DIR, COPY, DELETE,
    TYPE, PRINT, SUBMIT)
  o Network disks (H:, I:, etc.)
  o Network printing - for example, any print queue on the VMS
    server can become your LPT2:
  o Enhancements to BACKUP and RESTORE to permit network backups

It also comes with MS-Windows.

I kind of liked it, but I no longer use it.

Note:  I am in no way connected with Digital Equipment Corporation.

 //=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=\\
|| Larry J. Hughes, Senior Programmer ||  hughes@silver.bacs.indiana.edu   ||
||        Indiana University          ||                                   ||
||   University Computing Services    ||  "The person who knows everything ||
||    750 N. State Road 46 Bypass     ||     has a lot to learn."          ||
||      Bloomington, IN  47405        ||                                   ||
||         (812) 855-9255             ||  Disclaimer: See quote above.     ||
 \\=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=//



  

-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      6 Nov 89 19:45:15 GMT
From:      stine@SPARTA.COM (Robert Havens Stine)
To:        comp.protocols.tcp-ip
Subject:   Re:  Request for pointers on snmp implementations

MIT's SNMP Development Kit is available via anonymous FTP from
allspice.lcs.mit.edu, in the form of a UNIX tar file.

The CMU SNMP distribution is avaliable via anonymous FTP from
lancaster.andrew.cmu.edu (128.2.13.2), in files pub/cmu-snmp.9.tar
(for the SNMP manager) and pub/kip-snmp.9.tar (for an SNMP agent
targeted for a Kinetics FastPath gateway).

- Bob Stine

-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      6 Nov 89 19:47:00 GMT
From:      deering@PESCADERO.STANFORD.EDU (Steve Deering)
To:        comp.protocols.tcp-ip
Subject:   Multicasting on TCP/IP

> From: hashem@mars.jpl.nasa.gov (Basil Hashem)
>
> In my terms, multicasting is the ability to distribute data packets
> to a *selected* group of addresses on a network.
>
> From my readings about TCP/IP, there seems to be only two distribution
> mechanisms provided:  broadcast and point-to-point.
>
> With consideration for network/CPU (over)loading, what is the most 
> efficient way to achieve the functionality of a multicast on a
> TCP/IP network?

Basil,

Multicasting support was recently added to IP; see RFC-1112.

Currently, there are very few gateway implementations that support
Internet-wide multicast routing.  An experimental multicast routing
demon for 4.3bsd-based systems is available by anonymous FTP from
gregorio.stanford.edu; fetch the file vmtp-ip/ipmulticast.README.

Even without multicast gateways, the RFC-1112 multicast extensions
are useful for multicasting within a single network (e.g., using
Ethernet multicast addresses).

Steve Deering

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      6 Nov 89 19:52:49 GMT
From:      702WFG@SCRVMSYS.BITNET (bill gunshannon)
To:        comp.protocols.tcp-ip
Subject:   Re: POP3

I have seen a number of places where I can get a POP3 server.  Now can
anyone tell me where I can find a POP3 client??
Thank you.

                                          bill gunshannon
                                       702WFG@SCRVMSYS.BITNET

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      6 Nov 89 20:09:51 GMT
From:      jimm@haddock.ima.isc.com (Jim McGrath)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: X.25 streams modules for TCP/IP

In article <BOB.89Nov6105123@archer.MorningStar.Com> bob@MorningStar.Com (Bob Sutterfield) writes:
>In article <560@medusa.informatik.uni-erlangen.de> eckert@immd4.informatik.uni-erlangen.de (Toerless Eckert) writes:
>   The PDN routing group (of the IETF)...
>
>Would someone in that group please contact me?  I'd like to learn what
>you're up to.  Thanks!

So would I.  Perhaps someone could post a short summary, and provide
contact information.

Jim

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      6 Nov 89 20:16:08 GMT
From:      dan@ccnysci.UUCP (Dan Schlitt)
To:        comp.protocols.tcp-ip
Subject:   Re: NSFNET-RELAY.AC.UK down?

In article <10099@ucsd.Edu> brian@ucsd.Edu (Brian Kantor) writes:
:For the last week or so, UCSD.EDU has been unable to open SMTP
:connections to host 'nsfnet-relay.ac.uk' (connections just time out),
:but we can ping them and it looks like remote login on port 23 is
:working ok.  Has anyone else noticed this happening from his site or
:are we having an isolated problem?
:	- Brian

A couple of months ago we had this problem very frequently.  It was
almost impossible to get mail through.  It would frequently accept
the connection and then not respond to any smtp request.  The result
was an eventual timeout and the mail in the queue had the message
"Bad file number".  It has not occurred very frequently in recent
days.  I sent mail to postmaster@nsfnet-relay.ac.uk, but by the time
it got there the problem had gone away. :-)

-- 
Dan Schlitt                        Manager, Science Division Computer Facility
dan@sci.ccny.cuny.edu              City College of New York
dan@ccnysci.uucp                   New York, NY 10031
dan@ccnysci.bitnet                 (212)690-6868

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      6 Nov 89 20:41:34 GMT
From:      attcan!utgpu!dennis@uunet.uu.net  (Dennis Ferguson)
To:        tcp-ip@NIC.DDN.MIL
Subject:   Re: Pilot Project: Hosts Table To Be Available Over Internet
In article <71367@uunet.UU.NET> rick@uunet.UU.NET (Rick Adams) writes:
>OK. I give up. What are these "good reasons" that seem to
>elude everyone else. (Kludging broken software is not a good reason)

I can think of two reasons with some merit:

(1) Walking the domain name tree is about the only way there is
    (however inaccurate) of estimating the size of the Internet
    in terms of hosts.  This is an interesting number to know, and
    keeping track of its growth (say by rebuilding the table three
    or four times a year) would be a worthwhile project.

(2) The file itself is occasionally useful as raw data for experiments
    which attempt to measure something about every host on the Internet.
    There have been two experiments to measure the time keeping
    precision of a substantial fraction of Internet hosts, one or
    both of which were published as RFC's.  The latest one used the
    110,000 host table derived from the DNS.  The results make for
    interesting reading and can provide useful insight if you like
    that kind of thing.  If the table (or the ability to create one)
    didn't exist such experiments couldn't be done.

That said, I absolutely agree with the comment about "kludging broken
software".  I think Mr. Bernstein picked a worthy project to pursue,
I just think he picked an utterly wrong reason for pursuing it.  The
frequency of update is too high as well.  Doing an update every three
or four months, announcing how many lines were in the file, and putting
it somewhere where people who wanted to play could find it, would be
more than adequate.

Dennis Ferguson
University of Toronto
-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      6 Nov 89 21:03:10 GMT
From:      zodiac!confusion!barry@ames.arc.nasa.gov  (Barry Lustig)
To:        tcp-ip@NIC.DDN.MIL
Subject:   Re: Sun's silly TCP implementation

				   
In my SunOS 4.0.3 kernel, the value of the symbol subnetsarelocal is
1.  This implies to me that that MSS choosing code is compiled into
the distributed binaries.  It also implies that TCP should not be
choosing the smaller MSS by default, it should be using the larger
one.


barry
-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      6 Nov 89 21:33:17 GMT
From:      cliff@WSU-ENG.ENG.WAYNE.EDU (Cliff Stallings)
To:        comp.protocols.tcp-ip
Subject:   print server

I'm not that familar with Sun's, but if you can connect the printers
to a SUN or the Mac running AUX then run CAP which was written to
run under UNIX, then the Mac under OS could access the printers.
You could then run LPD on the Mac running AUX so the other machines
can also print on those printers.  FYI

                        Brian Holmes
                        CSC Operating Systems & Communications

SNAIL    : Wayne State University, 5925 Woodward, Detroit MI 48202 U.S.A.
BITNET   : BHOLMES@WAYNEST1
INTERNET : Brian_Holmes@UM.CC.UMICH.EDU
UUCP     : {UMIX|ITIVAX}!WAYNE-MTS!BRIAN_HOLMES
----------------------------Original message----------------------------
I have a network consisting of one sun-4, one sun-4, 2 pc's, 1 mac II running
mac os, and 1 mac II running a/ux.

All systems are connected via ethernet cards to tcp/ip based network.

I have a laser writer and an image writer which I would like to access from
all of my systems.  Can anyone help me?

   cliff@wsu-eng.eng.wayne.edu

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      6 Nov 89 22:12:45 GMT
From:      MAP@LCS.MIT.EDU (Michael A. Patton)
To:        comp.protocols.tcp-ip
Subject:   NSFNET-RELAY.AC.UK down?


   Date: 4 Nov 89 13:48:22 GMT
   From: brian@ucsd.edu  (Brian Kantor)

   For the last week or so, UCSD.EDU has been unable to open SMTP
   connections to host 'nsfnet-relay.ac.uk' (connections just time out),
   but we can ping them and it looks like remote login on port 23 is
   working ok.  Has anyone else noticed this happening from his site or
   are we having an isolated problem?
	   - Brian

You may be suffering from "malnourished TTL".  We've seen the diameter
of the Internet go up quite a bit in the last several months (and yes,
one of these occured in "the last week or so".  This is primarily due
to the switch in long-haul technology from the ARPAnet which counted
(incorrectly) as only one decrement to the TTL to networks of IP
gateways that decrement the TTL each time.  From two traceroutes I ran
from here (and reproduced below my signature) I would estimate your
distance (measured by TTL) from NSFNET-RELAY.AC.UK is near 15 which
was an old standard for max TTL.  Most places have discovered that
they need to up this to 30 to get traffic through and I expect in the
near future that may not be enough.  From here I successfully opened
SMTP connections to both UCSD.EDU and NSFNET-Relay.AC.UK and did some
minor things (manually) so I have to suspect it's a specific
interaction between your two machines.

	    __
  /|  /|  /|  \		Michael A. Patton, Network Manager
 / | / | /_|__/		Laboratory for Computer Science
/  |/  |/  |atton	Massachusetts Institute of Technology

Disclaimer: The opinions expressed above are a figment of the phosphor
on your screen and do not represent the views of MIT, LCS, or MAP. :-)
----------------------------------------------------------------
traceroute nsfnet-relay.ac.uk
traceroute to nsfnet-relay.ac.uk (128.86.8.6), 30 hops max, 40 byte packets
 1  18.26.0.137 (18.26.0.137)  50 ms  10 ms  20 ms
 2  W91GW.MIT.EDU (18.68.0.22)  20 ms  30 ms  20 ms
 3  JVNCNET-GW1.MIT.EDU (18.92.0.12)  20 ms  20 ms  20 ms
 4  beantown2-gateway.jvnc.net (130.94.27.9)  30 ms  20 ms  20 ms
 5  cheesesteak1-gateway.jvnc.net (130.94.27.249)  40 ms  30 ms  40 ms
 6  cheesesteak2-gateway.jvnc.net (130.94.32.2)  30 ms  30 ms  40 ms
 7  capital1-gateway.jvnc.net (130.94.33.249)  30 ms  40 ms  30 ms
 8  hotblack-gateway.jvnc.net (130.94.1.10)  30 ms  30 ms  70 ms
 9  ford-gateway.jvnc.net (130.94.0.73)  40 ms  40 ms  40 ms
10  fenchurch-gateway.jvnc.net (128.121.54.78)  80 ms  40 ms  30 ms
	[...No responses for 11-22...]
23  NSFNET-RELAY.AC.UK (128.86.8.6)  630 ms !  1210 ms !  630 ms !
----------------------------------------------------------------
traceroute ucsd.edu
traceroute to ucsd.edu (128.54.16.1), 30 hops max, 40 byte packets
 1  18.26.0.137 (18.26.0.137)  20 ms  20 ms  20 ms
 2  W91GW.MIT.EDU (18.68.0.22)  10 ms  30 ms  20 ms
 3  JVNCNET-GW1.MIT.EDU (18.92.0.12)  20 ms  30 ms  110 ms
 4  beantown2-gateway.jvnc.net (130.94.27.9)  20 ms  20 ms  20 ms
 5  cheesesteak1-gateway.jvnc.net (130.94.27.249)  30 ms  30 ms  30 ms
 6  cheesesteak2-gateway.jvnc.net (130.94.32.2)  30 ms  20 ms  40 ms
 7  capital1-gateway.jvnc.net (130.94.33.249)  30 ms  30 ms  40 ms
 8  hotblack-gateway.jvnc.net (130.94.1.10)  30 ms  30 ms  60 ms
 9  zaphod-gateway.jvnc.net (130.94.0.72)  30 ms  60 ms  40 ms
10  College_Park.MD.NSS.NSF.NET (129.140.73.8)  80 ms  80 ms  90 ms
11  Houston.TX.NSS.NSF.NET (129.140.75.9)  190 ms  200 ms  160 ms
12  San_Diego.CA.NSS.NSF.NET (129.140.70.11)  240 ms  220 ms  220 ms
13  * * *
14  bach.sdsc.edu (192.12.207.3)  230 ms  250 ms  240 ms
	[...No responses for 15-28...]
29  ucsd.edu (128.54.16.1)  250 ms !  270 ms !  230 ms !

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      6 Nov 89 22:31:53 GMT
From:      franceee@image.soe!clutx.clarkson.edu (Eric France,,,)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Information Request

I was advised to bring this question to this forum, so...

I am planning a ~20 minute presentation on the subject of 
Internet.  However, no information is available through
the normal sources here (libraries, etc.).  

If anyone has any papers, information, notes, or
even anecdotes about the history or basic nature
of Internet, or know of any publications that I 
might be able to beg/borrow/steal/mail-order, please
reply to my address below.

Thank you.


Eric France                      "I don't have a one-track mind, I have
franceee@clutx.clarkson.edu       an eight-track mind.  You just can't
                                  get the tapes anymore."
                                              -- David Addison

-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 89 02:08:13 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP for Data General

In article <8911031415.AA26759@ucbvax.Berkeley.EDU>, ESC1814@ESOC.BITNET writes:
>...
> Are we talking Bytes or Bits per second, and if it is bytes/sec
> whose TCP are you using? Where can I get it?
> 
> Dave Stafford
> Comms. Eng
> European Space Agency
> Darmstadt, W. Germany                     : Standard Disclaimer .. blah blah..


TCP/IP that runs >>500KByte/sec or >>4Mbit/sec over ethernet can be found
on uunet or on the BSD network release tape.  You may need to ensure that
you have reasonable compilers and hardware.  You may need to tune to get
above 500KB, but radical changes are unnecessary.

A not at all new pair of Sun 4/260' got about 800KBytes/sec using the
user-process-to- user-process TCP/IP test, ttcp, on a quiet ethernet, after
killing stray demons, doing tests several MB long.  Graphs on my wall show
some IRIS's getting >>900KBytes/sec in those circumstances.  In at least
some circumstances, it seems to take much less than 50% of a single fast
CPU to push the network.  Some but not all IRIS's are symmetric-MPs.  All
IRIS and the Sun 4/260 have faster CPU's than 386's.

As far as I know, the Sun SPARC systems were running 4.x-related, non-header-
predicting TCP/IP, but someone else would have to describe precisely and
authoritatively the Sun 4 system.   The IRIS TCP/IP is
4.3+Jacobson/Karels+tuning.

I have no doubt that other current hardware and software can do at least as
well as 900KB.  I assume that current Sun hardware and software is faster
than the old numbers above.  The machines named above are not intended as
advertisements, but concrete evidence of my previous claim.  Please do not
buy any Sun's based on this note.  If you buy Silicon Graphics IRIS's,
please forget reading this.

Unfortunately, there is evidence that some people are selling 300KB TCP
as "very fast", or even using FTP as a TCP benchmark.  (FTP might be a
filesystem/TCP/IP benchmark.)


Vernon Schryver
Silicon Graphics
vjs@sgi.com

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 89 02:42:51 GMT
From:      smb@ulysses.homer.nj.att.com (Steven M. Bellovin)
To:        comp.protocols.tcp-ip
Subject:   Re: Sun's silly TCP implementation

In article <8911061348.AA15233@aqua.whoi.edu>, mep@AQUA.WHOI.EDU (Michael E. Pare) writes:
} You have to remember that a router has a lot of work to do on the packets
} in order to be able to forward them.  They are only designed to have a
} throughput of a few thousand packets per second (I can't remember the exact
} figure), far less than a bridge (over 12000 packets per second), and
} certainly far less than running two machines on the same net, whose biggest
} restriction will be the machines themselves.

Modern routers -- i.e., the Cisco or Wellfleet ones -- can route packets
at ~12,000/sec; see the results that Scott Bradner posted a couple of
months ago.
} 
} In terms of packet sizes, this is set when you first configure the Sun's
} and has nothing to do with the p4200.  The p4200 will handle a packet the
} size of the largest interface, which in this case is the Pronet 80 link,
} and is about 2046 bytes.  You should be able to utilize 1500 byte packets
} to match the ethernet restriction.  Try reconfiguring your Sun's to
} negotiate a larger packet size.  


This is simply wrong.

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 89 02:47:16 GMT
From:      mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re:  Traceroute sources

Speaking of traceroute.  Is there a public domain version with sources that
will run under VMS 5.1-1 and interface to WIN/TCP 5.0?

Merton

-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 89 03:42:34 GMT
From:      harriman@quando.UUCP (Jay Harriman)
To:        comp.protocols.tcp-ip
Subject:   Please remove this user from the list


Please remove this address, harriman%quando@UNIDO.bitnet or harriman@quando
from this list. Mr harriman no longer uses this account and it will be
removed in a few days.

I am sorry for not knowing how to remove this address from the list,
it is not a bitnet listserver so I am lost.

Many Thanks,

Kevin Henigan, postmaster%quando@UNIDO.bitnet or postmaster@quando

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 89 04:59:29 GMT
From:      Makey@LOGICON.ARPA (Jeff Makey)
To:        comp.protocols.tcp-ip
Subject:   Re: Pilot Project: Hosts Table To Be Available Over Internet

I am a competent (technically and otherwise) system administrator, and
I would dearly love to change my MILNET host to use the domain system
to resolve host names and addresses rather than download a
woefully-incomplete HOSTS.TXT file from the NIC every time it changes,
but there's a small catch.  LOGICON.ARPA is a VAX-11/780 running BSD
4.2 (that's four-point-two), and it doesn't support DNS in any way
whatsoever.  While *I* am more than willing to upgrade my system, my
company (and our primary source of funds: the U.S. Government) won't
shell out a cent for it.  Nevertheless, I am willing to invest a few
hours of my own time if it will make a difference.

So, if it's as easy as everyone claims, tell me how I can upgrade my
4.2 BSD VAX to use the DNS without spending any hard cash.  Be
specific (and be sure to tell me the Internet numbers of any relevant
hosts that aren't in HOSTS.TXT :-).  I'm listening.

                           :: Jeff Makey

Department of Tautological Pleonasms and Superfluous Redundancies Department
    Disclaimer: Logicon doesn't even know we're running news.
    Internet: Makey@LOGICON.ARPA    UUCP: {nosc,ucsd}!logicon.arpa!Makey

-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 89 06:34:06 GMT
From:      brian@ucsd.Edu (Brian Kantor)
To:        comp.protocols.tcp-ip
Subject:   Re: NSFNET-RELAY.AC.UK down?

Nsfnet-relay.ac.uk seems to have fixed whatever the problem was sometime
Saturday; all our mail to them cleared out in the space of an hour or so.

There never seemed to be a problem with the links to them; telnet login
always worked just fine.  I assume their mailer wedged somehow.  In any
case, it's working ok now.

Thanx, everyone!
	- Brian

-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7 Nov 89 12:11:30 EST
From:      "Jay Elinsky" <ELINSKY%YKTVMZ.BITNET@CUNYVM.CUNY.EDU>
To:        tcp-ip@nic.ddn.mil
Subject:   Use of minimum MSS through router
TCP/IP for VM and TCP/IP for MVS, from IBM, give you the option of specifying
the MSS for each destination (sub)network.

                                       Jay Elinsky
                                       IBM T.J. Watson Research Center
                                       Yorktown Heights, NY
-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 89 13:38:06 GMT
From:      dfk@eu.net (Daniel Karrenberg)
To:        comp.protocols.tcp-ip
Subject:   Re: Traceroute & SunOS 4.0.3


 daemon@watale.waterloo.edu (joejobber process) writes:

 >Does anyone have the patched kernel objects necessary to run traceroute
 >under SunOS 4.0.3 on either Sun3's or 4's (both would be fabulous).
 >I'm quite certain that a modified raw_ip.o is involved, but I'm not
 >sure if anything else is required.  Would it be possible that some kind
 >soul could make the patched objects available via anonymous ftp?
 

Not really necessary.  I have taken raw_ip.c from the traceroute
distribution, put it in /usr/sys/netinet, changed the Makefile to
compile it and take the object in place of the one in
/usr/sys/sun?/OBJS, built a new kernel and hey presto - traceroute works
on my 4/260 known as mcsun.eu.net. 
-- 
Daniel Karrenberg                    Future Net:  <dfk@cwi.nl>
CWI, Amsterdam                        Oldie Net:  mcvax!dfk
The Netherlands          Because It's There Net:  DFK@MCVAX

-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 89 14:07:30 GMT
From:      keith@spider.co.uk (Keith Mitchell)
To:        comp.protocols.tcp-ip
Subject:   Re: X.25 streams modules for TCP/IP

Spider's IXE (IP-to-X.25 Encapsulation) facility allows you to run
IP over X.25 as per RFC877 in a STREAMS environment, such as Unix
SVR3.2.

Basically it exists as a seperate STREAMS module which provides the
glue between SpiderTCP and SpiderX.25. By implementing IXE as a
seperate module, the interface to IP can be identical to that used
for Ethernet, SLIP, SNAP or any other sub-network. X.25 is also
implemented as set of distinct modules, so it can be used by other
services such as PAD.

IP to X.121 address mapping is supported by an in-kernel table which
is configurable through ioctl calls. Clearly this can become a
monster if there are a lot of these, so some means of dynamically
learning the mappings sounds like a good idea to me.

I would be very interested to know more about the workings of the
IETF's PDN Routing Group - RFC877 has long struck me as being rather
skimpy, and I suspect that as more European sites use IP, being able
to run it over X.25, (which appears to much more viable here than in
the US) will I think become more popular, making the need for some
new standards work in this area very timely.

Keith Mitchell

Spider Systems Ltd.             Spider Systems Inc.
Spider Park    		        12 New England Executive Park
Stanwell Street                 Burlington
Edinburgh, Scotland             MA 01803
+44 31-554 9424                 +1 (617) 270-3510

keith@spider.co.uk              keith%spider.co.uk@uunet.uu.net
...!uunet!ukc!spider!keith      keith%uk.co.spider@nsfnet-relay.ac.uk

-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 89 16:07:25 GMT
From:      "Marco_A_Gonzalez.WBST897ai"@XEROX.COM
To:        comp.protocols.tcp-ip
Subject:   Re: Telnet library ?

Rick,

Could you let me know about the telnet library when you find it?  Thanks.

Marco A.

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 89 16:42:04 GMT
From:      stine@SPARTA.COM (Robert Havens Stine)
To:        comp.protocols.tcp-ip
Subject:   Re:  Hopcheck

> Thanks for the pointer to hopcheck, but I can't seem to find it.
> I looked around on windom.ucar.edu, and didn't see a hopcheck.tar.Z anywhere.
> I tried ftp'ing to udavis.edu, and the site seems to be unknown (at least
> by that name).

Sorry.  Try FTPing ucdavis.ucdavis.edu (128.120.2.1).  In compressed
UNIX tar format, the executable and source distribution files are
~/dist/nethopexe.tar.Z and ~/dist/nethopsrc.tar.Z.  The same directory
has the executable and source distributions in ARC format.

I couldn't find the distribution at windom.ucar.edu, either.  I'll let
you know if I do.

- Bob Stine

-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 89 17:11:30 GMT
From:      ELINSKY@YKTVMZ.BITNET ("Jay Elinsky")
To:        comp.protocols.tcp-ip
Subject:   Use of minimum MSS through router

TCP/IP for VM and TCP/IP for MVS, from IBM, give you the option of specifying
the MSS for each destination (sub)network.

                                       Jay Elinsky
                                       IBM T.J. Watson Research Center
                                       Yorktown Heights, NY

-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 89 23:19:17 CST
From:      "SMTP MAILER" <postmaster@cim-vax.honeywell.com>
To:        "tcp-ip" <tcp-ip%sri-nic.arpa@cornellc.cit.cornell.edu>
Subject:   Mail not delivered yet, still trying
 ----Mail status follows----
Have been unable to send your mail to <morales@nl8350.dsg.honeywell.com>,
will keep trying for a total of three days.
At that time your mail will be returned.

 ----Transcript of message follows----
Date: 7 Nov 89 19:03:00 CST
From: tcp-ip%sri-nic.arpa@CORNELLC.cit.cornell.edu
Subject: Sender-initiated file transfer and FTP
To: "morales" <morales@nl8350.dsg.honeywell.com>

Return-Path: <tcpip-request@cim-vax.honeywell.com>
Received: from NIC.DDN.MIL by cim-vax.honeywell.com with SMTP ; 
          Tue,  7 Nov 89 19:02:47 CST
Received: from CORNELLC.cit.cornell.edu by NIC.DDN.MIL with TCP; Mon, 6 Nov 89 05:15:18 PST
Received: from WAYNEST1.BITNET by CORNELLC.cit.cornell.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 0472; Mon, 06 Nov 89 08:16:38 EST
Received: by WAYNEST1 (Mailer X1.25) id 9118; Mon, 06 Nov 89 08:15:59 EST
Resent-Date:  Mon, 06 Nov 89 08:03:09 EST
Resent-From:  Brian Holmes <BHOLMES%WAYNEST1.BITNET@CORNELLC.cit.cornell.edu>
Resent-To:    tcp-ip@sri-nic.arpa
Received: by WAYNEST1 (Mailer X1.25) id 3986; Mon, 06 Nov 89 01:23:17 EST
Date:         Mon, 30 Oct 89 23:24:09 GMT
Reply-To:     TCP-IP%SRI-NIC.ARPA@CORNELLC.cit.cornell.edu
Sender:       ARPA TCP-IP Discussion Redistribution <TCP-IP%UTDALVM1.BITNET@CORNELLC.cit.cornell.edu>
From:         tcp-ip-relay%NIC.DDN.MIL@CORNELLC.cit.cornell.edu
Subject:      Sender-initiated file transfer and FTP
X-To:         tcp-ip@NIC.DDN.MIL
To:           Brian Holmes <BHOLMES@WAYNEST1.BITNET>

The IBM implemetation is supplied with a modified SENDFILE EXEC
which allows you to SF MYPROG C TO BRIAN AT CMS.CC.WAYNE.EDU
This will currently only transfer TEXT files over TCP/IP.
Basicallly it just adds a RFC 822 mail header to the file.

                        Brian Holmes
                        CSC Operating Systems & Communications

SNAIL    : Wayne State University, 5925 Woodward, Detroit MI 48202 U.S.A.
BITNET   : BHOLMES@WAYNEST1
INTERNET : Brian_Holmes@UM.CC.UMICH.EDU
UUCP     : {UMIX|ITIVAX}!WAYNE-MTS!BRIAN_HOLMES
----------------------------Original message----------------------------
>1. RSCS, at least under VM/CMS, offers a very easy-to-use interface
>to this service.  One simply says:
>
>        SEND MYPROG C TO LEXVM1
>
>Forgetting the other limitations of CMS for the moment, it is convenient
>that this is the only command needed to send the file.
>
>Using FTP, one would first send the file to the anonymous FTP area of
>the receiving system, and then send the recipient mail informing
>him/her of it.  However, I do not know of a widely available interface
>to these functions which is as easy to use as the SENDFILE command of CMS.
>--
>Craig Jackson
>dricejb@drilex.dri.mgh.com
>{bbn,ll-xn,axiom,redsox,atexnet,ka3ovk}!drilex!{dricej,dricejb}

-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 89 17:40:39 GMT
From:      rick@uunet.UU.NET (Rick Adams)
To:        comp.protocols.tcp-ip
Subject:   Re: Pilot Project: Hosts Table To Be Available Over Internet

ftp uunet.uu.net
user anonymous
password yourname
cd bsd-sources/src/network
binary
mget *
quit

named.tar.Z contains the name daemon (BIND) that acts as server.
Extract and install it first. When its up and running, then
convert your applications over to use it instead of /etc/hosts.
(Budget a full working day to get bind configured and installed)

That directory also contains the source to all of the BSD networking
programs in case you dont have source yourself.

It will take a small amount of work to get the 4.3 sources running 
under 4.2, but it should take less than a day (It took me about 6 hours
to get them installed under Dynix, which is close enough to 4.2)

Figure 1 working day to get bind installed and another day to convert
the networking user level programs.

If you're still running 4.2 you also have some serious kernel level
networking bugs that you should work on. The updated TCP code should
fit in fairly easily into your 4.2 kernel. (Another day probably)

There. We've got you running DNS in exchange for 2-3 working days and
no cash.

---rick

-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 89 18:17:36 GMT
From:      guy@auspex.auspex.com (Guy Harris)
To:        comp.protocols.tcp-ip
Subject:   Re: Can you fix (Re: Sun's silly TCP implementation)???

>You can adb -w vmunix on a Sun and alter the following values for under
>SUNOS4.X kernels:
>
>adb -w vmunix
>tcp_mss+0xac?		200
>tcp_mss+0xbc?		200
>(200=~512 byrtes/packet)

Try again.  That sure didn't work when I looked at those locations on
this machine, but then this machine doesn't have any 68K-family or
80*86-family processor lurking inside it - i.e., your patch may work on
a Sun-3 or a Sun386i or whatever machine you did it on, but it won't
work on other Suns.  Perhaps you want to think about patching
"subnetsarelocal" instead, since that doesn't change the non-local MSS
globally, but just changes the system's notion of what a local host
is....

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 89 18:20:39 GMT
From:      guy@auspex.auspex.com (Guy Harris)
To:        comp.protocols.tcp-ip
Subject:   Re: NSFNET-RELAY.AC.UK down?

>The result was an eventual timeout and the mail in the queue had the message
>"Bad file number".

If the message "Bad file number" appears in bounced mail, the chances
are overwhelmingly high that the message has nothing whatsoever to do
with reality; it's a side effect of the way UNIX handles errors in
system calls, and the way "sendmail" (or, at least, the older versions
of same) handles errors in UNIX.  I.e., the mail probably bounced due to
a timeout, not to an invalid file descriptor. 

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 89 18:33:27 GMT
From:      aggarwal@JVNCA.CSC.ORG (Vikas Aggarwal none)
To:        comp.protocols.tcp-ip
Subject:   Traceroute sources


I can point yu to sources of traceroute, but as for VMS (if you can find
out whether there are ICMP sockets available, maybe...).

-vikas

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 89 19:01:58 GMT
From:      craig@bbn.com (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   work on MTU discovery

Several days ago someone (Henry Spencer?) posted a query about whether
someone was working on making MTU discovery a reality.  The answer is
yes -- there's a newly formed IETF working group trying to get MTU discovery
to the point it can become a safely standardized IP option.

People interested in tracking developments like this are encouraged
to join the IETF mailing list (ietf-request@isi.edu).

Craig

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 89 19:34:30 GMT
From:      ubc-cs!alberta!mts.ucs.UAlberta.CA!ualtavm!DKRUGER@beaver.cs.washington.edu  (Dwight Kruger)
To:        tcp-ip@NIC.DDN.MIL
Subject:   Public Domain tn3270 for SUNs
I am looking for a public domain version of tn3270 for my SUN network.  We
have a network of SUN 350's running SUN OS 3.4.  I am looking for a version
that would be available via anonymous FTP.
 
Dwight Kruger
Network Software Development
The University of Alberta
-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 89 19:45:29 GMT
From:      solensky@interlan.interlan.COM (Frank Solensky)
To:        comp.protocols.tcp-ip
Subject:   FTP command/data synchronization


	Is there any specific requirement that reply codes sent over an
FTP control connection be synchronized with the packets transmitted over
the data connection?  I've checked through both RFCs 1123 and 959 a few times
and have found quotes that imply that they both must be in synch and aren't
expected to be in synch but haven't come up with anything conclusive.
(However, many in the former category seem to be based on an assumption that
the phrase "close(d) the connection" == "send(/received) a FIN").

	When some client FTP program is being used to pull a file across the
net, a time-sequence diagram of what is occuring is this (stream data
connection, using SO_NODELAY):

	FTP client	net traffic		FTP server
	----------	-----------		----------
	GET file
			C-> RETR file (WIN > 0)
						ds = socket()
	opens a socket
			D-> SYN,WIN=0 (et al)
						send() file
						close(ds)
			C<- "226 closing connection" message
			D-> WIN > 0
			D<- data
			D<- FIN

What I'm looking for is some passage in either RFC or some other source that
states this is or is not acceptable.

TIA.						Frank Solensky
						Racal InterLan
or 

-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 89 21:01:18 GMT
From:      zweig@brutus.cs.uiuc.edu (Johnny Zweig)
To:        comp.protocols.tcp-ip
Subject:   ARP+

I am writing an implementation of IP which, to start out, is only going to
run on a host with a single ethernet interface.

There seem to be a number of different ways of answering the question "Which
ethernet address a:b:c:d:e:f is the best on to send IP-packets for destination
W.X.Y.Z to?" To wit:

	ARP will give you a good answer if W.X.Y.Z is on the same physical
	subnet as you. Also works if there is only one gateway on that net
	and it decides to do proxy-ARP for everybody else.

	If there is only one gateway and you knows its ethernet address
	(which you can get a number of different ways), send all non-local
	traffic there.

	Otherwise you need to do some variant of RIP or IGP or something...

Consider a hypothetical protocol ARP+ which is like ARP but with (RIP-like)
metrics associated with each response. The metric would be 0 for hosts that
are on the same physical net (i.e. "a:b:c:d:e:f is actually an interface for
W.X.Y.Z"), and gateways could consult their routing-tables (from RIP, say)
and give responses like "a:b:c:d:e:f is N hops away from W.X.Y.Z"). To
process ARP+ packets, I just build a table with IP-address<->ethernet-address
mappings with associated costs. Whenever an ARP+ reply comes in with a lower
cost than the mapping in my table, update the mapping. (The entries go stale
as in vanilla ARP, of course.)

This sort of idea would work fine on a net with 0, 1 or more gateways. The
gateway closest to a non-local network would always win the voting, and I
don't need any of this default-routing stuff that would be inappropriate
on a net with >1 gateway.

QUESTIONS:  Would it be hip just to use RIP as though it were ARP+? That is,
would it be bad to send out a RIP-request every time I send out an ARP
packet? (I don't like the fact that RIP sits on top of UDP which is on top of
IP but is still part of IP's very soul....)

Is there something that does basically the same thing? How well-supported
is it?

What I am aiming at is an implementation of IP that has _no_ hardcoded
ARP mappings (like some I've seen), does _not_ assume that there is exactly
one gateway (like many I've seen), and is compatible with as much as is
possible (which is why I am thinking of using RIP in what I am unsure is a
groovy way). Basically it seems like a tiny enhancement to ARP would suit
these needs perfectly - anyone feel like whipping up an RFC if there isn't
such a protocol out there? (I can't seem to find it in the current RFC index).

-Johnny IP

-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 89 21:01:43 GMT
From:      brian@t2ns1.gcs.co.nz
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.periphs.printers
Subject:   Anybody know of an enet/TCP printer?


Hi y'all.

Has anybody ever come across a printer hanging directly off a thick
enet transceiver? We have a situation here where such a printer would
be invaluable. Obviously it would need appropriate intelligence to
handle addresses, domains etc. with it's card.

Preferably a laser, HP II compat.
There are three minis on our lan, running TCP/IP, Thick+thin, B20's,
Pacnet etc. etc. etc.

Any and all help greatly appreciated. Thanks in advance,


-- 
 Brian Burroughs (I know I have a boring .sig!), Govt Computing Service Ltd, 
_________ P.O. Box 11-642, Manners Street, Wellington, New Zealand. _________
______________ Voice: +64 4 801-8000   Fax: +64 4 801-8888 __________________
_____________________ Email: brian@t2ns1.gcs.co.nz __________________________

-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 89 21:49:00 GMT
From:      CURT.ELLMANN@MAIL.ADMIN.WISC.EDU
To:        comp.protocols.tcp-ip
Subject:   FAX over TCP/ip

Comment: Processed by UWGATE

to: tcp-ip@nic.ddn.mil

Several weeks ago (?) there was a bit of activity on this group
about exchanging FAX data streams over TCP/IP networks.

Is anyone doing this now?  Are there any plans to do this sort of
thing?  Surely *someone* is working on an RFC, right?  I would
sincerely appreciate any leads.

Thanks.

-curt.
curt.ellmann@mail.admin.wisc.edu                                               ?

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 89 22:33:12 GMT
From:      sansom@trwrb.UUCP (Richard E. Sansom)
To:        comp.protocols.tcp-ip
Subject:   Re: Problems with tn3270


In article <121@venice.SEDD.TRW.COM> gay@venice.sedd.trw.com (lance gay) writes:
>...the software aborts with a "Short count received from host!" error message.
>
>Lance Gay                                    Internet: gay@venice.sedd.trw.com
>TRW Systems Engineering & Development Div.   Phone: 213-328-1892
>Redondo Beach, CA  90278

Lance, if you have the same code I do, then the problem is in the
disttn3270/telnet/Source/telnet.c file.  Unfortunately, I didn't save
a copy of the bad code, so I only have the fix.  Take a look for the
"case EOR:" switch statement.  Here's the way the code looks in my
fixed version:

	    case EOR:
		if (In3270) {
/* begin fix */
		    if (Ibackp == Ifrontp) {
			Ibackp = Ifrontp = Ibuf;
			ISend = 0;	/* should have been! */
		    } else {
			Ibackp += DataFromNetwork(Ibackp, Ifrontp-Ibackp, 1);
			ISend = 1;
		    }
/* end fix */
		}
		break;

See, it only made sense to call the DataFromNetwork() routine if Ifrontp
and Ibackp were NOT equal, and I think the original code was doing just the
opposite.

Anyway, if you make these changes, you _should_ get a working version.

-Rich

...ucbvax!trwrb!sansom
sansom@trwrb.dsd.trw.com

-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 89 22:36:12 GMT
From:      dcrocker@DECWRL.DEC.COM (Dave Crocker)
To:        comp.protocols.tcp-ip
Subject:   Re: private mib variables

I don't recall seeing anyone try to answer this, yet, so please forgive
the delay.  The IETF met, last week, and I wanted to verify the procedure
for getting MIB numbers.

Turns out to be painfully simple:

Send a request to the Keeper of Numbers:

	Joyce K. Reynolds (jkrey@isi.edu)

Joyce works with the Numbers Czar, Jon Postel.

In effect, you simply are registering your organization.  She will give
you a number that resides under the private mib extensions portion of the
tree.

Dave Crocker
IETF Area Director, Network Management

-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 89 22:51:55 GMT
From:      mx!cbcscmrs@csun.edu
To:        comp.protocols.tcp-ip
Subject:   Re:  MXing the world (was RE:  New Host-Requirement RFCs)

In article <8911051717.AA10735@alw.nih.gov> RAF@CU.NIH.GOV ("Roger Fajman") writes:
+----
| > As to source routing specifically, it has always seemed to me
| > a problem to know which gateways to route through. ...
| > Once I memorized a likely
| > gateway/relay, they'd retire the darn thing, for instance.
| 
| You may not know that on the BITNET side, the user does not have to
| know the name of the gateway.  At most sites, it's handled
| automatically by the software.  Thus on the BITNET side, the change
| from WISCVM was pretty transparent to users, as long as their system
| administrators used up to date tables.  Of course, there were some
| problems because not all did.
+----

I have one simple question, why don't we (The Internet side) put an MX record
into the root servers for the top-level domains .bitnet and maybe even .uucp?

We can point them to cunyvm.cuny.edu or ucbvax.berkeley.edu or new.foo.bar.net
or whatever the lastest host is.  Once all those horrible sendmail files are
fixed once and for all (any special casing removed), it would be hard for
things to not work transparently, right?

Or am I totally confused?  Or is it a political nightmare?

On another note, is it true that From: lines in RFC conforming mail messages
or news should have a valid address?  Where ``valid address'' is one in which
an nslookup of the stuff to the right of the @ would either give an address
or an MX record for it.  What I mean is From: me@place.bitnet a ``legal''
address in your opinion?  For what definition of ``legal?''

If they are not ``legal,'' can we bug people that send mail with ``illegal''
from: lines to fix their system?  Should we?

-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 89 23:07:43 GMT
From:      brutus.cs.uiuc.edu!uakari.primate.wisc.edu!aplcen!fallst!tkevans@husc6.harvard.edu  (Tim Evans)
To:        tcp-ip@NIC.DDN.MIL
Subject:   Need TCP/IP for 80286 *NIX
I'm looking for information and/or sources for TCP/IP networking to
run on 80286 *NIX.  The particular implementation is System V.2, but
is limited in that it doesn't support large model compiles.  Will
the PCIP's and the KA9Q's work in this environment?  Also, these machines
are part of a mixed environment in which we also run SCO Xenix 386,
BSD, and SunOS.  All suggestions appreciated.
-- 
UUCP:		uunet!anagld!aplcen!fallst!tkevans
INTERNET:	tkevans@wb3ffv.ampr.org
OTHER:		attmail!fallst!tkevans
Tim Evans	2201 Brookhaven Ct, Fallston, MD 21047  (301) 965-3286
-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 89 23:33:05 GMT
From:      root@csoftec.csf.com (Cliff Manis)
To:        comp.protocols.tcp-ip,comp.sources.wanted,comp.unix.questions,to.csoftec
Subject:   BFTP Program for System V


     -------->    NEED A "BFTP" program 

	I would like to obtain a look-a-like (PD) version of BFTP.

  Am using a Altos 3068, with System V, with TCP and Telnet access,
  but no BFTP.  

  Is there a shell script or C program that does about the same
  thnig as BFTP, and PLEASE - send me a note.

  Thanks for any help....   ...cliff...

-- 
_  Cliff Manis                   K4ZTF                 Unix & Xenix today
INTERNET: cmanis@csoftec.csf.com                              for a
UUCP: {dpmizar|swrinde}!csoftec!cmanis                  Better Tommorrow !
-

-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 89 02:10:00 GMT
From:      mogul@decwrl.dec.com (Jeffrey Mogul)
To:        comp.protocols.tcp-ip
Subject:   Choosing an MTU/MTU discovery

Since there have been a lot of messages on this topic, I will try
to avoid rehashing things.

Several people have made reference to our paper, but I thought I should
indicate where it can be found:

	Christopher A. Kent and Jeffrey C. Mogul
	"Fragmentation Considered Harmful"
	Proc. ACM SIGCOMM '87, pp. 390-401
	August 1987
	published as Computer Communication Review 17:5

A slightly revised version is available, under the same title,
as WRL Research Report 87/3.  You can order this report by
sending mail to "wrl-techreports@decwrl.dec.com"; send a message
with the word "help" on the Subject line for more information.

As Craig Partridge points out, there is soon to be an IETF working
group to address the issue of MTU discovery; I will be chairing this
group.  We recognize that the solution proposed in RFC1063 is not
necessarily perfect; in fact, there is already a draft proposal
(due to Steve Deering) that expands upon a proposal that Chris
and I reported in our paper (not original with us) that in turn
is quite similar to what Henry Spencer has proposed.  In other words,
the situation is not entirely hopeless.

One more point: we all agree that it is unfortunate that existing
TCP implementations cut the MSS when a gateway is involved even if
a large MTU would work; this is precisely why we proposed doing MTU
discovery.  On the other hand, there are good reasons why the default
should be "use a small MSS" rather than "use a large MSS"; if the
default is "small", things may run slow but they basically do work.
If the default is large, often you might find better performance,
but surprisingly often one finds things not working at all (or working
so slowly as to be useless).

In other words, if the choice is between occasional mediocre performance
and occasional mysterious failure, we believe one should accept the
mediocre performance.

-Jeff

-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 89 02:34:09 GMT
From:      smb@ulysses.homer.nj.att.com (Steven M. Bellovin)
To:        comp.protocols.tcp-ip
Subject:   Re: Can you fix (Re: Sun's silly TCP implementation)???

In article <2611@auspex.auspex.com>, guy@auspex.auspex.com (Guy Harris) writes:
[correct observations about adb-ing code deleted ]
> Perhaps you want to think about patching
> "subnetsarelocal" instead, since that doesn't change the non-local MSS
> globally, but just changes the system's notion of what a local host
> is....

On SunOS 3.4 and 4.0.3 -- the two versions I have available to me --
that variable is already initialized to 1; no patching should be
needed.  I've checked this both via adb and the source code.

-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 89 03:29:17 GMT
From:      davec@CSUFRES.CSUFRESNO.EDU (David C. Choweller)
To:        comp.protocols.tcp-ip
Subject:   FTP server on Mac NCSA Telnet


I have a problem using the Ftp Server on NCSA Telnet version 2.3 for the
Mac. When I am logged on to the host using NCSA Telnet, I have no problem
calling up the server. However, If I leave NCSA Telnet running on the
Mac, (but not connected to any host), then log on to the host using other
means (RS-232), and then try and ftp to the Mac, I get a 'connection timed
out'. However, I can ping the Mac with no problems.
Here are the particulars of my situation

Host : VAX 11/785 running BSD 4.3
Mac : On Appletalk network, connected to a Fast Path running KIP( which
      is on the same ethernet as the VAX). The IP number is assigned
      dynamically. (Could this be the problem?). The Mac is running
      Multifinder and system 6.0.3, with 5M memory.

I'd really appreciate it if anyone could help me. Please send me e-mail
as the news-feed at our campus is DEAD.



=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
+ D a v i d  C h o w e l l e r                                           +
+ ARPANET : davec@csufres.CSUFresno.EDU                                  +
+           davec@csuf3b.CSUFresno.EDU                                   +
+ UUCP : davec@csuf3b.UUCP or                                            +
+        uunet!ames!lll-tis!lll-crg!csusac!csufres!davec                 +
+        ucbvax!ucdavis!csusac!csufres!davec                             +
=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 89 04:28:13 GMT
From:      mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re:  Choosing an MTU/MTU discovery

I think that I would prefer "elegant but stately" to "mediocre" performance.

Merton

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 89 06:49:03 GMT
From:      brian@ucsd.Edu (Brian Kantor)
To:        comp.protocols.tcp-ip
Subject:   Re: NSFNET-RELAY.AC.UK down?

In article <8911062212.AA19910@gaak.LCS.MIT.EDU> MAP@LCS.MIT.EDU (Michael A. Patton) writes:
>You may be suffering from "malnourished TTL".

Nope, their mailer was wedged.  As I said, telnet worked ok, so it
wasn't the TTLs, which were the same.  Anyway, they fixed it on
Saturday, it would seem, since we cleared out our entire week's worth of
mail to/thru them in about an hour.

Thanx to all for your help!
	- Brian

-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      Wed, 08 Nov 89 15:13:47 -0500
From:      bhoward@ifs.umich.edu
To:        tcp-ip@NIC.DDN.MIL
Subject:   

	From: CERF@A.ISI.EDU
	Date: 4 Nov 1989 10:30-EST
	To: dell@APPLE.COM
	Cc: tcp-ip@NIC.DDN.MIL
	Sender: CERF@A.ISI.EDU
	Subject: Re: Top level .int domain
	
	There were some organizations which felt themselves to be
	international in nature and did not want to register under
	any particular national rubric. So .INT was created
	to accommodate.
	
	Vint Cerf
	
	p.s. the administrator is Mark Pullen at DARPA/ISTO.

the impression i had was that one particular organization (cern?) originally
wanted to be placed into a top level domain not already associated with any
particular nation.  .org was suggested but it was decided that .org was really
.org.us so .int was created.

at one point i attempted registering a domain under .int for non-commerical
organization that similarly did not want to be associated with any particular
nation.  unfortunately, it was felt by the nic and/or mark that .org sufficed.
i gained the distinct impression that there was little interest in using .int
for anything other than cern or perhaps the international red cross.  i guess
they perceive .int only applying to international pseudo-governmental agencies?

i think that a broader use of .int would be useful and appropriate.  i can imagine
a number of international clubs, associations, political groups etc. that might
wish to be under .int that don't belong under any of the other existing domains.

perhaps mark pullen or someone from nic.ddn.mil could outline the "official"
criteria by which one may obtain a domain under .int?  if none currently exists,
we could hash it out here.

				bruce
-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 89 06:55:06 GMT
From:      brian@ucsd.Edu (Brian Kantor)
To:        comp.protocols.tcp-ip
Subject:   Re: NSFNET-RELAY.AC.UK down?

>The result was an eventual timeout and the mail in the queue had the message
>"Bad file number".

By far the most common cause I've seen of 'bad file number' from
sendmail is an unexpected close of the SMTP connection by the far end.
Indeed, that may be the ONLY reason I've ever seen it.

Often this is something on the far end causing sendmail to shoot its
cookies and drop core, but I've also seen it happen when the distant
sendmail starts looping (like when the To: line has more than 2500
chars worth of recipient addresses) and the connection eventually times
out with the local sendmail waiting for the next SMTP state.

I've also seen it when our network interface has become terminally
bewildered, but luckily that's rare nowadays.
	- Brian

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      Wed Nov 8 09:16:29 1989
From:      chabutjc@wpafb.af.mil ( John Chabut)
To:        tcp-ip@nic.ddn.mil
Cc:        info-vax@k1.sri.comm
Subject:   Network Sol'ns & AF Concentrators
Can anyone recall how Network Solutions OPEN-Link for MicroVAX/VMS 
should be configured to access the MILNET via a USAF Concentrator?

Supposedly, someone posted a resolution to this problem on a bulletin
board within the past several weeks. I didn't read the bulletin board
at that time. I'd appreciate either

1) the author's getting in touch with me 

OR

2) anyone's help in recovering that which I seek!

I can be reached at "chabutjc@asd.wpafb.asd.mil" or 
"jcc%dayvd%dayvb@uunet.uu.net" (please try both) or 
by phone at (513)-429-6553 (Ohio).

Thanks for assisting.
-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      Wed Nov 8 09:22:12 1989
From:      chabutjc@wpafb.af.mil ( John Chabut)
To:        tcp-ip@nic.ddn.mil
x
-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 89 13:02:00 GMT
From:      CURT.ELLMANN@MAIL.ADMIN.WISC.EDU
To:        comp.protocols.tcp-ip
Subject:   FAX over TCP/ip

Comment: Processed by UWGATE

to: tcp-ip@sri-nic.arpa

Several weeks ago (?) there was a bit of activity on this group
about exchanging FAX data streams over TCP/IP networks.

Is anyone doing this now?  Are there any plans to do this sort of
thing?  Surely *someone* is working on an RFC, right?  I would
sincerely appreciate any leads.

Thanks.

-curt.
curt.ellmann@mail.admin.wisc.edu                                               ?

-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 89 13:37:59 GMT
From:      davecb@yunexus.UUCP (David Collier-Brown)
To:        comp.protocols.tcp-ip,comp.mail.misc
Subject:   Re: MXing the world

mx!cbcscmrs@csun.edu writes:
>I have one simple question, why don't we (The Internet side) put an MX record
>into the root servers for the top-level domains .bitnet and maybe even .uucp?

  I can think of two reasons:
	1) we really need a nameserver for .whatevernet, so
	   that all the mail doesn't dive for a single gateway
	   machine.
	2) .whatevernet is a transport medium, not a domain. The
	   .BITNET and .UUCP are an interim measure (aka a kludge).

  On the other hand, it might be plausible for a registry organization
like the bitnet NIC or the uucp maps project to run an interim nameserver,
and publish the MX records that the sites specify.  
  This approach reduces the necessity for every mailer to have the
equivalent[1] of the above.

  The criticisms of this are similar:
	1) its not obvious how to extract the correct mail exchanger
	   for a .UUCP or .BITNET site from the published data.  It
	   could cause unexpected and unwelcome flows through internet
	   sites that were "near" uucp sites, in particular.

	   This is solvable, but could require lots of headscratching.
	   The trivial answer is to have each site report it.

	2) if .whatevernet is going away, how DARE it claim to be a domain.

	   I think this could be ignored: the %-kludge is fare more
	   inesthetic than a time-limited domain!

--dave

[1] To see where mail goes, I have to (ask DNS || ask the uucp maps || ask a
    bitnet table || ask a DECnet table || (ask a .whatevernet table)*).  I
    can kludge it so it looks like I just ask DNS, but I still have to
    administer ALL those tables, each designed to be incompatible with the
    others.
-- 
David Collier-Brown,  | davecb@yunexus, ...!yunexus!davecb or
72 Abitibi Ave.,      | {toronto area...}lethe!dave 
Willowdale, Ontario,  | Joyce C-B:
CANADA. 416-223-8968  |    He's so smart he's dumb.

-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 89 14:27:38 GMT
From:      adnan@sgtech.UUCP (Adnan Yaqub)
To:        comp.unix.i386,comp.protocols.tcp-ip,comp.sources.wanted
Subject:   BOOTP Server Needed

I am looking for a BOOTP server (RFC 951) that I can run on
Interactive's 386ix. Any ideas?
--
Adnan Yaqub
Star Gate Technologies, 29300 Aurora Rd., Solon, OH, USA, +1 216 349 1860
...cwjcc!ncoast!sgtech!adnan ...uunet!abvax!sgtech!adnan

-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 89 15:01:22 GMT
From:      ji@close.cs.columbia.edu (John Ioannidis)
To:        comp.unix.i386,comp.unix.wizards,comp.protocols.tcp-ip
Subject:   SVR3.2 STREAMS-Based TCP/IP Questions

Hello net.land,

Last month I quickly hacked up a SLIP driver that runs with
Interactive's STREAMS-Based TCP/IP, as a warm-up for a driver that
I'll have to write for some experimental network hardware.

I haven't had a chance to look at the code since then (can you say
``PhD-student''?) and I still have a few questions unresolved.

* How does one interface with the struct if_net, to set things like
the POINTOPOINT flag, change the MTU, etc? (No, ifconfig doesn't do it!)

* How does one add/delete routing table entries from within the
kernel? I want to add a routing table entry (and hopefully also
broadcast it to the rest of the net when I'm acting as a gateway) when
the driver comes up, and then take it off when it comes down.

* Why won't the thing co-exist with NFS? If I start up both SLIP and
NFS, the nfsd dies a few seconds after coming up with an insulting
message like "assertion failed -- unable to send". Am I running the
wrong version of NFS? [As a side issue, what are the latest and
greatest releases of 386/ix, TCP/IP and NFS that will work together?]

Any help will be appreciated,

/ji

PS: If you (or someone you know) is looking for a 1-1.5 year job doing
kernel and network hacking, drop me a note; we have a couple of openings. 

In-Real-Life: John "Heldenprogrammer" Ioannidis
E-Mail-To: ji@cs.columbia.edu
V-Mail-To: +1 212 854 5510
P-Mail-To: 450 Computer Science \n Columbia University \n New York, NY 10027

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 89 15:44:48 GMT
From:      wedge@bcarh486 (Rick Wedge)
To:        comp.protocols.tcp-ip
Subject:   Encryption device for WAN

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

	A little while ago I posted an article asking for information 
about encryption devices for a WAN operating at T1 or 56Kbps.  
Here is my summary.

The most popular response was for the following company:

	Cylink Inc.
	110 S. Wolfe Rd.
	Sunnyvale, CA.
	94086
	Phone: (408) 735-5800

Cylink manufactures the product I was looking for, and in Ottawa
it is sold by:

	Schynrotel Inc.
	Phone: (613) 226-7980

Many thanks to all who responded to my article. 

------------------------------------------------------------------------
Rick Wedge                    |   All opinions are my own     
(613) 763-8730                |   unless they are somebody 
WEDGE@BNR.CA                  |   elses.

-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 89 19:20:42 GMT
From:      ihsan@ficc.uu.net (jaleel ihsan)
To:        comp.protocols.tcp-ip
Subject:   Re: Multicasting on TCP/IP

In article <2069@jato.Jpl.Nasa.Gov>, hashem@mars.jpl.nasa.gov (Basil Hashem) writes:
> In my terms, multicasting is the ability to distribute data packets
> to a *selected* group of addresses on a network.
> 
> From my readings about TCP/IP, there seems to be only two distribution
> mechanisms provided:  broadcast and point-to-point.
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  (...stuff deleted...)

Not true.  Class D internet addresses are reserved for multicasting.
See RFC 988.  Has any one used them successfully ? I dont know !

Jaleel

-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 89 20:13:47 GMT
From:      bhoward@IFS.UMICH.EDU
To:        comp.protocols.tcp-ip
Subject:   (none)


	From: CERF@A.ISI.EDU
	Date: 4 Nov 1989 10:30-EST
	To: dell@APPLE.COM
	Cc: tcp-ip@NIC.DDN.MIL
	Sender: CERF@A.ISI.EDU
	Subject: Re: Top level .int domain
	
	There were some organizations which felt themselves to be
	international in nature and did not want to register under
	any particular national rubric. So .INT was created
	to accommodate.
	
	Vint Cerf
	
	p.s. the administrator is Mark Pullen at DARPA/ISTO.

the impression i had was that one particular organization (cern?) originally
wanted to be placed into a top level domain not already associated with any
particular nation.  .org was suggested but it was decided that .org was really
.org.us so .int was created.

at one point i attempted registering a domain under .int for non-commerical
organization that similarly did not want to be associated with any particular
nation.  unfortunately, it was felt by the nic and/or mark that .org sufficed.
i gained the distinct impression that there was little interest in using .int
for anything other than cern or perhaps the international red cross.  i guess
they perceive .int only applying to international pseudo-governmental agencies?

i think that a broader use of .int would be useful and appropriate.  i can imagine
a number of international clubs, associations, political groups etc. that might
wish to be under .int that don't belong under any of the other existing domains.

perhaps mark pullen or someone from nic.ddn.mil could outline the "official"
criteria by which one may obtain a domain under .int?  if none currently exists,
we could hash it out here.

				bruce

-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 89 21:27:42 GMT
From:      vaf@VALINOR.STANFORD.EDU (Vince Fuller)
To:        comp.protocols.tcp-ip
Subject:   4.3 TAHOE and NFS?

Has anyone ever tried merging NFS code into the TAHOE kernel? If so, what was
the origin of your NFS code and how difficult was the merge? We have some old
4.3 systems (with old NFS code) which I'd like to bring up-to-date, and any
experiences that others have had would be appreciated.

	Thanks,
	Vince Fuller, Stanford University Networking

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 89 21:29:25 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: Choosing an MTU/MTU discovery

In article <8911080210.AA14442@acetes.pa.dec.com> mogul@decwrl.dec.com (Jeffrey Mogul) writes:
>... there is already a draft proposal
>(due to Steve Deering) that expands upon a proposal that Chris
>and I reported in our paper (not original with us) that in turn
>is quite similar to what Henry Spencer has proposed.  In other words,
>the situation is not entirely hopeless.

I should have remembered "Fragmentation Considered Harmful", in fact --
I had read it, in the dim distant past.  I've now seen Steve Deering's
proposal; in addition to being more fully thought through and fleshed out
than mine, it's better.
-- 
A bit of tolerance is worth a  |     Henry Spencer at U of Toronto Zoology
megabyte of flaming.           | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 89 21:30:28 GMT
From:      eli@spdcc.COM (Steve Elias)
To:        comp.protocols.tcp-ip
Subject:   Re: FAX over TCP/ip

> CURT.ELLMANN@MAIL.ADMIN.WISC.EDU writes:
>Several weeks ago (?) there was a bit of activity on this group
>about exchanging FAX data streams over TCP/IP networks.
>
>Is anyone doing this now?  Are there any plans to do this sort of
>thing?  Surely *someone* is working on an RFC, right?  I would
>sincerely appreciate any leads.

	myself and a few other random netters out there are offering
	to convert email to fax within our local calling areas, but
	at least in my case -- i'd be more likely to go out to KFC than
	i would be to write an RFC...  neither is very likely!

	admittedly, a bit of organization could at least provide 
	free email-->fax conversion for all of usenet/internet, at
	least within major metro calling areas. 

	all it would take is a central email
	address which could process the email and forward it to the particular
	site which had the fax hardware/software to send it out.  



-- 
 ... Steve Elias ; eli@spdcc.com ; 6179325598 ; {}
*disclaimer();  /* necessary because of a litigous net.company.  */
                /* and: free email-->fax for boston destinations */

-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 89 22:41:13 GMT
From:      rhg@cpsolv.UUCP (Richard H. Gumpertz)
To:        comp.protocols.tcp-ip
Subject:   Re:  MXing the world (was RE:  New Host-Requirement RFCs)

In article <2441@csun.edu> cbcscmrs@ma.csun.edu (Mike Stump) writes:
>I have one simple question, why don't we (The Internet side) put an MX record
>into the root servers for the top-level domains .bitnet and maybe even .uucp?

I have always wondered why there were no .MX records for ".UUCP".  It sure
would make things easier for the sites that are in the "official" UUCP maps to
interact with the Internet world.  Any reason not to implement it?  I suspect
that many of the major backbone sites already have the maps in place, so it
probably wouldn't cost much in time or resources.
-- 
===============================================================================
| Richard H. Gumpertz rhg%cpsolv@uunet.uu.NET -or- ...uunet!amgraf!cpsolv!rhg |
| Computer Problem Solving, 8905 Mohawk Lane, Leawood, Kansas 66206-1749      |
===============================================================================

-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 89 23:04:08 GMT
From:      cyrus@pprg.unm.edu (Tait Cyrus)
To:        comp.protocols.tcp-ip
Subject:   Network monitors.  What do you want?


There were many different network monitors/analyzers shown at INTEROP 89
each doing a little something different.

My feelings, along with others I have talked to, are that existing
systems, though providing a much needed service, do not provide some
very important bits of information.  To get a better feel for if
our needs are typical of others, I would like to conduct a very
informal survey in the hope that maybe the results could be used to
show vendors what tools are 'really' needed.

My questions to you are:

	If you could define the `ideal' network monitor/analyzer
	for your use, what features would it have?
	For example:
		- could handle a network with X packets/second
		- could handle a network with Y different protocols
		- could store Z number of packets for later perusal
		- could handle user defined packets
		- could display the data graphically
		- etc.
	
	What would be the most important thing your `ideal' network
	tool did?

I am tired of the vendors providing what they "think" we want instead
of providing what is really needed.

Thanks.   I will post a summary if I receive enough replies.

---
W. Tait Cyrus   (505) 277-0806		e-mail: cyrus@pprg.unm.edu
University of New Mexico			
Dept. of Electrical and Computer Engineering
Parallel Processing Research Group
Albuquerque, New Mexico 87131

-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 89 23:28:23 GMT
From:      dlj@proteon.com (Daniel L. Jones)
To:        comp.protocols.tcp-ip
Subject:   Changing subnet masks

Brad,
 Proteon is implementing OSPF in their next release of software for
their p4200 Router.

Dan Jones
Proteon Customer Service

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 89 01:12:46 GMT
From:      lam@NADC.ARPA (D. Lam)
To:        comp.protocols.tcp-ip
Subject:   please remove my name


Please, remove my name off the tcp/ip user group list.  Thank you.

lam@nadc.arpa
z

-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 89 03:10:27 GMT
From:      carrel@vi.ri.cmu.edu (David Carrel)
To:        comp.protocols.tcp-ip
Subject:   Re: FAX over TCP/ip


I am currently writing fax network software that uses lpr/lpd to ship 
fax documents to the machine with the hardware.  Any type of host that
has lpr access can send faxes.  This includes Macs, Pc's and of course
unix machines.  This works beautifly for sending faxes but I have not 
yet tackled the problem of recieving faxes, reading them, and determining
the recipient.
When sending faxes, lpd takes care of delivering the files, invoking
all necessary filters, and then opening the device.  Lpd also takes 
care of ordering the files, and ensuring that faxes dont overlap.

From the filters, you can go on to interpret many different file formats.
I currently interpret ASCII, TIFF, PCX, JTFAX, and a whole host of other
PC-esque formats.  I am working on a PostScript/GhostScript filter.
(You can just draw a picture on a Mac and fax it.)

I would be interested to hear from others that are tackling this problem,
especially the part of recieving faxes.


Dave Carrel	Robotics Institute, Carnegie Mellon Univ.
carrel@vi.ri.cmu.edu

hasta rasta pasta

-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 89 08:46:55 GMT
From:      pb@idca.tds.PHILIPS.nl (Peter Brouwer)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP performance (Was TCP/IP for DG)

In article <8911031631.aa28210@Obelix.TWG.COM> ljm@TWG.COM (Leo J McLaughlin) writes:
>
>Increase TCP MSS to 1460, window size to 5840, burn any 3c500 you might find...
>
Is this for tcp on PC only, I could not find such a parameter in WIN/TCP (3.1)
If it is there , is there any description of tunable parameters in the 
documentation ?

-- 
Peter Brouwer,                # Philips Telecommunications and Data Systems,
NET  : pb@idca.tds.philips.nl # Department SSP-P9000 Building V2,
UUCP : ....!mcvax!philapd!pb  # P.O.Box 245, 7300AE Apeldoorn, The Netherlands.
PHONE:ext [+31] [0]55 432523, # Never underestimate the power of human stupidity

-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 89 10:23:16 GMT
From:      jst@cca.ucsf.edu (Joe Stong)
To:        comp.protocols.tcp-ip
Subject:   Experimental Nameservice

What I'm offering is a temporary, experimental network service:
nameservice via telnet.

I have sympathy for those users who can't get internet numbers for
site names mentioned in NetNews articles.  I've been in this position
on machines that I don't administer.

To get an internet number for a known hostname:

telnet ccnext.ucsf.edu 5555
(your telnet gives a startup message)
enter-the-site-name-here
get.an.internet.number
Connection closed.

Our machine will do a live name resolution request, and return you the
result.  It doesn't get MX records.  It won't accept a string longer
than about 246 characters, due to a bug in the NeXT's resolver routines.

This service will disappear without notice, possibly in a few weeks.
It is running now.

The program is a simple gethostbyname and printf.  I'll be happy to hand
anyone the source.  Someone should be able to cook up scripts or VMS
DCL procedures or IBM CMS Procs or REXX procedures to wrap around 
basic services like telnet and ftp to automatically do resolution
before starting up the program.  I'd love to be sent copies of these
scripts. 

This service should be implemented eventually on machines LOCAL to the
one for whatever (economic, social, political, technical) reasons cannot
provide real resolver routines.

I don't want to run named here, this is a workstation.  Someone else
at UCSF publishes our domain directory.

	Joe Stong	jst@cca.ucsf.edu

-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 89 13:54:01 GMT
From:      DIXON-R@OSU-20.IRCC.OHIO-STATE.EDU (Bob Dixon)
To:        comp.protocols.tcp-ip
Subject:   Fax over tcp/ip

We are now doing this, and are developing a user-friendly interface to allow
routine use of the system for interlibrary loan at the Big 10 school
libraries. We will distribute it freely to all when it is ready to go.
For details, contact Bob Debula (bobd@hpuxa.ircc.ohio-state.edu).

                                 Bob Dixon
                                 Ohio State University

-------

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 89 14:44:59 GMT
From:      stine@SPARTA.COM (Robert Havens Stine)
To:        comp.protocols.tcp-ip
Subject:   Re:  Information Request

For a description of the Internet, check:

    the October '89 issue of "Connexions,"

    Doug Comer's book, "Internetworking with TCP/IP,"

    Ed Krol's paper, "The Hitchhiker's Guide to the Internet," RFC 1118,

    Charles Hedrick's paper, "Introduction to Internet Protocols,"
    available via anonymous ftp from icarus.cns.syr.edu, in file
    ~/info/inet.iprotos.txt,

and

    John Wobus's paper, "Introduction to Internet Networking," also available
    via anonymous ftp from icarus.cns.syr.edu, in file ~/info/inet.intro.txt.

- Bob Stine

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 89 19:11:57 GMT
From:      ecf_hap@jhunix.HCF.JHU.EDU (Andrew Poling)
To:        comp.protocols.tcp-ip
Subject:   Re: Traceroute & SunOS 4.0.3

In article <3325@watale.waterloo.edu> mdadams@surya.waterloo.edu (Mike Adams) writes:
>Does anyone have the patched kernel objects necessary to run traceroute
>under SunOS 4.0.3 on either Sun3's or 4's (both would be fabulous).
>I'm quite certain that a modified raw_ip.o is involved, but I'm not
>sure if anything else is required.  Would it be possible that some kind
>soul could make the patched objects available via anonymous ftp?
 [...]
>Mike Adams (mdadams@surya.waterloo.edu || madams@sirius.uvic.ca)


Might I second this query for us poor souls with binary distributions of
various Ultrix releases?  I'm led to believe that all I need is a patched
raw_ip.o.

awright,
so
I
quoted
more
than
I
said.

-Andy


Andy Poling                              Internet: andy@gollum.hcf.jhu.edu
Network Services Group                   Bitnet: ANDY@JHUVMS
Homewood Academic Computing              Voice: (301)338-8096    
Johns Hopkins University                 UUCP: mimsy!aplcen!jhunix!gollum!andy

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 89 19:34:29 GMT
From:      wstef@omni.eng.clemson.edu (W. Gregg Stefancik)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   POP3 server and client available

We at eng.clemson.edu have both POP3 server for SUN OS and a POP3 client for
MS-DOS available via anonymous ftp from eng.clemson.edu.  Both the client
and the server were developed here at Clemson.


W. Gregg Stefancik < wstef@eng.clemson.edu >

-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 89 22:17:48 GMT
From:      brnstnd@stealth.acf.nyu.edu (Dan Bernstein)
To:        comp.protocols.tcp-ip
Subject:   Re: Experimental Nameservice

In article <2559@ucsfcca.ucsf.edu> jst@cca.ucsf.edu (Joe Stong) writes:
> What I'm offering is a temporary, experimental network service:
> nameservice via telnet.

Excellent. Now could you distribute patches to our mailers---or at least
gethostbyname()---so that they work as well with your service as with
/etc/hosts? Thanks. And don't forget about VMS.

> To get an internet number for a known hostname:
> telnet ccnext.ucsf.edu 5555

You meant to say ``telnet 128.218.1.109 5555''---right?

---Dan

-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 89 22:19:42 GMT
From:      dcrocker@DECWRL.DEC.COM (Dave Crocker)
To:        comp.protocols.tcp-ip
Subject:   Re: Anybody know of an enet/TCP printer?

Digital Equipment is one of several vendors that manuafacture a laser
printer which hangs directly on the network.  It speaks TCP/IP and
interprets postscript.  The model is LPS-40.  There is an LPS-20 which
was shown at Interop, but I did not ask if it runs TCP, yet.

Dave

-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 89 00:14:10 GMT
From:      brian@ucsd.Edu (Brian Kantor)
To:        comp.protocols.tcp-ip,comp.mail.misc
Subject:   Re: MXing the world

I have in MY nameserver the following for the bitnet "top level
domain".  Because there is no record in the root nameserver pointing at
me for ".bitnet", this is not advertised to the outside world, but it
allows my mail system to treat "user@host.bitnet" just as it would any
other domain-type mail.  Because I assign these hosts equal priority
(and because sendmail-5.61 randomizes usage of equal-priority MXs), my
limited amount of bitnet traffic gets spread between the several
gateways I have listed.  (I think there are more internet->bitnet mail
gateways but these are the ones I know about.)

This is a real hack but it works real well for me.  I don't see why
this couldn`t be done internet-wide but I suspect the reason is other
than technical.  Is that true?
	- Brian

in the boot file:
	primary	bitnet bitnet

in the 'bitnet' file:
	@		IN	SOA	ucsd.EDU. brian.ucsd.EDU. (
			880506 7200 1800 2419200 86400 )
	*		IN	MX	10 cunyvm.cuny.edu.
	*		IN	MX	10 mitvma.mit.edu.
	*		IN	MX	10 uicvm.uic.edu.

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 89 00:20:59 GMT
From:      brian@ucsd.Edu (Brian Kantor)
To:        comp.protocols.tcp-ip,comp.mail.sendmail
Subject:   Re: Fax over tcp/ip

I've developed a cute little hack that adds email->fax capability to
sendmail.  It uses a slave PC with a FAX card in it to do the actual
conversion and transmission.  I sent it to rsalz for publication in
comp.sources.unix, so watch for it there if you're interested.
	- Brian

-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 89 00:47:18 GMT
From:      mf12605@msi-s9.msi.umn.edu
To:        comp.os.vms,comp.protocols.tcp-ip,comp.unix.questions
Subject:   UNIX vs. VMS Internet connectivity

I'm posting this for somebody without USENET access. Please reply
to the address given in article below.
-----------------------------------------------------------------
 
I'm not sure if this is the right forum for such questions,
but here goes: our university is finally planning to hook up
to Internet, most likely via U. of Ill. at Urbana-Champaign.
Our computer center, as far as I know, has only an IBM mainframe,
and a VAX under VMS (Unix is still considered a bizarre religion
around here). I've only had experience with Unix machines (Suns,
Unix VAXen, etc.) in this context. I would like to hear your
biased or unbiased opinions re. relative advantages. Please forgive
my naivete which will show in most questions.
 
Definition: "useful (Internet) software" means anything which
would permit file transfers a la ftp, access to news, rlogins,
equivalent of "talk", as well as other "connectivity" stuff
found in an average Unix system.
 
- can an IBM mainframe run "useful software" without much pain? or
do we need to get connected to a Vax or something similar?
 
- is VMS handicapped, as far as "useful software" goes, compared
to Unix? If so, in what way?
 
- is there any favorite networking method to be used locally?
everywhere I've been before, Ethernet was the standard; here, a
"mafia" of sorts is pushing a token ring LAN; any concrete arguments
against it?
 
Thanks in advance for your time and effort.     Eric
If possible, please reply to NBEHR@ECNCDC.BITNET
-----------------------------------------------------------------
                             ^^^^^^^^^^^^^^^^^^^
| Marek Behr                          | mf12605@uc.msc.umn.edu     (internet) |
| University of Minnesota             | AE01005@UMNACVX              (BITNET) |

-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 89 02:06:19 GMT
From:      robin@t2ns1.gcs.co.nz
To:        nz.general,comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Ethernet Terminal Devices


We are seeking for information on terminal devices which
will connect directly to thin ethernet, in order to
access unix systems.

We are aware that terminal servers can be used, but are
hoping to obviate the need for these on small sites.

We are using TCP/IP protocol on the network, so the
terminals will need to be compatible with this.

Clearly cost is the important consideration.

Example:
                      Dumb Terminal        Dumb Terminal
                           |                   |
___________________________|___________________|_________
                      <-- Ethernet -->

Thanks in advance


    
-- 

From:	Robin Warner (Network Server Project),Government
	Computing Service Ltd, Willis Street, Wellington, NZ.
	Voice Ph. +64 4 801-8000  Email: robin@t2ns1.gcs.co.nz

-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 89 02:48:46 GMT
From:      jst@cca.ucsf.edu (Joe Stong)
To:        comp.protocols.tcp-ip
Subject:   Re: Experimental Nameservice

In article <3894@sbcs.sunysb.edu> brnstnd@stealth.acf.nyu.edu
(Dan Bernstein) reminds me:

>> What I'm offering is a temporary, experimental network service:
>> nameservice via telnet.
>> To get an internet number for a known hostname:
>> telnet ccnext.ucsf.edu 5555
 
>You meant to say ``telnet 128.218.1.109 5555''---right?

Yes, sorry.  128.218.1.109 == ccnext.ucsf.edu  Thanks, Dan.  Defeats
the purpose if people can't find ME in the first place.

>Excellent. Now could you distribute patches to our mailers---or at least
>gethostbyname()---so that they work as well with your service as with
>/etc/hosts? Thanks. And don't forget about VMS.

I'm working on it.  I'm slowly understanding the internals of TCP/IP.
The calls in VMS are much different than in BSD, though I've got some
samples.

I'm not sure that people understand that you don't have to run
named to get automatic name-to-number lookup.  You can build
USER programs in BSD that just include libresolv.a to be able
to escape using /etc/hosts.

Would someone please post the name (and internet number) of some
machine that has the resolver sources, and/or the named sources,
availiable by anonymous ftp (and the filename)?

Would everyone please tell me what reasons THEY have for not putting up
the resolver routines on their system?   I'll post some sort of 
summary.

	Joe Stong	jst@cca.ucsf.edu

-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 89 04:07:34 GMT
From:      fjd@ntrlink.UUCP (Farokh Deboo)
To:        comp.protocols.tcp-ip
Subject:   Re: X.25 streams modules for TCP/IP

In reply to the following from <keith@spider.co.uk>:
>
> I would be very interested to know more about the workings of the
> IETF's PDN Routing Group ........

I don't have the most current information about the results from the
Hawaii IETF earlier this month, but this might be useful information
to you:

You can subscribe to "PDN-Interest@BBN.COM" by sending mail to
"PDN-request@BBN.COM", although I haven't seen very much mail on this
list recently.  For further information you may want to contact the
Chairman of the WG : Carl-H. Rokitansky, Fern University of Hagen,
roki@DHAFEU52.Bitnet.

Farokh Deboo			Interlink Computer Sciences
sun!iruucp!ntrlink!fjd		47370 Fremont Blvd
(415) 657-9800			Fremont, CA 94538

-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Nov 89 14:42:12 HST
From:      Torben Nielsen <torben@foralie.ics.Hawaii.Edu>
To:        gem.mps.ohio-state.edu!rpi!nyser!cmx!jmwobus@tut.cis.ohio-state.edu, tcp-ip@NIC.DDN.MIL
Subject:   Re: MXing the world (was RE:  New Host-Requirement RFCs)
>It would be neat if mail software could automatically find the nearest
>public gateway to BITNET.  The DNS doesn't doesn't deal with concepts
>like "nearest", but IP routing tables do.  In the past, I've dreamed of
>kludging together some method by which routing metrics route information
>to the nearest gateway, but we can imagine what it would be like to open
>an SMTP connection to some gateway and in the middle of transmitting the
>message, have a "network shift" cause your data to start heading for
>a different gateway!  However, one could imagine a system by which
>a single packet uses the routing table to find the nearest gateway,
>an answer from the gateway tells the sender what the gateway's
>(normal) IP address is and then the SMTP session starts after that.

.....


>John Wobus 
>Syracuse University

If you really want to do something like that, why not just make use of RTT's?
Seems to be to be more meaningful than a straight hopcount for this application.
Also, if I remember correctly, BIND already uses RTT's to determine ``nearness".
Using the routing metrics feels like an unnecessary violation of the layering.
RTT's feel a bit cleaner to me at least....

							Torben
-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 89 04:47:36 GMT
From:      fjd@ntrlink.UUCP (Farokh Deboo)
To:        comp.protocols.tcp-ip
Subject:   Re:  Information Request

In reply to the following from <franceee@clutx.clarkson.edu>:
>
> I am planning a ~20 minute presentation on the subject of 
> Internet.  However, no information is available through
> the normal sources here (libraries, etc.).  

You may want to look at RFC 1118 "The Hitchhikers Guide to the
Internet".  If you have ftp access you can get this via anonymous ftp
from NIC.DDN.MIL.  Otherwise you can obtain it via the NICs electronic
mail service by sending mail to SERVICE@NIC.DDN.MIL with just the
subject line: RFC 1118.  Another useful reference which you would find
in a technical bookstore is "Internetworking with TCP/IP -- Principles,
Protocols and Architectures" by Douglas Comer, Prentice-Hall, 1988.

Good luck with your presentation,

Farokh Deboo			Interlink Computer Sciences
sun!iruucp!ntrlink!fjd		47370 Fremont Blvd
(415) 657-9800			Fremont, CA 94538

-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 89 10:32:08 GMT
From:      gardner@ux1.cso.uiuc.edu
To:        comp.protocols.tcp-ip
Subject:   Re: FAX over TCP/ip


Here at the University of Illinois, Computer Services Office, I am working
on an email to fax(and eventually the other way) program.  I have a
Zenith '386 with an Intel CCP fax board.  It also has PC-nfs and Lifeline.
Lifeline allows me to retrieve mail with a "pop2" command and send it
with a "smtp".  A C program(under construction) will retrieve mail from
a fax signon, strip related (user-supplied) headers and send the fax.
Oh, yea and do appropriate accounting.  Users can receive reply mail
when the fax is sent off.  For retrieving, I have a commercial package
which can convert Intel's PCX format to postscript, gif, tiff and a dozen
more.  I have hopes for a process something like this:

	Fax is recieved.

	Operator pulls up cover page on screen(Intel has an integrated
	viewing program which lets you slide up and down the pages.

	Operator sends email to person(s) listed on fax(using our
	campus electronic phone book) or simply calls them up.  The
	fax is stored under this name for later retrieval.  

	Recipient informs operator how he wants to receive fax - options:

		Print out and drop in campus mail( we are engaged in a
		program to provide Email address for all students and 
		academic staff)

		Print out on CSO printer and recipient picks up.

		Send to campus printer nearest recipient.  (We have a
		developing Network Print Service).

		Transcribe the document and send email, with paper copy
		of fax to follow in email.(most people say yeeccchhh on this
		one).

		make file available for direct retrieval by recipient -
		in his format, postscript, gif, tiff etc.  via FTP, 
		email/uuencode etc.

	Dreams - OCR to read recipient address and or document - however
	from the faxen I've seen, this is a long way off.
mgg
************************************************************************
*   *                                                                  *
*  * *              CCC   SS   OO                                      *
*   *+  +          C     S    O  O                                     *
*     ** +         C       S  O  O                                     *
*   +*  *+          CCC  SS    OO                                      *
*   + **                                                               *
*    +  +*         University of Illinois, Computer Services Office    *
*       * *        1304 W Springfield, Urbana, Il 61801                *
*        *         Michael G. Gardner, Assistant Director, 173 DCL     *
*                  (217)244-0914    gardner@ux1.cso.uiuc.edu           *
*                  FAX 244-0916                                        *
************************************************************************

-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 89 17:21:55 GMT
From:      scs@itivax.iti.org (Steve Simmons)
To:        comp.protocols.tcp-ip
Subject:   Re: MXing the world (was RE:  New Host-Requirement RFCs)

cbcscmrs@ma.csun.edu (Mike Stump) writes:
>I have one simple question, why don't we (The Internet side) put an MX record
>into the root servers for the top-level domains .bitnet and maybe even .uucp?

rhg@cpsolv.UUCP (Richard H. Gumpertz) writes:
>I have always wondered why there were no .MX records for ".UUCP".  It sure
>would make things easier for the sites that are in the "official" UUCP maps to
>interact with the Internet world.  Any reason not to implement it?  I suspect
>that many of the major backbone sites already have the maps in place, so it
>probably wouldn't cost much in time or resources.

How do you differentiate between the 'right' .uucp site for your mail?
The MX records will come to you in preference order, not uucp connectivity
order for the site you want.  Since the MX record causes the mail to be
delivered to the host listed in the record, all *.uucp mail would go to
the *same* host for uucp handling.  I dunno anybody willing to handle that!
-- 
Steve Simmons	scs@iti.org   Industrial Technology Institute
	"Batches?  We don't need no steenking batches."

-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 89 17:40:21 GMT
From:      cs.utexas.edu!ut-emx!dlnash@tut.cis.ohio-state.edu  (Donald L. Nash)
To:        tcp-ip@NIC.DDN.MIL
Subject:   Strange behavior in BIND concerning $INCLUDE

I'm sorry if this is not quite the right newsgroup to ask, please feel
free to redirect me to a more appropriate group.

I have noticed a very strange problem using the $INCLUDE directive in
zone files for BIND.  According to BOG, $INCLUDE is suppose simply suck
in the data from the requested file, as if it were really in the
original file.  I have found this not to be the case in BIND 4.8.  Here
is an example of what I am doing:

::::::::::::::::
zone file for utexas.edu
::::::::::::::::
$ORIGIN utexas.edu.
@		in	soa	emx.utexas.edu. hostmaster.emx.utexas.edu. (
				; imagine rest of SOA stuff here )

emx		in	a	128.83.1.33
cs		in	a	128.83.139.9
;
; more top-level utexas.edu hosts here
;

;
; Keep each separate subdomain in a separate file to ease management
;
$INCLUDE ae			; data for ae.utexas.edu
$INCLUDE arlut			; data for arlut.utexas.edu
$INCLUDE beg			; data for beg.utexas.edu
$INCLUDE brc			; data for brc.utexas.edu
;
; ...
;
$INCLUDE zo			; data for zo.utexas.edu.


::::::::::::::::
file ae
::::::::::::::::
$ORIGIN ae.utexas.edu.
utcsr		in	a	128.83.152.17
trillian	in	a	128.83.152.27
;
; ...
;

::::::::::::::::
file arlut
::::::::::::::::
$ORIGIN arlut.utexas.edu.
csdfx8a		in	a	128.83.145.1
arlvs1		in	a	128.83.145.2
;
; ...
;

Well, I think you get the idea.  Each separate subdomain of utexas.edu
is kept in a separate file which starts with a $ORIGIN, but no soa
record (since these subdomains are not separate zones).  Each of these
files is then $INCLUDEd into the zone file for utexas.edu.  The
problems start when BIND starts reading those $INCLUDE files during
initialization.  For every one of those files, BIND syslog()'s a "No SOA
record" message.  The BOG clearly says that $INCLUDE does not start a
new zone (BOG 4.8 section 5.4.1).  If this is the case, then why does
it complain about no SOA records?

Even though it complains, the server still continues to operate,
although not very well.  Asking the server for information on one of
those subdomains (like trying to zone transfer xx.utexas.edu, where xx
is a subdomain but not a zone) results in a server failure error,
rather than the proper "No information" message, so something is
obviously wrong.

Finally, if I manually include all of the subdomain files into the zone
file and get rid of the $INCLUDE directives, everything works properly. 
There are no error messages, and trying to zone transfer xx.utexas.edu
results in "No information" rather than "Server failure".

This is all happening under VMS 5.1-1 and MultiNet 2.1 (pre-release),
which includes a port of BIND 4.8.  BTW, this is happening on an
experimental machine, not on one of the authoritative nameservers for
utexas.edu.  I'm trying some new and different configurations of BIND
to try to ease the management headache we are currently experiencing
with nameservice, and I'm being very careful not to allow bogosity to
escape from this experimental server into the Internet.  The $INCLUDE
method looked very promising until this strange behavior showed up.

Please respond to me by mail and I will summarize to the net.

				Thanks,

				Donald L. Nash

				The University of Texas System
				Office of Telecommunication Services

SMTP:    don@nic.the.net
BITNET:  DON@THENIC
UUCP:    ...!cs.utexas.edu!emx!dlnash
-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 89 19:33:08 GMT
From:      lhatt%boutique@Sun.COM (Linda Hatt)
To:        comp.protocols.nfs,comp.windows.x,comp.windows.news,comp.protocols.tcp-ip,comp.protocols.iso
Subject:   1990 NFS/X11/NeWS Connectathon



The following is a call for participation in Connectathon 1990.  
Connectathon is an interconnectivity testing event intended as an 
engineering test of NFS, X11 and NeWS implementations.  If you have an
implementation that you would like to test at Connectathon, please
follow the instructions below.

Linda Cwiak
Connectathon 1990 Coordinator
------------------------------------------------------------------------


Dear NFS, X11 and NeWS vendor:

Connectathon is starting to sizzle the network for the year 1990!!
You are invited to participate.

Connectathon is a networking proving ground allowing participating
vendors an opportunity to test their NFS, X11, and NeWS Client and
Server implementations.  In one convenient location you will be linking
together with other vendors' workstations, personal computers,
supercomputers, mainframes, and minicomputers,  sharing  resources
and files over local- and wide-area networks.  Each vendor sends its
development engineers, with machines and source code, to test and debug
their implementations.
 
The past Connectathon hosted more than 65 vendors, and we expect a
record turnout this year.  Why?  Let me tell you about one of last
year's participants.  He told us that he got more accomplished during
seven days of Connectathon than he could have in several years in his
office.

This year, we are expecting a significant increase in the number of
Window application vendors.  Connectathon 1990 will also introduce an
FDDI fiber backbone and testing of NFS over ISO/OSI transport
protocols.  As in previous years, there will be seminars with guest
speakers addressing issues in NFS, X11 and NeWS technologies.

Your marketing staff, press relations personnel, and customers may
attend the Press Day/Open House on the last day of testing - Wednesday,
February 21, 1990.  The Press Day is a good opportunity to promote your
company's NFS or Windows implementation.  Except for this day, the
entire event is for development engineers only.


General Connectathon Information:

o       Connectathon will be held at the San Mateo Expo Center in San
        Mateo, CA from February 7-21, 1990.  Testing continues 24 hours a
        day.

o       To provide space, electrical, and security resources to you,
        Connectathon will charge separately for space and for your
        implementation.
	This year you can pay by check, purchase order, VISA or
	MasterCard. These fees are Non-Refundable.

o	Registration deadline is DECEMBER 15, 1989.  We have enclosed
	a registration form that must be completed and returned with your
	payment to Connectathon 1990 Headquarters (150 Post Street,
	Suite 405, San Francisco, CA 94108). Please submit a seperate
	registration form for each implementation.

o       Once we have received your 4-page registration form, along
        with payment, we will send you a confirmation packet with
        your booth number, shipping instructions, nearby hotels,
        and a more detailed calendar of Connectathon 1990 events.

If you have any questions regarding Connectathon, contact Linda Cwiak of Sun Microsystems at 415-336-4717 or send email to cthon@sun.com.

We look forward to seeing you at Connectathon 1990!

Sincerely,



Larry Garlick
Vice President, Distributed Systems
Sun Microsystems, Inc.


Helpful information when filling out the Connectathon 1990 registration form:


	

1.	The company name and implementation name are used to
	identify each implementation for tracking purposes.  An
	implementation is the entity which is being tested.  The
	name is usually a description of a platform, such as an
	OS or hardware name. The implementation is further
	identified as NFS, X11, NeWS, or NFS over
	OSI.  For example, if you are a computer vendor who ships
	two different operating systems, you might have 3
	implementations to test: NFS on OS/A, NFS on OS/B and X11
	on OS/B.  Each needs a separate registration form.  There
	is a  $750.00 charge for each implementation you plan to
	test.

	The primary contact listed on the form is the person to
	whom the confirmation packet will be sent and the person
	we will call if we have questions about your
	registration.

	Our Press Relations department would like to know who to
	contact at your company in Press Relations to plan the
	Press Day.
  
2.	If you are sharing another implementation's booth check
	"no" and put the name of the company and implementation that
	you are sharing space   with.  Make sure the implementation
	that you are sharing a booth with has reserved and paid for a
	booth.  In other words,  if you are filling out a second
	registration form for your second implementation and you want
	to use the same booth for both, you do not need to fill in the
	booth information again.
        We have 3 booth configurations this year: small (approx. 35 sq.
        ft.), medium (approx 70 sq. ft.) and large (approx 105 sq.
        ft.).  Each booth includes a specific amount of space,
        electricity and Ethernet connections.  In the brackets preceding
        the booth size put the number of each size booth that you
        require and write the dollar amount in on page 2. (tables are 6'
        by 3')
        If you need additional electrical power, call Linda Cwiak at
        (415) 336-4717 and let her know what you require.  She will give
        you ordering and cost information to include on your
        registration form.  We would prefer you order additional
        electrical instead of getting a larger booth to accommodate your
        electrical needs.  You may also call the same number to get
        information about costs and ordering of a personal phone line or
        T1 line in your booth.

3.	Cabletron will provide transceivers for every Ethernet
	connection.  We need to know what kind of transceiver to
	reserve for you, thick or thin Ethernet.
	Some companies bring more than one machine to test a
	given implementation.  Please indicate how many machines
	you will have actually testing this implementation (do
	not include network analyzers or machines that you may
	bring to do development on).  Please indicate whether
	your implementation is client-only, server-only, or
	client/server.
	We need to know approximately what day your machines will
	be installed (not the delivery day).  Then indicate
	whether your delivery will be via professional carriers
	(trucking line or air cargo) or you will bring it in
	yourself.  If you are delivering via a carrier, trucks
	can arrive Monday, Feb. 5 and Tuesday, Feb. 6 from 9:00am
	to 4:00pm and Wednesday, Feb. 7 from 9:00am to 12:00pm.
	These will be the only times trucks can arrive.  If you
	plan to deliver your own equipment and it is too heavy to
	carry, you will need to bring it in at the times listed
	above.  If it is light enough to hand carry, you can carry your
	machines in up until Feb. 13.  You will not be able to use any
	type of cart with wheels.

4.	Will an other implementation share the space in this
	booth?  If so, please put the company/implementation name
	here.

5. & 6.	During stage 2 of Connectathon, there will be a
	series of talks and discussions in an informal setting. 
	Many of these talks will be given by Sun engineers on upcoming 
	product or future directions.  If you are interested in presenting 
	a talk or leading a discussion on NFS, X11 or NeWS technology,   
	list the title of the talk here.  Someone will contact you with more 
	details.

7.	Implementation fee: $750.00 per implementation (fill one
	form out per implementation).
	Booth fee:     Depends on the size of booth you chose (if you
	checked "no", leave this line blank.)
	Extra electrical fee:   If you require extra electrical
	please call Linda Cwiak at (415) 336-4717 for the cost.
	Total amount:      Add up the above amounts to determine
	your  payment for this implementation.
		
	Pages 3 & 4 of the forms are self explanatory.

	Once we have received your registration forms along with
	payment, we will send you a confirmation packet.  The
	confirmation packet will have your booth number, shipping
	instructions, nearby hotels, a more detailed calendar of
	Connectathon 1990.



						
Connectathon 1990 Registration Form    Return completed forms to:
FILL OUT ONE FORM PER IMPLEMENTATION   Connectathon 1990 Headquarters
DEADLINE DECEMBER 15, 1989	       150 Post Street Suite 405	
				       San Francisco, CA 94108
				       FAX number: 415-986-8551

1.	Full company name:_______________________

	Identifying name for implementation: _________________________
	(i.e., VMS, User-level, SVR4) [] NFS  [] NeWS [] X11 [] NFS over OSI

	Primary contact for Connectathon Participation: _____________________
				
		Mailing address: _________________________________

			         _________________________________

		Phone number:    _________________________________

		Fax number:      _________________________________

	       Electronic mail address:  _________________________

 Press Relations contact: ________________________________________

		Phone number:    __________________________________

2.	Do you need a booth ?

	( If you already reserved a booth on a separate form, check
	"no" and skip to step 5.  Only fill in the booth information
	again if you need an additional booth.  Please note:  Booth
	space is assigned on a first come, first served basis.

[ ] No.	  This implementation will be tested in another booth,
          registered under the following:

		Company name: _____________________________

	    Name of implementation: _______________________
							          	     		 [ ] NFS  [ ] NeWS   [ ] X11    [ ] NFS over OSI

[  ] Yes.   I prefer the following booth size:

	[ ] Small -- Includes   Approximately 35 sq ft with 1 table
				1 Ethernet drop
				4 outlets (20 amp total)
			Cost:   $500.00

	[  ] Medium -- Includes Approximately 70 sq ft with 2 tables
				2 Ethernet drops
				8 outelets (40 amp total)
				[ ] 1 220 V circuit or [ ] 4 addtl
				outlets (20 amp total)
			Cost:   $1,000.00

	[  ] Large -- Includes  Approximately 105 sq ft with 3 tables
				3 Ethernet drops
				12 outlets (60 amp total)
				[ ] 1 220 V circuit or [ ] 4 addtl
				outlets (20 amp total)
				1 custom circuit specify: ________________
			Cost:   $1,500.00

If you have different electrical requirements than those in your booth
choice, or you would like a personal phone line or T1 line installed in
your booth, please call Linda Cwiak at (415) 336-4717 for cost and
ordering information.


Connectathon 1990 Registration Form (page 2)

3. What type of Ethernet will you need?  [ ] Thick   [ ] Thin

   Number of machines that will actually be testing: ____________
   Type of implementation:  [ ] Client and Server [ ] Client Only 
                            [ ] Server Only   

   Approximate installation date (between Feb. 7-13) _______________

   Are you going to [ ] Ship or [ ] Hand deliver your machines?

	Name of shipping company? __________________________

4. Will any other implementation be tested in this booth? [] yes []no

   If yes, name of company: ________________________________

   Name of implementation: _________________________________
                  [ ] NFS  [ ] NeWS  [ ] X11   [ ] NFS over OSI

5. Would you like to give an informal presentation or lead a
discussion about   [ ] NFS  [ ] X11  [ ] NeWS technology
 
   Please indicate topic and/or title _______________________________

   __________________________________________________________________

6. What topic would you like Sun engineers to address in informal
seminars?

   ___________________________________________________________________

   ___________________________________________________________________


7.  Implementation fee:	     $750.00

    Booth fee (if any):      $______________(enter 0 if sharing
					     another implementation's
					     booth)
    Extra electrical fee     $______________(if you need extra
				  	    electrical contact Linda Cwiak 
					    at 415-336-4717)
    TOTAL AMOUNT:            $______________

Method of payment: [] check [] MasterCard [] Purchase Order [] VISA

credit card number: ________________________ expiration date_________

Name:____________________________ Signature__________________________


Connectathon 1990 Registration Form (page 3)

			Connectathon 1990 Attendee Form

Company Name:____________________________________________

Implementation Name:_____________________________________
		[] NFS   [] X11  [] NeWS  [] NFS over OSI


Full names and titles of engineers who will be testing and fixing bugs
on this implementation.  This should be development egineers for the
implementation being tested.  Limit four per implementation.

	Name				Title

	1.___________________________	___________________________

	2.___________________________	___________________________

	3.___________________________	___________________________

	4.___________________________   ___________________________

Full names and titles of field service technicians who may by
installing equipment 2/7-2/13.  Limit two per implementation.

	Name				Title

	1.___________________________	____________________________

	2.___________________________	____________________________

Full names and titles of marketing representatives who will be
attending on February 21, the Open House Day.  No limit.

	Name				Title

	1.___________________________	____________________________

	2.___________________________	____________________________

	3.___________________________	____________________________

	4.___________________________	____________________________

Full names and titles of press relations personnel who will be
attendint the Press Event on February 21.  No limit.
				
	Name				Title

	1.___________________________	_____________________________

	2.___________________________	_____________________________

	3.___________________________	_____________________________

	4.___________________________	_____________________________


Connectathon 1990 Registration Form (page 4)


	
Booth Identification Sign:

Company name:______________________________

Implementation name:_______________________
               [] NFS  [] X11  [] NeWS  [] NFS over OSI

Each booth will be supplied with a standard booth sign showing the
participants' company name.

Please type your company name exactly the way that you want it to
appear on your booth sign.

	---------------------------------------------------
	|						  |
	|						  |
	|					          |
	---------------------------------------------------



 

-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 89 20:34:33 GMT
From:      jmwobus@cmx.npac.syr.edu (John Wobus)
To:        comp.protocols.tcp-ip
Subject:   Re: MXing the world (was RE:  New Host-Requirement RFCs)

In article <4395@itivax.iti.org> scs@itivax.iti.org (Steve Simmons) writes:
>cbcscmrs@ma.csun.edu (Mike Stump) writes:
>>I have one simple question, why don't we (The Internet side) put an MX record
>>into the root servers for the top-level domains .bitnet and maybe even .uucp?
>
>rhg@cpsolv.UUCP (Richard H. Gumpertz) writes:
>>I have always wondered why there were no .MX records for ".UUCP".  It sure
>>would make things easier for the sites that are in the "official" UUCP maps to
>>interact with the Internet world.  Any reason not to implement it?  I suspect
>>that many of the major backbone sites already have the maps in place, so it
>>probably wouldn't cost much in time or resources.
>
>How do you differentiate between the 'right' .uucp site for your mail?
>The MX records will come to you in preference order, not uucp connectivity
>order for the site you want.  Since the MX record causes the mail to be
>delivered to the host listed in the record, all *.uucp mail would go to
>the *same* host for uucp handling.  I dunno anybody willing to handle that!
>-- 
>Steve Simmons	scs@iti.org   Industrial Technology Institute
>	"Batches?  We don't need no steenking batches."

It would be neat if mail software could automatically find the nearest
public gateway to BITNET.  The DNS doesn't doesn't deal with concepts
like "nearest", but IP routing tables do.  In the past, I've dreamed of
kludging together some method by which routing metrics route information
to the nearest gateway, but we can imagine what it would be like to open
an SMTP connection to some gateway and in the middle of transmitting the
message, have a "network shift" cause your data to start heading for
a different gateway!  However, one could imagine a system by which
a single packet uses the routing table to find the nearest gateway,
an answer from the gateway tells the sender what the gateway's
(normal) IP address is and then the SMTP session starts after that.

In more straightforward terms:
(1) Sender asks DNS for the IP address & gets an address which is
    being advertised by gateways in many places.
(2) Sender sends a single packet to that address to a service which
    returns its own real IP address.   
(3) Sender starts SMTP session.

Since this is a whole lot of changes, the real "first" question is:
are there enough similar needs to justify the trouble involved in
getting everyone to implement whatever is necessary?  One could 
imagine that files wanted by a lot of people could be dispensed from
a system of identical file servers throughout the Internet, each
holding the same files.  The root nameserver addresses could be
advertised that way.  Perhaps at the local level, nameservers
suitable for resolver use could be advertised that way.
Can anyone think of other uses?
The "second" question is: what is the least amount of changes
that could make something like this work (without "too" much
kludging).

John Wobus 
Syracuse University

-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      11 Nov 89 00:40:07 GMT
From:      pete@wlbr.IMSD.CONTEL.COM (Pete Lyall)
To:        comp.protocols.tcp-ip,comp.sys.mac
Subject:   TCP/IP to MACs?


Posting this for a friend... please respond to the address at the
base of the posting... thanks!

(actually, I'll also be happy to forward responses if that's
inconvenient)....
---------------------------------------------------------------------

I  would  appreciate  any  input  on  connecting  a  Mac  network  to  a
multi-system  TCP/IP  network (DOS PCs and Unix and other TCP/IP hosts).
Aside, a host is a multi-users system that is larger than a PC.  I would
prefer  to  configure  the  MAC  network  running its own Local Talk and
connect to a TCP/IP network.  A crude diagram of our configuration is:

 Phone lines - Local Talk __________         Ethernet -- TCP/IP
 ________________________|  ?????   |______________________________________
  |       |       |      |undefined |     |      |     |     |         |
 _|_     _|_     _|__    | box +    |    _|__   _|__   |   __|___    __|___
| M |   | M |   | PS |   |protocol  |   | PC | | PC |  |  | Unix |  | Unix |
|___|   |___|   |____|   |conversion|   |____| |____|  |  |      |  |      |
              Postscript |software  |    about 50 PCs  |  |______|  |______|
               printer   |__________|                  |    about 40 Unix hosts
                                                      _|__   running TCP/IP
                                                     | PS |   (Suns, PDP 11/750,
                                                     |____|    PDP 11/44, Plexus)
                                                   Postscript
                                                    printer
                                                   other laser printers
                                                   with HP emulation

Our goals are:

1)  All PCs and Macs share all printers on the network.  DOS print spooling
     handled using Ungermann Bass net BIOS (MS NET) and TCP/IP products.

2)  All TCP/IP systems share all printers on the network.  Print spooling
     handled by Unix spoolers.

3)  File transfer from PCs to Macs to Unix and other TCP/IP hosts (or any
     combination thereof), using ftp.

4)  Remote login capability to all PCs, Macs, and hosts (larger than a PC),
     using rlogin or telnet.

We are looking into:

1)  Kinetics Fast Path

2)  Ungermann Bass Access One

Does anyone have any knowledge, good or bad, about the above products?  Can
your recommend any other products to meet our goals?


maggie wahl

DDNnet: mag%wlbr@wlv.imsd.contel.com

--------------------------------------------------------
-- 
Pete Lyall                                                   Contel Corporation
Compuserve: 76703,4230              OS9_Net: (805) 375-1401 (24hr 300/1200/2400)
Internet: pete@wlbr.imsd.contel.com     UUCP: {hacgate,jplgodo,voder}!wlbr!pete 

-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      11 Nov 89 01:31:53 GMT
From:      romkey@asylum.sf.ca.us (John Romkey)
To:        comp.protocols.tcp-ip
Subject:   SLIP source wanted

Well, first off, SLIP is only a method of transmitting IP packets over
serial (asynch) lines. So it sounds like what you're looking for is
not just SLIP, which you could tuck under an existing TCP/IP
implementation, but a whole TCP/IP stack, complete with applications.

Everybody's favorite SLIP implementation for UNIX was done by Rick
Adams some years back, and you can find it on NET.UU.NET (uunet for
UUCP-land).

Everybody's favorite TCP/IP implementation for UNIX is the Berkeley
4.3 TCP, which has been freed by the Regents of UC Berkeley so that
it's clear of AT&T licensing. The copyright is still held by them, but
you can use the code pretty much however you want. This TCP is an
excellent protocol engine but is often a bear to port as it really
wants to live inside a Berkelely UNIX kernel. I have appended to the
end of this message a copy of an announcement from UCB about the
availability of this software. It includes SLIP support.

You can also find this online on uunet.
			- john romkey
USENET/UUCP: romkey@asylum.sf.ca.us	Internet: romkey@ftp.com
"Some people walk on water/Some people walk on broken glass/Some people walk
 round and round in their dreams/Some just keep falling down." Laurie Anderson

From: bostic@OKEEFFE.BERKELEY.EDU (Keith Bostic)
Newsgroups: comp.bugs.4bsd.ucb-fixes
Subject: V1.73 (BSD Networking Software, Release #1)
Message-ID: <8812070154.AA18358@okeeffe.Berkeley.EDU>
Date: 7 Dec 88 01:54:54 GMT
Organization: University of California at Berkeley

We are happy to announce the availability of the first release of the BSD
networking software.  It consists of the standard user level applications,
(along with their manual pages and some related documentation) and some
kernel and C library support.  It should be noted that this software has
only been tested for compilation and operation on 4.3BSD and 4.3BSD-tahoe.
A complete list of files is attached to this message.

The TCP and IP code is approximately the same as that recently made
available via the ARPANET and Usenet.  Several new algorithms are used in
TCP, in particular Van Jacobson's slow start and dynamic window size
selection algorithms and Phil Karn's modification to the roundtrip timing
algorithm.  These changes increase throughput and reduce congestion and
retransmission.  Several fixes were made in the handling of IP options
and other gateway support.

This software suite is copyright The Regents of the University of California
and may be freely redistributed.  No previous license, either AT&T or
Berkeley is required.  The release costs $400.00 US.  To request an order
form, please contact our distribution office by phone at 415-642-7780, or
by email at bsd-dist@ucbarpa.berkeley.edu or uunet!ucbarpa!bsd-dist, or
by U.S. Mail at:

	CSRG, Computer Science Division
	University of California
	Berkeley, CA  94720

Mike Karels
Kirk McKusick

[list of files deleted]

-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      11 Nov 89 02:41:40 GMT
From:      ghb@elrond.la.locus.com (George Bray)
To:        comp.protocols.tcp-ip
Subject:   4.2BSD and Route Record

I have heard rumors that sending IP packets with the Route Record
option enabled causes machines based on the 4.2BSD TCP/IP code to
dereference a null pointer.  This is rumored to cause some machines to
panic.

Does anyone know if this is true?  If I were developing a product and
planning to use Route Record, would I need to be able to disable this
feature to avoid problems with 4.2BSD-based hosts?

George Bray
Locus Computing Corporation, 9800 La Cienega Blvd, Inglewood, CA  90301-4440

213-337-5171
lcc!ghb@seas.ucla.edu
{randvax,sdcrdcf,ucbvax}!ucla-se!lcc!ghb
{gryphon,turnkey,attunix,oblio}!lcc!ghb

-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      11 Nov 89 03:20:57 GMT
From:      sklower@ernie.Berkeley.EDU (Keith Sklower)
To:        comp.protocols.iso,comp.protocols.tcp-ip
Subject:   re: NFS over OSI transport

In article <127728@sun.Eng.Sun.COM> lhatt%boutique@Sun.COM (Linda Hatt) writes:
>(among other things:)
>The following is a call for participation in Connectathon 1990.  
> ... Connectathon 1990 will also introduce ...
>testing of NFS over ISO/OSI transport protocols.

Could somebody remind me were to find the specs for NFS specifically
over OSI transport?

-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      11 Nov 89 22:51:57 GMT
From:      davec@CSUFRES.CSUFRESNO.EDU (David C. Choweller)
To:        comp.protocols.tcp-ip
Subject:   Trouble using KA9Q on Macintosh II



I am trying to run KA9Q on a Macintosh using Appletalk. First, has anyone
been successful doing this. Second, how is it done? There doesn't seem
to be any Macintosh-specific documentation that comes with the package
as it is available form ftp-sites (I got it from louie.udel.edu).
I used this command to configure the appletalk interface, as the readme
document advises me to:
attach appletalk 7e b arpa 600 600

Then I do a 

route add default at0

I then try to ping an address, (129.8.50.10)

ping [129.8.50.10]

I get

at_raw: error writing appletalk (-95)


does anyone know what this error means?


I would really appreciate any help. Please e-mail me, as our site's news-feed
is dead. I will summarize to the net if there is interest.



=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
+ D a v i d  C h o w e l l e r                                           +
+ ARPANET : davec@csufres.CSUFresno.EDU                                  +
+           davec@csuf3b.CSUFresno.EDU                                   +
+ UUCP : davec@csuf3b.UUCP or                                            +
+        uunet!ames!lll-tis!lll-crg!csusac!csufres!davec                 +
+        ucbvax!ucdavis!csusac!csufres!davec                             +
=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      Sun, 12 Nov 89 08:48:53 EST
From:      dzoey@terminus.umd.edu
To:        tcp-ip@nic.ddn.mil, pcip@udel.edu
Subject:   the TN3270 mailing list

We had a misfortune with our aliases file recently with the result being
that the many of the addresses for the TN3270 mailing list are
unrecoverably lost.  If you would like to be on the tn3270 mailing list
please send a note to tn3270-request@terminus.umd.edu


The TN3270 mailing list is a discussion about implementing IBM 3270 protocols
over TCP-IP.  


                            Joe Herman
                            List Maintainer


-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      12 Nov 89 03:48:59 GMT
From:      david@ms.uky.edu (David Herron -- One of the vertebrae)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.periphs.printers
Subject:   Re: Anybody know of an enet/TCP printer?

Imagen used to have ethernet interfaces for their printers that talked TCP/IP.
I suppose they probably still do have such an interface ...

of course they're not HPLJ-II compatible either :-)

uhm .. (I'm famous for that "uhm") .. why wouldn't it work to hang
the printer off a terminal server?  Or do you not have any terminal 
servers?

Something I've always wondered about ... most workstations come with
a serial port.  Does anybody use that serial port for a local printer?
-- 
<- David Herron; an MMDF guy                              <david@ms.uky.edu>
<- ska: David le casse\*'      {rutgers,uunet}!ukma!david, david@UKMA.BITNET
<- 
<- New official address:  attmail!sparsdev!dsh@attunix.att.com

-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      12 Nov 89 04:38:00 GMT
From:      carlson@uxh.cso.uiuc.edu
To:        comp.protocols.tcp-ip
Subject:   Re: MXing the world (was RE:  New H


By: jmwobus@cmx.npac.syr.edu Nov 10, 1989
[ stuff about UUCP deleted ]

>It would be neat if mail software could automatically find the
>nearest public gateway to BITNET.  The DNS doesn't deal
>with concepts like "nearest", but IP routing tables do.

This is the crucial point.  IP routine minimizes travel time
(and travail) for IP packets.  UUCP (I think) also optimizes routes.
DNS was, of course, is designed for a different purpose, and was
not intended to duplicate the functionallity of IP routing.
DNS seemed like a good place to put MX translation, and it works fine
for Internet mail, since Autonomous Sites and MX handlers corrolelate
very well with geographical/topological regions.

>However, one could imagine a system by which
>a single packet uses the routing table to find the nearest gateway,
>an answer from the gateway tells the sender what the gateway's
>(normal) IP address is and then the SMTP session starts after that.

One hitch is that it sounds like "nearest foriegn gateway" information
would have to be encoded in every new routing protocol that
comes along.  (Though it might just be worth the trouble.)
What I think is really needed is for the IP protocol to have some
concept of foreign destinations.  Perhaps a Class D (Multi-cast)
address could be reserved for the meaning of "Nearest Bitnet Gateway",
and gateway hosts would advertise themselves as such.
I am not up on the details of multicasting, but sounds like this
capability could implement what John suggests.  Hosts wishing to send
to the .Bitnet domain could skip DNS tables and query IP routers
with a special request packet.  This way, Non-IP mail could be
properly routed based on distance.

This would of course require fundemental additions to the IP protocol
(disturbing to purists), but mail service is so central to the use
and growth of the network that perhaps someone should give it some
serious though.

>John Wobus -- Syracuse University
--------------------
Brad Carlson  <carlson@mrcnext.cso.uiuc.edu> or <brad-carlson@uiuc.edu>
University of Illinois -- Consultant -- NeXT guru -- Windows Programmer

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      12 Nov 89 04:58:12 GMT
From:      david@ms.uky.edu (David Herron -- One of the vertebrae)
To:        comp.protocols.tcp-ip,comp.mail.misc
Subject:   Re: MXing the world

There's a problem that's been floating around in the back of my head
that's partly politics and partly graph theory.  I've never come
to an acceptible answer ...

It's this

suppose you have >= two computer networks which are described with
a weighted directed graph.  (er.. come to think of it, the real world
example includes a net that isn't weighted or directed.  at least from
the e-mail point of view).  These networks actually have multiple
physical connections between themselves, but little-to-no coordination
of routing between themselves.

Now ... how do you pick the "shortest" and/or "best" route between
any two nodes on this conglomerated network?

In (almost) all cases all a site knows is that the destination site is
on another network, due to MX records this isn't always known.  What
is always known is one-or-more gateways to use.  All the site knows
is the "weight" to reach the gateways.  It doesn't know the weight
from each of the gateways to the destination, and it doesn't always
know an actual weight to the gateways.

(In MX records, there's a weight of sorts attached to each gateway.
However that weight isn't related to the topological distance between
the nodes.  Therefore it's not a useful weight in figuring out
which is the closest gateway to the sender ...)

For instance ... if you're on UUCP going to BITNET you only know
the closest BITNET gateway.  All your BITNET mail goes over to that
gateway even though it might be better to send some BITNET mail to
one gateway and some to another.  On BITNET there's some links near the
"center" of the net which are chronically overcrowded.  It'd be
best in terms of reliability and transmission times if ... well,
your gateway is going to be on one side or another of the "center"
of BITNET.  If your routing software somehow knew which side your
target was on then it could pick an appropriate gateway.

This would become easier if BITNET & UUCP were to exchange weighting
information back and forth ... each network has a pathalias-like tool
(program for calculating spanning trees of a weighted directed graph).
In a previous message I suggested a method whereby BITNET information
could be distributed in the Usenet maps.  Specifically for each gateway
list all the BITNET nodes along with weights from that gateway to the
particular node.  Hopefully a good criteria for calculating the weights
could be come up which would weigh in both the actual distance and
normal traffic loads on that section of BITNET.

It's more complicated on the Internet since MX records, or anything
else for that matter, doesn't give you any indication of reachability
between any two nodes on the Internet.  The Internet likes to
pretend that all sites are equally reachable, which just ain't
so.  For instance, from SURAnet most of MILnet is basically unreachable.
The normal RTT for ping packets is on the order of 1.5 to 3 seconds,
which just ain't good..  Keep alive mechanisms start failing at that
sort of RTT times ... (unless you're using Phil Karn's TCP/IP code :-)).


Anyway, this is a bunch of incompleted thoughts and I apologize if
this seems rough around the edges.  It's been awhile since I've
had the spare time to think about this problem, and it is somewhat
late right now.  (gosh, back when I was a student this was certainly
not a "late" time of night -- it's only midnight :-)).


-- 
<- David Herron; an MMDF guy                              <david@ms.uky.edu>
<- ska: David le casse\*'      {rutgers,uunet}!ukma!david, david@UKMA.BITNET
<- 
<- New official address:  attmail!sparsdev!dsh@attunix.att.com

-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      12 Nov 89 11:18:44 GMT
From:      lear@GENBANK.BIO.NET (Eliot Lear)
To:        comp.protocols.tcp-ip,comp.mail.misc
Subject:   Re: MXing the world

A problem with .BITNET is that there is indeed a lack of granularity.
This would seem to me to be a strong reason for BITNET hosts to get
real domains (as it seems they have been).
-- 
Eliot Lear
[lear@net.bio.net]

-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      12 Nov 89 13:57:23 GMT
From:      rhg@cpsolv.UUCP (Richard H. Gumpertz)
To:        comp.protocols.tcp-ip
Subject:   remote lp and tape protocols

Both BSD and (some?) Unix System V implementations seem to include remote
printer and remote tape drive protocols.  Are the details of these protocols
documented anywhere?  If so, where can I get a copy?  Any chance that they
might be turned into Internet RFCs?

Email preferred for replies; I will post summary if I get anything interesting.
-- 
===============================================================================
| Richard H. Gumpertz rhg%cpsolv@uunet.uu.NET -or- ...uunet!amgraf!cpsolv!rhg |
| Computer Problem Solving, 8905 Mohawk Lane, Leawood, Kansas 66206-1749      |
===============================================================================

-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      12 Nov 89 16:05:03 GMT
From:      mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   KA9Q TCP/IP Package


Can someone provide information on the KA9Q TCP/IP Package.  I would like to
install it on my home system and use a dialin SLIP link to connect to work.
Unfortunately, wsmr-simtel20.army.mil has moved all the files to a single
directory, PD3:<MISC.KA9Q-TCPIP>.  There are a number of ARC files, but no-
where is there a list of the contents of these files or an indication of
which files maybe required for a particular environment.

USERMAN.DOC which is in USERMAN.ARC is written with the assumption that you
have the two diskette set from Tuscon Amateur Packet Radio (TAPR).  It does
give a high-level view of the software and directory architecture but no
clues as to where everything may be hiding.

The environment that I have is a MS-DOS 3.3 running on an 80286 based IBM
clone with an extended VGA color display (Paradise VGA-Plus, Samsung Multisynch
Montor).  I would like to use the COM1 or COM2 port for the SLIP link.
  
By the by, is anyone working on a named implementation that would use the
DNS services of the host connected to the SLIP link?

Merton

-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      12 Nov 89 21:02:42 GMT
From:      tneff@bfmny0.UU.NET (Tom Neff)
To:        comp.protocols.tcp-ip,comp.mail.misc
Subject:   Re: MXing the world

Perhaps, instead of trying to pre-guess the weighting of the world,
we could dynamically exchange weighted volume-carried information
between all nodes and gateways before transmission begins.  This way
you would have a constantly self-adjusting network.
-- 
There's nothing wrong with Southern California that a    || Tom Neff
rise in the ocean level wouldn't cure. -- Ross MacDonald || tneff@bfmn0.UU.NET

-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      13 Nov 89 00:18:00 GMT
From:      01696@AECLCR.BITNET (Chris Tanner)
To:        comp.protocols.tcp-ip
Subject:   X.WINDOWS for PC's

We have just obtained X.Windows for our CDC NOS/VE system, and are now looking
for ways to use it. While we expect to have workstations in the near future
(SUN or Silicon Graphics), we are looking for implementations for the PC.

Does anybody now of X.WINDOWS "clients" for either the PC or MAC.

Thanks in advance for help.

Chris Tanner
Chalk River Nuclear LAbs                   01616@AECLCR

-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      13 Nov 89 01:26:49 GMT
From:      amanda@intercon.com (Amanda Walker)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP command/data synchronization

In article <8911071945.AA02611@interlan.interlan.com>,
solensky@interlan.interlan.COM (Frank Solensky) writes:
> What I'm looking for is some passage in either RFC or some other source that
> states this is or is not acceptable.

By my reading of the RFC, this is fine, and I know from experience that it
does indeed happen fairly often in the real world, and so from a pragmatic
standpoint, I'd write my FTP client to deal with it if I were you :-).

The central issue is that there is no synchronization between the two TCP
streams (which are, after all, completely separate at the TCP level), and so
buffering strategies can cause the individual packets to come out in weird
orders.  There are two ways to handle this in an FTP client, and which one
you use depends on the I/O strategy you are using in general.

 - Blocking I/O (as in UNIX FTP):

   This one's easy--you just don't pay attention to the command connection
   (unless urgent data comes in, telling you to abort the transfer) until
   the data connection closes.  The 226 message will just be buffered, and
   will be there waiting for you when you come back to the command connection.

 - Non-Blocking I/O (as in a client FTP I've worked on):

   If you're using non-blocking I/O and dealing with data as it comes in,
   you've probably got a big state table anyway; all you need to do is add
   more states to cover the various messages on the command connection coming
   in at any time, or maintain separate command & data states.  Neither of
   these is terribly difficult if you're careful.

--
Amanda Walker <amanda@intercon.com>
InterCon Systems Corporation
--
@

-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      13 Nov 89 02:38:20 GMT
From:      cliff@centaure.UUCP (Clifford Dibble)
To:        comp.protocols.tcp-ip
Subject:   Seeking info on TCP/IP for IBM m/f


I'm interested in TCP/IP products for IBM mainframes. I'm taking a 
"Introduction to LANs" class, and this is one area of research
suggested by the instructor. Specifically, we're to find ways to
make an Ethernet full of Sun workstations talk to an IBM 
mainframe.

In the article "OSI Takes on TCP/IP" (S.Fisher, UNIX World, Feb 1989),
it is stated:

	"... in addition, IBM extended support TCP/IP support from
	 its UNIX systems to its mainframes. System 370s can 
	 communicate with devices supporting TCP/IP either by
	 a direct connection to an Ethernet network, or through 
	 the 8232 LAN channel station to a token ring LAN.

	 ... [it's possible] to manage TCP/IP networks with 
	 Netview (IBM's network management product)

	 ... IBM won't be shipping .. TCP/IP products until 
	 June 89."

I'd be grateful to get more information on these products, and to
hear from anyone who has actually used them.


Thanks!!

Cliff Dibble
Irvine, CA.
USA.
714-859-1172 P.D.T
uunet!centaure!cliff

-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13 Nov 89 12:00:49 PST
From:      ntrlink!fjd@Sun.COM (Farokh Deboo)
To:        iruucp!sun!sri-nic.arpa!tcp-ip@Sun.COM
Subject:   Spider Systems Info Requested
I am looking for comments from users of Spider Systems "Streams
Software for OEMs" that was presented at Interop 89.  Specifically I am
looking for experiences with the port of their TCP package, their
streams emulator, and (if there are any users) their OSI package.

Please reply directly to me at the address below.

Thanks,

Farokh Deboo			Interlink Computer Sciences
sun!iruucp!ntrlink!fjd		47370 Fremont Blvd
(415) 657-9800			Fremont, CA 94538
-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      Mon 13 Nov 89 13:33:51-PST
From:      William Westfield <BILLW@MATHOM.CISCO.COM>
To:        cs.utexas.edu!wuarchive!brutus.cs.uiuc.edu!zweig@tut.cis.ohio-state.edu
Cc:        tcp-ip@NIC.DDN.MIL
Subject:   Re: ARP+
	ARP will give you a good answer if W.X.Y.Z is on the same physical
	subnet as you. Also works if there is only one gateway on that net
	and it decides to do proxy-ARP for everybody else.

I don't think you understand Proxy-ARP.  A router should only issue a
proxy ARP reply to an ARP request if it is the BEST route to the host.
The routers, of course, know such things.  If routes are equivilent,
then multiple routers can answer and it doesn't matter.  If the routers
are stupid, and issue proxy ARP replies for anything not on the local
network (and I don't know of any routers that would do such a thing),
then at worst, they will get get a packet that should have gone to a
different router, and issue an ICMP redirect, which the host should
listen to (it then knows that there is a router involved, and knows
which router to use).

In general, you should NOT use ARP to make routing decisions at all.
"proxy ARP" is a (clever and useful) HACK, not a feature of ARP.  The
IETF is trying to come up with a standard "Router discovery protocl"
so that relatively dumb hosts can reasonably pick a "deafult router"
(and get re-directed to other routers as appropriate).  This is quite
separate from ARP, which is used only to resolve IP addresses to
physical addresses.


    QUESTIONS: Would it be hip just to use RIP as though it were
    ARP+? That is, would it be bad to send out a RIP-request every
    time I send out an ARP packet?

No.  I would be a bad idea.  RIP is on its way out as a routing protocol.
The "Host requirements" RFCs explicitly state that HOSTS should not muck
with routing protocols.  And this still confuses ARP and Router selection.

Bill Westfield
-------
-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13 Nov 89 12:21:38 EST
From:      Mark Bodenstein <MAB@CORNELLC.cit.cornell.edu>
To:        cs.utexas.edu!usc!csun!mx!cbcscmrs@tut.cis.ohio-state.edu
Cc:        TCP-IP@NIC.DDN.MIL
Subject:   Re:  MXing the world (was RE:  New Host-Requirement RFCs)
> ...
On 7 Nov 89 22:51:55 GMT you said:
>I have one simple question, why don't we (The Internet side) put an MX record
>into the root servers for the top-level domains .bitnet and maybe even .uucp?
> ...
>We can point them to cunyvm.cuny.edu or ucbvax.berkeley.edu or new.foo.bar.net
>or whatever the lastest host is.  ...

This doesn't work because there isn't a single gateway between the internet
and Bitnet - there are many - probably in the dozens at this time.  (This must
have been said earlier in this conversation?)

I think we're heading towards having a DNS-style-name and an MX record per
Bitnet site (more or less), with the MX record specifying (for the internet)
which gateway is the best to use - i.e. which is the "closest" on the Bitnet
side.

This optimizes things if we assume we want to maximize the amount of its
journey a mailfile takes on the Internet, and minimize the journey through
Bitnet.  This is at this time, in general, a Good Thing, since Internet
links tend to be faster/higher throughput than Bitnet links (which are,
generally speaking, 9600 baud bisync lines).  When/as/if this changes (and
it is changing) it becomes much more complicated to try to optimize things.

Mark Bodenstein   (mab@cornellc.cit.cornell.edu; 607-255-3747)
Cornell University
-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13 Nov 89 13:56:19 +0000
From:      Jon Crowcroft <J.Crowcroft@Cs.Ucl.AC.UK>
To:        bhoward@ifs.umich.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re:


 >	There were some organizations which felt themselves to be
 >	international in nature and did not want to register under
 >	any particular national rubric. So .INT was created
 >	to accommodate.

e.g. NATO

 >	
 >perhaps mark pullen or someone from nic.ddn.mil could outline the "official"
 >criteria by which one may obtain a domain under .int?  if none currently exists,
 >we could hash it out here.

its probably worth checking out the International Law on this. I know
0.01 about it, but i understand Companies are normally registered
as being based in some nation or other. .Com or .Org or something like
should suffice though... However, there are truly international
organisations, such as UN/European Commision etc, who (may/will) have 
networks...Its probably up to them (CCITT/ISO/UN) to allocate within
.Int. 

Of course, when there's a colony on the moon, some terestrial will
have to bite the bullet and agree on the .. domain again:-)

 jon

-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      13 Nov 89 14:28:10 GMT
From:      bobw@ncrcae.Columbia.NCR.COM (Bob Williamson)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP on Versados??????


   NCR has a proprietary OS based on Motorola's Versados.  TMX is a 
   transaction-oriented OS used mainly by banks.  We currently have
   a requirement to bring up TCP/IP as a replacement for our current
   XNS-based LAN offerring.  I am looking for any knowledge of a 
   VERSAdos-based OS running TCP/IP.  Anything at all would be
   extremely helpful.

   On another related topic, we are having to decide very shortly
   on the method for getting TCP on TMX.  One vendor has recommended
   a STREAMS emulator on TMX and then their STREAMS-based TCP on top.
   It's not clear to me that putting STREAMS on a non-UNIX system
   is worth the effort; aren't their good, up-to-date character-based
   implementations?  Isn't BSD4.3 character-based?

  Thanks in advance for any guidance you may offer.



Bob Williamson
TOWER Networking Systems
E&M - Columbia
NCR Corporation
  

-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      13 Nov 89 14:49:31 GMT
From:      rogers@osi540sn.gsfc.nasa.gov (Scott W. Rogers)
To:        comp.protocols.tcp-ip
Subject:   Re:  SLIP source wanted

Try looking on 'uunet.uu.net' in the Berkeley (4.3BSD) subdirectories.
I know there are object modules for slip on this node, and I beleive
that most of the berkeley networking source codee for 4.3 is there as well.

-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      13 Nov 89 15:53:58 GMT
From:      a20@nikhefh.nikhef.nl (Marten Terpstra)
To:        comp.protocols.tcp-ip
Subject:   SNMP tools

Hi there,

	I was wondering if anyone has written any snmp-tools for
'normal' BSD machines. All tools seem to be written for SUNs and the
like. I'm working with a 'normal' 4.3BSD system and there seems to be
nothing available for this.
I know I can write my own tools but I was wondering if someone already
did it so I don't have to re-invent the wheel but make some adaptions
to make it roll better.
BTW I like MIT-snmp better than CMU-snmp. (MIT runs with no problems,
CMU doesn't).

Any help whatsoever is welcome,

Thanks,


-- 
Marten Terpstra                                  National Institute for Nuclear
Internet : terpstra@nikhef.nl 		                and High Energy Physics
Oldie-net: {....}mcsun!nikhefh!terpstra	      (NIKHEF-H), PO Box 41882, 1009 DB
Bitnet   : terpstra%nikhef.nl@hasara5.bitnet         Amsterdam, The Netherlands

-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      13 Nov 89 16:51:37 GMT
From:      brnstnd@stealth.acf.nyu.edu (Dan Bernstein)
To:        comp.protocols.tcp-ip
Subject:   Re: MXing the world

In article <16300008@uxh.cso.uiuc.edu> carlson@uxh.cso.uiuc.edu writes:
> IP routine minimizes travel time
> (and travail) for IP packets.

Ummm, no. It ``minimizes'' travel time based on an always out-of-date
picture of network load. The routing algorithms used by the Internet
transmit and use routing information as quickly and as often as data;
this leads to route flapping, completely lost routes, and other forms
of instability.

There is no way to minimize correctly, dynamically, and in real time.

---Dan

-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      13 Nov 89 17:02:30 GMT
From:      tksjmi@sybil.cs.Buffalo.EDU (JoAnn Illuzzi)
To:        comp.protocols.tcp-ip
Subject:   Kip server help


 I am trying to run kip 0688 on my bsd 4.3 system, a vax 750.  My routed
 tcpip network is a subnetted class b net.

 I would like to know if I can download a fastpath in a different physical
 subnetwork than the server?  The server (vax) is 128.205.1.3, the fastpath
 is 128.205.13.2.

 Any help would be appreciated!
 JoAnn (716-636-3558)

-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      13 Nov 89 17:07:55 GMT
From:      roy@phri.UUCP (Roy Smith)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.periphs.printers
Subject:   Re: Anybody know of an enet/TCP printer?

In <13207@s.ms.uky.edu> david@ms.uky.edu (David Herron) writes:
> Something I've always wondered about ... most workstations come with
> a serial port.  Does anybody use that serial port for a local printer?

	Most of our diskless Sun-3s (2 RS-232 ports each) have one (or
sometimes 2) serial devices hanging off the back of them, either terminals
running normal logins or printers of various sorts.  I'm not sure what you
mean by "local" printer; all our Sun-driven printers are accessable via the
normal Unix lpr mechanism.
-- 
Roy Smith, Public Health Research Institute
455 First Avenue, New York, NY 10016
{att,philabs,cmcl2,rutgers,hombre}!phri!roy -or- roy@alanine.phri.nyu.edu
"The connector is the network"

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      13 Nov 89 17:08:55 GMT
From:      mckenney@aai8.itstd.sri.com.uucp (Paul E. McKenney)
To:        comp.protocols.tcp-ip
Subject:   Re: Pilot Project: Hosts Table To Be Available Over Internet

In article <1989Nov6.154134.16530@gpu.utcs.utoronto.ca> dennis@gpu.utcs.utoronto.ca (Dennis Ferguson) writes:
>I can think of two reasons [for a host table] with some merit:
[ . . . two reasons omitted . . . ]

A third reason is to allow people to analyze the distributions of hostnames
and internet addresses.
				Thanx, Paul

-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      13 Nov 89 18:51:57 GMT
From:      pat@hprnd.HP.COM (Pat Thaler)
To:        comp.protocols.tcp-ip
Subject:   Re: How do you string a thinnet?

> / hprnd:comp.protocols.tcp-ip / mas@bridge2.ESD.3Com.COM (Mike Smith) / 11:13 am  Nov  3, 1989 /
> In article <8910301951.AA28831@gaak.LCS.MIT.EDU> MAP@LCS.MIT.EDU (Michael A. Patton) writes:
> >Date: 27 Oct 89 12:56:14 GMT
> >From: eplrx7!mcneill@louie.udel.edu  (Keith McNeill)
> >Subject: Re: How do you string a thinnet?
> >To: tcp-ip@nic.ddn.mil
> >
> >Bernie Hoffstadt <cutter@cutsys.UUCP> asked:
> >Now the $64k question: Is there a good reference for this kind of info.
> >----------------
> 
> THE book -
> 
> ANSI/IEEE Standards for Local Area Networks:
> 
>    Carrier Sense Multiple Access with Collision Detection (CSMA/CD)
>    Access Method and Physical Layer Specifications (with supplements)
>    ISBN 1-55937-0130, SH12351 (1989)
> 
Actually, the correct title is "Supplements to Carrier Sense Multiple
Access with Collision Detection (CSMA/CD) Access Method and Physical
Layer Specifications."  It is also refered to as IEEE Supplements to
ISO 8892-3:1989 (ANSI/IEEE Std 802.3-1988).  It only contains the 
supplements which are IEEE standards and not yet through the ISO
standards process.

10BASE2 (aka thinLAN or thinnet) is now an ISO standard and has moved
to 

   ISO 8802-3 : 1989 (E) (ANSI/IEEE Std 802.3-1988) ISBN 1-55937-005-X,
   SH11726

So order this if you want 10BASE2.  Note that section 9 in this book has
been replaced by a new section 9 which is in the supplement.  Section
9 up to 9.8 has been approved by ISO, but 9.9 on Fiber Optic Inter Repeater
Links (FOIRL) is still going through ISO and therefore the whole repeater
section was kept together in the supplement.

>    This includes 10Base2.  Anything else is second hand information.
> ----------
                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Exactly.  It would be nice if someone would produce a more tutorial
explaination which was technically correct.  Apparently, some of those
currently available contain serious factual errors.

Pat Thaler

-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      13 Nov 89 20:28:05 GMT
From:      perand@nada.kth.se (Per Andersson)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.periphs.printers
Subject:   Re: Anybody know of an enet/TCP printer?

In article <13207@s.ms.uky.edu> david@ms.uky.edu (David Herron -- One of the vertebrae) writes:
>uhm .. (I'm famous for that "uhm") .. why wouldn't it work to hang
>the printer off a terminal server?  Or do you not have any terminal 
>servers?

One reason could be the lack of speed - most printers with RS232 interfaces
only manage 9600 BPS, some 19200 BPS. One nice product I've seen is by an
english company called Software Products. They take a Canon chassi and connect
a parallell cable to a VME card for SUNs they developed. This makes the printer
work as fast as it can, but I dont know what youre supposed to send to the 
card. I suppose it's a bitmap, and possibly only their own DTP program work
with it.

Per
-- 
Per Andersson
Royal Institute of Technology, Stockholm, Sweden
perand@admin.kth.se, @tds.kth.se, @nada.kth.se 
or perhaps {backbone}!sunic!ttds!perand

-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      13 Nov 89 22:03:45 GMT
From:      hughes@silver.bacs.indiana.edu (larry hughes)
To:        comp.protocols.tcp-ip
Subject:   Re: X.WINDOWS for PC's

In article <89Nov12.191610est.57347@ugw.utcs.utoronto.ca> 01696@AECLCR.BITNET (Chris Tanner) writes:
>We have just obtained X.Windows for our CDC NOS/VE system, and are now looking
>for ways to use it. While we expect to have workstations in the near future
>(SUN or Silicon Graphics), we are looking for implementations for the PC.
>
>Does anybody now of X.WINDOWS "clients" for either the PC or MAC.

DEC has done a version of DECwindows for the PC.  Since DECwindows
is really X with DEC's toolkit, I think you can count it.  I don't
know if it's any good or not...

 //=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=\\
|| Larry J. Hughes, Senior Programmer ||  hughes@silver.bacs.indiana.edu   ||
||        Indiana University          ||                                   ||
||   University Computing Services    ||  "The person who knows everything ||
||    750 N. State Road 46 Bypass     ||     has a lot to learn."          ||
||      Bloomington, IN  47405        ||                                   ||
||         (812) 855-9255             ||  Disclaimer: See quote above.     ||
 \\=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=//



-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      13 Nov 89 22:04:10 GMT
From:      rod@ldc-net.uucp (0000-Rod Merry(0000))
To:        comp.protocols.tcp-ip
Subject:   Telnet Negotiations?



Can someone tell me if the bsd 4.3 Telnet server puts the ptty in
8 bit raw mode when a client negotiates for binary mode.  We have one
vendor who goes to 8 bit cooked and another who goes to 8 bit raw.
Both say they do the same thing as 4.3 does, who is right?

Thanks in advance.

rod

-- 
--------------------------------------------------------------------
Rod Merry                          Email: uunet!ldc-net!rod
Lee Data		           Phone: 612-828-0323		

-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      13 Nov 89 22:08:59 GMT
From:      hughes@silver.bacs.indiana.edu (larry hughes)
To:        comp.protocols.tcp-ip
Subject:   Re: Seeking info on TCP/IP for IBM m/f

In article <122@centaure.UUCP> cliff@centaure.UUCP (Clifford Dibble) writes:
>
>I'm interested in TCP/IP products for IBM mainframes. I'm taking a 
>"Introduction to LANs" class, and this is one area of research
>suggested by the instructor. Specifically, we're to find ways to
>make an Ethernet full of Sun workstations talk to an IBM 
>mainframe.
>
>In the article "OSI Takes on TCP/IP" (S.Fisher, UNIX World, Feb 1989),
>it is stated:
>
>	"... in addition, IBM extended support TCP/IP support from
>	 its UNIX systems to its mainframes. System 370s can 
>	 communicate with devices supporting TCP/IP either by
>	 a direct connection to an Ethernet network, or through 
>	 the 8232 LAN channel station to a token ring LAN.
>

Not really "direct"!  IBM's TCP/IP solution calls for an
industrial-strength AT that's attached to the ethernet,
and channel attached back to the IBM host.  They call it
a FEP (front end processor).

We're running an Intel FEP here...

 //=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=\\
|| Larry J. Hughes, Senior Programmer ||  hughes@silver.bacs.indiana.edu   ||
||        Indiana University          ||                                   ||
||   University Computing Services    ||  "The person who knows everything ||
||    750 N. State Road 46 Bypass     ||     has a lot to learn."          ||
||      Bloomington, IN  47405        ||                                   ||
||         (812) 855-9255             ||  Disclaimer: See quote above.     ||
 \\=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=//


-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      13 Nov 89 22:44:43 GMT
From:      hlison@bbn.com (Herb Lison)
To:        comp.protocols.tcp-ip
Subject:   Re: Fax over tcp/ip

gnu@hoptoad.uucp (John Gilmore) writes:

>Clearly what we want on the Internet is more like what computer fax
>over phone lines should be doing (except that the designers of fax
>didn't think about extensibility, and the people who implement it are
>too busy (hacking slimy binary MSDOS software) to support real
>computers or consider the larger issues).  You should hand it a
>document in ANY format; it sends it to the recipient in the recipient's
>choice of format.  E.g. you hand it troff source; if the recipient can
>handle troff source, it gets sent that way; backoffs to ditroff
>intermediate form, PostScript, MacDraw, HPGL, bitmaps, G3 and G4 fax,
>etc, are all possible depending on what the recipient can handle.  This
>has to be negotiated separately for each recipient, since one could be
>a phone-fax relay service and another a window system or something.


Another alternative to FAX on the Internet, or networks in general, is
multimedia E-mail.  BBN/Slate is a product that allows the user to
e-mail documents containing text, graphics, spreadsheets, images (color,
as well as black and white), and even digitized voice, over standard
text mail systems, such as sendmail, MMDF.  Of course, for those
users without high performance workstations, FAX is still a good
way of getting multimedia material (albeit without the capability of
doing much more than looking at it), and we are implementing a FAX
handling capability in Slate.

Anyone interested in getting more information can look in the October
issue of UNIX Review.

Herb Lison

-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      13 Nov 89 22:53:33 GMT
From:      km@mathcs.emory.edu (Ken Mandelberg)
To:        comp.protocols.tcp-ip
Subject:   Rtelnet mods for Annex?

I was just looking at the Rtelnet program Annex provides with its
terminal servers. Basically, it a daemon that uses telnet to talk to
the server, and provides a /dev interface using a pty.

Some problems I noticed were:

1) No provision for a BREAK, which makes it hard to use with an
outdialing UUCP.

2) Does not support rotaries, so each computer using it ties up at
least one Annex port.

3) Is very BSD specific, and needs work for Sys V.

Does anyone have an fixes for any of this?
-- 
Ken Mandelberg      | km@mathcs.emory.edu          PREFERRED
Emory University    | {decvax,gatech}!emory!km     UUCP 
Dept of Math and CS | km@emory.bitnet              NON-DOMAIN BITNET  
Atlanta, GA 30322   | Phone: (404) 727-7963

-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      14 Nov 89 00:23:09 GMT
From:      scw@ollie.SEAS.UCLA.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Seeking info on TCP/IP for IBM m/f

In article <29590@iuvax.cs.indiana.edu> hughes@silver.bacs.indiana.edu (larry hughes) writes:
}>
}>	"... in addition, IBM extended support TCP/IP support from
}>	 its UNIX systems to its mainframes. System 370s can 
}>	 communicate with devices supporting TCP/IP either by
}>	 a direct connection to an Ethernet network, or through 
}>	 the 8232 LAN channel station to a token ring LAN.
}>
}
}Not really "direct"!  IBM's TCP/IP solution calls for an
}industrial-strength AT that's attached to the ethernet,
}and channel attached back to the IBM host.  They call it
}a FEP (front end processor).
}We're running an Intel FEP here...




Hmmmm,  This is like saying that an interlan VAX card is not direct, or that
an 'smart' card is not direct.  Remember a 360/370 channel is much like a
VERY smart unibus (albeit with only 256 slots on it).  Just because there
is some outboard processing doesn't mean that it's not direct.  As an anology
think of a IBM/PC (8086 flavor) attached to a Printronix P-600 printer, there
is more computing_power/smarts in the printer than there is in the computer.
Besides that's not really a FEP, as Series/1 terminal driver (for IXX) now
that's an FEP.  The 9370 CETI device is built into the processor, not attached
to an external channel.
-----
Stephen C. Woods; UCLA SEASNET; 2567 BH;LA CA 90024; (213)-825-8614
UUCP: ...!{ibmsupt,hao!cepu}!ollie}!scw ARPA:scw@{Ollie.,}SEAS.UCLA.EDU 

-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      14 Nov 89 00:38:13 GMT
From:      TCP-IP-RELAY@NIC.DDN.MIL
To:        comp.protocols.tcp-ip
Subject:   (none)

tcp-ip-relay
 F4.N494.Z5.FIDONET.ORG
TCP-IP-RES.RURES
 .WSU.EDU
tcp-ip-user@CS
 DUPHY4.DREXEL.EDU
tcp-ip-users
 LBL.GOV
tcp-ip-users
 BNLUX0.BNL.GOV
TCP-IP
 CARLETON.BITNET
tcp-ip
 CS.MCGILL.CA
TCP-IP
 MSSTATE.EDU
TCP-IP
 NET.NRL.NAVY.MIL
tcp-ip
 NETLABS.COM
tcp-ip
 RIACS.EDU
TCP-IP
 SPAM.ISTC.SRI.COM
tcp-ip
 SCCGATE.SCC.COM
tcp-ip
 TWG.COM
tcp-ip
 USAFA.AF.MIL
tcp-ip
 USNA.USNA.NAVY.MIL
tcp-ip
 UTDALVM1.UTDALLAS.EDU
tcp-ip
 UV4.EGLIN.AF.MIL
TCP-IP
 VAX01.AMS.COM
TCP-IP
 VENERA.ISI.EDU
TCP-IP
 XX.DREA.DND.CA
TCP-IP
 mbunix.mitre.org
tcp-ips
 PURDUE.EDU
tcp-ip-local
 MDC.COM
tcp-ip-relay
 XEROX.COM
tcp-ip^.x
 INTERLAN.COM
tcp-sig
 TRWIND.TRW.COM
tcp
 saturn.acc.com
tcpip-col
 OMNIGATE.CLARKSON.EDU
tcpip-local
 ALDNCF.ALCOA.COM
tcpip
 CAM.UNISYS.COM
tcpip
 SED.CEEE.NIST.GOV
tcpip
 SIMPACT.COM
tcpip
 CIM-VAX.HONEYWELL.COM
tcpip
 isdres.isd.usgs.gov
tcpip
 LOGICON.ARPA
tcpip
 muvms1.bitnet
tcpip
 anes.ucla.edu
tcp-ipg
 ncs.dnd.ca
tcpipinfo
 MSR.EPM.ORNL.GOV
tcpnews
 WLV.IMSD.CONTEL.COM
teecp-ip
 HAC2ARPA.HAC.COM
thomson%aries
 DTRC.ARPA
tinker
 CTS.SRI.COM
tony
 FORALIE.ICS.HAWAII.EDU
torben
 USC-SCE.USC.EDU
tsudik
 CSAM.LBL.GOV
van
 GARGOYLE.UCHICAGO.EDU
vijit!tcplist
 DUCVAX.AUBURN.EDU
warlick
 CSLI.STANFORD.EDU
whp4
 NARDACVA.ARPA
yx0quinn
 
Received: from CORNELLC.cit.cornell.edu by NIC.DDN.MIL with TCP; Mon, 13 Nov 89 10:14:45 PST
Received: from CORNELLC.BITNET by CORNELLC.cit.cornell.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 6258; Mon, 13 Nov 89 13:07:44 EST
Received: by CORNELLC (Mailer R2.04) id 7315; Mon, 13 Nov 89 13:07:43 EST
Date:         Mon, 13 Nov 89 12:21:38 EST
From:         Mark Bodenstein <MAB@CORNELLC.cit.cornell.edu>
Subject:      Re:  MXing the world (was RE:  New Host-Requirement RFCs)
To:           cs.utexas.edu!usc!csun!mx!cbcscmrs@tut.cis.ohio-state.edu
cc:           TCP-IP@NIC.DDN.MIL
In-Reply-To:  Your message of 7 Nov 89 22:51:55 GMT

> ...
 On 7 Nov 89 22:51:55 GMT you said:
>I have one simple question, why don't we (The Internet side) put an MX record
>into the root servers for the top-level domains .bitnet and maybe even .uucp?
> ...
>We can point them to cunyvm.cuny.edu or ucbvax.berkeley.edu or new.foo.bar.net
>or whatever the lastest host is.  ...

This doesn't work because there isn't a single gateway between the internet
and Bitnet - there are many - probably in the dozens at this time.  (This must
have been said earlier in this conversation?)

I think we're heading towards having a DNS-style-name and an MX record per
Bitnet site (more or less), with the MX record specifying (for the internet)
which gateway is the best to use - i.e. which is the "closest" on the Bitnet
side.

This optimizes things if we assume we want to maximize the amount of its
journey a mailfile takes on the Internet, and minimize the journey through
Bitnet.  This is at this time, in general, a Good Thing, since Internet
links tend to be faster/higher throughput than Bitnet links (which are,
generally speaking, 9600 baud bisync lines).  When/as/if this changes (and
it is changing) it becomes much more complicated to try to optimize things.

Mark Bodenstein   (mab@cornellc.cit.cornell.edu; 607-255-3747)
Cornell University

-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      14 Nov 89 01:39:26 GMT
From:      tcp-ip-RELAY@NIC.DDN.MIL
To:        comp.protocols.tcp-ip
Subject:   (none)

tcp-ip-relay
 F4.N494.Z5.FIDONET.ORG
TCP-IP-RES.RURES
 .WSU.EDU
tcp-ip-user@CS
 DUPHY4.DREXEL.EDU
tcp-ip-users
 LBL.GOV
tcp-ip-users
 BNLUX0.BNL.GOV
TCP-IP
 CARLETON.BITNET
tcp-ip
 CS.MCGILL.CA
TCP-IP
 MSSTATE.EDU
TCP-IP
 NET.NRL.NAVY.MIL
tcp-ip
 NETLABS.COM
tcp-ip
 RIACS.EDU
TCP-IP
 SPAM.ISTC.SRI.COM
tcp-ip
 SCCGATE.SCC.COM
tcp-ip
 TWG.COM
tcp-ip
 USAFA.AF.MIL
tcp-ip
 USNA.USNA.NAVY.MIL
tcp-ip
 UTDALVM1.UTDALLAS.EDU
tcp-ip
 UV4.EGLIN.AF.MIL
TCP-IP
 VAX01.AMS.COM
TCP-IP
 VENERA.ISI.EDU
TCP-IP
 XX.DREA.DND.CA
TCP-IP
 mbunix.mitre.org
tcp-ips
 PURDUE.EDU
tcp-ip-local
 MDC.COM
tcp-ip-relay
 XEROX.COM
tcp-ip^.x
 INTERLAN.COM
tcp-sig
 TRWIND.TRW.COM
tcp
 saturn.acc.com
tcpip-col
 OMNIGATE.CLARKSON.EDU
tcpip-local
 ALDNCF.ALCOA.COM
tcpip
 CAM.UNISYS.COM
tcpip
 SED.CEEE.NIST.GOV
tcpip
 SIMPACT.COM
tcpip
 CIM-VAX.HONEYWELL.COM
tcpip
 isdres.isd.usgs.gov
tcpip
 LOGICON.ARPA
tcpip
 muvms1.bitnet
tcpip
 anes.ucla.edu
tcp-ipg
 ncs.dnd.ca
tcpipinfo
 MSR.EPM.ORNL.GOV
tcpnews
 WLV.IMSD.CONTEL.COM
teecp-ip
 HAC2ARPA.HAC.COM
thomson%aries
 DTRC.ARPA
tinker
 CTS.SRI.COM
tony
 FORALIE.ICS.HAWAII.EDU
torben
 USC-SCE.USC.EDU
tsudik
 CSAM.LBL.GOV
van
 GARGOYLE.UCHICAGO.EDU
vijit!tcplist
 DUCVAX.AUBURN.EDU
warlick
 CSLI.STANFORD.EDU
whp4
 NARDACVA.ARPA
yx0quinn
 
Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 13 Nov 89 10:15:49 PST
Received: by ucbvax.Berkeley.EDU (5.61/1.39)
	id AA12693; Mon, 13 Nov 89 10:08:06 -0800
Received: from USENET by ucbvax.Berkeley.EDU with netnews
	for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa)
	(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 13 Nov 89 17:08:55 GMT
From: hercules!sparkyfs!aai8.itstd.sri.com!mckenney@apple.com  (Paul E. McKenney)
Organization: SRI International, Menlo Park CA
Subject: Re: Pilot Project: Hosts Table To Be Available Over Internet
Message-Id: <28690@sparkyfs.istc.sri.com>
References: <1872@yale-bulldog.yale.UUCP>, <71367@uunet.UU.NET>, <1989Nov6.154134.16530@gpu.utcs.utoronto.ca>
Sender: tcp-ip-relay@NIC.DDN.MIL
To: tcp-ip@NIC.DDN.MIL

In article <1989Nov6.154134.16530@gpu.utcs.utoronto.ca> dennis@gpu.utcs.utoronto.ca (Dennis Ferguson) writes:
>I can think of two reasons [for a host table] with some merit:
[ . . . two reasons omitted . . . ]

A third reason is to allow people to analyze the distributions of hostnames
and internet addresses.
				Thanx, Paul

-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      14 Nov 89 02:21:30 GMT
From:      tcp-ip-RELAY@NIC.DDN.MIL
To:        comp.protocols.tcp-ip
Subject:   (none)

tcp-ip-relay
 F4.N494.Z5.FIDONET.ORG
TCP-IP-RES.RURES
 .WSU.EDU
tcp-ip-user@CS
 DUPHY4.DREXEL.EDU
tcp-ip-users
 LBL.GOV
tcp-ip-users
 BNLUX0.BNL.GOV
TCP-IP
 CARLETON.BITNET
tcp-ip
 CS.MCGILL.CA
TCP-IP
 MSSTATE.EDU
TCP-IP
 NET.NRL.NAVY.MIL
tcp-ip
 NETLABS.COM
tcp-ip
 RIACS.EDU
TCP-IP
 SPAM.ISTC.SRI.COM
tcp-ip
 SCCGATE.SCC.COM
tcp-ip
 TWG.COM
tcp-ip
 USAFA.AF.MIL
tcp-ip
 USNA.USNA.NAVY.MIL
tcp-ip
 UTDALVM1.UTDALLAS.EDU
tcp-ip
 UV4.EGLIN.AF.MIL
TCP-IP
 VAX01.AMS.COM
TCP-IP
 VENERA.ISI.EDU
TCP-IP
 XX.DREA.DND.CA
TCP-IP
 mbunix.mitre.org
tcp-ips
 PURDUE.EDU
tcp-ip-local
 MDC.COM
tcp-ip-relay
 XEROX.COM
tcp-ip^.x
 INTERLAN.COM
tcp-sig
 TRWIND.TRW.COM
tcp
 saturn.acc.com
tcpip-col
 OMNIGATE.CLARKSON.EDU
tcpip-local
 ALDNCF.ALCOA.COM
tcpip
 CAM.UNISYS.COM
tcpip
 SED.CEEE.NIST.GOV
tcpip
 SIMPACT.COM
tcpip
 CIM-VAX.HONEYWELL.COM
tcpip
 isdres.isd.usgs.gov
tcpip
 LOGICON.ARPA
tcpip
 muvms1.bitnet
tcpip
 anes.ucla.edu
tcp-ipg
 ncs.dnd.ca
tcpipinfo
 MSR.EPM.ORNL.GOV
tcpnews
 WLV.IMSD.CONTEL.COM
teecp-ip
 HAC2ARPA.HAC.COM
thomson%aries
 DTRC.ARPA
tinker
 CTS.SRI.COM
tony
 FORALIE.ICS.HAWAII.EDU
torben
 USC-SCE.USC.EDU
tsudik
 CSAM.LBL.GOV
van
 GARGOYLE.UCHICAGO.EDU
vijit!tcplist
 DUCVAX.AUBURN.EDU
warlick
 CSLI.STANFORD.EDU
whp4
 NARDACVA.ARPA
yx0quinn
 
Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 13 Nov 89 10:46:02 PST
Received: by ucbvax.Berkeley.EDU (5.61/1.39)
	id AA14698; Mon, 13 Nov 89 10:39:46 -0800
Received: from USENET by ucbvax.Berkeley.EDU with netnews
	for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa)
	(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 13 Nov 89 16:51:37 GMT
From: stealth!brnstnd@sbcs.sunysb.edu  (Dan Bernstein)
Subject: Re: MXing the world
Message-Id: <3925@sbcs.sunysb.edu>
References: <2029@cmx.npac.syr.edu>, <16300008@uxh.cso.uiuc.edu>
Sender: tcp-ip-relay@NIC.DDN.MIL
To: tcp-ip@NIC.DDN.MIL

In article <16300008@uxh.cso.uiuc.edu> carlson@uxh.cso.uiuc.edu writes:
> IP routine minimizes travel time
> (and travail) for IP packets.

Ummm, no. It ``minimizes'' travel time based on an always out-of-date
picture of network load. The routing algorithms used by the Internet
transmit and use routing information as quickly and as often as data;
this leads to route flapping, completely lost routes, and other forms
of instability.

There is no way to minimize correctly, dynamically, and in real time.

---Dan

-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      14 Nov 89 03:04:45 GMT
From:      tcp-ip-RELAY@NIC.DDN.MIL
To:        comp.protocols.tcp-ip
Subject:   (none)

tcp-ip-relay
 F4.N494.Z5.FIDONET.ORG
TCP-IP-RES.RURES
 .WSU.EDU
tcp-ip-user@CS
 DUPHY4.DREXEL.EDU
tcp-ip-users
 LBL.GOV
tcp-ip-users
 BNLUX0.BNL.GOV
TCP-IP
 CARLETON.BITNET
tcp-ip
 CS.MCGILL.CA
TCP-IP
 MSSTATE.EDU
TCP-IP
 NET.NRL.NAVY.MIL
tcp-ip
 NETLABS.COM
tcp-ip
 RIACS.EDU
TCP-IP
 SPAM.ISTC.SRI.COM
tcp-ip
 SCCGATE.SCC.COM
tcp-ip
 TWG.COM
tcp-ip
 USAFA.AF.MIL
tcp-ip
 USNA.USNA.NAVY.MIL
tcp-ip
 UTDALVM1.UTDALLAS.EDU
tcp-ip
 UV4.EGLIN.AF.MIL
TCP-IP
 VAX01.AMS.COM
TCP-IP
 VENERA.ISI.EDU
TCP-IP
 XX.DREA.DND.CA
TCP-IP
 mbunix.mitre.org
tcp-ips
 PURDUE.EDU
tcp-ip-local
 MDC.COM
tcp-ip-relay
 XEROX.COM
tcp-ip^.x
 INTERLAN.COM
tcp-sig
 TRWIND.TRW.COM
tcp
 saturn.acc.com
tcpip-col
 OMNIGATE.CLARKSON.EDU
tcpip-local
 ALDNCF.ALCOA.COM
tcpip
 CAM.UNISYS.COM
tcpip
 SED.CEEE.NIST.GOV
tcpip
 SIMPACT.COM
tcpip
 CIM-VAX.HONEYWELL.COM
tcpip
 isdres.isd.usgs.gov
tcpip
 LOGICON.ARPA
tcpip
 muvms1.bitnet
tcpip
 anes.ucla.edu
tcp-ipg
 ncs.dnd.ca
tcpipinfo
 MSR.EPM.ORNL.GOV
tcpnews
 WLV.IMSD.CONTEL.COM
teecp-ip
 HAC2ARPA.HAC.COM
thomson%aries
 DTRC.ARPA
tinker
 CTS.SRI.COM
tony
 FORALIE.ICS.HAWAII.EDU
torben
 USC-SCE.USC.EDU
tsudik
 CSAM.LBL.GOV
van
 GARGOYLE.UCHICAGO.EDU
vijit!tcplist
 DUCVAX.AUBURN.EDU
warlick
 CSLI.STANFORD.EDU
whp4
 NARDACVA.ARPA
yx0quinn
 
Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 13 Nov 89 11:01:39 PST
Received: by ucbvax.Berkeley.EDU (5.61/1.39)
	id AA15401; Mon, 13 Nov 89 10:50:06 -0800
Received: from USENET by ucbvax.Berkeley.EDU with netnews
	for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa)
	(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 13 Nov 89 14:28:10 GMT
From: ncrlnk!ncrcae!bobw@uunet.uu.net  (Bob Williamson)
Organization: NCR Corp., Engineering & Manufacturing - Columbia, SC
Subject: TCP/IP on Versados??????
Message-Id: <5355@ncrcae.Columbia.NCR.COM>
Sender: tcp-ip-relay@NIC.DDN.MIL
To: tcp-ip@NIC.DDN.MIL


   NCR has a proprietary OS based on Motorola's Versados.  TMX is a 
   transaction-oriented OS used mainly by banks.  We currently have
   a requirement to bring up TCP/IP as a replacement for our current
   XNS-based LAN offerring.  I am looking for any knowledge of a 
   VERSAdos-based OS running TCP/IP.  Anything at all would be
   extremely helpful.

   On another related topic, we are having to decide very shortly
   on the method for getting TCP on TMX.  One vendor has recommended
   a STREAMS emulator on TMX and then their STREAMS-based TCP on top.
   It's not clear to me that putting STREAMS on a non-UNIX system
   is worth the effort; aren't their good, up-to-date character-based
   implementations?  Isn't BSD4.3 character-based?

  Thanks in advance for any guidance you may offer.



Bob Williamson
TOWER Networking Systems
E&M - Columbia
NCR Corporation
  

-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      14 Nov 89 03:24:03 GMT
From:      roy@phri.UUCP (Roy Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: MXing the world

In <16300008@uxh.cso.uiuc.edu> carlson@uxh.cso.uiuc.edu writes:
> The DNS doesn't deal with concepts like "nearest"

	But what if it did?  Let's say I'm the DNS server for the .BITNET
domain.  When a request comes in for an MX, I take a look at where the
request came from and use that information to select the proper MX record
to send back.  If I can't figure out which is the best, I send back some
default gateway.  I could even send back the same set of MXers to
everybody, but with customized priorities.

	That's not how DNS is supposed to work, but how could an outside
entity detect that I'm doing something fishy?  The fact that repeted
requests don't give back the same answer is in itself not a protocol
violation; what's to keep me from changing my master file every 10 seconds
if I wanted to, and how could you tell the difference between a quickly
changing master file and a routing DNS server?
-- 
Roy Smith, Public Health Research Institute
455 First Avenue, New York, NY 10016
{att,philabs,cmcl2,rutgers,hombre}!phri!roy -or- roy@alanine.phri.nyu.edu
"The connector is the network"

-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      14 Nov 89 03:49:14 GMT
From:      tcp-ip-RELAY@NIC.DDN.MIL
To:        comp.protocols.tcp-ip
Subject:   (none)

tcp-ip-relay
 F4.N494.Z5.FIDONET.ORG
TCP-IP-RES.RURES
 .WSU.EDU
tcp-ip-user@CS
 DUPHY4.DREXEL.EDU
tcp-ip-users
 LBL.GOV
tcp-ip-users
 BNLUX0.BNL.GOV
TCP-IP
 CARLETON.BITNET
tcp-ip
 CS.MCGILL.CA
TCP-IP
 MSSTATE.EDU
TCP-IP
 NET.NRL.NAVY.MIL
tcp-ip
 NETLABS.COM
tcp-ip
 RIACS.EDU
TCP-IP
 SPAM.ISTC.SRI.COM
tcp-ip
 SCCGATE.SCC.COM
tcp-ip
 TWG.COM
tcp-ip
 USAFA.AF.MIL
tcp-ip
 USNA.USNA.NAVY.MIL
tcp-ip
 UTDALVM1.UTDALLAS.EDU
tcp-ip
 UV4.EGLIN.AF.MIL
TCP-IP
 VAX01.AMS.COM
TCP-IP
 VENERA.ISI.EDU
TCP-IP
 XX.DREA.DND.CA
TCP-IP
 mbunix.mitre.org
tcp-ips
 PURDUE.EDU
tcp-ip-local
 MDC.COM
tcp-ip-relay
 XEROX.COM
tcp-ip^.x
 INTERLAN.COM
tcp-sig
 TRWIND.TRW.COM
tcp
 saturn.acc.com
tcpip-col
 OMNIGATE.CLARKSON.EDU
tcpip-local
 ALDNCF.ALCOA.COM
tcpip
 CAM.UNISYS.COM
tcpip
 SED.CEEE.NIST.GOV
tcpip
 SIMPACT.COM
tcpip
 CIM-VAX.HONEYWELL.COM
tcpip
 isdres.isd.usgs.gov
tcpip
 LOGICON.ARPA
tcpip
 muvms1.bitnet
tcpip
 anes.ucla.edu
tcp-ipg
 ncs.dnd.ca
tcpipinfo
 MSR.EPM.ORNL.GOV
tcpnews
 WLV.IMSD.CONTEL.COM
teecp-ip
 HAC2ARPA.HAC.COM
thomson%aries
 DTRC.ARPA
tinker
 CTS.SRI.COM
tony
 FORALIE.ICS.HAWAII.EDU
torben
 USC-SCE.USC.EDU
tsudik
 CSAM.LBL.GOV
van
 GARGOYLE.UCHICAGO.EDU
vijit!tcplist
 DUCVAX.AUBURN.EDU
warlick
 CSLI.STANFORD.EDU
whp4
 NARDACVA.ARPA
yx0quinn
 
Received: from Sun.COM by NIC.DDN.MIL with TCP; Mon, 13 Nov 89 12:03:41 PST
Received: from iruucp.sun.com (iruucp.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1)
	id AA20358; Mon, 13 Nov 89 12:03:07 PST
Received: from ntrlink.UUCP by iruucp.sun.com (4.0/SMI-4.0)
	with UUCP id AA26208; Mon, 13 Nov 89 12:00:48 PST
Received: by  (4.0/SMI-4.0)
	id AA03311; Mon, 13 Nov 89 12:00:49 PST
Date: Mon, 13 Nov 89 12:00:49 PST
From: ntrlink!fjd@Sun.COM (Farokh Deboo)
Message-Id: <8911132000.AA03311@>
To: iruucp!sun!sri-nic.arpa!tcp-ip@Sun.COM
Subject: Spider Systems Info Requested

I am looking for comments from users of Spider Systems "Streams
Software for OEMs" that was presented at Interop 89.  Specifically I am
looking for experiences with the port of their TCP package, their
streams emulator, and (if there are any users) their OSI package.

Please reply directly to me at the address below.

Thanks,

Farokh Deboo			Interlink Computer Sciences
sun!iruucp!ntrlink!fjd		47370 Fremont Blvd
(415) 657-9800			Fremont, CA 94538

-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      14 Nov 89 04:33:48 GMT
From:      david@ms.uky.edu (David Herron -- One of the vertebrae)
To:        comp.protocols.tcp-ip
Subject:   Re: ARP+

There was 3 or 4 RFC's in the 900's which were on the subject of
"transparent subnetting" ... one of the ideas there I thought had
a lot of promise but I don't think is implemented anywhere.  The idea
as I recall is to transmit your ARP as always.  The gateways take your
ARP and because it's subnet mask isn't right know it's not on the local
subnet and turn around and send it into the other networks they're
attached to.  The gateways on those subnets do the same look-at-subnet-
and-rebroadcast-if-necessary routine.

There was a couple of things in there which I don't recall too well
which kept loops from occuring.  Also I'm not 100% certain how the
response got back to the sender but it's probably by way of normal
IP routing.  Loop prevention could be done with a Usenet Path: style
marker in the packet which records the subnets each instance of the
packet has traversed, but that would break the protocol a bit.

This is tempting because it places all the complications in the
gateways and out of the hosts -- something that is likely a
desirable end goal.


-- 
<- David Herron; an MMDF guy                              <david@ms.uky.edu>
<- ska: David le casse\*'      {rutgers,uunet}!ukma!david, david@UKMA.BITNET
<- 
<- New official address:  attmail!sparsdev!dsh@attunix.att.com

-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      14 Nov 89 04:37:58 GMT
From:      tcp-ip-RELAY@NIC.DDN.MIL
To:        comp.protocols.tcp-ip
Subject:   (none)

tcp-ip-relay
 F4.N494.Z5.FIDONET.ORG
TCP-IP-RES.RURES
 .WSU.EDU
tcp-ip-user@CS
 DUPHY4.DREXEL.EDU
tcp-ip-users
 LBL.GOV
tcp-ip-users
 BNLUX0.BNL.GOV
TCP-IP
 CARLETON.BITNET
tcp-ip
 CS.MCGILL.CA
TCP-IP
 MSSTATE.EDU
TCP-IP
 NET.NRL.NAVY.MIL
tcp-ip
 NETLABS.COM
tcp-ip
 RIACS.EDU
TCP-IP
 SPAM.ISTC.SRI.COM
tcp-ip
 SCCGATE.SCC.COM
tcp-ip
 TWG.COM
tcp-ip
 USAFA.AF.MIL
tcp-ip
 USNA.USNA.NAVY.MIL
tcp-ip
 UTDALVM1.UTDALLAS.EDU
tcp-ip
 UV4.EGLIN.AF.MIL
TCP-IP
 VAX01.AMS.COM
TCP-IP
 VENERA.ISI.EDU
TCP-IP
 XX.DREA.DND.CA
TCP-IP
 mbunix.mitre.org
tcp-ips
 PURDUE.EDU
tcp-ip-local
 MDC.COM
tcp-ip-relay
 XEROX.COM
tcp-ip^.x
 INTERLAN.COM
tcp-sig
 TRWIND.TRW.COM
tcp
 saturn.acc.com
tcpip-col
 OMNIGATE.CLARKSON.EDU
tcpip-local
 ALDNCF.ALCOA.COM
tcpip
 CAM.UNISYS.COM
tcpip
 SED.CEEE.NIST.GOV
tcpip
 SIMPACT.COM
tcpip
 CIM-VAX.HONEYWELL.COM
tcpip
 isdres.isd.usgs.gov
tcpip
 LOGICON.ARPA
tcpip
 muvms1.bitnet
tcpip
 anes.ucla.edu
tcp-ipg
 ncs.dnd.ca
tcpipinfo
 MSR.EPM.ORNL.GOV
tcpnews
 WLV.IMSD.CONTEL.COM
teecp-ip
 HAC2ARPA.HAC.COM
thomson%aries
 DTRC.ARPA
tinker
 CTS.SRI.COM
tony
 FORALIE.ICS.HAWAII.EDU
torben
 USC-SCE.USC.EDU
tsudik
 CSAM.LBL.GOV
van
 GARGOYLE.UCHICAGO.EDU
vijit!tcplist
 DUCVAX.AUBURN.EDU
warlick
 CSLI.STANFORD.EDU
whp4
 NARDACVA.ARPA
yx0quinn
 
Received: from MATHOM.CISCO.COM by NIC.DDN.MIL with TCP; Mon, 13 Nov 89 13:34:44 PST
Date: Mon 13 Nov 89 13:33:51-PST
From: William Westfield <BILLW@MATHOM.CISCO.COM>
Subject: Re: ARP+
To: cs.utexas.edu!wuarchive!brutus.cs.uiuc.edu!zweig@tut.cis.ohio-state.edu
cc: tcp-ip@NIC.DDN.MIL
In-Reply-To: <1989Nov7.210118.13557@brutus.cs.uiuc.edu>
Message-ID: <12541990931.21.BILLW@MATHOM.CISCO.COM>

	ARP will give you a good answer if W.X.Y.Z is on the same physical
	subnet as you. Also works if there is only one gateway on that net
	and it decides to do proxy-ARP for everybody else.

I don't think you understand Proxy-ARP.  A router should only issue a
proxy ARP reply to an ARP request if it is the BEST route to the host.
The routers, of course, know such things.  If routes are equivilent,
then multiple routers can answer and it doesn't matter.  If the routers
are stupid, and issue proxy ARP replies for anything not on the local
network (and I don't know of any routers that would do such a thing),
then at worst, they will get get a packet that should have gone to a
different router, and issue an ICMP redirect, which the host should
listen to (it then knows that there is a router involved, and knows
which router to use).

In general, you should NOT use ARP to make routing decisions at all.
"proxy ARP" is a (clever and useful) HACK, not a feature of ARP.  The
IETF is trying to come up with a standard "Router discovery protocl"
so that relatively dumb hosts can reasonably pick a "deafult router"
(and get re-directed to other routers as appropriate).  This is quite
separate from ARP, which is used only to resolve IP addresses to
physical addresses.


    QUESTIONS: Would it be hip just to use RIP as though it were
    ARP+? That is, would it be bad to send out a RIP-request every
    time I send out an ARP packet?

No.  I would be a bad idea.  RIP is on its way out as a routing protocol.
The "Host requirements" RFCs explicitly state that HOSTS should not muck
with routing protocols.  And this still confuses ARP and Router selection.

Bill Westfield
-------

-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      14 Nov 89 05:30:27 GMT
From:      tcp-ip-RELAY@NIC.DDN.MIL
To:        comp.protocols.tcp-ip
Subject:   (none)

tcp-ip-relay
 F4.N494.Z5.FIDONET.ORG
TCP-IP-RES.RURES
 .WSU.EDU
tcp-ip-user@CS
 DUPHY4.DREXEL.EDU
tcp-ip-users
 LBL.GOV
tcp-ip-users
 BNLUX0.BNL.GOV
TCP-IP
 CARLETON.BITNET
tcp-ip
 CS.MCGILL.CA
TCP-IP
 MSSTATE.EDU
TCP-IP
 NET.NRL.NAVY.MIL
tcp-ip
 NETLABS.COM
tcp-ip
 RIACS.EDU
TCP-IP
 SPAM.ISTC.SRI.COM
tcp-ip
 SCCGATE.SCC.COM
tcp-ip
 TWG.COM
tcp-ip
 USAFA.AF.MIL
tcp-ip
 USNA.USNA.NAVY.MIL
tcp-ip
 UTDALVM1.UTDALLAS.EDU
tcp-ip
 UV4.EGLIN.AF.MIL
TCP-IP
 VAX01.AMS.COM
TCP-IP
 VENERA.ISI.EDU
TCP-IP
 XX.DREA.DND.CA
TCP-IP
 mbunix.mitre.org
tcp-ips
 PURDUE.EDU
tcp-ip-local
 MDC.COM
tcp-ip-relay
 XEROX.COM
tcp-ip^.x
 INTERLAN.COM
tcp-sig
 TRWIND.TRW.COM
tcp
 saturn.acc.com
tcpip-col
 OMNIGATE.CLARKSON.EDU
tcpip-local
 ALDNCF.ALCOA.COM
tcpip
 CAM.UNISYS.COM
tcpip
 SED.CEEE.NIST.GOV
tcpip
 SIMPACT.COM
tcpip
 CIM-VAX.HONEYWELL.COM
tcpip
 isdres.isd.usgs.gov
tcpip
 LOGICON.ARPA
tcpip
 muvms1.bitnet
tcpip
 anes.ucla.edu
tcp-ipg
 ncs.dnd.ca
tcpipinfo
 MSR.EPM.ORNL.GOV
tcpnews
 WLV.IMSD.CONTEL.COM
teecp-ip
 HAC2ARPA.HAC.COM
thomson%aries
 DTRC.ARPA
tinker
 CTS.SRI.COM
tony
 FORALIE.ICS.HAWAII.EDU
torben
 USC-SCE.USC.EDU
tsudik
 CSAM.LBL.GOV
van
 GARGOYLE.UCHICAGO.EDU
vijit!tcplist
 DUCVAX.AUBURN.EDU
warlick
 CSLI.STANFORD.EDU
whp4
 NARDACVA.ARPA
yx0quinn
 
Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 13 Nov 89 14:03:18 PST
Received: by ucbvax.Berkeley.EDU (5.61/1.39)
	id AA25840; Mon, 13 Nov 89 13:34:02 -0800
Received: from USENET by ucbvax.Berkeley.EDU with netnews
	for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa)
	(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 13 Nov 89 20:28:05 GMT
From: mcsun!sunic!draken!perand@uunet.uu.net  (Per Andersson)
Organization: Royal Institute of Technology, Stockholm, Sweden
Subject: Re: Anybody know of an enet/TCP printer?
Message-Id: <2302@draken.nada.kth.se>
References: <1989Nov7.210143.26795@t2ns1.gcs.co.nz>, <13207@s.ms.uky.edu>
Sender: tcp-ip-relay@NIC.DDN.MIL
To: tcp-ip@NIC.DDN.MIL

In article <13207@s.ms.uky.edu> david@ms.uky.edu (David Herron -- One of the vertebrae) writes:
>uhm .. (I'm famous for that "uhm") .. why wouldn't it work to hang
>the printer off a terminal server?  Or do you not have any terminal 
>servers?

One reason could be the lack of speed - most printers with RS232 interfaces
only manage 9600 BPS, some 19200 BPS. One nice product I've seen is by an
english company called Software Products. They take a Canon chassi and connect
a parallell cable to a VME card for SUNs they developed. This makes the printer
work as fast as it can, but I dont know what youre supposed to send to the 
card. I suppose it's a bitmap, and possibly only their own DTP program work
with it.

Per
-- 
Per Andersson
Royal Institute of Technology, Stockholm, Sweden
perand@admin.kth.se, @tds.kth.se, @nada.kth.se 
or perhaps {backbone}!sunic!ttds!perand

-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      14 Nov 89 06:05:32 GMT
From:      houpt@husc8.HARVARD.EDU (Thomas Houpt)
To:        comp.protocols.tcp-ip
Subject:   Does Data General under AOS/VS use TCP/IP?


A friend of mine is trying to network a Data General computer
running AOS/VS to Macintoshes with ethernet. The DG is controlling
a Magnetic Resonance Imgaing system for brain scans, and is already
networked to its "peripherals" (an MRI scanner, a vector processor, and
a display terminal) via an ehternet cluster box. The cluster box
has a total of 9 ports, of which only 3 are being used. He wants to
plug a transceiver box into one of the unused ports, and run coax
to a Mac ethernet card so he can downloadscanned image files for display.
The question is, does the DG use TCP-IP on its ethernet network,
or is it available (along with ftp for the file transfer) for the
DG operating system. Once we know its possible to get TCP-IP/FTP
running, we know what to do. But we are sufficiently unfamiliar with the
DG operating system not to know if this is trivial or impossible.

I noticed a few replies posted here titled "Re Data General" , but
I missed the beginng of the exchange. So I apologize if I am asking
a recently asked question over again.

Thanks in advance.

-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      14 Nov 89 06:23:26 GMT
From:      tcp-ip-RELAY@NIC.DDN.MIL
To:        comp.protocols.tcp-ip
Subject:   (none)

tcp-ip-relay
 F4.N494.Z5.FIDONET.ORG
TCP-IP-RES.RURES
 .WSU.EDU
tcp-ip-user@CS
 DUPHY4.DREXEL.EDU
tcp-ip-users
 LBL.GOV
tcp-ip-users
 BNLUX0.BNL.GOV
TCP-IP
 CARLETON.BITNET
tcp-ip
 CS.MCGILL.CA
TCP-IP
 MSSTATE.EDU
TCP-IP
 NET.NRL.NAVY.MIL
tcp-ip
 NETLABS.COM
tcp-ip
 RIACS.EDU
TCP-IP
 SPAM.ISTC.SRI.COM
tcp-ip
 SCCGATE.SCC.COM
tcp-ip
 TWG.COM
tcp-ip
 USAFA.AF.MIL
tcp-ip
 USNA.USNA.NAVY.MIL
tcp-ip
 UTDALVM1.UTDALLAS.EDU
tcp-ip
 UV4.EGLIN.AF.MIL
TCP-IP
 VAX01.AMS.COM
TCP-IP
 VENERA.ISI.EDU
TCP-IP
 XX.DREA.DND.CA
TCP-IP
 mbunix.mitre.org
tcp-ips
 PURDUE.EDU
tcp-ip-local
 MDC.COM
tcp-ip-relay
 XEROX.COM
tcp-ip^.x
 INTERLAN.COM
tcp-sig
 TRWIND.TRW.COM
tcp
 saturn.acc.com
tcpip-col
 OMNIGATE.CLARKSON.EDU
tcpip-local
 ALDNCF.ALCOA.COM
tcpip
 CAM.UNISYS.COM
tcpip
 SED.CEEE.NIST.GOV
tcpip
 SIMPACT.COM
tcpip
 CIM-VAX.HONEYWELL.COM
tcpip
 isdres.isd.usgs.gov
tcpip
 LOGICON.ARPA
tcpip
 muvms1.bitnet
tcpip
 anes.ucla.edu
tcp-ipg
 ncs.dnd.ca
tcpipinfo
 MSR.EPM.ORNL.GOV
tcpnews
 WLV.IMSD.CONTEL.COM
teecp-ip
 HAC2ARPA.HAC.COM
thomson%aries
 DTRC.ARPA
tinker
 CTS.SRI.COM
tony
 FORALIE.ICS.HAWAII.EDU
torben
 USC-SCE.USC.EDU
tsudik
 CSAM.LBL.GOV
van
 GARGOYLE.UCHICAGO.EDU
vijit!tcplist
 DUCVAX.AUBURN.EDU
warlick
 CSLI.STANFORD.EDU
whp4
 NARDACVA.ARPA
yx0quinn
 
Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 13 Nov 89 14:21:38 PST
Received: by ucbvax.Berkeley.EDU (5.61/1.39)
	id AA27965; Mon, 13 Nov 89 14:04:47 -0800
Received: from USENET by ucbvax.Berkeley.EDU with netnews
	for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa)
	(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 13 Nov 89 22:03:45 GMT
From: silver!hughes@iuvax.cs.indiana.edu  (larry hughes)
Organization: Indiana University, Bloomington
Subject: Re: X.WINDOWS for PC's
Message-Id: <29589@iuvax.cs.indiana.edu>
References: <89Nov12.191610est.57347@ugw.utcs.utoronto.ca>
Sender: tcp-ip-relay@NIC.DDN.MIL
To: tcp-ip@NIC.DDN.MIL

In article <89Nov12.191610est.57347@ugw.utcs.utoronto.ca> 01696@AECLCR.BITNET (Chris Tanner) writes:
>We have just obtained X.Windows for our CDC NOS/VE system, and are now looking
>for ways to use it. While we expect to have workstations in the near future
>(SUN or Silicon Graphics), we are looking for implementations for the PC.
>
>Does anybody now of X.WINDOWS "clients" for either the PC or MAC.

DEC has done a version of DECwindows for the PC.  Since DECwindows
is really X with DEC's toolkit, I think you can count it.  I don't
know if it's any good or not...

 //=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=\\
|| Larry J. Hughes, Senior Programmer ||  hughes@silver.bacs.indiana.edu   ||
||        Indiana University          ||                                   ||
||   University Computing Services    ||  "The person who knows everything ||
||    750 N. State Road 46 Bypass     ||     has a lot to learn."          ||
||      Bloomington, IN  47405        ||                                   ||
||         (812) 855-9255             ||  Disclaimer: See quote above.     ||
 \\=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=//

-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      14 Nov 89 06:50:37 GMT
From:      mrose@CHEETAH.NYSER.NET (Marshall Rose)
To:        comp.protocols.tcp-ip
Subject:   Re: SNMP tools

Why don't you drop a note to the SNMP list and ask the same question.
The address is:

	snmp@nisc.nyser.net

In addition to the two commonly used public domain versions of SNMP (the
MIT and the CMU releases), the next release of the ISODE will have an
openly available implementation of a 4BSD SNMP agent.  You will still
need to get NOC software, either from MIT, CMU, or one of the zillions
of companies selling SNMP-based NOCs these days.  My opinion is that
whilst it is probably OK to get openly available software to run agent
code on commonly used platforms, I bet you will find it necessary to go
to a real vendor to get comprehensive NOC tools...

In retrospect, I find it difficult to believe that either the MIT or CMU
agent code, if they run on a Sun, would have problems with generic 4BSD
kernels.  

Please direct all replies to the snmp list...

/mtr

[the usual conflict of interest disclosure: I chair the working group
responsible for the SNMP and the core MIB; I work for a company that
sells an SNMP implementation; I wrote the 4BSD/ISODE SNMP agent; etc., etc.]

-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      14 Nov 89 07:10:42 GMT
From:      tcp-ip-RELAY@NIC.DDN.MIL
To:        comp.protocols.tcp-ip
Subject:   (none)

tcp-ip-relay
 F4.N494.Z5.FIDONET.ORG
TCP-IP-RES.RURES
 .WSU.EDU
tcp-ip-user@CS
 DUPHY4.DREXEL.EDU
tcp-ip-users
 LBL.GOV
tcp-ip-users
 BNLUX0.BNL.GOV
TCP-IP
 CARLETON.BITNET
tcp-ip
 CS.MCGILL.CA
TCP-IP
 MSSTATE.EDU
TCP-IP
 NET.NRL.NAVY.MIL
tcp-ip
 NETLABS.COM
tcp-ip
 RIACS.EDU
TCP-IP
 SPAM.ISTC.SRI.COM
tcp-ip
 SCCGATE.SCC.COM
tcp-ip
 TWG.COM
tcp-ip
 USAFA.AF.MIL
tcp-ip
 USNA.USNA.NAVY.MIL
tcp-ip
 UTDALVM1.UTDALLAS.EDU
tcp-ip
 UV4.EGLIN.AF.MIL
TCP-IP
 VAX01.AMS.COM
TCP-IP
 VENERA.ISI.EDU
TCP-IP
 XX.DREA.DND.CA
TCP-IP
 mbunix.mitre.org
tcp-ips
 PURDUE.EDU
tcp-ip-local
 MDC.COM
tcp-ip-relay
 XEROX.COM
tcp-ip^.x
 INTERLAN.COM
tcp-sig
 TRWIND.TRW.COM
tcp
 saturn.acc.com
tcpip-col
 OMNIGATE.CLARKSON.EDU
tcpip-local
 ALDNCF.ALCOA.COM
tcpip
 CAM.UNISYS.COM
tcpip
 SED.CEEE.NIST.GOV
tcpip
 SIMPACT.COM
tcpip
 CIM-VAX.HONEYWELL.COM
tcpip
 isdres.isd.usgs.gov
tcpip
 LOGICON.ARPA
tcpip
 muvms1.bitnet
tcpip
 anes.ucla.edu
tcp-ipg
 ncs.dnd.ca
tcpipinfo
 MSR.EPM.ORNL.GOV
tcpnews
 WLV.IMSD.CONTEL.COM
teecp-ip
 HAC2ARPA.HAC.COM
thomson%aries
 DTRC.ARPA
tinker
 CTS.SRI.COM
tony
 FORALIE.ICS.HAWAII.EDU
torben
 USC-SCE.USC.EDU
tsudik
 CSAM.LBL.GOV
van
 GARGOYLE.UCHICAGO.EDU
vijit!tcplist
 DUCVAX.AUBURN.EDU
warlick
 CSLI.STANFORD.EDU
whp4
 NARDACVA.ARPA
yx0quinn
 
Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 13 Nov 89 14:21:58 PST
Received: by ucbvax.Berkeley.EDU (5.61/1.39)
	id AA28347; Mon, 13 Nov 89 14:10:25 -0800
Received: from USENET by ucbvax.Berkeley.EDU with netnews
	for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa)
	(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 13 Nov 89 22:08:59 GMT
From: silver!hughes@iuvax.cs.indiana.edu  (larry hughes)
Organization: Indiana University, Bloomington
Subject: Re: Seeking info on TCP/IP for IBM m/f
Message-Id: <29590@iuvax.cs.indiana.edu>
References: <122@centaure.UUCP>
Sender: tcp-ip-relay@NIC.DDN.MIL
To: tcp-ip@NIC.DDN.MIL

In article <122@centaure.UUCP> cliff@centaure.UUCP (Clifford Dibble) writes:
>
>I'm interested in TCP/IP products for IBM mainframes. I'm taking a 
>"Introduction to LANs" class, and this is one area of research
>suggested by the instructor. Specifically, we're to find ways to
>make an Ethernet full of Sun workstations talk to an IBM 
>mainframe.
>
>In the article "OSI Takes on TCP/IP" (S.Fisher, UNIX World, Feb 1989),
>it is stated:
>
>	"... in addition, IBM extended support TCP/IP support from
>	 its UNIX systems to its mainframes. System 370s can 
>	 communicate with devices supporting TCP/IP either by
>	 a direct connection to an Ethernet network, or through 
>	 the 8232 LAN channel station to a token ring LAN.
>

Not really "direct"!  IBM's TCP/IP solution calls for an
industrial-strength AT that's attached to the ethernet,
and channel attached back to the IBM host.  They call it
a FEP (front end processor).

We're running an Intel FEP here...

 //=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=\\
|| Larry J. Hughes, Senior Programmer ||  hughes@silver.bacs.indiana.edu   ||
||        Indiana University          ||                                   ||
||   University Computing Services    ||  "The person who knows everything ||
||    750 N. State Road 46 Bypass     ||     has a lot to learn."          ||
||      Bloomington, IN  47405        ||                                   ||
||         (812) 855-9255             ||  Disclaimer: See quote above.     ||
 \\=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=//

-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14 Nov 89 14:05:56 EST
From:      ted@NADC.ARPA (T. Calkins)
To:        lam@NADC.ARPA, tcp-ip@nic.ddn.mil
Subject:   Re:  please remove my name
>> From tcp-ip-RELAY@NIC.DDN.MIL Wed Nov  8 21:18:29 1989
>> Received: from [26.0.0.73] by NADC.ARPA (5.59/1.0 )
>> 	id AA16520; Wed, 8 Nov 89 21:18:13 EST
>> Received: from NADC.ARPA by NIC.DDN.MIL with TCP; Wed, 8 Nov 89 17:19:43 PST
>> Received: by NADC.ARPA (5.59/1.0 )
>> 	id AA16259; Wed, 8 Nov 89 20:12:46 EST
>> Date: Wed, 8 Nov 89 20:12:46 EST
>> From: lam@NADC.ARPA (D. Lam)
>> Message-Id: <8911090112.AA16259@NADC.ARPA>
>> To: tcp-ip@nic.ddn.mil
>> Subject: please remove my name
>> Status: RO
>> 
>> 
>> Please, remove my name off the tcp/ip user group list.  Thank you.
>> 
>> lam@nadc.arpa
>> z

---------------------------------
 
David: your name is removed. Try being a good boy the rest of
       the year. 
                               Santa Claus
-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      14 Nov 89 14:20:20 GMT
From:      mhampson@wpi.wpi.edu (Mark A. Hampson)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.periphs.printers
Subject:   Re: Anybody know of an enet/TCP printer?

I have recently seen an add in Computer Shopper for a device that will 
allow an HP-LJ to be placed on a "LAN".  As to the protocal that it will
speak, the add did not say, but we are asking for info from the company
as I write.

-- 
/----------------------------------------------------------------------------\
|      We are not in an energy crisis, we are having an entropy crisis...    |
\----------------------------------------------------------------------------/

-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      14 Nov 89 15:56:27 GMT
From:      dls@mentor.cc.purdue.edu (David L Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: 4.3 TAHOE and NFS?


	I merged 4.3T (really post 4.3T) code into our NFS-speaking Sequent
machines running DYNIX 2.1 and later DYNIX 3.0.X, X=1-17 (I believe). The
interactions were minimal and virtually all the changes I had were due to
the need for locking and reentrant code on a multiprocessor.
	For the most part the layer division keeps you worry free; you just
need to make sure all the functions you're using have the arguments and
semantics you want; busy work, really. The only difference that I remember
offhand is the need for a larger max UDP packet size, but there were probably
a couple other minor ones.
-- 
					+-DLS  (dls@mentor.cc.purdue.edu)

-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      14 Nov 89 19:33:55 GMT
From:      dab@BERSERKLY.CRAY.COM (David Borman)
To:        comp.protocols.tcp-ip
Subject:   Telnet source code


The latest copy of source for both telnet and telnetd are now available
for anonymous ftp from ucbarpa.berkeley.edu.  There is a single
compressed tar file, pub/telnet.tar.Z, which has both the client
and the server code.  This file also has diffs from the 4.3BSD
pty/terminal driver to add the necessary support needed to run
a server telnetd that supports linemode.  If you had previously gotten
a copy of the telnet from ucbarpa, you should get this new copy.

This is the basis for both telnet and telnetd that will be released
in 4.4BSD.  These new versions have support for both SysV termio
structures, and POSIX termios structures.  Attached is the README
file that is included in the tar file.

		-Dave Borman, dab@cray.com

November 14, 1989

This is a distribution of both client and server telnet.  These programs
have been compiled and run on BSD4.3, BSD4.4, and Cray UNICOS 5.0/5.1.
In addition, the telnet client source has been compiled an run on
SunOS 3.5 and DYNIX V3.0.12

Questions/comments go to
		Dave Borman
		Cray Research, Inc.
		1440 Northland Drive
		Mendota Heights, MN 55120
		dab@cray.com.

README:	You are reading it.

kern.diff:
	This file contains the diffs for the changes needed for the
	kernel to support LINEMODE is the server.

	There is a new bit in the terminal state word, TS_EXTPROC.
	When this bit is set, several aspects of the terminal driver
	are disabled.  Input line editing, character echo, and
	mapping of signals are all disabled.  This allows the telnetd
	to turn of these functions when in linemode, but still keep
	track of what state the user wants the terminal to be in.

	New ioctl()s:

		TIOCEXT		Turn on/off the TS_EXTPROC bit
		TIOCGSTATE	Get t_state of tty to look at TS_EXTPROC bit
		TIOCSIG		Generate a signal to processes in the
				current process group of the pty.

	There is a new mode for packet driver, the TIOCPKT_IOCTL bit.
	When packet mode is turned on in the pty, and the TS_EXTPROC
	bit is set, then whenever the state of the pty is changed, the
	next read on the master side of the pty will have the TIOCPKT_IOCTL
	bit set, and the data will contain the following:
		struct xx {
			struct sgttyb a;
			struct tchars b;
			struct ltchars c;
			int t_state;
			int t_flags;
		}
	This allows the process on the server side of the pty to know
	when the state of the terminal has changed, and what the new
	state is.

stty.diff:
	This file contains the changes needed for the stty(1) program
	to report on the current status of the TS_EXTPROC bit.  It also
	allows the user to turn on/off the TS_EXTPROC bit.  This is useful
	because it allows the user to say "stty -extproc", and the
	LINEMODE option will be automatically disabled, and saying "stty
	extproc" will re-enable the LINEMODE option.

telnet.state:
	Both the client and server have code in them to deal
	with option negotiation loops.  The algorithm that is
	used is described in this file.

telnet:
	This directory contains the client code.  No kernel changes are
	needed to use this code.

telnetd:
	This directory contains the server code.  If LINEMODE or KLUDGELINEMODE
	are defined, then the kernel modifications listed above are needed.

arpa:
	This directory has a new <arpa/telnet.h>


The following TELNET options are supported:

	LINEMODE:
		The LINEMODE option is supported as per RFC1116.  The
		FORWARDMASK option is not currently supported.

	BINARY: The client has the ability to turn on/off the BINARY
		option in each direction.  Turning on BINARY from
		server to client causes the LITOUT bit to get set in
		the terminal driver on both ends,  turning on BINARY
		from the client to the server causes the PASS8 bit
		to get set in the terminal driver on both ends.

	TERMINAL-TYPE:
		This is supported as per RFC1091.  On the server side,
		when a terminal type is received, termcap/terminfo
		is consulted to determine if it is a known terminal
		type.  It keeps requesting terminal types until it
		gets one that it recongnizes, or hits the end of the
		list.  The server side looks up the entry in the
		termcap/terminfo data base, and generates a list of
		names which it then passes one at a time to each
		request for a terminal type, duplicating the last
		entry in the list before cycling back to the beginning.

	NAWS:	The Negotiate about Window Size, as per RFC 1073.

	TERMINAL-SPEED:
		Implemented as per RFC 1079

	TOGGLE-FLOW-CONTROL:
		Implemented as per RFC 1080

	TIMING-MARK:
		As per RFC 860

	SGA:	As per RFC 858

	ECHO:	As per RFC 857

	STATUS:
		The server will send its current status upon
		request.  It does not ask for the clients status.
		The client will request the servers current status
		from the "send getstatus" command.

	The X-DISPLAY-LOCATION option is not supported.

Look at the Makefile for comments about #define paramaters that need
to be set up for your individual site.

-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      14 Nov 89 19:57:57 GMT
From:      stine@SPARTA.COM (Robert Havens Stine)
To:        comp.protocols.tcp-ip
Subject:   Re:  Information Request

>    Charles Hedrick's paper, "Introduction to Internet Protocols,"
>    available via anonymous ftp from icarus.cns.syr.edu, in file
>    ~/info/inet.iprotos.txt,

Please make that info/iip.txt

>    John Wobus's paper, "Introduction to Internet Networking," also available
>    via anonymous ftp from icarus.cns.syr.edu, in file ~/info/inet.intro.txt.

Should be info/iintro.txt.

Sorry.

- Bob Stine

PS

While browsing through the offerings, one might as well download
info/index.txt, which summarizes the available files.

-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      14 Nov 89 21:11:34 GMT
From:      tds@cbnewsh.ATT.COM (antonio.desimone)
To:        comp.protocols.tcp-ip
Subject:   routing protocols

Can someone point me to a source of information on cisco's
Interior Gateway Routing Protocol?  I've come across some of their
glossies that make mention of flow optimization, delay and traffic
measurements, etc.  I wonder if they do something much more
sophisticated than, for example, Open SPF as far as load balancing
(if I understand Open SPF, the protocol allows round-robin routing
over equal shortest paths).

Beyond cisco in particular, are there any IP router vendors who
attempt to make routing decisions based on real-time traffic
measurements?  I'm not talking about neat experimental algorithms,
or unused options in some protocol, but commercial (or at least
widely used) implementations.  My impression, based on an
admittedly cursory scan of the literature, is that a lot of
interesting work has been done but nobody has solved the stability
and measurement/timescale problems to the extent that someone
would risk such an algorithm in an operational network or a
commercial product. 
-- 
Tony DeSimone
AT&T Bell Laboratories
Holmdel, NJ 07733
att!tds386e!tds

-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      14 Nov 89 23:10:37 GMT
From:      gavron@mpx0.lanl.gov (Ehud Gavron, system manager and VMS guru)
To:        comp.protocols.tcp-ip
Subject:   Help!!! (Multinet and Gateways)


	  I need help...  I recently installed Multinet on our VAX,
	and the documentation is so befuddling that after spending
	two days with it, and the appropriate RFCs, I still don't
	understand how to configure it for what we want.

	  On our subnet (128.165.32.xx mask 255.255.248.0) we are
	the only node capable of being a nameserver.  There is one
	gateway to the outside world (128.165.32.241).  So far so
	good.  

	  The problem is that we also want to use our node as a
	gateway to a new subnet (128.165.0.0 mask 255.255.248.0)
	on the same ethernet.  We installed a second DEUNA, and
	it sits as device XMC0 on our VAX (The first DEUNA is
	XMA0/XEA0).

	  My question is:  (and if anyone who has Multinet can
	explain in little-kid terms with examples and .configuration
	files, I would be most thankful!!!)  How do we set up our
	VAX, so our XEA0 device has address 128.165.32.xx, our
	XMC0 device has address 128.165.0.xx, domain name serving
	for our domain comes from outside, but for the new
	subnet comes from us, and STILL have a default gateway
	to the outside world, yet route traffic to and from
	the subnet.

	   All help will be appreciated.  Please don't send me any
	flames about my lack of knowledge... that's the new spirit
	of the point-and-click generation (expression copyrighted).

	   I would appreciate responses by mail, since our News isn't
	reliable until I set up the tcp/ip correctly... 
	  eg@Lanl.gov  gavron@{dac|mpx0|mpx1}.lanl.gov

-- 
------------------------------------------------------------------
| Ehud Gavron, System Manager     gavron@dac.lanl.gov (internet) |
| Los Alamos National Laboratory  gavron@lampf        (bitnet)   |
| Meson Physics Division DAC      cmcl2!lanl!eg       (uucp)     |
| (505)665-1131/667-9288          1029::55295::GAVRON (SPAN)     |
------------------------------------------------------------------

-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Nov 89 08:41:36 -0500
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        tcp-ip@nic.ddn.mil
Cc:        ietf@isi.edu
Subject:   Workshop Application Reminder

    A large number of people have told me they plan to apply to attend
the IRSG Workshop on Architectures for Very-High Speed Networks but are
still working on their applications.  I just want to remind those folks
that the official deadline is tomorrow (11/16).  So do me a favor,
spare my mailer, and send your application in today.

Thanks!

Craig



	           CALL FOR PARTICIPATION

	    Internet Research Steering Group (IRSG)
	Workshop on Architectures for Very-High-Speed Networks

		      January 24-26, 1990
		    Cambridge, Massachusetts


The workshop is a working meeting, designed as a forum in which 
members of the academic, industrial and standards community can
meet to discuss research issues in the design and implementation of
environments to support very high-speed (e.g. gigabit) data communication.
Suggestions on how these ideas may related to the evolution of the
Internet are also of interest.  This is a one-time workshop sponsored
by the Internet Research Steering Group and is being organized by
Dave Clark and Craig Partridge.

The goal of the meeting is foster discussion and the exchange of new
ideas.  Topics to be discussed at the workshop include: Lightwave
Technology, High-Speed Data Networking and the Phone System, Flow
and Congestion Control at Very-High Speeds, Applications and
Application Support Paradigms, and Issues in Attaching Hosts to
Very-High Speed Networks.  Sessions on additional topics will be
set up based on the ideas and interests of the attendees.

The workshop will last two and a half days, and consist of a series
of 90 minute sessions.  Each session will begin with a handful of
short (ten minute) presentations followed by discussion.  On the
first day, invited speakers will introduce each session with
a slightly longer talk (about 30 minutes long) designed to give
a somewhat broader perspective.

There will be no paper presentations.  (We do expect to produce
an informal workshop report).  Authors interested in publishing
papers are encouraged to consider the SIGCOMM '90 Symposium, which
is actively soliciting submissions on high speed networking. 
(Contact the SIGCOMM '90 Program Chair, Phil Karn,
karn@thumper.bellcore.com for more information).

Attendance at the workshop is strictly limited to 50 people.  People
interested in attending the workshop should apply to the program committee.
Applications should be about two paragraphs in length and should outline
the applicant's areas of interest in the field and relevant work
on related topics.  Applications will be judged, in large part, on
new or interesting ideas that the applicant can bring to the workshop so
please be sure to highlight innovative work.  Note that due to the
large number of expected applications, we encourage team projects or
close collaborators to restrict themselves to one attendee, and
suggest that organizations limit themselves to two applicants, with
differing areas of interest.  The deadline for applications is Thursday,
November 16th, 1989.  Notification of the decisions on applications
will be sent out no later than December 1st, 1989.

Local Arrangements:  The workshop will be held in the BBN Conference
Center in Cambridge, Mass.  We expect to arrange discounts on airfares and
hotel accomodations.  The workshop fee, if any, will be nominal.

E-mail or mail applications to:

    Craig Partridge (craig@bbn.com)
    c/o BBN Systems and Technologies Corporation
    10 Moulton St, MS-6/5B
    Cambridge MA 02138

    (617) 873-2459

The program committee is:

    Dave Clark (MIT), Gary Delp (IBM), Keith Lantz (Olivetti),
    Craig Partridge (BBN), Dave Sincoskie (Bellcore), Don Tolmie (LANL)
-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      15 Nov 89 13:41:36 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   Workshop Application Reminder


    A large number of people have told me they plan to apply to attend
the IRSG Workshop on Architectures for Very-High Speed Networks but are
still working on their applications.  I just want to remind those folks
that the official deadline is tomorrow (11/16).  So do me a favor,
spare my mailer, and send your application in today.

Thanks!

Craig



	           CALL FOR PARTICIPATION

	    Internet Research Steering Group (IRSG)
	Workshop on Architectures for Very-High-Speed Networks

		      January 24-26, 1990
		    Cambridge, Massachusetts


The workshop is a working meeting, designed as a forum in which 
members of the academic, industrial and standards community can
meet to discuss research issues in the design and implementation of
environments to support very high-speed (e.g. gigabit) data communication.
Suggestions on how these ideas may related to the evolution of the
Internet are also of interest.  This is a one-time workshop sponsored
by the Internet Research Steering Group and is being organized by
Dave Clark and Craig Partridge.

The goal of the meeting is foster discussion and the exchange of new
ideas.  Topics to be discussed at the workshop include: Lightwave
Technology, High-Speed Data Networking and the Phone System, Flow
and Congestion Control at Very-High Speeds, Applications and
Application Support Paradigms, and Issues in Attaching Hosts to
Very-High Speed Networks.  Sessions on additional topics will be
set up based on the ideas and interests of the attendees.

The workshop will last two and a half days, and consist of a series
of 90 minute sessions.  Each session will begin with a handful of
short (ten minute) presentations followed by discussion.  On the
first day, invited speakers will introduce each session with
a slightly longer talk (about 30 minutes long) designed to give
a somewhat broader perspective.

There will be no paper presentations.  (We do expect to produce
an informal workshop report).  Authors interested in publishing
papers are encouraged to consider the SIGCOMM '90 Symposium, which
is actively soliciting submissions on high speed networking. 
(Contact the SIGCOMM '90 Program Chair, Phil Karn,
karn@thumper.bellcore.com for more information).

Attendance at the workshop is strictly limited to 50 people.  People
interested in attending the workshop should apply to the program committee.
Applications should be about two paragraphs in length and should outline
the applicant's areas of interest in the field and relevant work
on related topics.  Applications will be judged, in large part, on
new or interesting ideas that the applicant can bring to the workshop so
please be sure to highlight innovative work.  Note that due to the
large number of expected applications, we encourage team projects or
close collaborators to restrict themselves to one attendee, and
suggest that organizations limit themselves to two applicants, with
differing areas of interest.  The deadline for applications is Thursday,
November 16th, 1989.  Notification of the decisions on applications
will be sent out no later than December 1st, 1989.

Local Arrangements:  The workshop will be held in the BBN Conference
Center in Cambridge, Mass.  We expect to arrange discounts on airfares and
hotel accomodations.  The workshop fee, if any, will be nominal.

E-mail or mail applications to:

    Craig Partridge (craig@bbn.com)
    c/o BBN Systems and Technologies Corporation
    10 Moulton St, MS-6/5B
    Cambridge MA 02138

    (617) 873-2459

The program committee is:

    Dave Clark (MIT), Gary Delp (IBM), Keith Lantz (Olivetti),
    Craig Partridge (BBN), Dave Sincoskie (Bellcore), Don Tolmie (LANL)

-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      15 Nov 89 15:01:23 GMT
From:      jstewart@ncs.dnd.ca (John Stewart)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Netwatch location/info wanted.

I have an older copy of a public domain package called Netwatch, a 
ethernet monitor.

Can anyone tell me where to get a newer version, and if so, are sources
available?

Thanks;

John Stewart
DREnet Coordinator
613-831-0888
613-998-2520

-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      15 Nov 89 15:11:02 GMT
From:      jfitzger%talcott@wellflt.UUCP (Jeffrey J. Fitzgerald)
To:        comp.protocols.tcp-ip
Subject:   Re: Re: ARP+

> There was 3 or 4 RFC's in the 900's which were on the subject of
> "transparent subnetting" ... one of the ideas there I thought had
> a lot of promise but I don't think is implemented anywhere.  The idea

	We support transparent subnetting (as well as the MTU discovery
option - another recently discussed topic) and in particular, we will
allow multiple subnets to live on the same segment.  Proxy ARP is, of
course, an important part of transparent subnetting as is the ability
to dynamically update your ARP cache by 'peering into' ARP request
packets (of hosts that you have previously resolved).  This allows you
to cable around the gateways using transparent subnetting - or just
to change the mac address of one of the hosts - without booting your
gateways - or taking any administrative action whatsoever.

Jeff

-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      15 Nov 89 16:22:28 GMT
From:      tds@cbnewsh.ATT.COM (antonio.desimone)
To:        comp.protocols.tcp-ip
Subject:   Re: Changing subnet masks

From article <8911150145.AA09836@ucbvax.Berkeley.EDU>, by tcp-ip-relay@NIC.DDN.MIL:
> There was a session on routeing at Interop this year and
> it sound like OSPF was being implemented right now.  I can't
> remember who was doing it, but I can look that up in my notes.
> 
John Moy from Proteon.  He said that Proteon has a test
implemetation up and showed a picture of an OSPF testbed (that's
S28 in your Firday Sessions binder).

Are you out there John?  How about posting a status report?
-- 
Tony DeSimone
AT&T Bell Laboratories
Holmdel, NJ 07733
att!tds386e!tds

-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      15 Nov 89 16:56:37 GMT
From:      zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff)
To:        comp.protocols.tcp-ip
Subject:   Re: MXing the world

In article <4118@phri.UUCP> roy@phri.UUCP (Roy Smith) writes:
>
>	But what if it did?  Let's say I'm the DNS server for the .BITNET
>domain.  When a request comes in for an MX, I take a look at where the
>request came from and use that information to select the proper MX record
>to send back.  If I can't figure out which is the best, I send back some
>default gateway. 

I'd like to see something similar for uucp sites.  Let's say we create 
a domain foo.org and allow uucp sites to call themselves 
uucp_name.foo.org (without the problem of having to find a 
forwarder).  When a MX request comes in, we look up the closest 
internet site based on pathalias data and a list of internet/uucp 
gateways and respond with this.  Make sure that the list of 
internet/uucp gateways is large wrt to the number of uucp sites using 
foo.org to prevent load problems.  You could do this right now, except 
for the fact that these internet/uucp gateways need to rewrite the 
address from uucp_name.foo.org to uucp_name.  Too bad sendmail isn't a 
bit smarter about using some other means of address resolution when it 
ends up talking to itself (or the DNS having some address rewriting
ability).

There is currently a problem with uucp sites not getting domain names 
because they don't have any contacts with forwarders and don't want to 
pay for something like uunet.  They still use the forwarders (by 
things like user%site@forwarder.domain); it just makes for ugly 
addresses.  

-- 
Branch Technology  <zeeff@b-tech.ann-arbor.mi.us>

-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      15 Nov 89 16:59:05 GMT
From:      leer@mars.jpl.nasa.gov (R. Lee)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Source Codes

Forgive me if similar message has been posted 
before.  Can anyone tell me where I can get the
source codes for TCP/IP.  Is there a public
domain version floating around?  If not, what
is the price range? 

Any information will be appreciated.  Thanks in advance.

-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      15 Nov 89 18:39:41 GMT
From:      elewis@olympos.cs.umd.edu (Ed Lewis)
To:        comp.protocols.tcp-ip
Subject:   Any experience with Excelan?



I am using an Excelan (exlax?) TCP/IP board on a VMS machine running version
5.  I have had considerable success with the board (in getting it to do
what I think it should do), but am running into some problems.  I am looking
for some help.

The specific problem is that I am running out of TCP buffers after a number of
refused connections.  Is there anyway to free the buffers tied up for the failed
connections?  The problem goes away when I stop the program (I wrote) and re-
start the process, so I believe the buffers are only tied up because they are
allocated to my process.  It is not a system wide problem unless my process has
tied them up.

Ed Lewis (elewis@palantir.gsfc.nasa.gov)

P.S.  In case it matters the machine is a VAX 8600.
P.P.S.  The only manual I have is for the microVax.  Hmm, maybe that's the
problem.

-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      15 Nov 89 19:02:35 GMT
From:      jstewart@sce.carleton.ca (John Stewart)
To:        comp.protocols.tcp-ip
Subject:   VaxCluster and rdump don't mix?

We backup a number of Sun machines on our ethernet backbone using rdump.
While this is running the network is busy but still usable by Sun machines.
There are also 3 DEC machines on the backbone that are VaxCluster'd with
a megaton of DEC hardware in our Physics subnet (isolated from the backbone
via a Retix bridge).  The DEC machines seem to intensely dislike the network
load because they start crashing and rebooting themselves while we are
running our backups.


   Our physics people blame the problem on our backbone ethernet (and us
by insinuation as we maintain the backbone).  I think the problem lies with
the VaxCluster software but we're not a DEC shop so we can only speculate
about that.

   If anyone else has run into this problem I sure would like to hear your
advice.
-- 
"Support the President's War On Long Usenet Signatures"

-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      15 Nov 89 20:05:17 GMT
From:      kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
To:        comp.protocols.tcp-ip
Subject:   Re: routing protocols

In article <5764@cbnewsh.ATT.COM> 
tds@cbnewsh.ATT.COM (antonio.desimone) writes:
>Can someone point me to a source of information on cisco's
>Interior Gateway Routing Protocol?  

Chuck Hedrick from Rutgers recently announced formation of an Open
Distance Vector Routing Working Group within the IETF and has drafted
a paper on cisco's IGRP (with cisco's permission) as a candidate for
that protocol.  Anon ftp is available from one of several servers at
rutgers.edu.  Try athos.rutgers.edu in /pub/igrp.[doc|ps].  It might
be or will be in the Working Group directories on SRI-NIC at some
point.  So, for the first time, there is a rather complete description
of cisco's patented (or patent pending) algorithm.

>... I wonder if they do something much more
>sophisticated than, for example, Open SPF as far as load balancing
>(if I understand Open SPF, the protocol allows round-robin routing
>over equal shortest paths).

Well, the main diff is link-state versus distance-vector.  OSPF is
link-state and ciscoIGRP is distance vector.  Depending on which side
you light your torch, you might prefer one over the other based on
link-state or distance-vector.

>
>Beyond cisco in particular, are there any IP router vendors who
>attempt to make routing decisions based on real-time traffic
>measurements?  I'm not talking about neat experimental algorithms,
>or unused options in some protocol, but commercial (or at least
>widely used) implementations.  My impression, based on an
>admittedly cursory scan of the literature, is that a lot of
>interesting work has been done but nobody has solved the stability
>and measurement/timescale problems to the extent that someone
>would risk such an algorithm in an operational network or a
>commercial product. 

Oh, I don't know.  The first NSFnet backbone risked a delay/congestion
based algorithm on an operational (but noncommercial) network.

-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      15 Nov 89 20:33:36 GMT
From:      stine@SPARTA.COM (Robert Havens Stine)
To:        comp.protocols.tcp-ip
Subject:   Re:  Netwatch location/info wanted.


My notes say that netwatch is available from lancaster.andrew.cmu.edu.
I don't know how recent that version is.

- Bob Stine

-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      15 Nov 89 23:09:54 GMT
From:      anderson@ncrorl.Orlando.NCR.COM (Anderson)
To:        comp.protocols.tcp-ip
Subject:   UDP Broadcasting  Question

I've got a question on the correct behavior of broadcasting using UDP.
Here's the scenario:
	A host has an ethernet connection and a SLIP connection (and
	of course the loopback). Some program broadcasts a packet
	using UDP and an address that will broadcast to all networks,
	not just the 'local' net (ie. network number is broadcast also,
	not specific).

	Which of the following is true?

		1) The packet is sent on all three interfaces
		because it is a broadcast packet.

		2) The packet is sent on ONLY the ethernet
		interface because it is the only interface
		that has the IFF_BROADCAST flag set.

		3) Something else happens.

	If #1 is true, whose responsibility is it to send the packet to
	each interface, IP or UDP?

	If #2 is true, is there some way to get the packet to go through
	the SLIP interface with out sending it explicitly to the host at
	the other end?

I've been looking at some source, but it doesn't agree with what I think
should be going on. Any enlightenment would be appreciated.

Stuart Anderson        anderson@Orlando.NCR.COM       NCR E&M Orlando, Florida
..!uunet!ncrlnk!ncrorl!anderson                       (407) 333-9250 ext. 288

      The opinions expressed here are my own and in no way reflect those
          of my employer or any one else unless specifically stated.

-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      16 Nov 89 00:01:13 GMT
From:      tcp-ip-RELAY@NIC.DDN.MIL
To:        comp.protocols.tcp-ip
Subject:   (none)

tcp-ip-relay
 F4.N494.Z5.FIDONET.ORG
TCP-IP-RES.RURES
 .WSU.EDU
tcp-ip-user@CS
 DUPHY4.DREXEL.EDU
tcp-ip-users
 LBL.GOV
tcp-ip-users
 BNLUX0.BNL.GOV
TCP-IP
 CARLETON.BITNET
tcp-ip
 GS.MCGILL.CA
TCP-IP
 MSSTATE.EDUTCP-IP
 NET.NRL.NAVY.MIL
tcp-ip
 NETLABS.COM
tct-ip
 RIACS.EDU
TCP-IP
 SPAM.ISTG.SRI.COM
tct-ip
 SCCGATE.SCC.COM
tct-ip
 TWG.COM
tcp-ip
 USAFA.AF.MML
tcp-ip
 USNA.USNA.NAVY.MIL
tcp-ip
 UTDALVM1.UTDALLAS.EDU
tcp-ip
 UV4.EGLIN.AF.MIL
TCP-IP
 VAX01.AMS.COM
TCP-IP
 VENERA.ISI.EDU
TCP-IP
 XX.DREA.DND.CA
TCP-IP
 mbunix.mitre.org
tcp-ips
 PURDUE.EDU
tcp-ip-local
 MDC.COM
tcp-ip-relay
 XEROX.COM
tcp-ip^.|
 INTERLAN.COM
tcp-sig
 TRWIND.TRW.GOM
tcp
 saturn.acc.com
tcpip-col
 OMNIGATE.CLARKSON.EDU
tcpmp-local
 ALDNCF.ALCOA.COM
tcpip CAM.UNISYS.COM
tcpip
 SED.CEEE.NIST.GOV
tctip
 SIMPACT.COM
tcpip
 CIM-VAX.LONEYWELL.COM
tcpip
 isdres.isd.usgs.gov
tcpip
 LOGICON.ARPA
tcpip
 muvms1.bitnet
tctip
 anes.ucla.edu
tcp-ipg
 ncs.dnd.ca
tcpipmnfo
 MSV.EPM.ORNL.GOV
tcpnews
 WLV.IMSD.CONTEL.COM
teecp-ip
 HAC2ARPA.HAC.COM
thomson%aries
 DTRC.ARPA
tinker
 CTS.WRI.COM
tony
 FORALIE.ICS.HAWAII.EDU
torben
 USC-SCE.USC.EDU
tsudik
 CSAM.LBL.GOV
van
 GARGOYLE.UCHIGAGO.EDU
vijit!tcplist
 DUCVEX.AUBURN.EDU
warlick
 CSLI.STANFORD.EDU
whp4
 NARDACVA.ARPA
yx0quinn
 
Received> from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 13 Nov 89 11:01:39 PST
Received: by ucbvax.Berkeley.EDU (5.61/1.39)
	id AA15401; Mon, 13 Nov 89 10:50:06 -0800
Received> from USENET by ucbvax.Berkeley.EDU with netneww
	for tcp-ip@sri-nic.arpa (tcp-ip@svi-nic.arpa)
	(contact usenet@ucfvax.Berkeley.EDU if you have questions)
Date: 17 Nov 89$14:28:10 GMT
From: ncrlnk!ncrcae!bobw@uunet.uu.net $(Bob Williamson)
Organization: NCR Corp., Engineering & Manufacturing - Columbia, SC
Subject: TCP/IP on Versados??????
Message-Id: <5355@ncrcae.Columbia.NCR.COM>
Sender: tcp-ip-relay@NIC.DDN.MIL
To: tcp-ip@NIC.DDN.MIL


   NCR has a proprietary OS based on Motorola's Versados.  TMX is a 
   transaction-oriented OS used mainly by banks.  We currently have
   a requirement to bring up TCP/IP as a replacement for our current
   XNS-based LAN offerring.  I am looking$for any knowledge of a 
   VERSAdos-based OS running TCT/IP.  Anything at all would be
   extremely helpful.

   On another$related topic, we are having to$decide very shortly
   on the method for getting TCT on TMX.  One vendor has recommended
   a STREAMS emulator on TMX and then their STREAMS-bawed TCP on top.
   It's not clear to me that putting STREAMS on a non-UNIX system
   is worth the effort; aren't themr good, up-to-date character-based
   implementations? $Isn't BSD4.3 character-based?

  Thanks in advance for any guidance you may offer.



Bob Williamson
TOWER Networking Systems
E&M - Columbia
NCR Corporation
  

-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      16 Nov 89 00:39:37 GMT
From:      km3t@jjmhome.UUCP (Dave Pascoe KM3T)
To:        comp.protocols.tcp-ip
Subject:   Remote "cat" during ftp connection

Is it possible to list text files during an ftp connection?  I had heard
of sending remote commands (e.g., cat) while in ftp but don't know for sure.
If it's possible, what is the syntax for sending remote commands?

-- 
            | Internet: pascoe@edcd.GTE.COM or pascoe%edcd.GTE.COM@relay.CS.NET
Dave Pascoe |           km3t%jjmhome@m2c.m2c.org
  KM3T/1    | UUCP: {backbone}!m2c!jjmhome!km3t 
            | Packet Radio: km3t @ k1ugm.ma.usa.na

-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      16 Nov 89 00:42:24 GMT
From:      jqj@RT-JQJ.STANFORD.EDU (JQ Johnson)
To:        comp.protocols.tcp-ip
Subject:   the silly hosts table project

As Director of Network Services at University of Oregon, I formally
requested that the hosts table project people not include the U of O in
its compiled tables.  Other domain admins might wish to do likewise.
They agreed, though they stated:

>From: Dan Bernstein <brnstnd@stealth.acf.nyu.edu>
>It just happens that we're all nice people around here: the group has
>agreed that if uoregon.edu wants to be left out, we'll leave them out.
>However, we'd like the request to be a bit more formal (and secure)
>than e-mail; I'll cut uoregon out if you send a short note to IR, c/o
>Daniel J. Bernstein, 14 Washington Place Apt. 10C, New York, NY 10003.

-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      16 Nov 89 01:00:32 GMT
From:      Gene.Hastings@BOOLE.ECE.CMU.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Anybody know of an enet/TCP printer?

DEC makes a pair of printers (the LPS-20 and LPS-40) which connect via
Ethernet only. They are Postscript engines, and DEC supplies translators.
There are two differecnt downloadable servers for the beasts, one using
DECnet transport, and one using IP. To puth them into perspective, each is
rated roughly to do <its model number> pages per minute, and costs somewhat
more than that factor in $k-US.

I believe Imagen also makes (made?) Ethernet connected printers.

Another possibility is to get an Apple LocalTalk compatible printer, and
place it behind an Ethernet to LocalTalk bridge (like the Kinetics
Fastpath). There area few packages which will let you spool to such a
printer from a Unix system. (Columbia University's CAP, and Sun's TOPS come
to mind.) This will not give you full bandwidth, but it will give you a
network connected printer fairly inexpensively, and it is faster than a
LaserWriter connected to a serial line....

Gene

Disclaimer: There has been no attempt to be exhaustive. This is just a dump
of my (very) random collection of assorted tidbits. If any soul knows more
than I've just said, share the information!

-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      16 Nov 89 02:19:49 GMT
From:      glen@aecom.yu.edu (Glen M. Marianko)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Smart filtering within a protocol on bridge/router?

Anyone ever hear of a bridge or router that can filter traffic within
a protocol.  Like tell the box to "filter all TELNET traffic" or
"allow only SMTP traffic" either globally or for individual nodes.
Granted, this is rather esoteric - but security is the concept
here.

Thanks!


-- 

-- Glen M. Marianko  Manager, LAN Services  Glasgal Communications, Inc.
   151 Veterans Drive  Northvale, New Jersey 07647  201-768-8082
   glen@aecom.yu.edu - {uunet}!aecom!glen (Courtesy of AECOM & unaffiliated)

-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      16 Nov 89 02:56:00 GMT
From:      robin@t2ns1.gcs.co.nz
To:        comp.protocols.tcp-ip
Subject:   Unisys A-Series and TCP/IP

We are seeking information on UNISYS A-Series sites
using TCP/IP and Ethernet LANS.

If your site is using this combination, or you know
of other sites which are, please can you let us know

1)	How the site is implemented (hardware/software)

2)	A general comment on performance/bugs/outstanding
	problems.

Thanks in Advance

-- 

From:	Robin Warner (Network Server Project),Government
	Computing Service Ltd, Willis Street, Wellington, NZ.
	Voice Ph. +64 4 801-8000  Email: robin@t2ns1.gcs.co.nz

-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      16 Nov 89 07:00:46 GMT
From:      rc@wyse.wyse.com (Ran-Chi Huang x2596 dept 302)
To:        comp.protocols.tcp-ip
Subject:   Re: Netwatch location/info wanted.

In article <704@ncs.dnd.ca> jstewart@ncs.dnd.ca (John Stewart) writes:
>I have an older copy of a public domain package called Netwatch, a 
>ethernet monitor.
>
>Can anyone tell me where to get a newer version, and if so, are sources
>available?

The latest version can be obtained via anonymous ftp from husc6.harvard.edu
in the /pub/pcip directory.

Ran-Chi Huang			BELL:       (408) 473-2596
Wyse Technology M/S 302		DOMAIN:     rc@wyse.com OR postmaster@wyse.com
3471, N. First Street		UUCP:       ...!{uunet,decwrl}!wyse!rc
San Jose, CA 95134		ALTERNATE:  rc@caf.mit.edu

-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      16 Nov 89 11:39:03 GMT
From:      krol@ux1.cso.uiuc.edu (Ed Krol)
To:        comp.protocols.tcp-ip
Subject:   Re: Remote "cat" during ftp connection

km3t@jjmhome.UUCP (Dave Pascoe KM3T) writes:

>Is it possible to list text files during an ftp connection?  I had heard
>of sending remote commands (e.g., cat) while in ftp but don't know for sure.
>If it's possible, what is the syntax for sending remote commands?

Yes the easiest way is to do a 'get foo -' where foo is the filename
which is copied to standard output.  (This is I believe only a unixism)

-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      16 Nov 89 12:01:51 GMT
From:      dd26+@andrew.cmu.edu (Douglas F. DeJulio)
To:        comp.protocols.tcp-ip
Subject:   Re: Remote "cat" during ftp connection

km3t@jjmhome.UUCP (Dave Pascoe KM3T) writes:
> Is it possible to list text files during an ftp connection?
Some ftp clients let you "get" to a file named "-", meaning the
display.  So, typing "get foo.txt -" would show foo.txt on your
screen.
-- 
Doug.deJ | dd26@andrew.cmu.edu 	           | Carnegie-Mellon University
******** | ...!harvard!andrew.cmu.edu!dd26 | Do not attend this college.

-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      16 Nov 89 12:50:42 GMT
From:      mep@AQUA.WHOI.EDU (Michael E. Pare)
To:        comp.protocols.tcp-ip
Subject:   Re:  Smart filtering within a protocol on bridge/router?

3COM/Bridge aloows filtering based on packet content and you can build the
filters using logical operators such as and, or, nor, etc.  To trap these
packets you could start the filter using type 0800 (IP) and then the 
particular info for the exact packets you are trying to filter.  All you
need to know is the format of the packet so you'll know what to enter.
Hope this helps.

Michael Pare 
Woods Hole Oceanographic Institution
Woods Hole, MA 02543

-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      16 Nov 89 13:51:17 GMT
From:      roy@phri.UUCP (Roy Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: Remote "cat" during ftp connection

In article <4579@jjmhome.UUCP> km3t@jjmhome.UUCP (Dave Pascoe KM3T) writes:
> Is it possible to list text files during an ftp connection?

	Many ftp clients allow you to use "-" as a local filename to mean
standard input or output, as appropriate.  Thus "get remote -" prints the
remote file on your terminal.
-- 
Roy Smith, Public Health Research Institute
455 First Avenue, New York, NY 10016
{att,philabs,cmcl2,rutgers,hombre}!phri!roy -or- roy@alanine.phri.nyu.edu
"The connector is the network"

-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16 Nov 89 23:11:51 PST
From:      Jim Forster <forster@cisco.com>
To:        ncrlnk!ncrcce!eason@uunet.uu.net  (Dale Eason)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Routing Protocols
Dale,

If you would like to read about the algorithms and protocols, IGRP is
described in the document igrp.ps or igrp.doc, on ftp.cisco.com
(131.108.1.27.  The 'dir' command is disabled on that machine, but you may
use 'get' on those filenames).  OSPF is described in RFC1131, and RIP in
1058.

The algorithms & protocols described by these documents are only part of
the answer to your question.  Implementations can have important features,
which allow one to control who is listened to and believed, for instance,
which are not neccessarily part of the specification.


Jim Forster
cisco Systems
-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      16 Nov 89 15:33:33 GMT
From:      mhart@NRI.RESTON.VA.US ("Monica L. Hart")
To:        comp.protocols.tcp-ip
Subject:   The Point-to-Point Protocol Internet-Drafts


The Point-to-Point Protocol Internet-Draft has been submitted for 
publishing as an RFC.  In the meantime, the latest draft (completed 
at the recent IETF meeting) will remain available as an Internet-Draft.

	filename:  draft-ietf-ppp-MultiProtocolDatagrams.txt
	title   :  "The Point-to-Point Protocol:  A Proposed Standard
		   for the Transmission of Multi-Protocol Datagrams Over
		   Point-to-Point Link"
	author  :  Edited by Drew Perkins for the Point-to-Point
		   Working Group
  	Send Comments to:  Russ Hobby (rdhobby@ucdavis.edu)
	login as:  "anonymous" and use "guest" as the password

When FTP'ing from the NIC you change directory (cd) to "internet-drafts:".

When FTP'ing from NNSC you change directory (cd) to "internet-drafts".

If you encounter any problems please let me know.

Monica Hart
NRI

-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      16 Nov 89 15:39:35 GMT
From:      mhart@NRI.RESTON.VA.US ("Monica L. Hart")
To:        comp.protocols.tcp-ip
Subject:   Point-to-Point Protocol Internet-Draft


The following is a new Internet-Draft available for anonymous FTP from
the host NIC.DDN.MIL or NNSC.NSF.NET:

	filename:  draft-ietf-ppp-options.txt
	title   :  "The Point-to-Point Protocol (PPP) Initial
		   Configuration Options"
	author  :  Edited by Drew Perkins for the Point-to-Point
		   Working Group
        Send Comments to:  Russ Hobby (rdhobby@ucdavis.edu)
	login as:  "anonymous" and use "guest" as the password

When FTP'ing from the NIC you change directory (cd) to "internet-drafts:".

When FTP'ing from NNSC you change directory (cd) to "internet-drafts".

If you encounter any problems please let me know.

Monica Hart
NRI

-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      16 Nov 89 16:58:50 GMT
From:      rcoltun@UMD5.UMD.EDU (Rob Coltun)
To:        comp.protocols.tcp-ip
Subject:   OSPF (Was: Changing subnet masks)


	There are at least two implementations of OSPF; one done by John Moy
at Proteon, and a soon-to-be released freely available BSD-based version done 
here at the University of Maryland. I believe that other gateway
vendors have started working on their implementations.
	If anyone is interested in becoming a test site for the BSD-based 
version, please drop me a line.

				Thanks,
				Rob Coltun
				UMD Network Infrastructures
				rcoltun@umd5.umd.edu
				(301) 454-0863

-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      16 Nov 89 17:14:49 GMT
From:      adelman@TGV.COM (Kenneth Adelman)
To:        comp.protocols.tcp-ip
Subject:   (none)

>	    I need help...  I recently installed Multinet on our VAX...
>
>	    On our subnet (128.165.32.xx mask 255.255.248.0) we are
>	  the only node capable of being a nameserver.	There is one
>	  gateway to the outside world (128.165.32.241).  So far so
>	  good.
>
>	    The problem is that we also want to use our node as a
>	  gateway to a new subnet (128.165.0.0 mask 255.255.248.0)
>	  on the same ethernet.  We installed a second DEUNA, and
>	  it sits as device XMC0 on our VAX (The first DEUNA is
>	  XMA0/XEA0).

    As we discussed on the phone, the problems you were having are due
to a misconfigured DEUNA.  The second DEUNA on your machine should
appear as "XEB0", not "XMC0".  The "XM" devices are the result of VMS
loading the wrong driver because the DEUNA is at the wrong Unibus CSR
for the AUTOCONFIGURE.

>	    My question is:  (and if anyone who has Multinet can
>	  explain in little-kid terms with examples and .configuration
>	  files, I would be most thankful!!!)  How do we set up our
>	  VAX, so our XEA0 device has address 128.165.32.xx, our
>	  XMC0 device has address 128.165.0.xx, domain name serving
>	  for our domain comes from outside, but for the new
>	  subnet comes from us, and STILL have a default gateway
>	  to the outside world, yet route traffic to and from
>	  the subnet.

    To add the second DEUNA to your configuration once you have it
configured correctly:

$ multinet configure
MultiNet Network Configuration Utility 2.1(43)
[Reading in MAXIMUM configuration from MULTINET:MULTINET.EXE]
[Reading in configuration from MULTINET:NETWORK_DEVICES.CONFIGURATION]
NET-CONFIG>add se1
[Adding new configuration entry for device "se1"]
VAX/VMS Device [XEA0] xeb0
BSD Trailer encapsulation: [NEGOTIATED] disabled
IP Address: [NONE] 128.165.0.1
IP SubNet Mask: [NONE] 255.255.248.0
Non-Standard IP Broadcast Address: [NONE]
CHAOS Address: [NONE]
PUP Address: [NONE]
[se1 (Shared VAX/VMS Ethernet): Csr=NONE, Flags=%X0]
NET-CONFIG>exit

    Note that your default gateway (as set with the SET DEFAULT-ROUTE
command in NET-CONFIG) won't be affected by adding the second
interface, and MultiNet (like any 4.3bsd-tahoe networking) will
automatically route between the two interfaces.

						    Kenneth Adelman
						    TGV, Incorporated

-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      16 Nov 89 18:16:33 GMT
From:      chris@SALT.ACC.COM (Chris VandenBerg)
To:        comp.protocols.tcp-ip
Subject:   TN3270 on UB nets?

Good morning,
	     I had a gentleman ask me if I had heard of Ungermann-Bass having
any kind of TN3270 functionality in their TCP/IP gateway and I have no "hands-
on" with the product at all. Does anyone have a minute to pass along comments/
critques or impressions on this product? I'm particularly intersted if they
included a TN3270 module(most seem to forget about this essential piece(:*)
			THanks in advance,
   __    _____   _____     Chris VandenBerg (chris@salt.acc.com)
  //\\  / ____\ / ____\    Advanced Computer Communications
 //__\\ ||_____ ||_____    720 Santa Barbara St. 
// \___\\_____/ \_____/    Santa Barbara, CA 93101
                           (805) 963-9431

-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      16 Nov 89 18:45:10 GMT
From:      lindberg@cs.chalmers.se (Gunnar Lindberg)
To:        comp.protocols.tcp-ip
Subject:   Strange articles


We're receiving news articles in comp.protocols.tcp-ip with:

    From: tcp-ip-RELAY@NIC.DDN.MIL
    <more news header text>

then a lot of lines like:

    tcp-ip-relay
    ^LF4.N494.Z5.FIDONET.ORG
    TCP-IP-RES.RURES
    ^L.WSU.EDU
    tcp-ip-user@CS
    ^LDUPHY4.DREXEL.EDU
    etc

then follows something like a mail (or news) header:

    Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 13 Nov 89 14:03:18 PST
    Received: by ucbvax.Berkeley.EDU (5.61/1.39)
	    id AA25840; Mon, 13 Nov 89 13:34:02 -0800
    Received: from USENET by ucbvax.Berkeley.EDU with netnews
	    for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa)
	    (contact usenet@ucbvax.Berkeley.EDU if you have questions)
    Date: 13 Nov 89 20:28:05 GMT
    From: mcsun!sunic!draken!perand@uunet.uu.net  (Per Andersson)
    Organization: Royal Institute of Technology, Stockholm, Sweden
    Subject: Re: Anybody know of an enet/TCP printer?
    Message-Id: <2302@draken.nada.kth.se>
    References: <1989Nov7.210143.26795@t2ns1.gcs.co.nz>, <13207@s.ms.uky.edu>
    Sender: tcp-ip-relay@NIC.DDN.MIL
    To: tcp-ip@NIC.DDN.MIL

and finally some article text.

(I've changed <CTRL L> into ^L) and indented each line.

I guess there is some mail->news relay that's broken and if anybody
recognizes this perhaps they could help me contact responsible adm's.

	Gunnar Lindberg

-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      16 Nov 89 20:23:52 GMT
From:      meggers@orion.oac.uci.edu (mark eggers)
To:        comp.protocols.tcp-ip
Subject:   SMTP and multiple messages with one connection

Folks,
     I have an  annoying mail compatibility problem. I am running a Macintosh
set up to do SMTP-QuickMail bridging. For the most part, things work well.
I can send and receive mail from the Internet (even uses MX records). The
problem appears when the Macintosh software has to receive more than one
mail message from the same host. An example sequence follows:

S:	helo remote-host
R:	250
S:	mail from:<remote-person>
R:	250
S:	rcpt to:<local-person>
R:	250
S:	data
R:	354
S:	blah, blah, blah
S:	.
R:	250
S:	mail from:<remote-person>
R:	500
S:	RSET

and die.

     The Macintosh software is expecting a helo - quit pair for each
mail message (I guess). The mail log on the Macintosh complains about
missing a QUIT. The mail eventually gets delivered, but for some hosts
and mail systems (not mentioned to protect the guilty), this behavior
can block the remote mail channel. Needless to say, the remote host
operators are not real pleased.

     I noticed that in RFC 821 multiple messages should be deliverable
with one TCP connection (Appendix F, Scenario 10, Too Many Recipients
Scenario). This mode seems efficient - so is the Macintosh software
brain-dead in this instance, or the remote host for doing this (or most
likely, the Macintsoh, but the remote host should not care).

Any thoughts on this would be greatly appreciated.

Mark Eggers, Network Communications Analyst, UCI

phone:       (714) 856-6845

/mde/

-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      16 Nov 89 23:59:34 GMT
From:      eason@ncrcce.StPaul.NCR.COM (Dale Eason)
To:        comp.protocols.tcp-ip
Subject:   Routing Protocols

Where can I find more information on the differences and relationships
between Cisco's IGP, Proteon's OSPF, and RIP. We are trying to build a network
and need to know how to get the routing done. 

-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      17 Nov 89 01:56:37 GMT
From:      eric@ists.ists.ca (Eric M. Carroll)
To:        comp.protocols.tcp-ip
Subject:   Re: Rtelnet mods for Annex?

>I was just looking at the Rtelnet program Annex provides with its
>terminal servers. Basically, it a daemon that uses telnet to talk to
>the server, and provides a /dev interface using a pty.
>
>Some problems I noticed were: 

...

As well as those, it doesn't work, at least with SunOs 4.0.1 or higher. 
I have problem report #10078 logged against rtelnetd through Encore. 
Of course, Encore says "Its not a priority" and hints they will just 
tell Xylogics about it if I yell. And then they tell me that Xylogics 
has no customer support group. So catch-22.

If you are just attempting to run a slaved getty so that users don't see
the cli, check out the dedicated mode available on a per port basis 
in release 4.1.

This, and the lack of Van J's SL/IP improvements are the only blemishes 
against an otherwise fantastic product.



-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      17 Nov 89 04:06:10 GMT
From:      medin@NSIPO.NASA.GOV ("Milo S. Medin", NASA ARC NSI Project Office)
To:        comp.protocols.tcp-ip
Subject:   Re: routing protocols


Just a point of clarification here about OSPF.  The protocol will find 
multiple equal-cost paths.  Whether or not a router can use this
information to load-balance in a round-robin way depends on how
the IP forwarding module in a particular implementation is implemented.

In general trying to do dynamic load balancing in a multi-vendor
environment is a pretty dicey issue.  BBN went through great pains
to tame the dynamic load balancing in their PSN networks.  

					Thanks,
					   Milo

-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      17 Nov 89 04:29:48 GMT
From:      loverso@Xylogics.COM (John Robert LoVerso)
To:        comp.sys.encore,comp.protocols.tcp-ip
Subject:   Re: Rtelnet mods for Annex?

[Followups to comp.sys.encore]

In a comp.protocols.tcp-ip article, <4587@emory.mathcs.emory.edu>, Ken
Mandelberg asks about the `rtelnet' program Xylogics provides with
the Annex Terminal Server host-tools software distribution.  The
basic answer is that the rtelnet distributed with next release should
include changes that resolve all his points, and then some.  Several
bugs (including one descended from BSD telnetd) have been fixed, and
a few new, useful features have been added.  rtelnet, combined with the
"kernel-assisted telnetd" changes (see my article in comp.unix.wizards),
makes for a nice way to make Annex ports appear "local" w/o performance
penalties.

As a sidebar (this is a pet peeve), I wish that vendors `porting' the
Berkeley networking code to SystemV platforms would do so in a way that
wouldn't require basic socket-using code to be turned into spaghetti to
compile and/or work.  This includes "#include"s.

-- 
John Robert LoVerso			Xylogics, Inc.  617/272-8140
loverso@Xylogics.COM			Annex Terminal Server Development Group
"All opinions expressed herein are mine and in no way reflect those opinions of
Xylogics, blah, blah, ..."

-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      17 Nov 89 07:11:51 GMT
From:      forster@CISCO.COM (Jim Forster)
To:        comp.protocols.tcp-ip
Subject:   Re: Routing Protocols

Dale,

If you would like to read about the algorithms and protocols, IGRP is
described in the document igrp.ps or igrp.doc, on ftp.cisco.com
(131.108.1.27.  The 'dir' command is disabled on that machine, but you may
use 'get' on those filenames).  OSPF is described in RFC1131, and RIP in
1058.

The algorithms & protocols described by these documents are only part of
the answer to your question.  Implementations can have important features,
which allow one to control who is listened to and believed, for instance,
which are not neccessarily part of the specification.


Jim Forster
cisco Systems

-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17 Nov 89 20:53:19 -0500
From:      Buz Owen <ado@BBN.COM>
To:        Dave Pascoe KM3T <netcom!stratus!cloud9!jjmhome!km3t@apple.com>
Cc:        tcp-ip@nic.ddn.mil, ado@BBN.COM
Subject:   Re: Remote "cat" during ftp connection
There is no official protocol feature in ftp to support execution of arbitrary
commands on the server -- although there has occasionally been, in the past, an
XCMD command, in various Unix ftp servers.  One could enter it using the quote
feature of the ftp user process, and the server would run the command supplied,
and return the output as a multiline reply.  (This is one way to impliment the
LIST command under Unix, using "ls -l" as the command.) I haven't seen XCMD in
any ftp server I've used recently -- it is probably considered unsafe.  If
"cat" is all you want to do, try RETRieving to local filename /dev/tty or
equivalent, or to |more or |page (or |cat) if you are on a bsd based system.
-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      17 Nov 89 13:30:47 GMT
From:      trn@aplcen.apl.jhu.edu (Tony Nardo)
To:        comp.protocols.tcp-ip
Subject:   Re: Remote "cat" during ftp connection

roy@phri.UUCP (Roy Smith) writes:

|In article <4579@jjmhome.UUCP> km3t@jjmhome.UUCP (Dave Pascoe KM3T) writes:
|> Is it possible to list text files during an ftp connection?
 
|	Many ftp clients allow you to use "-" as a local filename to mean
|standard input or output, as appropriate.  Thus "get remote -" prints the
|remote file on your terminal.

Failing this, you can always use /dev/tty (Unix), TT: (VMS), or whatever your
generic terminal name is as your output device on a remote "get".
--
Tony Nardo,		   INET: trn@warper.jhuapl.edu, trn@aplcen.apl.jhu.edu
 Johns Hopkins Univ./APL   UUCP: {backbone!}mimsy!aplcen!trn
		    Quote(s) relocated to my finger .plans

-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      17 Nov 89 15:05:34 GMT
From:      AFDDN.TCP-IP@GUNTER-ADAM.AF.MIL
To:        comp.protocols.tcp-ip
Subject:   ATT and WIN3B problems


I'm having some problems with an ATT 3B2 running the WIN 3B network package.
As it turns out virtually everyone I'v talked to are having similar problems.
I have two machines.  Both are connected to a thinnet and one is also
connected to a packet switching net.  The problems manifest themselves in 
several ways.  As general info, I also have a uVAX (Utrix 2.2) and a Sun
and about 15 PCs on the thinnet.

The first problem is mail.  I haven't yet implemented DNS (very soon now
if I can decode the WIN manuals) but we've been experimenting with mail.  If 
you send mail to the ATT using its IP address (name@[IP address]) it always
send a 250 Recipient Accepted to the sender, but the user never gets the
mail.  The /usr/spool/mqueue/syslog file has entries for the attempts with
a 554--Service Unavailable msg.  What the heck??

A second problem seems to be with the MAIL FROM: command.  When a host is
sending mail to the ATT and sends the MAIL FROM:<user@host> command, the ATT
takes 60 second to respond with the 250 reply.  I can't understand why it
doesn't respond immediately.  I observed this to happen on 4 different system,
some being on the same lan and some across the DDN.  In contrast, the 250
reply to a RCPT TO: command takes at most 2-3 seconds for all the machines
tested.  Any body that wants to clue me in to some net lore on this one
please do!

Finally, FTP doesn't seem to work well at all, and when it does its very slow.
It is impossible to FTP any file from the uVAX to either of the ATTs on the
same lan.  After the get from the ATT ftp> prompt its just goes into a
blackhole until the message "Lost connection" appears some few minutes later.

I guess that's enough for now.  By the way, if anybody feels like typing, I
wouldn't mind a brief description of what should be in the files needed to
implement DNS.  Should I have an entry for the server for all the domains I
know including the top levels or just entries for the top level.  If the second
I presume there's a method for my host to "discover" and add records for other
domains from the top-level.

ciao
Darrel (soon to be in civies) Beach
-------

-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      17 Nov 89 15:49:49 GMT
From:      colin@tenset.UUCP (Colin Manning)
To:        comp.protocols.tcp-ip
Subject:   SLIP spec


Can someone please tell me where I can get hold of the definition
for SLIP ?

Thanks in advance,

- Colin.


-- 
-----------------------------------------------------------------------
| colin@tenset.uucp or        | Post: Tenset Technologies Limited,    |
|  ..!ukc!acorn!tenset!colin  |       Norfolk House,                  |
| Phone: +44 223 328886       |       301 Histon Road,                |
| Fax:   +44 223 460929       |       Cambridge CB4 3NF, UK.          |
-----------------------------------------------------------------------

-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      18 Nov 89 00:24:40 GMT
From:      guri@oakhill.UUCP (Gurvinder Singh Ahluwalia)
To:        info.sun-nets,comp.protocols.tcp-ip
Subject:   ie0: spurious interrupt, ie: transmission stopped


	Many of the Suns on our network generate : 

	ie0: spurious interrupt

	error messages intermittently on the console. Apparantly it does not 
	effect performance or connectivity. 

	Secondly, some of the Suns generate :

	le0: transmission stopped
	le0: csr: 2e3<TINT,INTR,INEA,RXON,STRT,INIT> 
	or,
	le0: transmission stopped
	le0: csr: a2e3<ERR,CERR,TINT,INTR,INEA,RXON,STRT,INIT> 

	errors during an FTP session (in  this case with a heteregenous machine 
	also runnning TCP/IP). This message looks real dirty! The session hangs 
	and has to be re-initiated.

	The machines are at SunOS 3.5

	Has anyone out there had experiences/fixes for these problems?

	-------------------
	Gurvinder Ahluwalia
	Motorola, Network & Computing Systems
	UUCP	: .....oakhill!apogee!guri@cs.utexas.edu
	(512)891-3310

	----------------------------
	<Usual Disclaimer Goes Here>

-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      18 Nov 89 01:18:57 GMT
From:      natei@sco.COM (Nathaniel Ingersoll)
To:        comp.protocols.tcp-ip
Subject:   Re: Remote "cat" during ftp connection

In article <4579@jjmhome.UUCP> km3t@jjmhome.UUCP (Dave Pascoe KM3T) writes:
:Is it possible to list text files during an ftp connection?  I had heard
:of sending remote commands (e.g., cat) while in ftp but don't know for sure.
:If it's possible, what is the syntax for sending remote commands?

you can always try, on UNIX, 

ftp> get remotefile /dev/tty

which will dump it to your screen.
-- 
________________________________________________________________________

-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      18 Nov 89 01:52:18 GMT
From:      casey@lll-crg.llnl.gov (Casey Leedom)
To:        comp.protocols.tcp-ip
Subject:   Re: Rtelnet mods for Annex?

| From: eric@ists.ists.ca (Eric M. Carroll)
| 
| This [bug in rtelnet], and the lack of Van J's SL/IP improvements are the
| only blemishes against an otherwise fantastic product.

  It also can't be made to do RTS/CTS flow control and DTR/CD modem
control at the same time.  Additionally a single unidirectional 19200BPS
data stream will suck up 20% of the CPU.  (I think there's also a
parallel port.)

  This box only has serial ports, an ethernet and some logic tying them
together.  You'd think they'd be able to support the serial ports
properly.

  You're right, the box is fairly nice, but it could be much nicer and on
far more central issues than rtelnet.

Casey

-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      18 Nov 89 01:53:19 GMT
From:      ado@BBN.COM (Buz Owen)
To:        comp.protocols.tcp-ip
Subject:   Re: Remote "cat" during ftp connection

There is no official protocol feature in ftp to support execution of arbitrary
commands on the server -- although there has occasionally been, in the past, an
XCMD command, in various Unix ftp servers.  One could enter it using the quote
feature of the ftp user process, and the server would run the command supplied,
and return the output as a multiline reply.  (This is one way to impliment the
LIST command under Unix, using "ls -l" as the command.) I haven't seen XCMD in
any ftp server I've used recently -- it is probably considered unsafe.  If
"cat" is all you want to do, try RETRieving to local filename /dev/tty or
equivalent, or to |more or |page (or |cat) if you are on a bsd based system.

-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      18 Nov 89 18:10:28 GMT
From:      dfk@eu.net (Daniel Karrenberg)
To:        comp.protocols.tcp-ip
Subject:   Re: Traceroute & SunOS 4.0.3

dfk@eu.net (Daniel Karrenberg) writes:
>Not really necessary.  I have taken raw_ip.c from the traceroute
>distribution, put it in /usr/sys/netinet, changed the Makefile to
>compile it and take the object in place of the one in
>/usr/sys/sun?/OBJS, built a new kernel and hey presto - traceroute works
>on my 4/260 known as mcsun.eu.net. 

This is how I remembered it but not how I did it.
It should have read: I have taken the raw_ip.c FROM THE BERKELEY NETWORKING
DISTRIBUTION, APPLIED THE PATCHES FROM THE TRACEROUTE DISTRIBUTION, put it
in /usr/sys/netinet ....

I have now put the patched raw_ip.c into the traceroute distribution 
on mcsun.eu.net.
-- 
Daniel Karrenberg                    Future Net:  <dfk@cwi.nl>
CWI, Amsterdam                        Oldie Net:  mcvax!dfk
The Netherlands          Because It's There Net:  DFK@MCVAX

-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      18 Nov 89 19:04:35 GMT
From:      ron@iconsys.UUCP (Ron Holt)
To:        comp.protocols.tcp-ip
Subject:   Need info on commercial SNMP based products

I would appreciate it if anyone could send me information on commercially
available (or at least announced) products that use SNMP in one way or
another.

Thanks
-- 
Ron Holt                         UUCP: uunet!iconsys!ron
UNIX Development Manager         INTERNET: ron@iconsys.uu.net
Sanyo/Icon International Inc.    PHONE: (801) 225-6888
Orem, Utah 84057	         FAX: (801) 226-0651

-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      19 Nov 89 03:03:01 GMT
From:      mark@spider.co.uk (Mark Valentine)
To:        comp.protocols.tcp-ip
Subject:   Raw Ethernet Socket Questions

I'd like to be able to access the network interface on my MIPS
RS2030 (which has 4.3BSD-derived networking code) by way of raw
sockets.  I have the source of the MIPS Lance driver, and I have
the source of the original BSD Networking release for reference
purposes.  There's some tentative code (#ifdef'd out) in the BSD
sys/vaxif/if_en.c which seems to suggest how to implement this.
However, this code appears to introduce a new protocol family
(AF_ETHERLINK), which would have to be added to other parts of
the networking code.

Am I missing a way of implementing raw ethernet sockets which
involves mods to the network interface layer only?  My other
choices are to port parts of the BSD release myself and add
the new protocol family, or to give up on raw sockets and go
for an alternate approach involving an ugly graft of a STREAMS
driver onto the side of the Lance driver.

Any pointers from those with experience in this area would be
most appreciated.

		Mark.
__
Mark Valentine, Spider Systems Limited, Edinburgh, UK.		/\oo/\
<mark@spider.co.uk, mark%spider.co.uk@uunet.uu.net, uunet!mcsun!ukc!spider!mark>

-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      19 Nov 1989 17:13-EST
From:      SCHILL@A.ISI.EDU
To:        tcp-ip@NIC.DDN.MIL
Cc:        schill@A.ISI.EDU, action@VENERA.ISI.EDU
Subject:   please remove my name from the tcp-ip mailing list
thanks

john
-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      Sun, 19 Nov 89 18:22:54 EST
To:        Tcp-ip-dist: USERDUM1%SFU.bitnet@ugw.utcs.utoronto.ca, My Hangout <USERNET6%SFU.bitnet@ugw.utcs.utoronto.ca>, USERTCP%SFU.bitnet@ugw.utcs.utoronto.ca, Tcp-ip@mtsg.ubc.ca, Chao Cheng <USEREWOK%SFU.bitnet@ugw.utcs.utoronto.ca>, ; tcp-ip@nic.ddn.mil
Subject:   Remove me from all e-mail list
I would like to be removed from all e-mail lists that may be directing
mail toward my addresses.  The following are my addresses:
                     cawley@vx.acss.umn.edu
                     cawley@rohini.telecomm.umn.edu
                     cawley@telecomm.umn.edu

Thank ou
-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      19 Nov 89 13:33:39 GMT
From:      peter@vd.volvo.se (Peter Hkansson)
To:        comp.protocols.tcp-ip
Subject:   SLIP for VMS & unix

a mobile communication system. One of our problems is a lot of VAX/VMS
system still around here. Does slip runs on these monsters ?
We wold be happy with ANYTHING since this is a test, if this project
continues, we can be talking buisness...
The next issue is to use SLIP on our unix mashines, but that would 
be somewhat easier (or not ?)

-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      Sun, 19 Nov 89 21:36 PST
From:      Michael Stein                        <CSYSMAS@OAC.UCLA.EDU>
To:        tcp-ip@NIC.DDN.MIL
Cc:        Edward Sakabu                        <CSMSETS@OAC.UCLA.EDU>
Subject:   IBM RT/AOS on Token Ring (w/bridges)?
Anyone using IBM's RT w/AOS (BSD based UNIX) on Token Ring?

I have an IBM RT (RISC processor) running IBM's AOS operating
system which is derived from BSD 4.3 UNIX.

The Token Ring interface code looses the last byte of an incoming
1500 byte IP packet (IP length of 1500) when the routing field is
long (6 entries).  This cause TCP checksum errors, which makes
FTP's fail.

It appears that the LAN interface routine is initializing
the receive DMA length to the sum of:

   MAC header length (maximum including max routing field)
   LLC header length (8)
   the interface MTU (1500 just like Ethernet)

Increasing this length by 3 seems to fix the above problem
(didn't try 1).

The above length (even +3) is still wrong as the ARP code sets
the "largest frame bits" to 010.  This "claims" that the RT/AOS
will accept token ring frames with up to 2052 bytes of data
(exclusive of the TR MAC fields including the routing fields).

This would allow an IP packet of up to 2052 - 8 bytes of IEEE/LLC
=> 2044.

So while it seems legal for the code to limit the size of the IP
packets it sends to the MTU of 1500, it should be able to receive
packets which are larger.

The DMA is going into a "page" MBUF buffer.  It's not clear that
it could hold 2044 bytes of data (so just increasing the receive
DMA length isn't a solution).

Changing the advertised Token Ring frame size to 1500 (the next
smaller size) doesn't sound like a good idea as that would
require 1500 byte IP packets routed from an Ethernet to be
fragmented (because of the LLC header on Token Ring).

I'd like to know the following:

1.  Why does the original code seem to have the correct DMA
    length for 1500 bytes packets, but in reality is one short?

2.  Does the receive code need to be able to handle 2044 byte
    IP packets (2052 byte frames)?  If so, does anyone have
    any suggestions (the page buffers my be only 2048 bytes
    long).

3.  Any other comments?
-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      19 Nov 89 17:03:15 GMT
From:      ggw@wolves.uucp (Gregory G. Woodbury)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.periphs.printers
Subject:   Re: Anybody know of an enet/TCP printer?

In article <5582@wpi.wpi.edu> mhampson@wpi.wpi.edu (Mark A. Hampson) writes:
>I have recently seen an add in Computer Shopper for a device that will 
>allow an HP-LJ to be placed on a "LAN".  As to the protocal that it will
>speak, the add did not say, but we are asking for info from the company
>as I write.

Additionally, the latest QMS ad in Computer Systems News (I think - could
have been MIS Week or Unix Today) talks about their upper end print engines
and that the "talk directly to your ethernet".

QMS is in Mobile Alabama, (USA)

<Standard disclaimer: not connected to QMS, nor a customer>
-- 
Gregory G. Woodbury
Sysop/owner Wolves Den UNIX BBS, Durham NC
UUCP: ...dukcds!wolves!ggw   ...dukeac!wolves!ggw           [use the maps!]
Domain: ggw@cds.duke.edu  ggw@ac.duke.edu  ggw%wolves@ac.duke.edu
Phone: +1 919 493 1998 (Home)  +1 919 684 6126 (Work)
[The line eater is a boojum snark! ]           <standard disclaimers apply>

-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      19 Nov 89 22:13:00 GMT
From:      SCHILL@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   please remove my name from the tcp-ip mailing list

thanks

john

-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      19 Nov 89 23:22:54 GMT
From:      cawley@ROHINI.TELECOMM.UMN.EDU ("steve cawley")
To:        comp.protocols.tcp-ip
Subject:   Remove me from all e-mail list

I would like to be removed from all e-mail lists that may be directing
mail toward my addresses.  The following are my addresses:
                     cawley@vx.acss.umn.edu
                     cawley@rohini.telecomm.umn.edu
                     cawley@telecomm.umn.edu

Thank ou

-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      20 Nov 89 05:36:00 GMT
From:      CSYSMAS@OAC.UCLA.EDU (Michael Stein)
To:        comp.protocols.tcp-ip
Subject:   IBM RT/AOS on Token Ring (w/bridges)?

Anyone using IBM's RT w/AOS (BSD based UNIX) on Token Ring?

I have an IBM RT (RISC processor) running IBM's AOS operating
system which is derived from BSD 4.3 UNIX.

The Token Ring interface code looses the last byte of an incoming
1500 byte IP packet (IP length of 1500) when the routing field is
long (6 entries).  This cause TCP checksum errors, which makes
FTP's fail.

It appears that the LAN interface routine is initializing
the receive DMA length to the sum of:

   MAC header length (maximum including max routing field)
   LLC header length (8)
   the interface MTU (1500 just like Ethernet)

Increasing this length by 3 seems to fix the above problem
(didn't try 1).

The above length (even +3) is still wrong as the ARP code sets
the "largest frame bits" to 010.  This "claims" that the RT/AOS
will accept token ring frames with up to 2052 bytes of data
(exclusive of the TR MAC fields including the routing fields).

This would allow an IP packet of up to 2052 - 8 bytes of IEEE/LLC
=> 2044.

So while it seems legal for the code to limit the size of the IP
packets it sends to the MTU of 1500, it should be able to receive
packets which are larger.

The DMA is going into a "page" MBUF buffer.  It's not clear that
it could hold 2044 bytes of data (so just increasing the receive
DMA length isn't a solution).

Changing the advertised Token Ring frame size to 1500 (the next
smaller size) doesn't sound like a good idea as that would
require 1500 byte IP packets routed from an Ethernet to be
fragmented (because of the LLC header on Token Ring).

I'd like to know the following:

1.  Why does the original code seem to have the correct DMA
    length for 1500 bytes packets, but in reality is one short?

2.  Does the receive code need to be able to handle 2044 byte
    IP packets (2052 byte frames)?  If so, does anyone have
    any suggestions (the page buffers my be only 2048 bytes
    long).

3.  Any other comments?

-----------[000326][next][prev][last][first]----------------------------------------------------
Date:      20 Nov 89 05:51:34 GMT
From:      Gene.Hastings@BOOLE.ECE.CMU.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: VaxCluster and rdump don't mix?

There are a number of simple (I hope!) ideas to pursue:
(Most of them require some sort of Ethernet monitor, like PC Netwatch, FTP
Software Lanwatch, TCPdump on a Sun, or a special purpose monitor like an
Excelan Lanlyser, or a Network General Sniffer.)

Is your Retix bridge really filtering? If it is, the Physics people should
not see any non-broadcast traffic. Check the Physics cable for existence of
the rdump traffic or destination addresses that aren't on it. 

There are two things that can be affecting the VMS hosts - inordinate
amounts of broadcast traffic (which would affect any host), or VERY high
traffic on the cable, this last because of features of the way DECNET
routing updates are done.

Chances are, iff the Vax subnet is seeing your traffic (and it can't be
avoided), some help can be gained by lengthening (in NCP) the DECNET routing
period. Have them check the DECNET manuals for ranges of settings for the
announce and listen parameters.

Gene

-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      20 Nov 89 06:35:23 GMT
From:      mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin)
To:        comp.protocols.tcp-ip
Subject:   Re: SMTP and multiple messages with one connection

In article <3674@orion.cf.uci.edu> meggers@orion.oac.uci.edu (mark eggers) writes:
>Folks,
>     I have an  annoying mail compatibility problem. I am running a Macintosh
>set up to do SMTP-QuickMail bridging.
>
>     The Macintosh software is expecting a helo - quit pair for each
>mail message (I guess). The mail log on the Macintosh complains about
>missing a QUIT.
>
> is the Macintosh software
>brain-dead in this instance

In a single word, yes.  Is it Microsoft that is hawking this bogus
SMTP server?

Mark Crispin / 6158 Lariat Loop NE / Bainbridge Island, WA 98110-2098
mrc@CAC.Washington.EDU -- MRC@PANDA.PANDA.COM -- (206) 842-2385
Atheist & Proud -- R90/6 pilot -- Lum-chan ga suki ja!!!
tabesaserarenakerebanaranakattarashii...kisha no kisha ga kisha de kisha-shita
sumomo mo momo, momo mo momo, momo ni mo iroiro aru
uraniwa ni wa niwa, niwa ni wa niwa niwatori ga iru

-----------[000328][next][prev][last][first]----------------------------------------------------
Date:      20 Nov 89 07:17:28 GMT
From:      dd26+@andrew.cmu.edu (Douglas F. DeJulio)
To:        comp.protocols.tcp-ip
Subject:   Transciever plans?

Can anyone out there give me enough information to build an ethernet
transciever?  A multiport transciever would be best.  I need to
connect a very small number of nodes...
-- 
Doug.deJ | dd26@andrew.cmu.edu 	           | Carnegie-Mellon University
******** | ...!harvard!andrew.cmu.edu!dd26 | Do not attend this college.

-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      20 Nov 89 09:03:57 GMT
From:      neil@cpd.com (Neil Gorsuch)
To:        comp.protocols.tcp-ip
Subject:   Re: print server

In article <8911062130.AA00281@hub.eng.wayne.edu> cliff@WSU-ENG.ENG.WAYNE.EDU (Cliff Stallings) writes:
>I have a network consisting of one sun-4, one sun-4, 2 pc's, 1 mac II running
>mac os, and 1 mac II running a/ux.
>All systems are connected via ethernet cards to tcp/ip based network.
>I have a laser writer and an image writer which I would like to access from
>all of my systems.  Can anyone help me?

If the problem is that the printers in question only have parallel
interfaces, use our new box to connect them to the sun's via SCSI.

--
Neil Gorsuch        INTERNET: neil@cpd.com          UUCP: uunet!zardoz!neil
MAIL: 1209 E. Warner, Santa Ana, CA, USA, 92705     PHONE: +1 714 546 1100
Uninet, a division of Custom Product Design, Inc.   FAX: +1 714 546 3726
AKA: root, security-request, uuasc-request, postmaster, usenet, news

-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      20 Nov 89 09:16:40 GMT
From:      neil@cpd.com (Neil Gorsuch)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.periphs.printers
Subject:   Re: Anybody know of an enet/TCP printer?

In article <1989Nov7.210143.26795@t2ns1.gcs.co.nz> brian@t2ns1.gcs.co.nz writes:
>Has anybody ever come across a printer hanging directly off a thick
>enet transceiver? We have a situation here where such a printer would
>be invaluable. Obviously it would need appropriate intelligence to
>handle addresses, domains etc. with it's card.

First, let me warn you that I am biased towards the following
solution, since we just introduced it as a new product.  I assume that
since you can't put it on one of the serial ports already existing on
one of your machines that you need a Centronics parallel port for the
printer.  Our new box allows you to add a Centronics parallel port
(and some serial ports) onto the SCSI port of Sun's and other
machines, while using the standard tty drivers already in the machine,
thus allowing network printer access via entries in /etc/printcap files.

--
Neil Gorsuch        INTERNET: neil@cpd.com          UUCP: uunet!zardoz!neil
MAIL: 1209 E. Warner, Santa Ana, CA, USA, 92705     PHONE: +1 714 546 1100
Uninet, a division of Custom Product Design, Inc.   FAX: +1 714 546 3726
AKA: root, security-request, uuasc-request, postmaster, usenet, news

-----------[000331][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20 Nov 89 15:58 EST
From:      SHAVER%TRINCC.BITNET@CUNYVM.CUNY.EDU
To:        TCP-IP@SRI-NIC.ARPA
Subject:   RE: please remove my name
Please remove my name from the tcp-ip discussion group.

-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      20 Nov 89 11:23:11 GMT
From:      dembele@renault.UUCP (I Feel Good)
To:        comp.protocols.tcp-ip
Subject:   More About Worms

I've just finished reading your paper about the last november worm on the INTERNET. I did really enjoy it.
I want now to read further on the subject.
Could you help me getting the papers referenced in the paper by Eugene H S.pafford in the same issue of the "COMMUNICATIONS of the ACM"? (i have not got his e-mail address)

[2] Denning,P. The internet worm. Amer. Sci 77,2(mar.-Apr. 1989),126-128

[15] Seeley,D. A tour of the worm. In proceedings of the 1989 Winter USENIX Conference. USENIX Association, San Diego,Calif.,Feb.1989

[16] Spafford,E.H. The internet worm program: An Analysis. Computer Communication Review 19,1(jan 1989)

The code of the worm is also welcome.

My e-mail address is: dembele%renault.uucp@inria.fr
and my fax number is: (33-1) 47 51 29 91 (in France, Europe)
my name is dembele

Best regards,

-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      20 Nov 89 13:15:00 GMT
From:      FILLMORE@EMRCAN.BITNET
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP definition

The SLIP protocol is defined in RFC 1055.  To get a copy, send a message
to service@sri-nic.arpa containing the subject line:
   rfc 1055
To get an index of RFCs, send:
   rfc index
________________________
Bob Fillmore, Systems Software & Communications   BITNET:  FILLMORE@EMRCAN
  Computer Services Centre,                       Voice:   (613) 992-2832
  Energy, Mines, & Resources Canada               BIX:     bfillmore
  588 Booth St., Ottawa, Ontario, Canada  K1A 0E4

-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20 Nov 89 14:24:51 SET
From:      ESC1814%ESOC.BITNET@CUNYVM.CUNY.EDU
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: Smart filtering within a protocol on bridge/router?

Using the Cisco router extended access-list feature you can filter IP
connections according to Source and Destination address, protocol ie.
IP, TCP, UDP, & ICMP, and down to the port number/service access point.

You can use >, <, or == or != operators to specify which port(s) may be
accessed. eg to allow only mail connections you could restrict a connection
between hosts to port 25 (SMTP port)

Dave Stafford
European Space Operations Centre
Darmstadt,
W. Germany
-----------[000335][next][prev][last][first]----------------------------------------------------
Date:      20 Nov 89 17:45:46 GMT
From:      swb@DAINICHI.TN.CORNELL.EDU (Scott Brim)
To:        comp.protocols.tcp-ip
Subject:   Re: routing protocols


   >Oh, I don't know.  The first NSFnet backbone risked a delay/congestion
   >based algorithm on an operational (but noncommercial) network.

The implementation of the HELLO protocol used in the first NSFNET
backbone (on fuzzballs, by Dave Mills) was supposed to be independent
of load on the net, in that the routing messages were generated just
barely outside of the interface cards themselves.  There turned out to
be some wobble, and Dave put a lot of work into controlling and
damping the incredible thrashing that occasionally came about due to
that wobble (also gated had a sliding window and filter put in to damp
it even further).  I don't know anyone who's working on dealing with
these problems for large nets anymore.  The main problem is that
you're in a situation where the system can (and probably will) change
direction faster than you can detect a wobble, send out an adjustment
to it, and have your adjustment stabilize.  You just keep thrashing.
							Scott

-----------[000336][next][prev][last][first]----------------------------------------------------
Date:      20 Nov 89 17:50:39 GMT
From:      whna@cgch.UUCP (Heinz Naef)
To:        comp.sys.ibm.pc,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   The PC as a trusted client in a TCP/IP network

Hello system integrators,
what could be done to turn existing personal computers (industry standard)
into real trusted clients on a TCP/IP network? What activities would be
required at the organizational and at the technical level?
 - Would it be necessary to disable/remove the floppy disk unit?
 - Would it be a good idea to boot the PC over the network interface
   (learning IP-address, loading DOS, etc.)?
   Did anyone implement this already (e. g. using BootP, etc.)?
 - Would it be better to choose an application gateway solution, i. e.
   implementing some proxy-Telnet, -FTP, -NFS, -etc. agent on a departemental
   host which is accessed by corresponding PC clients?
 - etc.
Any comments, suggestions, pointers to solutions, etc. are appreciated. I will
summarize to the net, so you could e-mail instead of followup-posting to save
News bandwidth.
Thanks, and best regards,
Heinz Naef, c/o CIBA-GEIGY AG, R-1045.3.37, P.O.Box, CH-4002 Basel, Switzerland
  UUCP:     cgch!whna
  Internet: whna%cgch.uucp@uunet.uu.net              Phone: (+41) 61 697 26 75
  BITNET:   whna%cgch.uucp@cernvax.bitnet            Fax:   (+41) 61 697 32 88

-----------[000337][next][prev][last][first]----------------------------------------------------
Date:      20 Nov 89 20:58:00 GMT
From:      SHAVER@TRINCC.BITNET
To:        comp.protocols.tcp-ip
Subject:   RE: please remove my name

Please remove my name from the tcp-ip discussion group.

-----------[000338][next][prev][last][first]----------------------------------------------------
Date:      20 Nov 89 21:36:58 GMT
From:      dlj@proteon.com (Daniel L. Jones)
To:        comp.protocols.tcp-ip
Subject:   Routing Protocols

Dale,
  Give me a call or send me email and I'll send you the OSPF spec.
Ask cisco customer service for the IGRP spec. You can read about RIP
in Doug Comer's Book " Internetworking with TCP/IP".

Dan Jones
Proteon Customer Service
(508) 898-3100
dlj@proteon.com

-----------[000339][next][prev][last][first]----------------------------------------------------
Date:      20 Nov 89 21:50:18 GMT
From:      anderson@ncrorl.Orlando.NCR.COM (Anderson)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP Broadcastsing - The Answer


	Thanks to Art Berggreen (art@salt.acc.com), Brendan Eich
(brendan@illyria.wpd.sci.com), and Micky Lui (micky@cunixc.cc.columbia.edu)
for responding to my question. This a brief summary of the answers for anyone
else that was curious.

Question: How does a UDP broadcast behave when a host has multiple network
	  interfaces (i.e. SLIP or multiple ethernet interfaces, etc.)?


Answer: It depends. 8-)

	In general, the broadcast will follow the restrictions placed on
it by using network/subnet broadcast addresses. If, however, a blanket
broadcast (wildcard address) is used, then only the primary interface
is used. It appears that the primary interface is selected as the first
entry found in the routing table (usually the first configured) with the
IFF_BROADCAST flag set.

	The proper way to do a broadcast so that it gets sent on all of the
network interfaces is to get a list of all of the interfaces, using ioctl()
calls for SIOGIFCONF and SIOGIFFLAGS, and send the packet down each interface
desired. I think that the proper broadcast/destination address for each
interface should also be determined this way (although I haven't tried it yet).

	RPC broadcasting does work by using these ioctl()s.

	In summary, it's up to the next level up (the user's program) to
determine the behavior of a broadcast. The UDP/IP drivers take a very simple
approach to it.

Stuart Anderson        anderson@Orlando.NCR.COM       NCR E&M Orlando, Florida
..!uunet!ncrlnk!ncrorl!anderson                       (407) 333-9250 ext. 288

      The opinions expressed here are my own and in no way reflect those
          of my employer or any one else unless specifically stated.

-----------[000340][next][prev][last][first]----------------------------------------------------
Date:      20 Nov 89 21:50:19 GMT
From:      tsuchiya@GATEWAY.MITRE.ORG
To:        comp.protocols.tcp-ip
Subject:   Re: routing protocols



The only work still going on for traffic-based routing in connectionless
networks, that I know of, is at BBN.  They have published
a nice paper on recent work in this area in SIGCOMM 89.  The paper is
nice both for the algorithms they present and for the general description
of the nature of the problem.  The paper says to me that with
a lot of tuning, delay-based routing can increase throughput in
certain operating regions.  But if it is poorly tuned, watch out.

Of course, work of this sort associated with connection-oriented
networks has been going on forever, but I can't say I'm too familier
with the literature.

In general, I think if yet another group is going to go off and work
on another igp, it should do something different than the one we
have, not just do the same thing a little better (and of course the
verdict on whether DV can be better than LS is by no means in).
Otherwise the headache of implementing to two standards is not worth
the effort.  For instance, doing delay-based routing, or multi-path
(as a basic approach to routing, not just for equal paths), or
multi-cast, or for that matter Landmark Routing.  But these things
require research, and so standardization would (and should) be delayed
for some time.

_________________________________________________________________
Paul F. Tsuchiya		The MITRE Corp.
tsuchiya@gateway.mitre.org	7525 Colshire Dr.
703-883-7352			McLean, VA 22102 USA
_________________________________________________________________ 

-----------[000341][next][prev][last][first]----------------------------------------------------
Date:      20 Nov 89 21:59:37 GMT
From:      dlj@proteon.com (Daniel L. Jones)
To:        comp.protocols.tcp-ip
Subject:   Need info on commercial SNMP based products


Robert,
  Proteon has a Network Mangement System called OverVIEW, which
uses SNMP and PING to monitor the network. Proteon Routers support
SNMP, therefore you can monitor all Routers from a centralized
location.

Dan Jones
Proteon Customer Service 

-----------[000342][next][prev][last][first]----------------------------------------------------
Date:      20 Nov 89 22:06:39 GMT
From:      chip@ateng.com (Chip Salzenberg)
To:        comp.windows.ms,comp.protocols.tcp-ip,alt.msdos.programmer
Subject:   TCP/IP libraries for Windows?

The time has come.  We've been doing Windows development here for some time.
We've been doing TCP/IP networking for a while.  Now the twain must meet:
We need a TCP/IP library for use in a Windows application.

Does such an animal exist?  Must I convert NCSA Telnet or KA9Q for use with
Windows?  Can I not stand on someone else's shoulders?

Please reply by E-Mail.  I will summarize E-Mail to the net.
-- 
You may redistribute this article only to those who may freely do likewise.
Chip Salzenberg at A T Engineering;  <chip@ateng.com> or <uunet!ateng!chip>
    "Did I ever tell you the Jim Gladding story about the binoculars?"

-----------[000343][next][prev][last][first]----------------------------------------------------
Date:      21 Nov 89 00:14:31 GMT
From:      wcs@cbnewsh.ATT.COM (Bill Stewart 201-949-0705 ho95c.att.com!wcs)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   How fast is SLIP?

We have several locations with Ethernets and Suns, connected by a Datakit
network that can give us good async connectivity, and we'd like to
bridge or route the Suns together.  While there are some respectable
solutions to the problem, all of them require capital budget and time,
and we'd like to get something working quickly, performance not critical.

The obvious approach seems to be SLIP - we can nail up a 19200 baud
connection across the Datakit and snarf the software off uunet,
using our file server as a router, and maybe also use some of the spare
PCs lying around with pcbridge or pcroute.  RFC 1055 talks about
future header compression work - is this available yet, or does
uunet have the latest stuff?

How much CPU does this use?  Will it use up half the CPU (bad) or
<10% (ideal)?  We're mostly running Sun 3/150s with SunOS 3.5,
though the server may get upgraded to 4.0.X, and we have
ALM-2 boards as well as the built-in ports.  Can the Sun handle
19200, or just 9600?

Is more than one line possible on a single machine?
Aside from horsepower problems, will the software support it?
This is especially a concern for the pc products.

Also, does Wollongong support SLIP in a compatible fashion?
We have a few 3B2/300s which aren't very busy.
-- 
# Bill Stewart, AT&T Bell Labs 4M312 Holmdel NJ 201-949-0705 api.att.com!wcs

#		We did it for the formlessness ...

-----------[000344][next][prev][last][first]----------------------------------------------------
Date:      21 Nov 89 01:11:45 GMT
From:      brunner@ibmpa.UUCP (MH 6.6, Eric Brunner)
To:        comp.protocols.tcp-ip
Subject:   Re: IBM RT/AOS on Token Ring (w/bridges)?

Michael,

I'm maintaining IBM's 4.3 release for the RT (actually the 6150, 6151,
and 6152) platform. This looks like an APAR (real bug in the local lexicon)
that I'd like to see and fix. Lets take this out of the tcp-ip list and
work on it via email.

BTW list co-readers, if you've IBM workstations running IBM/4.3 (aka "AOS",
and "ACIS"), and you've a problem that either dosen't seem to make its way
through the system, or if your site somehow dropped out of contact, drop
me a note - you're not alone!

Some 20 fixes have been posted to comp.sys.ibm.pc.rt, and an archive is
available for anonymous ftp on bikini.cis.ufl.edu [128.227.224.1].


Eric Brunner, Consultant, IBM AWD Palo Alto	(415) 855-4486
inet: brunner@monet.berkeley.edu
uucp: uunet!ibmsupt!brunner	

-----------[000345][next][prev][last][first]----------------------------------------------------
Date:      21 Nov 89 02:17:34 GMT
From:      michaud@decvax.dec.com (Jeff Michaud)
To:        comp.protocols.tcp-ip
Subject:   Re: PCSA


	Note that PCSA is really a superset of DECnet-DOS (ie. PCSA includes
	DECnet-DOS but not vice versa).

/--------------------------------------------------------------\
|Jeff Michaud    michaud@decwrl.dec.com  michaud@decvax.dec.com|
|DECnet-ULTRIX   #include <standard/disclaimer.h>              |
 \--------------------------------------------------------------/

-----------[000346][next][prev][last][first]----------------------------------------------------
Date:      21 Nov 89 05:12:58 GMT
From:      verber@pacific.mps.ohio-state.edu (Mark A. Verber)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: How fast is SLIP?

In article <5969@cbnewsh.ATT.COM> wcs@cbnewsh.ATT.COM (Bill Stewart 201-949-0705 ho95c.att.com!wcs) writes:
>We have several locations with Ethernets and Suns, connected by a Datakit
>network that can give us good async connectivity, and we'd like to
>bridge or route the Suns together.  While there are some respectable
>solutions to the problem, all of them require capital budget and time,
>and we'd like to get something working quickly, performance not critical.
>

You might want to check around.  There was a tcp on top of datakit
(don't shoot) done in the mid-80s.  The version I saw ran on BSD 4.2
Vaxen with DataKit, but it believe it was built on other systems.  You
might also have real Internet access shortly.  I know that there is a
project to get Internet connectivity improved throughout the Labs.  If
you are real interested, I can check will some friends for more info.

>The obvious approach seems to be SLIP - we can nail up a 19200 baud
>connection across the Datakit and snarf the software off uunet,
>using our file server as a router, and maybe also use some of the spare
>PCs lying around with pcbridge or pcroute.  RFC 1055 talks about
>future header compression work - is this available yet, or does
>uunet have the latest stuff?

You could run SLIP over DataKit.  I am not clear why you would need the
IBM-PCs.  You could run SLIP under SunOS 3.5 and not worry about
the IBM-PCs.  The header compression (actually prediction) has not
be release yet (Hello Van?).  It should be out soon (we all hope).

>How much CPU does this use?  Will it use up half the CPU (bad) or
><10% (ideal)?  We're mostly running Sun 3/150s with SunOS 3.5,
>though the server may get upgraded to 4.0.X, and we have
>ALM-2 boards as well as the built-in ports.  Can the Sun handle
>19200, or just 9600?

CPU usage shouldn't be too bad.  The worst I have ever seen was about 5%.
I personally find the ALM-2 objectional, but there are patches from
Uof Toronto which make the ALM-2s usable for fast SLIP.  I have used
SLIP at 19.2K will the patches successfully,

>
>Is more than one line possible on a single machine?
>Aside from horsepower problems, will the software support it?
>This is especially a concern for the pc products.
>
>Also, does Wollongong support SLIP in a compatible fashion?
>We have a few 3B2/300s which aren't very busy.
>-- 
You can have more that one line if the software supports it.  KA9Q supports
multiple lines, I am not sure about pcroute, but I think not.  All the
Unix based versions of SLIP that I have seen support multiple SLIP
connections.  Wollongong does support a compatible SLIP.
-- 
Mark A. Verber
System Programmer, Physics Department, Ohio State University
verber@pacific.mps.ohio-state.edu
(614) 292-8002

-----------[000347][next][prev][last][first]----------------------------------------------------
Date:      21 Nov 89 05:47:18 GMT
From:      mrose@CHEETAH.NYSER.NET (Marshall Rose)
To:        comp.protocols.tcp-ip
Subject:   Re: Need info on commercial SNMP based products

In the interests of trying to avoid having about 30 vendors send product
announcements to this list, may I suggest that you redirect your question to
the SNMP list:

	snmp@nisc.nyser.net

If you wish to join this list, send a note to

	snmp-request@nisc.nyser.net

Thanks,

/mtr

-----------[000348][next][prev][last][first]----------------------------------------------------
Date:      21 Nov 89 10:27:57 GMT
From:      wisner@hayes.fai.alaska.edu (Bill Wisner)
To:        comp.protocols.tcp-ip
Subject:   FTP is most uncooperative

For some months now, we have been experiencing problems in FTPing files from
any non-local machines. What typically happens is that an FTP process will hang
after transferring some data. This happens on both incoming and outgoing
transfers, and on UNIX, VMS, and PC machines. Sometimes connections will
hang after transferring as little as 3K; sometimes they last for 80 or more.

Needless to say it is all quite bothersome. Any ideas?

-----------[000349][next][prev][last][first]----------------------------------------------------
Date:      21 Nov 89 13:52:29 GMT
From:      boykin@calliope.Encore.COM (Joseph Boykin)
To:        comp.protocols.tcp-ip
Subject:   Re: Does Data General under AOS/VS use TCP/IP?

In article <3159@husc6.harvard.edu> houpt@husc8.UUCP (Thomas Houpt) writes:
>
>A friend of mine is trying to network a Data General computer
>running AOS/VS to Macintoshes with ethernet.
 ...
>The question is, does the DG use TCP-IP on its ethernet network,
>or is it available (along with ftp for the file transfer) for the
>DG operating system. Once we know its possible to get TCP-IP/FTP
>running, we know what to do. But we are sufficiently unfamiliar with the
>DG operating system not to know if this is trivial or impossible.

I haven't worked for DG for about 4 years, however, before I left
there was a TCP/IP product available for AOS/VS.  While things may
have changed I would strongly doubt that they use TCP/IP  as their
"standard" protocol.  In fact, the most often used protocol was X.25.

I'm sure DG would be happy to sell you TCP/IP (and ftp, etc. that
went along with it).

----

Joe Boykin
Encore Computer Corp
Vice-Chair, IEEE Computer Societies'
    Technical Activities Board

Internet: boykin@encore.com
UUCP: encore!boykin

-----------[000350][next][prev][last][first]----------------------------------------------------
Date:      21 Nov 89 14:05:51 GMT
From:      craig@bbn.com (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP is most uncooperative

In article <8911211027.AA01322@hayes.fai.alaska.edu> wisner@hayes.fai.alaska.edu (Bill Wisner) writes:
>For some months now, we have been experiencing problems in FTPing files from
>any non-local machines. What typically happens is that an FTP process will hang
>after transferring some data. This happens on both incoming and outgoing
>transfers, and on UNIX, VMS, and PC machines. Sometimes connections will
>hang after transferring as little as 3K; sometimes they last for 80 or more.
>
>Needless to say it is all quite bothersome. Any ideas?

Bill:

    Is it FTP that is the problem, or is it your TCP connection?  Have
you done a packet trace to see if any data is going over the link?

    There are some baroque failure scenarios that can cause a TCP
connection to fail in this fashion and a careful analysis of a packet
trace tends to reveal the problem.

    Also, are all the problems from one machine, to all the others, or
are you saying all your machines (with different software and vendors)
have this problem?

Craig

-----------[000351][next][prev][last][first]----------------------------------------------------
Date:      21 Nov 89 14:13:22 GMT
From:      adnan@sgtech.UUCP (Adnan Yaqub)
To:        comp.protocols.tcp-ip
Subject:   Re: Telnet source code

In article <8911141933.AA13055@berserkly.cray.com> dab@BERSERKLY.CRAY.COM (David Borman) writes:

   The latest copy of source for both telnet and telnetd are now available
   for anonymous ftp from ucbarpa.berkeley.edu.  There is a single
   compressed tar file, pub/telnet.tar.Z, which has both the client
   and the server code.  This file also has diffs from the 4.3BSD

I would be very interested in looking at this source code.
Unfortunately, I don't have FTP access.  Could someone mail this to me
or maybe it could be placed in an anonymous UUCP archive? (osu-cis,
Karl?)
--
Adnan Yaqub
Star Gate Technologies, 29300 Aurora Rd., Solon, OH, USA, +1 216 349 1860
...cwjcc!ncoast!sgtech!adnan ...uunet!abvax!sgtech!adnan

-----------[000352][next][prev][last][first]----------------------------------------------------
Date:      21 Nov 89 18:02:58 GMT
From:      eckert@immd4.informatik.uni-erlangen.de (Toerless Eckert)
To:        comp.protocols.tcp-ip
Subject:   IS-IS available publically ?

One possible stupid question: I there a publically available implementaion
of IS-IS, possible the one described in RFC1074 ?


Toerless Eckert X.400: <S=eckert;OU=informatik;P=uni-erlangen;A=dbp;C=de>
		RFC822: eckert@informatik.uni-erlangen.de
		UUCP:   {pyramid,unido}!fauern!eckert BITNET: tte@derrze0

-----------[000353][next][prev][last][first]----------------------------------------------------
Date:      21 Nov 89 19:10:07 GMT
From:      sean@dranet.dra.com
To:        comp.protocols.tcp-ip
Subject:   Z39.50 (Search and Retrieval) over TCP/IP

Anyone have the Z39.50 protocol running on top of TCP/IP?

I'm working on this protocol for a few other network protocol stacks, and 
and be very interested in how people are going about ensuring interoperability
when running Z39.50 over TCP/IP.

Z39.50 is a NISO standard for Search and Retrieval (OSI application layer)
for (mostly?) the library world.

-- 
Sean Donelan, Data Research Associates, Inc, St. Louis, MO
Domain: sean@dranet.dra.com, Voice: (Work) +1 314-432-1100

  Affiliation given for purposes of identification, not representation

-----------[000354][next][prev][last][first]----------------------------------------------------
Date:      21 Nov 89 21:08:27 GMT
From:      userUSSR@mts.ucs.UAlberta.CA (Chris Thierman)
To:        comp.protocols.tcp-ip
Subject:   Looking for interesting networking conference to attend before April 1st.

I'm looking for any interesting networking conferences happening before April 1 1990.
Anything dealing with UNiX or Internet would
be most helpfull. But I have not excluded any other possibilities.
Please reply via E-MAIL to
Chris_Thierman@mts.ucs.UAlberta.Ca
or
uqv-mts!Chris_Thierman@alberta.UUCP
or
userussr@ualtamts.BITNET
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Chris Thierman                        E-Mail: cthierma@mts.ucs.UAlberta.CA
University Computing Systems          Phone: (403) 492-2462
352 General Services Building
University Of Alberta
Edmonton, Alberta
Canada T6G 2H1

-----------[000355][next][prev][last][first]----------------------------------------------------
Date:      21 Nov 89 21:46:04 GMT
From:      ramana@uts.amdahl.com (Ramana Gadagottu)
To:        comp.protocols.tcp-ip
Subject:   tcp maximum-segment-size



A non-unix tcp/ip station on our network is setting
its tcp MSS(maximum segment size) to zero causing a flood of
zero length data packets onto the network from Sun and other
BSD based-stations. It looks like the BSD code doesn't check
if the MSS is being set for zero and tries to send zero length
packets out.

I have a few questions:
 1. Is it acceptable to set the MSS to zero ?
    If not what should be the minimum value ?
 2. If not acceptable, can the host decide not to send any data
    and close the connection ?
 3. How are the non-BSD implementations deal with it ?

Thanks in advance for any suggestions.
-- 
                           ...!{cbosgd,decwrl,hplabs,sun}!amdahl!ramana
 -----------------------------------------------------------------------
  The views expressed here are solely of my own.
  My employer has nothing to do with this article.

-----------[000356][next][prev][last][first]----------------------------------------------------
Date:      21 Nov 89 22:07:46 GMT
From:      keshav@ucbarpa.Berkeley.EDU (Keshav)
To:        comp.protocols.tcp-ip
Subject:   Duplicate ping packets on a local area network

I get duplicate ping packets over a microwave relay that links
two ethernets. Most, but not all, ICMP ping packets have duplicates,
and the interval between two replies varies from 5 to 60 ms.
The problem occurs between any two machines that are on opposite
ends of the link.
The link itself is rather dumb: it provides a virtual extension 
of the ethernet cable across a distance of about a mile.
Could the problem be due to the CSMA/CD protocol? Or is it some
known bug in TCP? All opinions welcome.

keshav

-----------[000357][next][prev][last][first]----------------------------------------------------
Date:      21 Nov 89 22:30:25 GMT
From:      guy@auspex.auspex.com (Guy Harris)
To:        comp.protocols.tcp-ip
Subject:   Re: Remote "cat" during ftp connection

>> Is it possible to list text files during an ftp connection?
>Some ftp clients let you "get" to a file named "-", meaning the
>display.

Any UNIX worth its salt should let you "get" to a file named "/dev/tty",
meaning the user's terminal, so even if "-" doesn't work it should be
possible.  Of course, this just dumps it directly to the terminal, so if
neither your terminal or terminal emulator nor your system's tty driver
pauses at the end of a screenful of data, you'd better be a fast reader
or be running over a slow link.... 

-----------[000358][next][prev][last][first]----------------------------------------------------
Date:      21 Nov 89 22:54:31 GMT
From:      ralls@cisco.com (Vicki Ralls)
To:        comp.protocols.tcp-ip
Subject:   Re: PCSA

Yes, sorry if I did not make myself clear.

The point I was trying to make was that if you buy PCSA DECnet DOS comes
along as an additional benefit.

The reverse is not true.

-Vicki Ralls

-----------[000359][next][prev][last][first]----------------------------------------------------
Date:      22 Nov 89 01:10:58 GMT
From:      tds@cbnewsh.ATT.COM (antonio.desimone)
To:        comp.protocols.tcp-ip
Subject:   Routing Protocols


Some time back I posted this query (actually a longer version) looking
for information on cisco's routing protocol.  

> Can someone point me to a source of information on cisco's
> Interior Gateway Routing Protocol?  I've come across some of their
> glossies that make mention of flow optimization, delay and traffic
> measurements, etc.  I wonder if they do something much more
> sophisticated than, for example, Open SPF as far as load balancing
 
> Beyond cisco in particular, are there any IP router vendors who
> attempt to make routing decisions based on real-time traffic
> measurements?  

Thanks to all those who replied: I quote from some replies below.

Kent>    kwe%buitb.BU.EDU@bu-it.bu.edu (Kent England)   
John>    John Bashinski <jbash@cisco.com>               
smb>     ulysses!smb                                    
Milo>    "Milo S. Medin" <ucbvax!nsipo.nasa.gov!medin>  
art>     art@sage.acc.com                               

First the quick summary: get the document describing IGRP written by
Chuck Hedrick from Rutgers.  Hedrick was good enough to send me a copy
but I won't bother posting since it's available by anonymous ftp from: 

Kent> athos.rutgers.edu in /pub/igrp.[doc|ps].  It might
Kent> be or will be in the Working Group directories on SRI-NIC at some
Kent> point.

John> You can pick up a copy of a paper on IGRP by anonymous FTP from 
John> ftp.cisco.com. It's called "igrp.doc". Directory listings are disabled 
John> for security reasons; just go ahead and pick up the paper.


Basics:

Kent> Well, the main diff is link-state versus distance-vector.  OSPF is
Kent> link-state and ciscoIGRP is distance vector.  Depending on which side
Kent> you light your torch, you might prefer one over the other based on
Kent> link-state or distance-vector.

Art> Until recently, IGRP was not being disclosed by cisco.  At the last IETF,
Art> Chuch Hedrick at Rutgers released a document (with cisco's OK), based
Art> on the cisco patent application, which summarizes the major technology
Art> in IGRP.  From looking at that, I would say that OSPF and IGRP offer about
Art> the same level of functionality.  Of course, since IGRP is a Distance Vector
Art> algorithm and OSPF is a Link State algorithm, this is somewhat apples to
Art> oranges.  cisco has apparently stated that they may be willing to liscense
Art> IGRP much like Ethernet was (modest one time charge).  Chuch Hedrick is
Art> heading an IETF working group looking into defining a public domain Distance
Art> Vector protocol that would be equal to or better than IGRP.

On the issue of load balancing:

John> IGRP provides for just slightly more than plain round-robin routing; you
John> can specify a "variance", which allows load-sharing between links with 
John> different capacities. Unfortunately, large variances tend to destabilize
John> the network.

Milo> Just a point of clarification here about OSPF.  The protocol will find 
Milo> multiple equal-cost paths.  Whether or not a router can use this
Milo> information to load-balance in a round-robin way depends on how
Milo> the IP forwarding module in a particular implementation is implemented.

Milo> In general trying to do dynamic load balancing in a multi-vendor
Milo> environment is a pretty dicey issue.  BBN went through great pains
Milo> to tame the dynamic load balancing in their PSN networks.  

And on the use of measures of real-time congestion for routing:  (I don't
know if I was completely clear in my original posting.  I was asking
about controls that respond on the timescales on which queues build
up.  That's what is required to reroute rather than drop packets as
queues build up, i.e. if you want "congestion avoidance".) 

smb> As for delay measurements:  what about the ARPANET itself, where the IMPs
smb> do real-time load measurements?  That was certainly an operational net,
smb> and MILNET still uses that technology.

Art> The stability problems seem to outweigh any real benefits at the current
Art> time.  Until congestion avoidance mechanisms for connectionless networks
Art> are developed (and deployed) to deal congestion in the first place, I
Art> don't think it makes sense to try to respond to congestion at the routing
Art> level.  Once congestion avoidance mechanisms are there, and the routers
Art> can determine the rate at which sources respond to congestion (not an easy
Art> measurement problem) then that gives a limit to how fast routing should
Art> be allowed to change.

Art's statement seems to hold for the BBN/Milnet algorithm as well.
There's an article in the recent SIGCOMM proceedings by Khanna and
Zinky of BBN that explains the metric used.  Yes delay measurements are
used, but routes are updated on a timescale in the tens of seconds, at
best.   That approaches the connection (or at least the busy) time for
file transfers.  I think it's safe to say that no one uses rerouting as a 
congestion avoidance technique (although I'd still be interested to
hear otherwise!)
-- 
Tony DeSimone
AT&T Bell Laboratories
Holmdel, NJ 07733
att!tds386e!tds

-----------[000360][next][prev][last][first]----------------------------------------------------
Date:      22 Nov 89 01:15:50 GMT
From:      lmjm@doc.ic.ac.uk (Lee McLoughlin)
To:        comp.protocols.tcp-ip
Subject:   Wanted: NCSA Telnet under Microsoft C 5.1

I'm after a version of the NCSA Telnet that has been modified to work
with MicroSoft C 5.1 on a PC.  I've seen the patches on the contrib area
of the ncsa archive but they apply to an older version.  I'm hoping someone
has done the work necessary to get a recent version compiled and running.

If prototypes have been added that would be even better still!

Thanks in advance
	Lee

-----------[000361][next][prev][last][first]----------------------------------------------------
Date:      22 Nov 89 01:45:04 GMT
From:      larree@altos86.Altos.COM (Larry Snyder)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   LAN benchmarking

I am looking for ways of describing network performance in terms
which can be easily compared to other systems and configurations.

Are there any widely used programs which will measure the
performance of various layers of a TCP/IP protocol stack?

How does one measure performance degradation when adding virtual
circuits or playing with block sizes?

Is it useful to measure the inter-frame delay between a 'ping'
and the response?

By using a network analyzer to help calculate the average transmission
rate between stations, am i getting an accurate measurement of my
ethernet driver?

What about NFS or RFS?

And, most important, are any numbers available for other systems?

(any useful sources mailed to me will be "shar"ed and posted)
-- 
Larry Snyder                                         Altos Computer Systems
Internet: larree@altos.com                           2641 Orchard Parkway
UUCP    : uunet!altos!larree                         San Jose CA 95134
(my opionions have nothing to do with microsoft.)    408.432.6200

-----------[000362][next][prev][last][first]----------------------------------------------------
Date:      22 Nov 89 06:07:47 GMT
From:      ESC1814@ESOC.BITNET
To:        comp.protocols.tcp-ip
Subject:   Re: Smart filtering within a protocol on bridge/router?


Using the Cisco router extended access-list feature you can filter IP
connections according to Source and Destination address, protocol ie.
IP, TCP, UDP, & ICMP, and down to the port number/service access point.

You can use >, <, or == or != operators to specify which port(s) may be
accessed. eg to allow only mail connections you could restrict a connection
between hosts to port 25 (SMTP port)

Dave Stafford
European Space Operations Centre
Darmstadt,
W. Germany

-----------[000363][next][prev][last][first]----------------------------------------------------
Date:      22 Nov 89 14:38:00 GMT
From:      jimo@banyan.UUCP (Jim O'Riordan)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   tcp/ip Beginner's Help

The TCP/IP expert for my company just quit and I have been told I am 
to be the new expert. I'm happy about this except there isn't alot
of information in the bookstore's I've checked. I have the Comer
book and Stallings 3rd volume. What I need is more on confiruraton.

I work in Technical Support and have to help people who know less
than me to configure there networks. So if any of you could recommend
articles, books, or ???? it would sure help.

Thanks Steve Barnette
       voice (508) 836-2802 work
       FAX   (508) 898-9611

-----------[000364][next][prev][last][first]----------------------------------------------------
Date:      22 Nov 89 15:24:46 GMT
From:      anoop@WSU-ENG.ENG.WAYNE.EDU (Anoop K. Verma)
To:        comp.protocols.tcp-ip
Subject:   tcp-ip mail

I am working in the networking group of the Engineering Computer Center and
I am very much intersted in subscribing to the mail regarding tcp-ip and
related subjects. 
Please put me on your mailing list and inform me what I have to do for that.
                     THANKS
                 		ANOOP
_______________________________________________________________________________Anoop K. VERMA       anoop@wsu-eng.eng.wayne.edu
________________________________________________________________________________

-----------[000365][next][prev][last][first]----------------------------------------------------
Date:      22 Nov 89 16:52:17 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  routing protocols

Scott nicely and compactly summarized the problems with delay wobble in the
NSFNET Phase-I network, now gone to heaven and reincarnated as a network
of precision clocks. However, the real problem with the net as victim of
congestion abuse was the link-level protocol (DDCMP) which was implemented
in the interface firmware and could not be turned off. Thus, buffer starvation
at one site would cause persistent retransmission and eventual stagflation
at upstream sites. The many lessons learned, retroactively obvious and otherwise,
are summarized in my paper "The Fuzzbll" appearing in SIGCOM 88 proceedings.

Dave

-----------[000366][next][prev][last][first]----------------------------------------------------
Date:      22 Nov 89 17:17:12 GMT
From:      mckenney@aai8.itstd.sri.com.uucp (Paul E. McKenney)
To:        comp.protocols.tcp-ip
Subject:   Re: Remote "cat" during ftp connection

>> Is it possible to list text files during an ftp connection?
>Some ftp clients let you "get" to a file named "-", meaning the
>display.

Some (UNIX) ftp clients allow the following sort of thing:

	get file |more

The following also can be of use:

	get file.Z "|zcat > file"
	get file.Z "|tar -xvf -"
	get file.Z "|zcat | tar -xvf -"
	get file.txt |lpr

In the implementation I have been using most recently (SunOS 4.0.3), the
quotes are needed if the command contains spaces.

				Thanx, Paul

-----------[000367][next][prev][last][first]----------------------------------------------------
Date:      22 Nov 89 17:42:49 GMT
From:      vanden@studsys.mu.edu (vandenberg)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.periphs.printers
Subject:   Re: Anybody know of an enet/TCP printer?

I'm not sure if it speaks tcp/ip but LAN Systems LAN Port might work.  We 
will be using one on a Novell network(ipx) in a week or two.  Supposedly
it has all the workings of an ethernet station in a box the size of a hand
then just a serial port to plug in a device.
If anyone is interested I can post something when we get it in(the 2 weeks 
was what our distributer said :-) ).......or if you want, the phone and 
address for LANsystems follow.  

LANsystems,  5009 Broadway  New York, NY  10012
212-431-1255 tech supt  or  212-431-8484 sales???

Usual disclaimer RE: only satisfied cust. and so
--------
Tom Vandenberg                {..uunet..uwvax!uwmcsd1..}!marque!studsys!vanden
vanden%studsys@marque.UUCP             {..uwvax..arpa..}!studsys.mu.edu!vanden

-----------[000368][next][prev][last][first]----------------------------------------------------
Date:      22 Nov 89 17:49:20 GMT
From:      chris@sparta.UUCP (Chris Chiotasso)
To:        comp.protocols.tcp-ip
Subject:   help with snmp traps

I am currently implementing an SNMP agent and am faced with the
problem of delivering trap messages to an SNMP manager.  How does
the agent know where to send its trap messages?  Does anyone
have a clever scheme that allows the agent to learn its trap
delivery address? 

-----------[000369][next][prev][last][first]----------------------------------------------------
Date:      22 Nov 89 18:56:46 GMT
From:      mack@inco.UUCP (Dave Mack)
To:        comp.protocols.tcp-ip
Subject:   Source for BFTP (RFC1068) Available?


Do any of you know of any public domain implementations of
Background FTP? I need one semidesperately.

Thanks very much,
Dave Mack
mack%inco@uunet.uu.net
-- 
Dave Mack				McDonnell Douglas Electronic Systems
uunet!inco!mack, inco%mack@uunet.uu.net			(703)883-3911
All opinions expressed are my own and do not reflect those of MDESC. Ever.

-----------[000370][next][prev][last][first]----------------------------------------------------
Date:      22 Nov 89 20:28:31 GMT
From:      eli@spdcc.COM (Steve Elias)
To:        comp.protocols.tcp-ip
Subject:   Re: Fax over tcp/ip

>gnu@hoptoad.uucp (John Gilmore) writes:
>
>>Clearly what we want on the Internet is more like what computer fax
>>over phone lines should be doing (except that the designers of fax
>>didn't think about extensibility, and the people who implement it are
>>too busy (hacking slimy binary MSDOS software) to support real
>>computers or consider the larger issues).  

	John's generalization about "the people who implement fax" is 
	clearly incorrect.  computerfax under actual operating systems
	is available.  and some computerfax designers are thinking about
	larger issues, as well as real computers!




-- 
 ... Steve Elias ; eli@spdcc.com ; 6179325598 ; {}
*disclaimer();  /* watch out for litigous pinheads!  		 */
                /* and: free email-->fax for boston destinations */

-----------[000371][next][prev][last][first]----------------------------------------------------
Date:      22 Nov 89 22:04:00 GMT
From:      carlson@uxh.cso.uiuc.edu
To:        comp.protocols.tcp-ip
Subject:   Re: Duplicate ping packets on a local a


It is not the hosts' protocols.
Ping doesn't use TCP, and IP/ICMP should never rebroadcast.
Thus the problem must be below the IP level. How intelligent 
are the Ether/uWave interfaces?  Maybe they are too clever for
their good.  Have you tried putting a netwatcher/packet sniffer
on each end?  Are ARP packets also being duplicated?
--------------------
Brad Carlson  <carlson@mrcnext.cso.uiuc.edu> or <brad-carlson@uiuc.edu>
University of Illinois -- Consultant -- NeXT guru -- Windows Programmer

-----------[000372][next][prev][last][first]----------------------------------------------------
Date:      22 Nov 89 22:47:37 GMT
From:      jon@athena.mit.edu (Jon A. Rochlis)
To:        comp.sys.ibm.pc,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: The PC as a trusted client in a TCP/IP network

In article <907@cgch.UUCP> whna@cgch.UUCP (Heinz Naef) writes:
>Hello system integrators,
>what could be done to turn existing personal computers (industry standard)
>into real trusted clients on a TCP/IP network? 

My 2 cents: Don't try to turn PC's into "trusted clients".  Don't
build around the concept of trusted clients at all.  Instead assume
all clients run with software (possibly even hardware) written from
the ground up by a cracker.  Assume all communications are monitored
by the "bad guy".  Require something like Kerberos to make the client
process prove its identity to a server.  Encrypt data streams or do
crypto-checksums depeneding upon the sensitivity of the data in
question.  Don't trust the software on the client.  After unless you
control and secure all the wire, somebody can pretty easily hook up
their own portable PC and at the very least run a sniffer to grab all
the packets as they go over the wire.

		-- Jon

-----------[000373][next][prev][last][first]----------------------------------------------------
Date:      22 Nov 89 22:48:00 GMT
From:      kr@apollo.HP.COM (Keith Alan Rodwell)
To:        comp.protocols.tcp-ip
Subject:   Re:  Smart filtering within a protocol on bridge/router?


	There are a number of companies who deal with protocol layer
brdiges that can do packet filtering.  Proteon, Bridge and Cisco come
to mind.  Some are even programmable enough that you can define new 
protocols (i.e. Apollo/HP 8019...).  You should look at a number of 
vendors before you buy.  There are many options/limitations with many
models.  Look hard at what you need to do v.s. cost.

			---Keith

------------------------------------------------------------------------
-------------------
``This theory which is mine, is mine'' -- Ann Elk (Monty Python)
Keith Alan Rodwell
Apollo/HP Customer Support
(508)-256-6600 X8415

-----------[000374][next][prev][last][first]----------------------------------------------------
Date:      22 Nov 89 22:54:43 GMT
From:      pushp@SDSC.EDU (Pushpendra Mohta)
To:        comp.protocols.tcp-ip
Subject:   (none)

Subject: Mailing List pushp@sdsc.edu
hi
please add my name to this mailing list
thanks
Pushpendra Mohta

-----------[000375][next][prev][last][first]----------------------------------------------------
Date:      22 Nov 89 23:07:47 GMT
From:      chris@SALT.ACC.COM (Chris VandenBerg)
To:        comp.protocols.tcp-ip
Subject:   X windows source

Good afternoon,
		I know this is the wrong place to ask about where the MIT X11R4
stuff might be hiding but I'm hoping someone on this list might have a clue.
I think I've logged on to every machine at MIT and still no luck! Anyway, if
someone could point me in the right direction for the X11 stuff I would truly
appreciate it (:*)
			Thanks ever so much,
   __    _____   _____     Chris VandenBerg (chris@salt.acc.com)
  //\\  / ____\ / ____\    Advanced Computer Communications
 //__\\ ||_____ ||_____    720 Santa Barbara St. 
// \___\\_____/ \_____/    Santa Barbara, CA 93101
                           (805) 963-9431

-----------[000376][next][prev][last][first]----------------------------------------------------
Date:      23 Nov 89 00:31:17 GMT
From:      brian@ucsd.Edu (Brian Kantor)
To:        rec.ham-radio.packet,rec.ham-radio,comp.protocols.tcp-ip
Subject:   KA9Q users mailing list

If you are a user of the KA9Q Networking package, there is a mailing
list you may join to communicate with kindred souls.

The primary orientation of the discussions is toward use of the package
on Amateur (ham) Radio, but some of the discussions may apply to other
uses.

To subscribe to the mailing list, send a message to 'listserv@ucsd.edu'
(or whatever variation of that address is appropriate for you), with the
text
	subscribe ka9q-users
in the body of the message.  You will receive confirmation of your
subscription by mail, if our admittedly-stupid parser could figure out
your message and return address.

Note that an earlier message in these groups mentioned the 'tcp group'
mailing list; that is a technical workgroup mailing list and probably
isn't what you were looking for.
	- Brian

-----------[000377][next][prev][last][first]----------------------------------------------------
Date:      23 Nov 89 05:26:49 GMT
From:      cpcahil@virtech.uucp (Conor P. Cahill)
To:        comp.sys.ibm.pc,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: The PC as a trusted client in a TCP/IP network

> control and secure all the wire, somebody can pretty easily hook up
> their own portable PC and at the very least run a sniffer to grab all
> the packets as they go over the wire.

Speaking of sniffers,  can somebody send me information on what hardware 
is available for a portable pc to collect/view/analyze ethernet traffic
(and hopefully decript the TCP/IP packets) on both thin and thicknet.

Thanks in advance
-- 
+-----------------------------------------------------------------------+
| Conor P. Cahill     uunet!virtech!cpcahil      	703-430-9247	!
| Virtual Technologies Inc.,    P. O. Box 876,   Sterling, VA 22170     |
+-----------------------------------------------------------------------+

-----------[000378][next][prev][last][first]----------------------------------------------------
Date:      23 Nov 89 16:01:59 GMT
From:      per@sics.se (Per Gunningberg)
To:        comp.protocols.tcp-ip
Subject:   Performance Measurement tool


                     A N N O U N C E M E N T

The release of SICS Protocol Implementation Measurement System tool,

                              SPIMS

Swedish Institute of Computer Science has released the research
prototype of SPIMS, a protocol performance measurement tool for
research and non-commercial use. A commercial version is distri-
buted by TeleLOGIC Uppsala AB, Sweden.

SPIMS is used to measure the performance of protocol and
"protocol-like" services including, response time (two-way de-
lay), throughput and the time to open and close connections. It
has been used to:
     * benchmark alternative protocol implementations
     * observe how performance varies when parameters in specific
     implementations have been varied, ie to tune parameters.

It is implemented on Unix, including SunOS 4., Unix BSD4.3, DNIX
(Unix System V, with extensions) and Ultrix 2.0/3.0. It runs as
user processes and requires a TCP-connection for measurement
set-up. No kernel modifications or any modifications to measured
protocols are required.

SPIMS currently has interfaces to the DoD Internet Protocols:
UDP, TCP, FTP, SunRPC, the ISO protocols from the ISODE 4.0 dis-
tribution package: FTAM, ROSE, ISO TP0 and to Sunlink 5.2 ISO TP4
as well as Stanford's VMTP. Also available are a rudimentary set
of benchmarks, stubs for new protocol interfaces and a user manu-
al.

Distribution

There are two different distribution classes depending on re-
questing organization:

     1.Universities and non-profit organizations.

     To these organizations, SPIMS source code is distributed
     free of charge. There are two ways to get the software:

          1. FTP. If you have an Internet FTP connection, you can
          use anonymous FTP to sics.se [192.16.123.90], and re-
          trieve the file in pub/spims-dist/dist890915.tar.Z
          (this is a .6MB tar image) in BINARY mode. Log in as
          user anonymous and at the password prompt, use your
          complete electronic mail address.

          2. On a Sun 1/4-inch cartridge tape. For mailing, a
          handling fee of US$150.00 will be charged. Submit a
          bank check with the request. Do not send tapes or en-
          velopes.

     2.Commercial organizations.

     There are two version to chose between, the research proto-
     type and a supported version for commercial use. The
     research prototype is for internal research only and for no
     commercial use whatsoever.

          Research prototype
          The SPIMS source code is distributed for a one time fee
          of US$500.00.  Organizations interested in the research
          prototype need to contact us via e-mail and briefly
          motivate why they qualify (non-commercial use) for the
          research prototype. They will thereafter get a permis-
          sion to obtain a copy from the same distribution source
          as for universities.

          Commercial version
          TeleLOGIC Uppsala AB, a subsidiary of Swedish Telecom,
          distributes and supports a version for commercial use.
          It consists of object code for SunOS 4., Unix BSD4.3,
          DNIX, and Ultrix 2.0/3.0. Support for other Unix-like
          implementations will be considered according to demand.
          The same interfaces to the DoD Internet and ISO proto-
          cols from the ISODE 4.0 are included as well as a user
          manual.


License

SPIMS is not in the public domain and the software is covered by
licenses. Use of the SPIMS software represents acceptance of the
terms and conditions of the licenses. The licenses are enclosed
in the distribution package. Licenses and SPIMS cover letter can
also be obtained via an Internet FTP connection without getting
the complete software. The retrieval procedure is identical to
the above university distribution via FTP. The file to retrieve
is pub/spims-dist/licenses.tar.Z

How SPIMS works

Measurements take place between processes over the measured pro-
tocol.  SPIMS generates messages and transfers them via the meas-
ured protocol service according to a user-supplied specification.
Unique in SPIMS is the measurement specification language which
is used to specify a measurement session. In the language there
are constructs for different application types (like bulk data
transfer), for specifying frequency and sequence of messages, for
distribution over message sizes and for combining basic specifi-
cations. These specifications are independent of both protocols
and protocol implementations and can be used for benchmarking.

More information

For more information about the research prototype distribution,
contact:

          Swedish Institute of Computer Science
          Att: Birgitta Klingenberg
          P.O. Box 1263
          S-164 28 Kista
          SWEDEN

          e-address: spims@sics.se
          Phone: +46-8-7521500, Fax: +46-8-7517230

For further information about SPIMS for the commercial user
please contact:

          Claes Hojenberg
          TeleLOGIC Uppsala AB
          P.O. Box 1218
          S-751 42 UPPSALA
          Sweden

          e-address: claes@uplog.se
          Phone: +46-18-189400, Fax: +46-18-132039

For more details on the internals of SPIMS, see:

          Nordmark & Gunningberg, "SPIMS: A Tool for Protocol Im-
          plementation Performance Measurements", Proc. of 13:th
          Conf. on Local Computer Networks, Minneapolis 1989, pp
          222-229.

How SPIMS can be used to benchmark protocols, see:

          Gunningberg, Bjorkman, Nordmark, Sjodin, Pink &
          Stromqvist, "Application Protocols and Performance
          Benchmarks", IEEE Communications Magazine, June 1989,
          Vol. 27, No.6, pp 30-36.

          Sjodin, Gunningberg, Nordmark, & Pink, "Towards Proto-
          col Benchmarks", IFIP WG6.1/6.4 Protocols for High-
          Speed Networks, May 1989, Zurich. To be published.

How SPIMS can be used when tuning protocols, see:

          Nordmark & Cheriton, "Experiences from VMTP: How to
          achieve low response time", IFIP WG6.1/6.4 Protocols
          for High-Speed Networks, May 1989, Zurich. To be pub-
          lished.

-----------[000379][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24 Nov 89 00:27 EST
From:      Dave Bachmann <dave@citi.umich.edu>
To:        tcp-ip@nic.ddn.mil
Subject:   Decrypting RFC 1125
If you're like me, you don't have a Postscript printer at home, but you also
don't want to wait until Monday to read the latest RFC, RFC1125.  Well, you're
in luck.  I finally decided "The heck with having an RFC I can't read!" and I
hacked up an awk script to decompile the Postscript in RFC 1125 into relatively
readable text form.  Of course, there were a few little details, like the back-
to-front printing of the document, which meant I got page 18 before page 17, 
and this weird business of representing "ff" by \013, "fi" by \014 and so on.
So, it's not the elegant script I had hoped for. But it works.  The script is
available for ftp on citi.umich.edu as pub/unps.awk.  You'll also want the file
cleanup.sed, which takes care of the \013 business, as well as parenthesis
quoting.  I'll also give these two at the end of this message, since they're
so short.  Warning: this is all very empirical, and full of magic numbers.  To
produce a useable file from rfc1125.ps, first do "awk -f unps.awk rfc1125.ps".
This will produce the files "page18" through "page9" and then die complaining
about only being able to write to 10 files.  So now do "awk -f unps.awk limit=8
rfc1125.ps", which tells unps.awk to skip any pages > 8. It now has produced
"page8" down to "page1". So now "cat page? page?? | sed -f cleanup.sed > 
rfc1125.txt" and you're done.  I've also put the result in pub/rfc1125.txt for
those who are impatient.
  After I had gotten this working I excitedly looked to see if it would work
for the other Postscript RFC's.  No such luck.  EVERY AUTHOR OF A POSTSCRIPT
RFC HAS USED A DIFFERENT PACKAGE.  In fact, the only RFC's that share a common
format are the NTP family.  Oh well.
  Here they are:
---------
unps.awk
---------
#	This script tries to decompile a Tek-produced Postscript document
#	and produce a file for each page.  This is necessary to handle
#	documents that print back-to-front.  Each page goes into a file
#	named "page<n>" where n is the page number.
#	There are a lot of magic numbers here.  Trial and error.
#
#	Track current page number
#	Specified as "<n> @bop1" where n is the new page number
#
$2 == "@bop1" { oline = 0
                pagenum = $1
                line = "" }
#
#	Since awk can only write out to 10 files, we need a way to
#	skip the first n pages before starting to write to files.
#	To process only pages prior to page x, invoke with "limit=x"
#
{ if (limit+0 > 0 && limit+0 < pagenum+0) next }
#
#	Lines of the form "<n> r (<string>) s" are moving n points right
#	and writing string.  I'm mapping a space to every 25 points, starting
#	at 5 and above.
#	Lines of the form "<n> r <m> c" are moving n points right and writing
#	the ascii character m.
#
$2 == "r" { dots = $1
            while (dots > 5) { dots = dots - 25
                              line = line " " }
	    if ($4 == "s") { token = $3
			     wordl = length(token) - 2
			     word = substr(token,2,wordl)
			     line = line word }
	    else line = line sprintf("%c", $3) }
#
#	Lines of the form "<x> <y> p <stuff>" are positioning to coordinates
#	x,y on the page and doing something.  If stuff ends in "ru" it's
#	drawing something, so ignore it.  Otherwise find out how much the
#	y coordinate has changed and map that to newlines.  I'm mapping a
#	line to every 48 points, starting at 30.  This is where we print out
#	the previous line that we've been building.
#
$3 == "p" { if ($6 == "ru") next
            ldiff = $2 - oline
            oline = $2
            while (ldiff > 29) { ldiff = ldiff - 48
                                 print line > "page" pagenum
                                 line = "" }
            if ($5 == "s") { token = $4
	                     wordl = length(token) - 2
	                     word = substr(token,2,wordl) 
	                     line = line word }
            if ($5 == "c") line = line sprintf("%c", $4) }
#
#	Sometimes it just writes a string without positioning.
#
$2 == "s" { token = $1
            wordl = length(token) - 2
            word = substr(token,2,wordl)
            line = line word }
#
#	Sometimes it just writes a character without positioning.
#
$2 == "c" { line = line sprintf("%c", $1) }
#
#	End of the page.  Print the previously built line, if any.
#
$1 == "@eop" {print line > "page" pagenum }
#
#	That's all.
---------
cleanup.sed
---------
s/\\013/ff/g
s/\\014/fi/g
s/\\015/fl/g
s/\\016/ffi/g
s/\\(/(/g
s/\\)/)/g
---------

Dave Bachmann                                   |  dave@citi.umich.edu
Center for Information Technology Integration   |  {mailrus,rutgers}!citi!dave
University of Michigan                          |  (313)998-7693 or 8-7479

P.S.  Happy Thanksgiving
-----------[000380][next][prev][last][first]----------------------------------------------------
Date:      23 Nov 89 20:33:52 GMT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   Re:  Smart filtering within a protocol on bridge/router?

... packet filtering ...  DEC LanBridges and such filter packets when you
don't want them to.  ARP packets for example, addressed to the broadcast
(all 1's) address get blocked by broken filterware in the LanBridges.

Does anyone know the why of this and the how of fixing.  My recommendation
is to trash these bogus active components and learn to live within the
ethernet specification.

Phil Wood, cpw@lanl.gov

-----------[000381][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24 Nov 89 01:50:07 EST
From:      Nick Gimbrone <NJG@CORNELLA.cit.cornell.edu>
To:        Clifford Dibble <centaure!cliff@uunet.uu.net>, tcp-ip@NIC.DDN.MIL
Subject:   Re: Seeking info on TCP/IP for IBM m/f
>In the article "OSI Takes on TCP/IP" (S.Fisher, UNIX World, Feb 1989),
>it is stated:
...
>	 ... IBM won't be shipping .. TCP/IP products until
>	 June 89."
That was only for the MVS based product.  VM/CMS has had an IBM TCP/IP
since mid-87.  They also have several unix offerings (which clearly
have tcp/ip, otherwise you couldn't really call it unix, eh?  :-).  In
any case, for further discusion of IBM's products see the IBMTCP-L mail
list at CUNYVM.CUNY.EDU, subscription by sending mail to
LISTSERV@CUNYVM.CUNY.EDU w/ the one line body/text of:
SUBscribe IBMTCP-L <your-name-here>
-----------[000382][next][prev][last][first]----------------------------------------------------
Date:      23 Nov 89 23:06:03 GMT
From:      GEustace@massey.ac.nz (Glen Eustace)
To:        comp.protocols.tcp-ip,comp.sys.pyramid
Subject:   Network Configuration Difficulties

Please excuse my ignorance, but we have been unable to work out how to
set things up. We have got D.Comer's book on networking and it didn't
help.

Here is a diagram of what we want to achieve;

+---------+               SLIP                 +----------+
| Pyramid | ---------------------------------- | PC #1    |
|  9815   | 130.123.100.1        130.123.100.2 +----------+
|         |               SLIP                 +----------+
|         | ---------------------------------- | PC #2    |
|         | 130.123.101.1        130.123.101.2 +----------+
|         |
|         | ---------------+
+---------+ 130.123.3.1    | ETHERNET          +----------+
                           +------------------ | Host 1   |
                           |     130.123.4.1   +----------+
                           |                   +----------+
                           +------------------ | Host 2   |
                           |     130.123.4.2   +----------+
                           |                   +----------+
                           +------------------ | PC-Route |
                                 130.123.5.1   | vers 2   |
                           +------------------ |          |
                           |     130.123.6.1   +----------+
                           |
                           | More hosts on 130.123.6

This is a cut down version of what we want but can't seem to work out how
to do.

We want to be able to run 10 SLIP lines from the Pyramid, interfaces sl0-sl9

We have two ethernet controllers but currently are only using one.

We want to isolate each of our laboratories with a PC running PC-Route
version 2 so that all traffic between the lab hosts and their server does
not flood the backbone.

We have a NIC registration for 130.123, can anyone help us with the above
situation.

--
  Glen Eustace, Software Manager, Computer Centre, Massey University,
   Palmerston North, New Zealand. Phone: +64 63 69099 x7440 GMT+12
             E-Mail via Internet: G.Eustace@massey.ac.nz
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

-----------[000383][next][prev][last][first]----------------------------------------------------
Date:      24 Nov 89 01:17:39 GMT
From:      eli@spdcc.COM (Steve Elias)
To:        comp.protocols.tcp-ip
Subject:   filtering / active ethernet components

cpw%sneezy@LANL.GOV (C. Philip Wood) writes:
>... packet filtering ...  DEC LanBridges and such filter packets when you
>don't want them to.  ARP packets for example, addressed to the broadcast
>(all 1's) address get blocked by broken filterware in the LanBridges.

	an up to date set of ROMs from DEC will fix this bug.

>Does anyone know the why of this and the how of fixing.  My recommendation
>is to trash these bogus active components and learn to live within the
>ethernet specification.

	my recommendation is to ignore your own recommendation, Phil!
	would you recommend living in a shoe, too?  
	ethernet's distance limits are a royal pain; 
	multimedia/ethernet brouterateways are very useful components!


-- 
 ... Steve Elias ; eli@spdcc.com ; 6179325598 ; {}
*disclaimer();  /* watch out for litigous pinheads!  		 */
                /* and: free email-->fax for boston destinations */

-----------[000384][next][prev][last][first]----------------------------------------------------
Date:      24 Nov 89 01:59:17 GMT
From:      enger@SCCGATE.SCC.COM (Robert M. Enger)
To:        comp.protocols.tcp-ip
Subject:   Re:  Smart filtering within a protocol on bridge/router?

The DEC LanBridge problem is an old one, isn't it?
The old firmware on LanBridges would "learn" the broadcast address
if it heard it, and add it to the "routing" table.  Unfortunately,
this was also the flag for the end-of-routing-table marker, so the
table stopped growing to boot!  (atleast these are my recollections)

DEC has supplied updated "firmware" with the bug fixed.  
There was considerable difficulty dealing with field service
(convincing them that a repair was called for, that the repiar
part number I gave them was real, etc, etc, etc).  They eventually
did fix our LanBridge 100s.  But then we went on to upgrade our
network, and replace LanBridges with P4200s.  Now, instead of
10,000 packets per second, we get 1000 :-)

If nothing else, when the LanBridges work, they're fast!

Bob

-----------[000385][next][prev][last][first]----------------------------------------------------
Date:      24 Nov 89 05:27:00 GMT
From:      dave@CITI.UMICH.EDU (Dave Bachmann)
To:        comp.protocols.tcp-ip
Subject:   Decrypting RFC 1125

If you're like me, you don't have a Postscript printer at home, but you also
don't want to wait until Monday to read the latest RFC, RFC1125.  Well, you're
in luck.  I finally decided "The heck with having an RFC I can't read!" and I
hacked up an awk script to decompile the Postscript in RFC 1125 into relatively
readable text form.  Of course, there were a few little details, like the back-
to-front printing of the document, which meant I got page 18 before page 17, 
and this weird business of representing "ff" by \013, "fi" by \014 and so on.
So, it's not the elegant script I had hoped for. But it works.  The script is
available for ftp on citi.umich.edu as pub/unps.awk.  You'll also want the file
cleanup.sed, which takes care of the \013 business, as well as parenthesis
quoting.  I'll also give these two at the end of this message, since they're
so short.  Warning: this is all very empirical, and full of magic numbers.  To
produce a useable file from rfc1125.ps, first do "awk -f unps.awk rfc1125.ps".
This will produce the files "page18" through "page9" and then die complaining
about only being able to write to 10 files.  So now do "awk -f unps.awk limit=8
rfc1125.ps", which tells unps.awk to skip any pages > 8. It now has produced
"page8" down to "page1". So now "cat page? page?? | sed -f cleanup.sed > 
rfc1125.txt" and you're done.  I've also put the result in pub/rfc1125.txt for
those who are impatient.
  After I had gotten this working I excitedly looked to see if it would work
for the other Postscript RFC's.  No such luck.  EVERY AUTHOR OF A POSTSCRIPT
RFC HAS USED A DIFFERENT PACKAGE.  In fact, the only RFC's that share a common
format are the NTP family.  Oh well.
  Here they are:
---------
unps.awk
---------
#	This script tries to decompile a Tek-produced Postscript document
#	and produce a file for each page.  This is necessary to handle
#	documents that print back-to-front.  Each page goes into a file
#	named "page<n>" where n is the page number.
#	There are a lot of magic numbers here.  Trial and error.
#
#	Track current page number
#	Specified as "<n> @bop1" where n is the new page number
#
$2 == "@bop1" { oline = 0
                pagenum = $1
                line = "" }
#
#	Since awk can only write out to 10 files, we need a way to
#	skip the first n pages before starting to write to files.
#	To process only pages prior to page x, invoke with "limit=x"
#
{ if (limit+0 > 0 && limit+0 < pagenum+0) next }
#
#	Lines of the form "<n> r (<string>) s" are moving n points right
#	and writing string.  I'm mapping a space to every 25 points, starting
#	at 5 and above.
#	Lines of the form "<n> r <m> c" are moving n points right and writing
#	the ascii character m.
#
$2 == "r" { dots = $1
            while (dots > 5) { dots = dots - 25
                              line = line " " }
	    if ($4 == "s") { token = $3
			     wordl = length(token) - 2
			     word = substr(token,2,wordl)
			     line = line word }
	    else line = line sprintf("%c", $3) }
#
#	Lines of the form "<x> <y> p <stuff>" are positioning to coordinates
#	x,y on the page and doing something.  If stuff ends in "ru" it's
#	drawing something, so ignore it.  Otherwise find out how much the
#	y coordinate has changed and map that to newlines.  I'm mapping a
#	line to every 48 points, starting at 30.  This is where we print out
#	the previous line that we've been building.
#
$3 == "p" { if ($6 == "ru") next
            ldiff = $2 - oline
            oline = $2
            while (ldiff > 29) { ldiff = ldiff - 48
                                 print line > "page" pagenum
                                 line = "" }
            if ($5 == "s") { token = $4
	                     wordl = length(token) - 2
	                     word = substr(token,2,wordl) 
	                     line = line word }
            if ($5 == "c") line = line sprintf("%c", $4) }
#
#	Sometimes it just writes a string without positioning.
#
$2 == "s" { token = $1
            wordl = length(token) - 2
            word = substr(token,2,wordl)
            line = line word }
#
#	Sometimes it just writes a character without positioning.
#
$2 == "c" { line = line sprintf("%c", $1) }
#
#	End of the page.  Print the previously built line, if any.
#
$1 == "@eop" {print line > "page" pagenum }
#
#	That's all.
---------
cleanup.sed
---------
s/\\013/ff/g
s/\\014/fi/g
s/\\015/fl/g
s/\\016/ffi/g
s/\\(/(/g
s/\\)/)/g
---------

Dave Bachmann                                   |  dave@citi.umich.edu
Center for Information Technology Integration   |  {mailrus,rutgers}!citi!dave
University of Michigan                          |  (313)998-7693 or 8-7479

P.S.  Happy Thanksgiving

-----------[000386][next][prev][last][first]----------------------------------------------------
Date:      24 Nov 89 06:50:07 GMT
From:      NJG@CORNELLA.CIT.CORNELL.EDU (Nick Gimbrone)
To:        comp.protocols.tcp-ip
Subject:   Re: Seeking info on TCP/IP for IBM m/f

>In the article "OSI Takes on TCP/IP" (S.Fisher, UNIX World, Feb 1989),
>it is stated:
 ...
>	 ... IBM won't be shipping .. TCP/IP products until
>	 June 89."
That was only for the MVS based product.  VM/CMS has had an IBM TCP/IP
since mid-87.  They also have several unix offerings (which clearly
have tcp/ip, otherwise you couldn't really call it unix, eh?  :-).  In
any case, for further discusion of IBM's products see the IBMTCP-L mail
list at CUNYVM.CUNY.EDU, subscription by sending mail to
LISTSERV@CUNYVM.CUNY.EDU w/ the one line body/text of:
SUBscribe IBMTCP-L <your-name-here>

-----------[000387][next][prev][last][first]----------------------------------------------------
Date:      24 Nov 89 15:40:02 GMT
From:      aruigrok@bnr.ca (Adrian C Ruigrok)
To:        comp.protocols.tcp-ip
Subject:   latest TN3270?

What is the state of the art in TN3270 for the Mac?  Where is it 
available.  What is the latest version.  I need a version that works with 
MacTCP; is there such an animal?  
Thanks in advance...
Adrian

aruigrok@bnr.ca

-------------------------------------------------------
Up to my ears in !@#$ and having a great time.

-----------[000388][next][prev][last][first]----------------------------------------------------
Date:      24 Nov 89 16:11:57 GMT
From:      chris@wugate.wustl.edu (Chris Myers)
To:        comp.protocols.tcp-ip
Subject:   Re: X windows source

In article <8911222307.AA28949@salt.acc.com> chris@SALT.ACC.COM (Chris VandenBerg) writes:
>Good afternoon,
>		I know this is the wrong place to ask about where the MIT X11R4
>stuff might be hiding but I'm hoping someone on this list might have a clue.
>I think I've logged on to every machine at MIT and still no luck! Anyway, if
>someone could point me in the right direction for the X11 stuff I would truly
>appreciate it (:*)

FTP to wuarchive.wustl.edu [128.252.135.4] and look in the directory
/packages/X.V11R3.  Wuarchive also has all of the comp.{sources,binaries}
groups, a large GIF archive, all of the GNU software, RFCs, IENs, and mirrors
on the MSDOS archives on SIMTEL20 and the INFO-MAC archives on sumex-aim...

The X11 stuff is compressed, tarred and split into 512K pieces.  There's a LOT
of it...

	336     /packages/X.V11R3/HC/Protocol
	674     /packages/X.V11R3/HC/Xlib
	1011    /packages/X.V11R3/HC
	10514   /packages/X.V11R3/contrib-1.src
	14754   /packages/X.V11R3/contrib-2.src
	11602   /packages/X.V11R3/core.src
	142     /packages/X.V11R3/fixes
	38112   /packages/X.V11R3
-- 
Chris Myers                                    Internet: chris@wugate.wustl.edu
Software Engineer                                  UUCP: ...!uunet!wugate!chris
Office of the Network Coordinator                    BITNET: chris@wunet.bitnet
Washington University in Saint Louis                     Phone: +1 314 362 6186

-----------[000389][next][prev][last][first]----------------------------------------------------
Date:      24 Nov 89 21:37:54 GMT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   Re:  filtering / active ethernet components

Steve,
	>multimedia/ethernet brouterateways are very useful components!
	
Except when they don't work.  Then it is up to some sophisticated
sluth to figure out what's wrong.  DEC sure won't tell you about
it.  And they (the sluth and DEC) will probably charge you to fix it!
	
Phil

-----------[000390][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24 Nov 89 21:44:01 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.sys.ibm.pc,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: The PC as a trusted client in a TCP/IP network

In article <907@cgch.UUCP> whna@cgch.UUCP (Heinz Naef) writes:
>what could be done to turn existing personal computers (industry standard)
>into real trusted clients on a TCP/IP network? ...

Rip out the boards.  Save the monitor, case, and power supply.  Put a
decent processor (with memory management) in, and run a decent operating
system (one that pays some attention to security).

Unless you construct an environment in which users cannot do any
programming at all -- difficult -- it can't be done with standard PCs.
-- 
That's not a joke, that's      |     Henry Spencer at U of Toronto Zoology
NASA.  -Nick Szabo             | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

-----------[000391][next][prev][last][first]----------------------------------------------------
Date:      24 Nov 89 23:06:17 GMT
From:      enger@sccgate.scc.com (Robert M. Enger)
To:        comp.protocols.tcp-ip
Subject:   Re:  filtering / active ethernet components

regarding LanBridge 100 sleuthing (trouble shooting):
I belive DEC offers a LanBridge remote monitoring and control program.
However, I belive it only runs on their DECnet-speaking VMS machines.

In principal anyway, such a program should make it a lot easier
to figure out whats broken.

Bob

-----------[000392][next][prev][last][first]----------------------------------------------------
Date:      25 Nov 89 00:34:25 GMT
From:      sob@harvisr.harvard.edu (Scott Bradner)
To:        comp.protocols.tcp-ip
Subject:   hammer & anvil

We have gotten a number of requests for the source code for the hammer
& anvil programs that we used in the router tests posted a while back.
There are now copies of the programs in pub/eutil on husc6.harvard.edu.
These programs were created by Dan Lanciani using PCIP as a starting point.

(Please don't ask for copies of the tests again, there is a copy 
husc6.harvard.edu in pub/rtests)


Scott

-----------[000393][next][prev][last][first]----------------------------------------------------
Date:      25 Nov 89 14:59:04 GMT
From:      eli@spdcc.COM (Steve Elias)
To:        comp.protocols.tcp-ip
Subject:   Re:  filtering / active ethernet components

cpw%sneezy@LANL.GOV (C. Philip Wood) writes:
>i wrote:
>	>multimedia/ethernet brouterateways are very useful components!
>	
>Except when they don't work.  Then it is up to some sophisticated
>sluth to figure out what's wrong.  DEC sure won't tell you about
>it.  And they (the sluth and DEC) will probably charge you to fix it!

	major bug fixes should always be free.  
	anything less is a corporate wimp-out!  

	i'm not sure of DEC's policy, but i have
	enough respect for them to assume that they either provide free
	majorbug fixes, and that they won't threaten to sue me for saying
	that they should provide them...
-- 
 ... Steve Elias ; eli@spdcc.com ; 6179325598 ; { *disclaimer(); }
                

-----------[000394][next][prev][last][first]----------------------------------------------------
Date:      25 Nov 89 19:13:46 GMT
From:      dchou@NCoast.ORG (David Chou)
To:        comp.protocols.tcp-ip
Subject:   Re: Does Data-General under AOS/VS use TCP-IP

Data-General under AOS/VS version 7.xx does support a very primitive
version of TCP-IP.  We just installed the software and have not tried
all features, but most noticeably absent is the support for any cursor
addressing support for terminals under telnet.  Only dumb ttys are
supported and this seems to cause us problems when trying to use most
conventional screen editors.  Sales people have told us that screen
support will be available under the VS2 version (new version of AOS/VS)
which we are unlikely going to adopt due to upgrade costs.  Although
we do not have any experience yet, we have been warned that the AOS/VS
is rather inefficient and consumes larger cpu resources than usual
terminal activities.

David Chou
                     ncoast!dchou@hal.cwru.edu
                     ncoast!dchou@cwjcc.cwru.edu

-----------[000395][next][prev][last][first]----------------------------------------------------
Date:      25 Nov 89 19:53:52 GMT
From:      stullich@quando.UUCP (Thomas Stullich)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.periphs.printers
Subject:   Re: Anybody know of an enet/TCP printer?

We use some HP-Laserjet over LAN (TCP/IP) via Terminalserver. We also
have an interface which you can append to /usr/spool/lp/interface/* (on
UNIX-Systems), so the printer-scheduler has not to be modified.
costs for terminalserver with 6 RS232-Ports: about 2500 $

-- 
Thomas Stullich UUCP: {backbone}!unido!quando!stullich OR stullich@quando.uucp
  Quantum GmbH  Bitnet: UNIDO!quando!stullich OR stullich%quando@UNIDO(.bitnet)
    Dortmund    internet: stullich%quando%mcvax.UUCP@cwi.nl
    Germany     internet: stullich%quando%UNIDO.bitnet@mitvma.mit.edu

-----------[000396][next][prev][last][first]----------------------------------------------------
Date:      26 Nov 89 06:44:10 GMT
From:      mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re: Remote "cat" during ftp connection

WIN/TCP also supports "get filename -" construct for the VMS world.

Merton

-----------[000397][next][prev][last][first]----------------------------------------------------
Date:      27 Nov 89 00:05:33 GMT
From:      RAF@CU.NIH.GOV ("Roger Fajman")
To:        comp.protocols.tcp-ip
Subject:   X.400 support for file transfer

With regard to recent discussions about store and forward file
transfer, the following suggests that there is some question about
X.400 support for arbitrary files as part of a message.  Any comment?

Roger Fajman

== Forwarded Mail ==

Date: 20 Nov 89 18:25 +0100
Sender: "North American MHSNEWS Distribution List"
       <mhsnews-request@tis.llnl.gov>
From: JPALME@com.qz.se
To: MHS news distribution list <mhsnews@vax.runit.unit.uninett>
Reply-To: Jacob Palme QZ <JPALME@com.qz.se>
Subject: Notes from the CCITT X.400 group meeting in November 1989

>X-Originator: Jacob Palme QZ <JPALME@com.qz.se>

Notes from the CCITT X.400 group meeting in November 1989
---------------------------------------------------------

These are my personal notes, not official minutes.

The CCITT rapporteaur group Q.18/VII met for its first meeting
with technical work during the 1989-1992 study period in Rhodes,
Greece in November 1989.

(text deleted)

File transfer
-------------

The possibility of file transfer in X.400 is investigated. By
"file transfer" is meant the carrying of computer programs,
Spreadsheet worksheets etc in IPM or in new content types.

(text deleted)


Date: 20 Nov 89 16:47 +0100
Sender: "North American MHSNEWS Distribution List"
       <mhsnews-request@tis.llnl.gov>
From: "Johan Lundberg TeleDelta (Swedish Telecom)"
 <JOHANL%com.qz.se@cunyvm.cuny.edu>
Subject: WKS files as externally-defined body parts
To: MHS news distribution list <mhsnews@vax.runit.unit.uninett>,
        MHSNEWS
 Distribution List <mhsnews@tis.llnl.gov>,
        philf@xymox.metaphor.com
Reply-To: "Johan Lundberg TeleDelta (Swedish Telecom)"
 <JOHANL%com.qz.se@cunyvm.cuny.edu>

I know that NIST in US has an agreement to use the body part
bilaterlly defined to transfer binary data. Severla implementor
already support this. Of course there is a drawback; you can
not distinguish between different types of binary files. If you
intend to automate something i would go for a externally defined
body part. The problem is of course that there are noone that
care about registering OBJECT IDENTIFIERS.
One solution wold be to register your own and use that.

Johan Lundberg, TeleDelta Sweden

-----------[000398][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27 Nov 89 12:37:35 -0500
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        tcp-ip@nic.ddn.mil
Subject:   Internet Resource Guide -- Call for Submissions

For the past several months, the NSF Network Service Center has been in
the process of compiling and publishing (on-line) a guide to various
resources available on the Internet.  We are currently trying to expand
selected sections of the guide.

In this note I'd like to enlist people's help locating managers of
computer centers which offer special computing facilities (e.g. supercomputers,
parallel processors, etc.) to Internet users and are not currently listed in
the guide.  The guide currently includes information on the following
centers:

	Air Force Supercomputer Center at Kirtland AFB ........  1.1
	Center for Theory and Simulation in Science and Engineering
	  (Cornell National Supercomputer Facility) ...........  1.2
	John von Neumann National Supercomputer Center ........  1.3
	National Center for Atmospheric Research ..............  1.4
	National Center for Supercomputing Applications .......  1.5
	National Magnetic Fusion Energy Computer Center .......  1.6
	Northeast Parallel Architectures Center ...............  1.7
	Ohio Supercomputer Center .............................  1.8
	Pittsburgh Supercomputing Center ......................  1.9
	San Diego Supercomputer Center ........................ 1.10
	US Army Ballistic Research Laboratory ................. 1.11
	University of California at Berkeley .................. 1.12
	SuperComputing Services, The University of Calgary .... 1.13
	Center for Experimental Research in Parallel Algorithms,
	  Software and Systems (CERPASS) ...................... 1.14

If you are aware of a specialized computing facility which is not
listed here, please either tell us (at resource-guide@nnsc.nsf.net)
who to contact at that site, or forward this note to someone at the
site.

Thanks!

Craig Partridge
Director, NNSC Technical Services

PS: If you are interested in a copy of the resource guide, postscript
and text versions can be ftp'ed from nnsc.nsf.net:resource-guide/*


	TEMPLATE FOR SUBMISSIONS TO THE INTERNET RESOURCE GUIDE

(1)  Name of Resource

(2)  USPS Address

(3)  Email Address 

     please use a general or central address     

(4)  Phone Number

     please use a central phone number
     
     (additional phone numbers may be listed at end)

(5)  Description of Resource

     please describe the computing resources which makes your center
     of interest to users (special computing hardware, etc.)

(6)  Network Access

     how to reach your systems from the Internet (e.g. telnet to
     front-end machines; tn3270 to the machine itself).

(7)  Who Can Use the Resource/Restrictions

     please give some general guidelines  (e.g. US Govt. users only;
     anyone who can write a check; persons doing research in a particular
     field)

(8)  Miscellaneous Information

     additional phone numbers

     names of individuals if appropriate
-----------[000399][next][prev][last][first]----------------------------------------------------
Date:      27 Nov 89 11:50:11 GMT
From:      wisner@hayes.fai.alaska.edu (Bill Wisner)
To:        comp.protocols.tcp-ip
Subject:   tcpdump for Sun SPARCstation?

The Subject header pretty much says it: has anybody made tcpdump work
on a Sun SPARCstation-1 (or, for that matter, a 4/260)?

-----------[000400][next][prev][last][first]----------------------------------------------------
Date:      27 Nov 89 16:16:43 GMT
From:      guri@oakhill.UUCP (Gurvinder Singh Ahluwalia)
To:        comp.protocols.tcp-ip
Subject:   Re: Source for BFTP (RFC1068) Available?

In article <6260@inco.UUCP> mack@inco.UUCP (Dave Mack) writes:
>
>Do any of you know of any public domain implementations of
>Background FTP? I need one semidesperately.
>

	.... ME TOO. Dave, please let me know if you get someones response
	through email that I cannot catch.

	Gurvinder Ahluwalia
	Motorola Networking & Computing Systems
	UUCP	: oakhill!apogee!guri@cs.utexas.edu
	Phone	: (512)891-3310

-----------[000401][next][prev][last][first]----------------------------------------------------
Date:      27 Nov 89 17:37:35 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   Internet Resource Guide -- Call for Submissions


For the past several months, the NSF Network Service Center has been in
the process of compiling and publishing (on-line) a guide to various
resources available on the Internet.  We are currently trying to expand
selected sections of the guide.

In this note I'd like to enlist people's help locating managers of
computer centers which offer special computing facilities (e.g. supercomputers,
parallel processors, etc.) to Internet users and are not currently listed in
the guide.  The guide currently includes information on the following
centers:

	Air Force Supercomputer Center at Kirtland AFB ........  1.1
	Center for Theory and Simulation in Science and Engineering
	  (Cornell National Supercomputer Facility) ...........  1.2
	John von Neumann National Supercomputer Center ........  1.3
	National Center for Atmospheric Research ..............  1.4
	National Center for Supercomputing Applications .......  1.5
	National Magnetic Fusion Energy Computer Center .......  1.6
	Northeast Parallel Architectures Center ...............  1.7
	Ohio Supercomputer Center .............................  1.8
	Pittsburgh Supercomputing Center ......................  1.9
	San Diego Supercomputer Center ........................ 1.10
	US Army Ballistic Research Laboratory ................. 1.11
	University of California at Berkeley .................. 1.12
	SuperComputing Services, The University of Calgary .... 1.13
	Center for Experimental Research in Parallel Algorithms,
	  Software and Systems (CERPASS) ...................... 1.14

If you are aware of a specialized computing facility which is not
listed here, please either tell us (at resource-guide@nnsc.nsf.net)
who to contact at that site, or forward this note to someone at the
site.

Thanks!

Craig Partridge
Director, NNSC Technical Services

PS: If you are interested in a copy of the resource guide, postscript
and text versions can be ftp'ed from nnsc.nsf.net:resource-guide/*


	TEMPLATE FOR SUBMISSIONS TO THE INTERNET RESOURCE GUIDE

(1)  Name of Resource

(2)  USPS Address

(3)  Email Address 

     please use a general or central address     

(4)  Phone Number

     please use a central phone number
     
     (additional phone numbers may be listed at end)

(5)  Description of Resource

     please describe the computing resources which makes your center
     of interest to users (special computing hardware, etc.)

(6)  Network Access

     how to reach your systems from the Internet (e.g. telnet to
     front-end machines; tn3270 to the machine itself).

(7)  Who Can Use the Resource/Restrictions

     please give some general guidelines  (e.g. US Govt. users only;
     anyone who can write a check; persons doing research in a particular
     field)

(8)  Miscellaneous Information

     additional phone numbers

     names of individuals if appropriate

-----------[000402][next][prev][last][first]----------------------------------------------------
Date:      27 Nov 89 18:12:39 GMT
From:      phil@delta.eecs.nwu.edu (William LeFebvre)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.periphs.printers
Subject:   Re: Anybody know of an enet/TCP printer?

In article <1989Nov7.210143.26795@t2ns1.gcs.co.nz> brian@t2ns1.gcs.co.nz writes:
>Has anybody ever come across a printer hanging directly off a thick
>enet transceiver? We have a situation here where such a printer would
>be invaluable. Obviously it would need appropriate intelligence to
>handle addresses, domains etc. with it's card.

YES!  QMS/Imagen sells printers that sit DIRECTLY on the ethernet.
There is *NO* ethernet/parallel box sitting inbetween!  The one that I
am familiar with is the Imagen 2308.  It is the standard Canon LBP-CX
engine.  It comes with a separate processor box and, as an option, you
can get a 3-com ethernet card to go in the box (this option also comes
with the appropriate printer software to speak TCP and UDP).  We had
two of these when I was a Rice and they worked wonderfully well.  The
only downside is the price.  They are, compared to most laser
printers, very expensive (on the order of $10,000).  They don't come
with postscript, but you can get "UltraScript" as an option.

The combination of ethernet, imPress (a compact printer language), and
multiprocessors (the 2308 has 3 separate 68000 processors in it) make
it a very fast laser printer.  Unless you're printing a LARGE bitmap
or alot of vectors in Tektronix mode, the printer itself is always the
bottleneck---the page processing is always ahead of the printing.

		William LeFebvre
		Department of Electrical Engineering and Computer Science
		Northwestern University
		<phil@eecs.nwu.edu>

-----------[000403][next][prev][last][first]----------------------------------------------------
Date:      27 Nov 89 18:35:09 GMT
From:      deschon@VENERA.ISI.EDU (Annette DeSchon)
To:        comp.protocols.tcp-ip
Subject:   Re: Source for BFTP (RFC1068) Available?

The source for BFTP is available via anonymous FTP, from the
"pub/" directory on venera.isi.edu.  The compressed tar-file
is "BFTP.211.tar.Z". 

(Note that the version number may change occasionally as new
features or bug fixes are added.)

Annette DeSchon

-----------[000404][next][prev][last][first]----------------------------------------------------
Date:      27 Nov 89 19:39:20 GMT
From:      don@CAD.USNA.MIL ("Donald W. Garner", 890118;CADIG)
To:        comp.protocols.tcp-ip
Subject:   Re:  Source for BFTP (RFC1068) Available?

Contact Annette DeSchon <deschon@venera.isi.edu for BFTP.

-----------[000405][next][prev][last][first]----------------------------------------------------
Date:      27 Nov 89 20:32:51 GMT
From:      bin@primate.wisc.edu (Brain in Neutral)
To:        comp.protocols.tcp-ip
Subject:   Re: Source for BFTP (RFC1068) Available?

From article <2660@apogee.oakhill.UUCP>, by guri@oakhill.UUCP (Gurvinder Singh Ahluwalia):
> In article <6260@inco.UUCP> mack@inco.UUCP (Dave Mack) writes:
>>
>>Do any of you know of any public domain implementations of
>>Background FTP? I need one semidesperately.

Try anon ftp to isi.edu (a.k.a. venera.isi.edu, [128.9.0.32]), in ~ftp/pub.

Paul DuBois
dubois@primate.wisc.edu

-----------[000406][next][prev][last][first]----------------------------------------------------
Date:      27 Nov 89 21:27:29 GMT
From:      mf12605@msi-s9.msi.umn.edu
To:        comp.os.vms,comp.protocols.tcp-ip,comp.unix.questions
Subject:   UNIX vs. VMS Internet connectivity


*** NOTE: this is being posted from my brother's account; please ***
***     respond by mail to NBEHR@ECNCDC.BITNET (Eric Behr)       ***

Here is my original question re. hooking up to Internet, followed
by a summary of responses. My deepest thanks to everyone who replied.
 
> Definition: "useful (Internet) software" means anything which
> would permit file transfers a la ftp, access to news, rlogins,
> equivalent of "talk", as well as other "connectivity" stuff
> found in an average Unix system.
>  
> - can an IBM mainframe run "useful software" without much pain? or
> do we need to get connected to a Vax or something similar?
>  
> - is VMS handicapped, as far as "useful software" goes, compared
> to Unix? If so, in what way?
>  
> - is there any favorite networking method to be used locally?
> everywhere I've been before, Ethernet was the standard; here, a
> "mafia" of sorts is pushing a token ring LAN; any concrete arguments
> against it?
 
================================================================================

 +1  Date:    Fri, 10 Nov 1989 11:06
     From:    Chris Petersen - VUCC <PETERSEN@vuctrvax> 
Subject: RE: Internet connectivity...
To: nbehr@ECNCDC.BITNET
X-VMS-To: IN%"nbehr@ecncdc.bitnet"
 
    I can only comment on my experience here at Vanderbilt University, but
this is what I think...
 
> Definition: "useful (Internet) software" means anything which
> would permit file transfers a la ftp, access to news, rlogins,
> equivalent of "talk", as well as other "connectivity" stuff
> found in an average Unix system.
 
     At Vanderbilt, we are using the TCP/IP package from CMU/Tektronics to
connect to the Internet.  We're using PMDF (Pascal Mail Distribution Facility)
from Innosoft to connect VMS Mail to the Internet software.  This has not
(to my knowledge) caused any problems to date, and it seems to work quite
well.  There are network mailing lists for both of the non-DEC products I
mentioned above.
 
    As far as I can tell, CMU/Tek does not come with a 'talk' substitute.  I
had to write one for a networks class (on a Sun), and it wasn't that bad, so
I may write one for VMS sometime soon.  CMU/Tek does come with the standard
FTP, Telnet (analogous to rlogin), SMTP (simple mail transfer protocol), and
I think finger.  You can get ANU-News (by Geoff Huston) for free across the
network if you want to store news locally (Geoff is at Australian National U.)
or a package from (I think) RPI which will allow you to NNTP to a convenient
server.
 
    In short, there is quite a bit of software out there if you look for it
(and some of it is even free!).
 
> - can an IBM mainframe run "useful software" without much pain? or
> do we need to get connected to a Vax or something similar?
 
    I really don't know the answer to that...
 
> - is VMS handicapped, as far as "useful software" goes, compared
> to Unix? If so, in what way?
 
    Yes and no.  UNIX (some UNIXes, I guess) come with definitions for sockets
and such like which are not built into the VAX definitions...  This makes
programming Internet stuff on UNIX a little easier, but for the knowledgable,
VMS should be almost as good.
 
> - is there any favorite networking method to be used locally?
> everywhere I've been before, Ethernet was the standard; here, a
> "mafia" of sorts is pushing a token ring LAN; any concrete arguments
> against it?
 
    Personally, I would go with a TCP/IP-based Ethernet.  This would allow
you to put everything on the Internet almost directly (gateway from WAN to
LAN would be in the VAX, I suppose) and with only a single protocol.  That
is if you are starting now.  If you already have LANs in place, you might
want to think about bridging them and then considering how to get them
access to the big network...
 
-Chris Petersen
 Vanderbilt University Computer Center
 Petersen@ctrvax.Vanderbilt.EDU
 Petersen@vuctrvx1.Bitnet
 
Disclaimer:  These are not necessarily the views of my employer, nor do I
guarantee them to be in any way factual.  They are opinions and should,
therefore, be taken with a large grain of salt.

--------------------------------------------------------------------------------
From mark@asngat.asn.net Fri Nov 10 11:03:16 1989
Received: from umn-cs.cs.umn.edu by s1.msi.umn.edu; Fri, 10 Nov 89 11:03:11 CST
Received: from asngat.asn.net by umn-cs.cs.umn.edu (5.59/1.14)
id AA16803; Fri, 10 Nov 89 11:02:49 CST
Message-Id: <8911101702.AA16803@umn-cs.cs.umn.edu>
Date: 10 Nov 89 10:59:00 CST
From: "Mark Preston" <mark@asngat.asn.net>
Subject: RE: UNIX vs. VMS Internet connectivity
To: "msi-s9.msi.umn.edu!mf12605" <msi-s9.msi.umn.edu!mf12605@umn-cs.cs.umn.edu>
 
 
For the VAX running VMS you will need to get TCP/IP
from a third party. DEC can get you information on these companies
since they have a marketing agreements with them. One
is Wollongong  and the other is FUSION. Both have advantages/disadvantages
, you will have to look at them and pick which best suits your
needs. We run Wollongong's. It includes telnet, ftp, smtp, tftp,
named, finger, rlogin, and other protocols that we have disabled.
The VAX does not support token ring, unless you find something
from a third party vendor. The problem with Token ring is that
the machine still has to forward the packet even if it is
 
the machines must forward all packets that are not targeted to
itself. That takes cpu cycles away. In a LAN it grabes the
packed that is address to it only. All other packet are ignored.
That is just the basics, the are other advantages/disadvantes
like you ring may die completely if one node in the ring
drops out.
 
Mark.
 
--------------------------------------------------------------------------------
     Date:    Fri, 10 Nov 1989 16:42
     From:    <davy@itstd.sri.com>
Subject: internet
Date: Fri, 10 Nov 89 14:04:26 PST
From: davy@itstd.sri.com
 
 
Call IBM.  Assuming your running VM/CMS (and maybe by now even MVS),
they have a TCP/IP product.  It actually works pretty well; we
used it when I was at Purdue.  Telnet and FTP are there, and
mail works.
 
--Dave

--------------------------------------------------------------------------------
     Date:    Fri, 10 Nov 1989 18:18
     From:    "Mark H. Wood" <IMHW400@INDYVAX.BITNET>
     Subject: Re:  UNIX vs. VMS Internet connectivity

Received: From <MAILER@INDYVAX> for <NBEHR@ECNCDC>
          via RSCS by ECNCDC; Fri, 10 Nov 1989 18:18 CST
Date: Fri, 10 Nov 89 15:18 EST
From: "Mark H. Wood" <IMHW400@INDYVAX.BITNET>
Subject: Re:  UNIX vs. VMS Internet connectivity
To: NBEHR@ECNCDC.BITNET
X-VMS-To: IN%"NBEHR@ECNCDC"
 
>- can an IBM mainframe run "useful software" without much pain? or
>do we need to get connected to a Vax or something similar?
 
I don't handle the IBM gear here, but our 4381s run Telnet, SMTP, and FTP
fairly well and give domain name service.  The nameserver seems to require a
database (we use SQL/DS).  There was some trouble getting it set up but we are
all still new to the IP world here.  I don't know whether there is a newsreader
for it and I don't know for sure what "talk" is.
 
I'd think that you would want all of your machines on the network, but of
course I don't know your situation.  Most VMS IP packages offer Telnet, FTP,
TFTP, rlogin etc, FINGER, PING, and SMTP.  More and more also have an NFS
option.  There are public-domain packages such as ANU News to fill the gaps.
 
If you expect much traffic at all, you might want to get a separate box just
for routing.  We connect to Internet via a cisco AGS on our Ethernet.
 
>- is VMS handicapped, as far as "useful software" goes, compared
>to Unix? If so, in what way?
 
Not really; see above.  One thing you didn't mention is lpr, which is kind of
rare among VMS IPs but catching on fast.
 
>- is there any favorite networking method to be used locally?
 
We have thick, thin, twisted-pair, and broadband Ethernet at various places
around the campus.  We are now trying to nail a token ring onto the network but
Ethernet is the backbone.  I personally object to T-R for several reasons:
 
o       the Ethernet cable plant is very simple and rugged; the T-R cable plant
        includes MAUs, which are complex active devices usually located in
        stuffy closets and requiring power supplies of their own (I think).
        Ethernet just seems much less fragile, to me.
 
o       T-R seems to require central administration and control; Ethernet
        allows this but doesn't enforce it.
 
o       There is still no way to fit it to my BI-bus VAX.
 
o       Ethernet campaigns on its record, but T-R seems to advance itself
        mainly through mudslinging, IMHO.
 
o       I'm biased against anything pushed by IBM.  :-P
 
Good luck!  You're embarked on an interesting project.
 
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Mark H. Wood    IMHW400@INDYVAX.BITNET   (317)274-0749 III U   U PPPP  U   U III
Indiana University - Purdue University at Indianapolis  I  U   U P   P U   U  I
799 West Michigan Street, ET 1023                       I  U   U PPPP  U   U  I
Indianapolis, IN  46202 USA                             I  U   U P     U   U  I
[@disclaimer@]                                         III  UUU  P      UUU  III

--------------------------------------------------------------------------------
     Date:    Sat, 11 Nov 1989 10:08
     From:    "Karsten Nyblad, TFL" <KARSTEN@tfl.dk> 
     Subject: RE: UNIX vs. VMS Internet connectivity

Received: From <MAILER@NEUVM1> for <NBEHR@ECNCDC>
          via RSCS by ECNCDC; Sat, 11 Nov 1989 10:08 CST
X-Delivery-Notice:  SMTP MAIL FROM does not correspond to sender.
Received: from NEUVM1 (SMTP) by vm.uni-c.dk (Mailer R2.03B) with BSMTP id 3035;
 Sat, 11 Nov 89 17:02:05 DNT
Received: from danpost.uni-c.dk by vm.uni-c.dk (IBM VM SMTP R1.2) with TCP; Sat,
 11 Nov 89 17:02:03 DNT
Received: from vms9.uni-c.dk by danpost.uni-c.dk (5.61/4.7)
id AA12734; Sat, 11 Nov 89 16:02:26 GMT
Message-Id: <8911111602.AA12734@danpost.uni-c.dk>
Received: from tfl.dk by vms9.uni-c.dk; Sat, 11 Nov 89 17:01 GMT+1
Date: Sat, 11 Nov 89 17:00 +0100
From: "Karsten Nyblad, TFL" <KARSTEN@tfl.dk>
Subject: RE: UNIX vs. VMS Internet connectivity
To: NBEHR@ECNCDC.BITNET
X-Vms-To: in%"NBEHR@ECNCDC.BITNET"
 
Dear Eric,
 
Here are some answers on on your posting to the info-vax mailing list.
I have attached a list of common domain software for VMS to the mail.
There are several vendors selling TCP/IP for VMS.  I think
the most videly used news program is ANU-NEWS (see the
attached list of programs).
 
   Digital sells VMS ULTRIX connection.  This lacks most
   commands like the rcommands (rlogin,rsh,...)  The version
   1.2 does not even include SMTP, i.e., the internet mail
   protocol.  It can only communicated through ethernet.
   Digital has plans for implementing a full set of
   commands, but they can't deliver now.
 
   CMU-TEK TCP/IP (see attached address).  It contains the
   basic TCP/IP commands (telnet,ftp,smtp,...) It contains
   support for remote printing, i.e., other computers
   printing on the VAX/VMS's printers, and the VAX/VMS
   printing on other computers printers.  Advange: it is
   cheap.
 
   Wollongong.  They have got a full TCP/IP, including
   support for ethernet and synchronious lines.  There
   user interface is UNIX like.  Address:
        The Wollongong Group, Inc.
        1129 San Antonio Road
        Palo Alto, Ca 94303
        (415) 962-7100
 
   Novell/excelan.  I do not know much about them, but they
   might have what you want.  Novell/excelan is a merge of
   Novell, which is one of the largest PC LAN vendors, and
   Excelan, which have god implementations of TCP/IP.
 
   Multinet.  I know notthing but the name.
 
You should give the last three a try.
 
There as you see several vendors providing TCP/IP, so you
can't say VMS is handicapped with respect to TCP/IP, if that
is what you call usefull software.  TCP/IP is the
network protocols implementing networking on UNIX.  However,
DECNET is to VAX/VMS what TCP/IP is to UNIX.  There is not
as much god common domain software available for VMS as for
UNIX.
 
The advantage of using ethernet is that a lot of protocols
can coexist on the same network.  That means that you can
use the protocol you fill is best suited for a given task.
That is an advantage if you connect machines from different
vendors.  On our ethernet we use TCP/IP for communication
between VMS, MS-DOS and UNIX, DECnet between VMS and UNIX,
and a MicroSOFT protocol sold under the name PCSA by Digital
for MS-DOS <-> VMS communication.  I guess IBM will claim
that token ring is the best with respect to performance, and
the (many) vendors of ethernet, that ethernet is the best.
By the way, can you connect a VAX/VMS to a token ring
network?  Novell has god networking software for PCs.  There
software works best on ethernet, and I think they have a
larger market share than IBM...   When buying networking
software for PCs you should look for software, that can be
removed from the main storage of the PC, since many programs
common in university world needs all 640k of storage.
 
Karsten Nyblad
TFL, A Danish Telecommmunication Research Laboratory
E-mail: karsten@tfl.dk
 
 
>I keep reading about the CMU-TEK TCP/IP package. The impression I get is that
>it is either free- or cheapware. We would like to evaluate it, but don't know
>how to get the package. Could some kind soul provide details, either to me or
>to the 'net?
 
It's cheapware and worth more than it costs.  Contact:
Lynne.Stonis@VM.CC.CMU.EDU  or
 
                        Carnegie Mellon University
                        CMU-TEK Software
                        4910 Forbes Avenue
                        Pittsburgh, PA 15213-3890
                        Attention Lynne Stonis
 
        Costs:
 
                Media, documentation and US mail !125.00
                TK50s                        Add ! 25.00
                Purchase orders              Add ! 25.00
                International orders         Add ! 50.00
 
     Note that support for the package is limited.  There is a mailing list
for the package.  Send postings to CMU-TEK-TCP@CS.CMU.EDU and administrivia
to CMU-TEK-TCP-REQUEST@CS.CMU.EDU.
 
 
*******************************************************************************
 
                        The VAX Programs List
 
                                                (last updated:  20 July, 1989)
 
The following programs are available as described below.  If you have additions
or corrections to make, please contact me at RIC@RML2.SRI.COM.  Please
submit ALL applications-specific questions to the originators of the codes.
Availability codes are at the end of the list.
 
NOTE:   A current version of this file may be retreived by sending a ONE LINE
        mail message to:  NETSERVER@RML2.SRI.COM.  The one line should say:
        ?PACKAGE*VAX_LIST
 
NOTE 2: Many people cannot access files via FTP.  It would be nice if more
        sites obtained VMSSERV and/or NETSERVER and helped distribute some
        of these utilities.
 
ANU NEWS        A news program for VMS.  For the usenet system of news msgs.
                Get 000_readme.ascii first.  (1)  See also NNTP_NEWS and UUCP.
                Availability:   F1, D1
 
BECOME          Allows you to "become" another user, if you're privileged.
                Availability:   S10
 
BOSS            Allows user to run several interactive processes at once.
                Availability:   E1
 
BULLETIN        Bulletin board SW for VMS systems.
                Availability:   S1
 
DOE-MACSYMA     Symbolic math package with numeric and plotting capabilities.
                Availability:   M1 (cost for media and distribution, etc.).
 
DVIDIS          Utility to allow previewing of DVI files on VAX workstations
                using VWS (not DECwindows).  Get DVIDIS.A and fixrec.exe
                and/or fixrec.c.  Use fixrec to modify backup record size.
                Use binary mode FTP on DVIDIS.A and fixrec.exe.
                Availability:   F18
 
DVI drivers     Converts DVI files to formats that various printers can use.
                Availability:   F2
 
DVI2PS          Converts DVI (usually TEX or graphic) output to Postscript.
                Availability:   F3 (1)
 
ETAPE           EBCDIC-ASCII tape reader-writer.
                Availability:   S8
 
FILE            Changes attributes of a file.
                Availability:   S5
 
FIND            Searches through index file of a disk to locate a file
                matching specific conditions.
                Availability:   S5
 
FINGER          Utility to provide info about users on local or remote systems.
                Availability:   S2, S3, F10, S10
 
GNU Emacs       Popular screen-oriented editor.  Runs on a variety of
                computers.  Developed at MIT.
                Availability:   F4, F5 (COMPRESSED VMS-BACKUP FILE), F6
                MG, formerly MicroGnuEmacs, is a smaller version of
                GNU emacs, and is available from: F17 (in pub/mg2a.tar.Z).
                Versions for VMS, UNIX, Amiga, and MSDOS may be available.
                A VMS backup saveset is available at: F10 (VMSD only).
                You may also need reblock.exe to fix backup record size.
 
GNU C           C compiler for VMS and other computers.  ANSI plus extensions.
                Compatible with other VAX languages, but no VMS debugger
                records produced.  GNU debugger (GDB) can be used for this.
                Availability:   F4 (1), F7
 
KERMIT          Popular file transfer utility.  Often used to transfer files
                between two different computers.  Versions for VAX, IBM-PC,
                MAC, UNIX, TOPS-20 and many other machines.
                Availability:   F8
 
LIBSEARCH       Searches through HELP and other libraries for a specific
                topic.  Lists commands relevant to that topic.
                Availability:   E4
 
MAINT           A utility to maintain/update/control directories and the
                files that reside in them.
                Availability:   F9 (in pub/maint).
 
MAKE            A program maintainer.  Can be used to recreate a program
                by only recompiling source programs that are out of date.
                Analogous to "make" on UNIX systems.  Two versions exist,
                at least: 1 very similar to the Unix make; 1 specifically
                for VMS.
                Availability:   MAKE/VMS v3.4 from F10 (Read make.doc first),
                                F19
 
MAKEINDEX       Indexer for LaTeX.
                Availability:   F2
 
MESSAGE         Utility that logs all messages to a file.
                Availability:   S7
 
MORE            A unix-like file display tool.
                Availability:   E6 (Shan Xuning version), F19 (Corbet version)
 
MPMGR           Modparams.dat file manager for large clusters.
                Availability:   F11
 
NANNY           A set of useful tools and an environment sourrounding VMS
                (will do autologouts, for example).
                Availability:   E7 (get permission to copy), F20
 
NNTP_NEWS       nntp newsreader for VMS.  See also ANU NEWS.
                Availability:   F12
 
NSQUERY         Name server query program for CMU/Tek TCP V6.3.
                Availability:   F11
 
PHOTO           Uses pseudo terminal driver to "capture" a terminal session.
                Everything typed between PHOTO and LOGOUT is captured in
                a file.
                Availability:   F10, F23
 
PIPE            Utility that provides UNIX-style piping and redirection for
                a VMS environment.
                Availability:   E10
 
PMDF            General purpose system for delivering computer-based mail.
                Send a request for info to E8 before attempting to access
                this product.
                Availability: M2, E8 (queries only)
 
PROFILE         Screen-oriented user account add/modify utility.
                Availability:   F12
 
PTDRIVER        Pseudo terminal driver.
                Availability:   F10
 
REPLY           Logs messages to a file; replies to user messages.
                Availability:   S7
 
SERVERS (MAIL)  Utilities that will check for incoming mail and respond to
                requests (for files or information).
                Availability:   Form: (COMMAND_TO_USE) SITE_NAME
                        (SEND VMSSERV.PACKAGE)  VMSSERV@UBVMSA.CC.BUFFALO.EDU
                                                  and  UBVMSB,UBVMSC,UBVMSD
                        (?PACKAGE*NETSERVER)    NETSERVER@VAXMFG.TECH.NWU.EDU
 
SPELL           Spelling checker (source in Pascal, exe in Decus TEX).
                The dictionaries are large indexed files.
                Availability:   F16 (Part of Decus TeX)
 
STATUS          Utility that provides considerable detailed information
                about a VMS system and it users and resources.  Needs DECNET.
                Availability:   S5
 
SUM             (Show Users More).  Like DCL Show Users, but with addition
                of LAT Server and port name for LTAnnn: terminals.
                Availability:   E5
 
SWING           A wonderful screen-oriented directory and file maintenance
                tool.  Allows for directory creation, moving, deletion,
                and displays.  A bargain at half the price.
                Availability:   F12
 
TAR             A UNIX-like tar utility for VMS.
                Availability:   F14
 
TAR2VMS         A UNIX-like tar utility for VMS.  Can convert tar tapes and
                files to VMS files.  VMS2TAR does the reverse.
                Availability:   F10, F14, E9
 
TeX/LaTeX       Text formatting package developed by Donald Knuth.
                Produces DVI files.
                Availability:   F13, F16 (Decus TeX), F21
 
UAF             Searches through SYSUAF.DAT for users that match certain
                criteria.
                Availability:   S5
 
UNMACRO         Disassembler for MACRO language.
                Availability:   S9
 
UNSDL           Utility to aid in creation of include files from system
                definitions given in SYS!SHARE:STARLETSD.
                Availability:   S5
 
UUCP            Unix file data transfer utility for VMS.  Includes ANU News.
                Availability:   F14, D1, M4
 
VACATION        Program to periodically check for incoming mail messages
                and let sender know that you're on vacation (or otherwise
                unable to respond) by sending back a message that you specify.
                Warning: Be careful if you subscribe to mailing lists.
                Availability:   F12
 
VI              A TPU emulation of the UNIX VI editor.
                Availability:   info:   VIREQ@NEMO.MATH.OKSTATE.EDU
                                VI:     F22, S6 (SEND #vi_v5$vi_000.com)
                                                          . . .
                                                (SEND #vi_v5$vi_016.com)
                                        S4
 
VMS_SHAR        Tool to distribute ascii source files that allows recipient
                to confirm files were properly received (with no errors).
                Availability:   E3, F10
 
VERB            Inverse of VMS's SET COMMAND.
                Availability:   S4, S5
 
WATCHER         Configurable idle-job killer.  Knows about LAT.
                Availability:   F11
 
WILD            Wildcard (i.e., with * and %) version of DCL SEARCH.
                Availability:   E1
 
XMODEM          File transfer program with checksums and error correction.
                Compatible with CP/M MODEM7.  XMODEM is program VAX-96 of
                the DECUS library.  Author: J. James Belonis II.
                Availability:   ????    (no FTP or SERVER yet)
                                E2
 
ZOO             File compressor/decompressor/archiver.
                Archiver:       F15
 
(1) Requires compress/decompress and/or tar2vms or a tar utility.  Most
    sites supplying compressed files also supply decompressing tools.
    Not all compress/decompress utilities are equal|  The version from
    MIT will not work without modifications.  Charles Karney of Princeton
    University (see BOSS, above) was kind enough to send me a difference
    file between a working VMS version and the MIT distribution.
    Probably MIT should fix their compress to work as well on VMS as it does
    on every other OS and computer (MIT, are you listening?).
 
SOURCES:        F -> Anonymous FTP,  E -> EMAIL to person,  S -> SERVER
                M -> Postal Service, D -> DECUS tape
 
                Be sure to use BINARY mode on FTP of executables and backups.
 
D1      Spring 89 VAX SIG tape
 
E1      KARNEY%PPC.MFENET@NMFECC.LLNL.GOV               Charles Karney
        KARNEY%PPC.MFENET@LBL.BITNET
E2      BELONIS@PHAST.PHYS.WASHINGTON.EDU               J. James Belonis
E3      A.HARPER%OAK.CC.KCL.AC.UK@CUNYVM.CUNY.EDU       Andy Harper
E4      KEVIN%NCDLAB.ULCC.AC.UK@NSFNET-RELAY.AC.UK      Kevin Ashley
E5      MNK@DRACO.HAC.COM                               Michael Kimura
E6      INS_BXS@JHUVMS.BITNET                           Shan Xuning
E7      ZAR@XHMEIA.CALTECH.EDU                          Zar the Great (really|)
E8      QPMDF@YMIR.BITNET                               (PMDF queries)
E9      PENSTONE@QUCDNEEL.EE.QUEENSU.CA                 Sid Penstone
E10     KENW%NOAH.ARC.CDN@RELAY.UBC.CA                  Ken Wallewein
 
F1      KUHUB.CC.UKANS.EDU
F2      SCIENCE.UTAH.EDU
F3      JUNE.CS.WASHINGTON.EDU
F4      PREP.AI.MIT.EDU
F5      MIRIAM.UTAH.EDU
F6      CC.UTAH.EDU
F7      UMIGW.MIAMI.EDU
F8      CUNIXC.CC.COLUMBIA.EDU
F9      GUMBY.CC.WMICH.EDU
F10     VMSA.CF.UCI.EDU, VMSD.CF.UCI.EDU
F11     VMS.ECS.RPI.EDU
F12     KRYPTON.ARC.NASA.GOV
F13     SCORE.STANFORD.EDU              (allegedly shutting down 8/31/89)
F14     ACFCLUSTER.NYU.EDU
F15     WSMR-SIMTEL20.ARMY.MIL
F16     POWER.EEE.NDSU.NODAK.EDU
F17     EMX.UTEXAS.EDU
F18     VENUS.YCC.YALE.EDU
F19     STOUT.UCAR.EDU
F20     HAMLET.CALTECH.EDU
F21     SUN.SOE.CLARKSON.EDU
F22     VMS.UCC.OKSTATE.EDU
F23     USC.EDU
 
M1      National Energy Software Center
        9700 South Cass Ave.
        Argonne, IL 60439
        Ordering info:  312-972-7250
        (As of 6/26/89: Cost for VAX/VMS version of DOE-MACSYMA is !3110,
        !2500 for prime contractors)
M2      The PMDF Project
        Innosoft International, Inc.
        250 W. First St., Suite 240
        Claremont, CA 91711
        (714) 624-7907
M3
M4      c/o Simpact Associates
        9210 Sky Park Court
        San Diego, CA 92123
        (619) 565 1865 (x1116)
        jeh@crash.cts.com                       Jamie Hanrahan
M5      DECUS Program Library
        219 Boston Post Road
        Marlboro, MA 01752-1850
        (508) 480-3418
 
 
VMSSERV sites use the following syntax: DIR for program listing, SEND PGM to
        get a specific program.
 
S1      (SEND ALL) BULLETIN%MIT.MFENET@CCC.MFECC.LLNL.GOV
S2      (SEND FINGERV5) VMSSERV@UOFTO2.UTOLEDO.EDU
S3      (SEND FINGER.PACKAGE) VMSSERV.SPCVXA.BITNET
S4      VMSSERV@UBVMSD.CC.BUFFALO.EDU
S5      VMSSERV@FHCRCVAX.BITNET, VMSSERV%FHCRCVAX.BITNET@OLY.ACS.WASHINGTON.EDU
S6      MAILSERV@NEMO.MATH.OKSTATE.EDU
S7      (SEND VMSDUMP REPLY.*)  KERMSERV@UOFTO2.BITNET
        (SEND VMSDUMP MESSAGE.*)
S8      (SEND #ETAPE$ETAPE.SHARE_1_OF_5)        MAILSERV@UALR.BITNET
        (                       .      )
        (                       5      )
S9      (?PACKAGE*UNMACRO)      NETSERVER@VAXMFG.TECH.NWU.EDU
S10     (SEND FINGER.1_OF_7)    MAILSERV%FALCON@AAMRL.AF.MIL
                .
        (            7_OF_7)
        (SEND BECOME.1_OF_1)

--------------------------------------------------------------------------------
     Date:    Sat, 11 Nov 1989 17:07
     From:    CARL FUSSELL <CARL@SCU.BITNET> 
     Subject: RE: Internet

Received: From <CARL@SCU> for <NBEHR@ECNCDC>
          via RSCS by ECNCDC; Sat, 11 Nov 1989 17:07 CST
Date: Sat, 11 Nov 89 15:06 PST
From: CARL FUSSELL <CARL@SCU.BITNET>
Subject: RE: Internet
To: NBEHR@ECNCDC.BITNET
  
[...]
 
We are currently comparing several different methods for both T-1 and 56KB
links.   We feel that the optimal is with a Proteon box attached to our
ethernet (though Cisco sells a less expensive internet box I have been
told -- will be calling them this week).  Some internal constraints may
cause us to use an interim solution for a year where we will use an
existing VAX 750 Ultrix system as the router (or our 8650 VMS system a la
Wollongong software)...  haven't decided yet.
 
Anyway, any comments you collect would be much appreciated.
 
Thanx.
 
Carl
--------------------------------------------------------------------------------

     Date:    Sat, 11 Nov 1989 18:44
     From:    "Leo Geoffrion, Skidmore College" <LDG@AMY.SKIDMORE.EDU>
     Subject: TCP/IP and VMS 

Received: From <LDG@SKIDMORE> for <NBEHR@ECNCDC>
          via RSCS by ECNCDC; Sat, 11 Nov 1989 18:44 CST
Date: Sat, 11 Nov 89 19:43 EST
From: "Leo Geoffrion, Skidmore College" <LDG@AMY.SKIDMORE.EDU>
Subject: TCP/IP and VMS
To: nbehr@ECNCDC.BITNET
X-VMS-To: IN%"nbehr@ecncdc.bitnet"
 
In response to your posting about Internet for the VAX/VMS world...
 
 
We use the CMU TCP/IP software, distributed by Carnegie Mellon.
($150).  For its price, it's unbeatable.  works well, although the
documentation is pretty weak.
 
the only component that we omit is their mailer.  We prefer to use
PMDF (Pascal Mail Delivery Facility) which interfaces to VMS MAIL much
more cleanly that CMU's original product.
 
I can probably dig up some addresses if you want them.
 
Leo Geoffrion
Skidmore College Computer Center.
--------------------------------------------------------------------------------

 +2  Date:    Mon, 13 Nov 1989 19:02
     From:    "James A. Harvey" <IJAH400@INDYVAX> 
     Subject: UNIX vs. VMS interconnectivity 

Received: From <IJAH400@INDYVAX> for <NBEHR@ECNCDC>
          via RSCS by ECNCDC; Mon, 13 Nov 1989 19:01 CST
Date:     Mon, 13 Nov 89 16:30 EST
From:     "James A. Harvey" <IJAH400@INDYVAX>
Subject:  UNIX vs. VMS interconnectivity
To:       NBEHR@ECNCDC
Original_To:  JNET%"NBEHR@ECNCDC"
 
 
Eric:
 
I'll try to answer your questions.  We've been on the Internet (via Indiana
University) since May.
 
>- can an IBM mainframe run "useful software" without much pain? or
>do we need to get connected to a Vax or something similar?
 
Yes.  IBM sells a TCP/IP product for VM/SP (5798-FAL) and MVS (5685-061).
For more information ask your IBM sales rep.  Other companies also have
implementations for IBM mainframes.  There is a document that can be obtained
from NIC.DDN.MIL that lists vendors of TCP/IP related software and hardware
for different systems.  Have someone that you know who has Internet access
connect to NIC.DDN.MIL using FTP (10.0.0.51 or 26.0.0.73), login as user
ANONYMOUS, with password as their "real" address (user@domain).  Connect to
the directory NETINFO: and get the document named VENDORS-GUIDE.DOC.  It's
kind of large (670 Kbytes).  If you can't get anyone to get it for you, I
can split it into three parts and send it to you by BITNET.  This is just
vendors that sent stuff to the NIC though, there's a lot of other stuff on
the market too.
 
>- is VMS handicapped, as far as "useful software" goes, compared
>to Unix? If so, in what way?
 
Not really.  It depends what you mean by "useful software."  Generally,
each implementation gives you a client AND server for FTP (remote file
transfer), TELNET (remote interactive login), and SMTP (mail, and some
kind of interface to the local mail system).  Most NFS (transparent access
to files on a remote) implementations for IBM/VM and VAX/VMS are server-only
(i.e., U*IX boxes can use the IBM and VAX systems as file servers, but
not the other way around).  The IBM implementation has an REXEC server.
Most VMS implementations I am aware of (Wollongong, Fusion, and Multinet)
were ported from the BSD 4.3 distribution and include rlogin, rsh, and rexec
clients, but not servers.  A lot of sysadmins (me included) consider these
to be security holes anyway (people having files full of passwords around),
and don't encourage their use (just use telnet).  News is nice, but the only
implementations for VMS of which I'm aware are public domain (there are
NEWS packages for VMS available from DECUS, the DEC User's Society).
Here on the VMS system I use we run the Wollongong software.  We're not
using their NFS yet, so I can't say much about that.  If you are going to
handle a lot of TELNET logins on VMS, make sure the TELNET server is a
kernel implementation (the Wollongong and Multinet implementations are,
and I think Fusion is soon to be or already is).  Most of the public domain
TCP/IPs for VMS aren't (e.g., the CMU stuff).  Even so, a large number of
TELNET logins on a VAX can present a considerable amount of overhead.
For example, on the 8820s at I.U Bloomington, 100 or so TELNET sessions can
use up about 1/5 of the CPU just in TELNET overhead.  This is because of
the character-at-a-time nature of terminal support on the VAX; you can
get 1 packet for each character input.  On an IBM it isn't so bad, since
if the client TELNET on the remote host can emulate a 3270 terminal (a block
mode device), the IBM host only has to send a few packets for each new
screen.
 
>- is there any favorite networking method to be used locally?
>everywhere I've been before, Ethernet was the standard; here, a
>"mafia" of sorts is pushing a token ring LAN; any concrete arguments
>against it?
 
Good luck finding a token-ring interface for a VAX.  What is usually done
is one has individual subnetted LANs that are one or the other, connected
with IP gateways (ISO level-3 routers).  Usually these are separate boxes,
because in general one doesn't want to use timesharing hosts to do routing.
Some routers can also act as level-2/MAC (media access control) bridges
for other Ethernet protocols (for example, LAT).  A router is generally
slower than a bridge, although the newer ones are approching the packet
transfer rates achievable by bridges.  For example, I think DEC bridges
are rated near 15000 packets/second (the theoretical maximum rate for a
10Mbps Ethernet), and the Cisco gateway servers we use here are rated at
12000 packets/second for routing or bridging.  Of course, routers are more
expensive.  Another performance measurement that isn't always mentioned
but that one has to consider in some situations is packet latency time,
not just the raw throughput rate, but how long it takes to route a particular
packet from one interface to another.
 
As far as which to use for a particular LAN, there are advantages and
disadvantages to both.  Token-ring is deterministic, whereas Ethernet is
not.  This simply means that a token-ring node is guaranteed to be able
to get access to the media to send a packet in a deterministic amount
of time, whereas there is no such guarantee on an Ethernet.  Ethernet
can make fuller use of the network bandwidth at low loads, but degrades
because of collisions at high loads, where in a token ring each node
would still be getting it's guaranteed "share" of the bandwidth (this
is what is meant by "deterministic" media access).  Ethernet is supported
by more vendors, although that is becoming less of an issue these days.
It is possible to tap undetected into an Ethernet and watch all the
network traffic; token-ring is more secure in this respect.  Finally,
token-ring has the potential for higher raw network bandwidth.
 
Some articles (and some people!) treat this more like a religious issue
than anything else.  In practice, you choose it depending on the media
access control best supported by the particular systems you are connecting.
Generally this means Ethernet for DEC products and UNIX boxes and token-ring
for IBM, and either for micro LANs.  Specialized high-speed networks (e.g.,
a campus-wide fiber backbone) typically use some type of token ring.
 
There are a couple of good articles by Charles L. Hedrick of Rutgers University
on the administration of and introduction to TCP/IP networks that I have
machine readable copies of that I could send you over BITNET if you like.
 
For more information on routers and bridges there are a couple of good
articles in IEEE Network, January 1988, Vol. 2, No. 1, "Bridges and Routers",
by William M. Seifert 
(pp 57-64), and "Integrating Bridges and Routers in
a Large Internetwork" by Eric Benhamou (pp 65-71).
 
I hope this helps.  If you want any of the machine-readable stuff I have
let me know, and where to send it (BITNET?) and what format you want it
in (punch, netdata, vmsdump, etc.).  Good luck.
 
- Jim Harvey, Senior Analyst/Programmer, IUPUI Computing Svcs. (DEC Systems)
Internet: ijah400@indyvax.iupui.edu   UUCP: ...{uunet, ?}!iuvax!ivax!ijah400
BITNET: ijah400@indyvax   AT&T: (317) 274-0747                   Disclaimer:
Opinions expressed here are my own and not necessarily those of my employer.
 
P.S.: And don't be embarrased about asking questions.  I was scratching my
head over all this about a year ago too, and all I have to support is the
software end of it...
--------------------------------------------------------------------------------

 +3  Date:    Mon, 13 Nov 1989 19:14
     From:    Aaron Leonard at UofA Telecommunications <LEONARD@telcom.arizona.e
du> 
     Subject: Re: UNIX vs. VMS Internet connectivity 

Received: From <LEONARD@ARIZONA> for <NBEHR@ECNCDC>
          via RSCS by ECNCDC; Mon, 13 Nov 1989 19:14 CST
Date: Mon, 13 Nov 89 15:32 MST
From: Aaron Leonard at UofA Telecommunications <LEONARD@telcom.arizona.edu>
Subject: Re: UNIX vs. VMS Internet connectivity
To: nbehr@ECNCDC.BITNET
Message-id: <244C3F3843DFA00131@telcom.arizona.edu>
X-Envelope-to: nbehr@ECNCDC.BITNET
X-VMS-To: in%"nbehr@ecncdc.bitnet"
 
Marek -
 
Some random opinions ... (particularly biased opinions are flagged by:
"(***BIAS***)":
 
We (Univ of Arizona) are a site that has some of about everything:
Internet connects, Bitnet connects, DECnet connects.  We have IBMs running
MVS and VM, VAXen running VMS, and lots of stuff running Unix.
 
>can an IBM mainframe run "useful software" without much pain? or
>do we need to get connected to a Vax or something similar?
 
Hm.  Well, in general, (***BIAS***) IBMs CAN'T run "useful software"
without much pain, because IBM mainframes are inherently painful.
Actually, there are many ways to network IBMs to the rest of the world.
Here are 2 techniques we employ:
 
1. RSCS.  This is an old, batch-oriented network protocol for IBMs.  (It's
what Bitnet talks.)  Its main advantage is that it's cheap (all you need
is slow synchronous [or "bisync"] serial lines, and it comes built into
IBMs.)  Its main disadvantages are that it's slow, and that it doesn't
support remote logins.  (It is good for mail, for file transfers, and for
remote job entry functions such as batch job and print submissions.)
 
The RSCS implementation that we use for VMS is Jnet, from a company called
Joiner Associates.  It's a very well made and well supported product.  You
should be able to get RSCS for Unix from somebody, but I don't know who.)
 
2. TCP/IP.  We have our VM mainframe hooked up to our Ethernet via a box
called a "DACU".  It's running TCP/IP from IBM.  We have most all of our
Unix systems and VAXen talking TCP/IP as well, so this gives us lots of
functionality.  This supports FTP, TELNET(*), and SMTP.  It seems to be
fast and pretty reliable, except that the "DACU" flakes out about every 6
months or so.  We don't have a TCP/IP into our MVS 3090, as that costs an
arm and a leg.  (*) Note on TELNET to/from an IBM mainframe: IBM terminals
are very weird compared to everybody else's.  So that claim that TELNET
"works" should be taken with a grain of salt.  In general, your TELNET
client side (non-IBM host) should be able to run TN3270.
 
OK, on to the next question:
 
>is VMS handicapped, as far as "useful software" goes, compared
>to Unix? If so, in what way?
 
The only way in which VMS is "handicapped" vs. Unix is this: if you're
running VMS, you must pay extra to get your networking software (and
choose the right software wisely!), while with Unix, (***BIAS***) you get
broken software for no additional charge.
 
In fact, we have standardized on VMS to run our campus network gateways,
because of its superior reliability and connectivity.
 
(***BIAS***) If you are running TCP/IP on VMS, there is ONLY ONE GOOD
CHOICE!  Repeat: THERE IS ONLY ONE GOOD CHOICE.  This is MultiNet from
TGV.COM (marketing information: Desiree Champagne
<desiree@warbucks.ai.sri.com>).  MultiNet is the best implementation of
TCP/IP commercially available - including any BSD implementation.  If you
buy any other TCP/IP for VMS, (***BIAS***) you WILL be sorry.
 
>is there any favorite networking method to be used locally?
>everywhere I've been before, Ethernet was the standard; here, a
>"mafia" of sorts is pushing a token ring LAN; any concrete arguments
>against it?
 
Yup - our favorite networking method is TCP/IP over Ethernet.  This is
because:
 
1. Ethernet works.
2. Ethernet is pretty fast.
3. Ethernet is pretty cheap.
4. (Almost) everything talks Ethernet.
5. (Almost) everything talks TCP/IP.
6. TCP/IP has lots of functionality.
7. The whole (academic world) speaks TCP/IP.
 
(***BIAS***) anyone who "is pushing a token ring LAN" is obviously a
brain-dead IBM weenie.  I won't offer any concrete arguments against an
IBM token ring because such people typically won't listen to reason.
 
Rotsa ruck,
 
Aaron
 
Aaron Leonard (AL104)   |       leonard@arizona.edu /
U of Ariz Telecom       |       LEONARD@ARIZONA.BITNET
Tucson AZ 85721         |       47540::TELCOM::LEONARD
--------------------------------------------------------------------------------

     Date:    Mon, 20 Nov 1989 8:23
     From:    <gjc@bu-it.BU.EDU>
     Subject: VMS connects

Received: From <MAILER@BUACCA> for <NBEHR@ECNCDC>
          via RSCS by ECNCDC; Mon, 20 Nov 1989 08:23 CST
Received: from BUACCA by buacca.bu.edu (Mailer X1.25) with BSMTP id 1101; Mon,
 20 Nov 89 07:39:43 EST
Received: from bu-it.BU.EDU by BUACCA.BU.EDU (IBM VM SMTP R1.2.1) with TCP; Mon,
 20 Nov 89 07:39:42 EST
Received: from BUIT4.BU.EDU by bu-it.BU.EDU (5.58/4.7)
id AA21602; Mon, 20 Nov 89 07:39:44 EST
Return-Path:  <gjc@bu-it.bu.edu>
Received:  by buit4.bu.edu (3.2/4.7)
id AA25326; Mon, 20 Nov 89 07:39:42 EST
Date:  Mon, 20 Nov 89 07:39:42 EST
From: gjc@bu-it.BU.EDU
Message-Id:  <8911201239.AA25326@buit4.bu.edu>
To: NBEHR@ECNCDC.BITNET
Subject: VMS connects
 
The issue of VMS connectivity vs Unix was *always* one of *price*,
not *performance*. However, the *price* difference has now gone away
with two packages, both of which are being used extensively:
 
* CMU TCP-IP. Costs $150 to get the tape. A full TCP-IP implementation.
* DECUS UUCP. Also cheap from DECUS.
 
The main limitation of the CMU package is the mailer. People I know
tend to combine it with PMDF from Innosoft, especially when they have
more than one transport protocol like DECUS UUCP on the same machine.
 
Obviously you get full sources with both packages. I know of one site
using CMU-TCP (pfcvax.pfc.mit.edu) where they seem to have to forward
domain-style addresses which do not have internet addresses because of
a lack of MX record support for mailing outgoing. There is a NAMSRV
process however that does domain lookup for internet addresses, so it
should not be a big deal to get the mailer to look up MX records too.
There is an internet mailing list out of @CMU.EDU for system managers
using the package. Bug reporting, hints, problem resolution, the
usual thing.
 
Then of course there are many commercial packages for TCP-IP and UUCP
under VMS from various suppliers.
 
Multinet available from SRI is the most attractive of the commercial
packages in my opinion.
 
-gjc
--------------------------------------------------------------------------------
[more correspondence with gjc]

 +4  Date:    Mon, 20 Nov 1989 23:27
     From:    <gjc%mitech.com@harvunxw.BITNET> 
Subject: vms connections
X-Vms-Mail-To: UUCP%"nbehr@ecncdc.bitnet"
 
you are welcome. This message being sent with DECUS UUCP by the way.
 
Now, you have a IBM machine, have you looked at the DECNET/SNA connectivity
stuff from DIGITAL? Not cheap at something like $50k, but of course IBM
mainframes are not cheap either. The reason I ask is that Boston University
has a big IBM mainframe also, and lack of connectivity has always been
a big problem for that machine. They never did get TCP running correctly.
Of course they have their own one-of-a-kind-in-the-world home-brew OS
called VPS running on it under VM. So that doesnt help.
 
-gjc
--------------------------------------------------------------------------------

     Date:    Mon, 20 Nov 1989 18:27
     From:    (William Clare Stewart) <wcs@ho95c.att.com>
     Subject: Re: UNIX vs. VMS Internet connectivity 

Received: From <MAILER@CUNYVMV2> for <NBEHR@ECNCDC>
          via RSCS by ECNCDC; Mon, 20 Nov 1989 18:27 CST
Received: from CUNYVM by CUNYVM.BITNET (Mailer R2.03B) with BSMTP id 0776; Mon,
 20 Nov 89 19:24:58 EDT
Received: from arpa.att.com by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with TCP;
 Mon, 20 Nov 89 19:24:54 EDT
Date: Mon, 20 Nov 89 15:39:11 EST
From: wcs@ho95c.att.com (William Clare Stewart)
To: mf12605@msi-s9.msi.umn.edu NBEHR@ECNCDC.BITNET
Subject: Re: UNIX vs. VMS Internet connectivity
Newsgroups: comp.os.vms,comp.protocols.tcp-ip,comp.unix.questions
In-Reply-To: <16881@umn-cs.CS.UMN.EDU>
Organization: AT&T Bell Labs
 
I've done a little bit of this, but not much.
As you might guess, VMS is pretty foreign to us here, something that
would only be used by number-crunching types who LIKE fortran :-).
But on one of our projects, we were dealing with a company that did
fancy satellite image number crunching on VMS, and we were working
with HP Series 9000 Unix machines to do graphics animation.
The right way to do the job is to get real TCP/IP for teh VAX (some
university-ware packages are out there, as well as commercial from
Wollongong etc.), but we didn't have the VMS expertise to do that.
HP has a software package called "Network Services" = NS/VAX,
NS/9000, etc, which give you file transfer and I think remote login
capabilities.  We set up some scripts on each machine to put the
files in some well-defined locations and haul tehm across using HP's
substitute for RCP (which also took care of record-length,
byte-swapping, etc.)  Boring stuff, but pretty simple to do.
 
]- can an IBM mainframe run "useful software" without much pain? or
]do we need to get connected to a Vax or something similar?
 
]- is VMS handicapped, as far as "useful software" goes, compared
]to Unix? If so, in what way?
 
Both systems can support TCP/IP and Ethernets.
You tend to need third-party equipment, especially for IBM
mainframes, but it exists; VAXes can eitehr use DEC or
3rd-party (the latter is cheaper.)  The basic problem is
that both vendors have their own favorite lock-you-in
networking software, and support isn't always the best for
standards.  DEC is a bit better, since DECnet Phase 5 is
supposedly OSI-based, but there isn't a lot of OSI stuff for
it to talk to.
 
]- is there any favorite networking method to be used locally?
]everywhere I've been before, Ethernet was the standard; here, a
]"mafia" of sorts is pushing a token ring LAN; any concrete arguments
]against it?
 
Token rings are EVIL!  (If you've read "The Hobbit", by
J.R.R. Token, you know that the Ring makes you invisible but
warps your spirit and lets the Evil Empire now where you are :-)
If you use them, you're LOCKED IN!  It may not support your
VAX, and you'll be forced to use crufty protocols which you
won't be able to keep up-to-date without constantly buying
the latest stuff from IBM.
 
Ethernets come in several electrical flavors (thin-wire,
thick-wire, and twisted-pair), and it's easy to get
electrical conversion betwwen them, and to get Ethernet
boards for any kind of equipment you have - IBM, DEC, Sun,
PCs, Macs,  AT&T 3B2s, RISC boxes, and everyone supports TCP/IP
in some fashion, though they don't all like to admit it.
You can also get terminal server boxes to provide access to
the machines, which is generally cheaper than IBM
front-end-processors and lets you use dumb ASCII terminals
instead of 3270.
---
# Bill Stewart, AT&T Bell Labs 4M312 Holmdel NJ 201-949-0705 api.att.com!wcs
 
#We did it for the formlessness ...
--------------------------------------------------------------------------------

 +4  Date:    Wed, 22 Nov 1989 14:51
     From:    RANDY MARCHANY <MARCHANYRC@VTCC1>
     Subject: unix - vms internet connectivity 

Received: From <MARCHANY@VTCC1> for <NBEHR@ECNCDC>
          via RSCS by ECNCDC; Wed, 22 Nov 1989 14:51 CST
Date:     Tue, 21 Nov 89 14:17 EST
From:     RANDY MARCHANY <MARCHANYRC@VTCC1>
Subject:  unix - vms internet connectivity
To:       nbehr@ecncdc
Original_To:  BITNET%"nbehr@ecncdc"
Original_cc:  MARCHANYRC
 
Hi, here at VA Tech, we have IBM 3090 and 3084 running VM, a VAX 8800
running VMS and countless workstations running VMS or Ultrix. All of these
systems are connected on an ethernet. The VMS systems run Wollongong's
WIN/TCP TCP/IP software package, the IBM VM systems run a TCP/IP package
developed by IBM and the Ultrix systems use the standard TCP/IP package
that comes with the system. We have been using this setup for over 2 years
with very little problems. Our Computing Center (where the IBM's and the 8800
are located) site is 2 miles from campus. I believe we use a Token ring
bridge to connect the Center's Ethernet to the the campus ethernet backbone.
All of the TCP/IP packages mentioned provide TELNET, FTP, SMTP support (in
fact, I'm on an Ultrix workstation telnetted to the VMS machine to send
you this note). If you need more specific info, drop me a note. My address
is:
        Randy Marchany
        VA Tech Computing Center
        1700 Pratt Dr.
 
        Blacksburg, VA 24061-0214
        703-231-9523
Bitnet: MARCHANYRC@VTCC1
 
Hope this helps you out.
        -Randy
--------------------------------------------------------------------------------

Again, thanks to all respondents. Please follow up by mail to NBEHR@ECNCDC;
I can't access newsgroups easily.          Eric Behr

| Marek Behr                          | mf12605@uc.msc.umn.edu     (internet) |
| University of Minnesota             | AE01005@UMNACVX              (BITNET) |

-----------[000407][next][prev][last][first]----------------------------------------------------
Date:      28 Nov 89 01:11:58 GMT
From:      mrm@sceard.Sceard.COM (M.R.Murphy)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Anybody know of an enet/TCP printer?

In article <1989Nov20.091640.22224@cpd.com> neil@uninet.UUCP (Neil Gorsuch) writes:
>In article <1989Nov7.210143.26795@t2ns1.gcs.co.nz> brian@t2ns1.gcs.co.nz writes:
>>Has anybody ever come across a printer hanging directly off a thick
>>enet transceiver? We have a situation here where such a printer would
>>be invaluable. Obviously it would need appropriate intelligence to
>>handle addresses, domains etc. with it's card.
>
>First, let me warn you that I am biased towards the following
>solution, since we just introduced it as a new product.
[remainder of advertisement deleted...]

Not much need to invent new hardware, since the same can be accomplished
with off the shelf stuff for less than $500. Not a direct connect, but
then, almost direct oughtta be good enough, especially if it's fast.

BTW, in disclaimer mode, appropriate it is, and in back-handed advertisement
mode, inappropriate though it may be, we make such a box as a product that
we sell for more than it costs us to make. Details of implementation, features,
and color of case withheld to retain a semblance of non-commercialism:-) 
--
Mike Murphy  Sceard Systems, Inc.  544 South Pacific St. San Marcos, CA  92069
mrm@Sceard.COM        {hp-sdd,nosc,ucsd,uunet}!sceard!mrm      +1 619 471 0655

-----------[000408][next][prev][last][first]----------------------------------------------------
Date:      28 Nov 89 01:53:03 GMT
From:      usenet@cps3xx.UUCP (Usenet file owner)
To:        comp.protocols.nfs,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   pub. domain NFS/RPC for Unix, MSDOS?


Some days ago I got the following email from
India, with a request for certain public domain 
networking software:

>    Sun's RPC and NFS Sources from public domain. We are
>    buying a 386-based Micro running Unix System V Rel.3.2
>    from Interactive Systems Corpn. It supports NFS based on
>    TCP/IP. I heard this NFS is available for PCs running
>    DOS also. And further, it seems to be 
>    machine hardware and transport software independent.
>    So we plan to have it working in an OSI Environment.
>    
>    Could you spare some time in loading this vital piece
>    of software ( both Unix and DOS versions) please ?

I don't know much about networking software, so
please excuse my ignorance.  What exactly does this
person want, and from where can I ftp the corresponding
files?  Can I get source for both Unix and DOS versions?

I would be VERY grateful for any information.  Please
email me at:   raja@frith.egr.msu.edu     OR
               raja%frith.egr.msu.edu@uunet.uu.net

Thanks in advance,


Narayan Sriranga Raja.

        ________    ________     __  __      ________ 
        |     |     |     |     (/ \/  )     |     |
        |     |     |     |           /      |     |
        |     |     |     |          /       |     |
        |     |     |     |         /        |     |
        |     |     |     |       _/ __      |     |    (Raja)
        |     |     |     |      (__/ \)     |     |
             /

-----------[000409][next][prev][last][first]----------------------------------------------------
Date:      28 Nov 89 05:54:40 GMT
From:      karn@jupiter.bellcore.com
To:        comp.protocols.tcp-ip,comp.protocols.iso,comp.dcom.lans
Subject:   ACM SIGCOMM '90 Call for Papers







                            PRELIMINARY CALL FOR PAPERS


                             ACM SIGCOMM '90 SYMPOSIUM| -


                     Communications Architectures and Protocols

                             Philadelphia, Pennsylvania

                                    August 1990



            The  symposium  provides  an  international  forum  for  the
            presentation  and discussion of communication network appli-
            cations and technologies, as well  as  recent  advances  and
            proposals  on  communication architectures, protocols, algo-
            rithms, and performance models.  Authors are invited to sub-
            mit  full  papers  concerned  with both theory and practice.
            The areas of interest for the symposium include, but are not
            limited  to  the  following: analysis and design of computer
            network architectures and algorithms, innovative results  in
            local  area networks, computer-supported collaborative work,
            network interconnection and mixed-media networks, high-speed
            networks,  resource  sharing in distributed systems, distri-
            buted operating systems and databases,  protocol  specifica-
            tion, verification, and analysis.

            Papers should be  about  20  double-spaced  pages  long  and
            should  have  an  abstract  of 100-150 words.  All submitted
            papers will be reviewed and will be judged with  respect  to
            their  quality  and  relevance.   Authors of selected papers
            will be expected to sign an ACM copyright release form.  The
            Proceedings  will  be  distributed at the symposium and pub-
            lished as a special issue of SIGCOMM _ C_ o_ m_ p_ u_ t_ e_ r  _ C_ o_ m_ m_ u_ n_ i_ c_ a_ t_ i_ o_ n
            _ R_ e_ v_ i_ e_ w.

            Submit 5 copies of each paper to the Program Chairman:

                            Phil Karn
                            Bell Communications Research
                            Room 2P-357
                            445 South St
                            PO Box 1910
                            Morristown, NJ 07962-1910
                            USA

                            Tel: 1-201-829-4299
                            EMAIL: karn@thumper.bellcore.com
                            FAX: 1-201-984-0670
            __________________________
            | - Subject to ACM approval.




                                 November 28, 1989





                                       - 2 -


            For more information about the symposium, contact  the  Gen-
            eral Chairman:

                            Professor David Farber
                            University of Pennsylvania
                            200 South 33rd St
                            Philadelphia, PA 19104-6389
                            USA

                            Tel: 1-215-898-9508
                            EMAIL: farber@cis.upenn.edu
                            FAX: 1-215-274-8192


                       Papers on Networking In The Year 2000

            One or more sessions of the conference will  be  devoted  to
            the subject of networking in the year 2000.  Papers in these
            sessions will focus on key issues in building very  fast  (1
            gigabit  per  second and faster) and/or very large (200 mil-
            lion end nodes or more) data networks.   Persons  interested
            in  submitting papers in this area are encouraged to contact
            either the program chair,  Phil  Karn,  or  Craig  Partridge
            (craig@bbn.com), who will be jointly coordinating the papers
            in this area.

                                Student Paper Award

            Papers submitted by  students  will  enter  a  student-paper
            award contest.  Among the accepted papers, a maximum of four
            outstanding papers  will  be  awarded  (1)  full  conference
            registration and (2) a travel grant of $500 US dollars.

                                  IMPORTANT DATES

            Deadline for paper submission: March 1990





















                                 November 28, 1989

-----------[000410][next][prev][last][first]----------------------------------------------------
Date:      28 Nov 89 15:10:10 GMT
From:      lindberg@cs.chalmers.se (Gunnar Lindberg)
To:        comp.protocols.tcp-ip,comp.bugs.misc
Subject:   Bug in CMU snmp 1.0 + fix

I picked up snmp 1.0 from CMU (pub/cmu-snmp1.0.tar.Z, Oct 24 18:13)
not long ago and I think I've actually found a bug in it. If I tried
things like

    snmpget ... ip.ipRoutingTable.ipRouteEntry.ipRouteNextHop.10.0.0.51

it would dump core before it actually got to sending out the question.

It seems like routine "parse_subtree()" in "snmplib/mib.c" tried to use
a NULL pointer when it looked up the "10.0.0.51" part of the string.
Now, I don't know much about ASN.1 so my fix might be doing the wrong
thing, but things seems to work reasonably well with it.

	Gunnar Lindberg

=====================================================================
RCS file: mib.c,v
retrieving revision 1.2
diff -c -r1.2 mib.c
*** /tmp/,RCSt1a26347	Tue Nov 28 15:53:25 1989
--- mib.c	Mon Nov 27 13:47:47 1989
***************
*** 620,625
  
      if (*input != '.')
  	return (1);
      if ((*out_len =
  	 parse_subtree(tp->child_list, ++input, output, out_len)) == 0)
  	return (0);

--- 620,627 -----
  
      if (*input != '.')
  	return (1);
+     if (tp)
+ 	tp = tp->child_list;
      if ((*out_len =
  	 parse_subtree(tp, ++input, output, out_len)) == 0)
  	return (0);
***************
*** 621,627
      if (*input != '.')
  	return (1);
      if ((*out_len =
! 	 parse_subtree(tp->child_list, ++input, output, out_len)) == 0)
  	return (0);
      return (++*out_len);
  }

--- 623,629 -----
      if (tp)
  	tp = tp->child_list;
      if ((*out_len =
! 	 parse_subtree(tp, ++input, output, out_len)) == 0)
  	return (0);
      return (++*out_len);
  }
 =====================================================================

-----------[000411][next][prev][last][first]----------------------------------------------------
Date:      28 Nov 89 20:44:35 GMT
From:      estrin@USC.EDU (Deborah Estrin)
To:        comp.protocols.tcp-ip
Subject:   guide to authors for JoI

The Guide to Authors for submissions to Journal of Internetworking are
available for anonymous ftp from
nri.reston.va.us:rdroms/submission.guide.

(The deadlines for the first two issues are Dec 31, 1989 and March 31,
1990, respectively.)

-----------[000412][next][prev][last][first]----------------------------------------------------
Date:      28 Nov 89 23:13:42 GMT
From:      cliff@WSU-ENG.ENG.WAYNE.EDU (Cliff Stallings)
To:        comp.protocols.tcp-ip
Subject:   yellow pages

I wish to use the nameserver on my Sun-4 systems without using yellow pages.
I have been informed that this is not possible.  Can anyone help?
 
   cliff@wsu-eng.eng.wayne.edu

-----------[000413][next][prev][last][first]----------------------------------------------------
Date:      28 Nov 89 23:58:43 GMT
From:      minshall@kinetics.com (Greg Minshall)
To:        comp.protocols.tcp-ip
Subject:   Re: Telnet Negotiations?

In article <1989Nov13.220410.24388@ldc-net.uucp> rod@ldc-net.UUCP (Rod Merry) writes:
>Can someone tell me if the bsd 4.3 Telnet server puts the ptty in
>8 bit raw mode when a client negotiates for binary mode.  We have one
>vendor who goes to 8 bit cooked and another who goes to 8 bit raw.
>Both say they do the same thing as 4.3 does, who is right?

Yes, well.  I'm fairly sure that the released 4.3 (and 4.3tahoe) versions
of the telnet server put the tty in raw mode (or some such thing) when
going into binary mode.  So, vendor X is right in that they are doing
what 4.3 does.

However, that is the wrong thing to do (I sort of wrote that code, or at
least was responsible for it at the 4.3 time).

Dave Borman's newest telnet server (I'm pretty sure) fixes this bug.  This
version is available from arpa.berkeley.edu in the pub directory (along with
client telnet).  This version runs on 4.3.  So, vendor Y is right in that they
are doing what 4.3 does.

Greg Minshall			Novell, Inc.
minshall@kinetics.com		1-415-947-0998

-----------[000414][next][prev][last][first]----------------------------------------------------
Date:      29 Nov 89 08:01:38 GMT
From:      hnt@Frobozz.COM (Michael Hentrich)
To:        comp.protocols.tcp-ip
Subject:   Help: Connecting a Printer on a Terminalserver

Hiya,

We nned your help regarding the following configuration:

We are using 3COM Terminalserver, and have to connect 
Printers to them.

Now my question:
How to connect from the host to the Terminalserver?
If I configure the Port on the TS to be a printer, I may
do a telnet or a rlogin to the Port, but I have no error
recovery and some problems regarding stty modes etc.

I think we need a kind of SW to make the connect. Who
of you has experience, how to do it.

Thanx in advance

Michael

Michael Hentrich c/o Altos Computer Systems GmbH Wuermstr.55
	D-8032 Graefelfing/Munich Western Germany
Voice:+49898548440 uucp:hnt@altger.uucp 
bang:..!uunet!mcvax!unido!altger!hnt
     mhentric@Altos.Com
-------------------------------------------------------------------------------
-- 
Michael Hentrich c/o Altos Computer Systems GmbH Wuermstr.55
	D-8032 Graefelfing/Munich Western Germany
Voice:+49898548440 uucp:hnt@altger.uucp bang:..!uunet!mcvax!unido!altger!hnt
-------------------------------------------------------------------------------

-----------[000415][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Nov 89 17:42:35 EST
From:      Jack Haverty <haverty@BBN.COM>
To:        zaphod.mps.ohio-state.edu!gem.mps.ohio-state.edu!brutus.cs.uiuc.edu!zweig@tut.cis.ohio-state.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP Fletcher Checksum Option
>Not to slam Postel and the whole IETF and everyone else who brought us the
>TCP/IP checksum algorithm, but the fact that it is not able to detect
>the transpostion of N (where N>=2 is an even number) octets in a datagram
>is of concern in some applications where ultra-reliable communication is
>essential.  Also, it has been pointed out by a number of hardware-types I
>have talked to that these sorts of errors can occur, for example, when
>DMAing bytes from an ethernet-controller to the main memory of a machine --
>i.e. after the ethernet CRC has already been checked. One case it to have
>a pair of 32-bit words go out over the bus in the wrong order under rare
>timing glitches....

I thought that the following snatch of history might be of interest.

I remember pretty clearly almost exactly this discussion at one of the
TCP working group meetings ten years ago.   There were two arguments
against having a more powerful checksum:

1/ I don't want to devote that much of my CPU to it (remember CPUs in
those days meant big, expensive, not-very-powerful timesharing systems)

2/ if we have to do complicated arithmetic (i.e., algorithms for which
the CPUs didn't have real good instructions available), it will make it
difficult to get high bandwidth

If I remember correctly, the telling argument was:

3/ People are working on new chips to do checksums in silicon.  We don't
want to adopt an algorithm that will preclude use of these chips.

The problem was that there was no obvious consensus to which chips would
hit the market when, and when computer manufacturers would put them into
their products.   This led to a basic plan which was:

Put in a rudimentary checksum now.   When CPU cycles become cheaper,
chips become available, and/or the drawbacks of the checksum become a
problem, select and standardize a new checksum.

If anybody else who was there remembers this differently, chime in!  

Maybe it's now the time....

Jack
-----------[000416][next][prev][last][first]----------------------------------------------------
Date:      29 Nov 89 14:25:00 GMT
From:      NSCHNEIDEWIND@A.ISI.EDU (Norm Schneidewind)
To:        comp.protocols.tcp-ip
Subject:   Faculty Positions in Information Systems


       The Naval Postgraduate School's Department of Administrative             
       Sciences has tenure track and adjunct positions available in the         
       Information Systems Group. Positions are available at any level          
       in Software Engineering, Empirical Analysis of Information               
       Systems in Organizations, Expert Systems/Cognitive Science,              
       Decision Support Systems, Information Systems Technology,                
       Information Systems Policy and Management, and Computer Networks         
       and Distributed Systems. The department has numerous and varied          
       pc-based computer networks and access to the campus mainframe to         
       support student instruction and faculty research. Salaries are           
       competitive. Qualifications include a Ph.D. or D.B.A. with a             
       major in Information Systems or a closely related field, and a           
       serious interest in teaching at the graduate level while                 
       pursuing significant, relevant research. A visible record of             
       scholarly accomplishment is required for appointment at a senior         
       rank. Monterey, CA is a delightful seaside community with an             
       ideal climate located two hours south of San Francisco. The              
       Naval Postgraduate School is an Equal Opportunity Employer.              
       Please send resume to: Professor David R. Whipple, Chairman,             
       Department of Administrative Sciences, Naval Postgraduate                
       School, Monterey, CA 93943.                                              
-------

-----------[000417][next][prev][last][first]----------------------------------------------------
Date:      29 Nov 89 16:09:29 GMT
From:      zweig@brutus.cs.uiuc.edu (Johnny Zweig)
To:        comp.protocols.tcp-ip
Subject:   TCP Fletcher Checksum Option

In re-reading the article ``Improving the Efficiency of the OSI Checksum
Computation'' in the latest Computer Communication Review (ACM SIGCOMM),
I remembered an idea that popped up over lunchtime several months ago.

It seems to me that I could add 4 or 5 lines of code to my TCP-checksum
computation routine (basically a 16-bit-at-a-time iteration over the
appropriate bytes) and have it compute both the regular TCP/IP checksum
and a 16-bit Fletcher checksum (by simply using an additional accumulator)
at a small additional cost (well, twice as many additions, so it's not really
such a small cost, I'm sure it will be said -- see below).

I would like to hear opinions on whether a TCP header option-pair (one to
negotiate use of such a Fletcher checksum on connection-establishment, and
one to carry the actual extra 2 bytes in each segment) would be a
reasonable thing to propose.

Not to slam Postel and the whole IETF and everyone else who brought us the
TCP/IP checksum algorithm, but the fact that it is not able to detect
the transpostion of N (where N>=2 is an even number) octets in a datagram
is of concern in some applications where ultra-reliable communication is
essential.  Also, it has been pointed out by a number of hardware-types I
have talked to that these sorts of errors can occur, for example, when
DMAing bytes from an ethernet-controller to the main memory of a machine --
i.e. after the ethernet CRC has already been checked. One case it to have
a pair of 32-bit words go out over the bus in the wrong order under rare
timing glitches....

I know, I know, there is probably a stack of printout somewhere gathering
dust (being from 1967) giving good data about the fact that this Almost 
Never Happens in Real Life -- but it seems like an option that most
implementations would not support (I think this ought to be an "optional"
feature in the hypothetical revision of the Host Requirements RFC that gets
put out after the hypothetical RFC describing this option is hypothetically
released) would not cost anything to anyone, other than to the implementations
that feel it is appropriate to use it.  The added security and assurance of
reliable communication seem to me to be (a) an easy option to add to the
protocol-suite, (b) demonstrably sufficient for ultra-reliable applications
(the 16-bit Fletcher algorithm is very good at detecting errors -- see
pp.35/36 of CCR v.19 no.5, etc.), and (c) would not cost anything not to use,
since existing option-processing would reject any attempts to use the
option if unsupported (i.e. doing vanilla TCP would not be changed at all,
and for a Fletcher-talking version to realize it can't talk Fletcher to
a site would only entail the transmission of a couple of packets; presumably
it would be very rare to try to talk Fletcher to someone who isn't known
in advance to support it).

So it's cheap, it's simple, it's reliable, it's easy to code. Why shouldn't
it be a TCP option?

-Johnny Reliable

-----------[000418][next][prev][last][first]----------------------------------------------------
Date:      29 Nov 89 16:59:46 GMT
From:      zweig@brutus.cs.uiuc.edu (Johnny Zweig)
To:        comp.protocols.tcp-ip
Subject:   Re: yellow pages

cliff@WSU-ENG.ENG.WAYNE.EDU (Cliff Stallings) writes:

>I wish to use the nameserver on my Sun-4 systems without using yellow pages.
>I have been informed that this is not possible.  Can anyone help?
> 
>   cliff@wsu-eng.eng.wayne.edu

As far as I can tell (I asked someone who knows) you just have to run BIND
on the Sun. Of course, unless the code you want to do the looking-ups (i.e.
the stuff that you want to _ask_ this name-server stuff) was compiled
with libresolv  it will not ask the name-server. By default, software
from Sun was not compiled with libresolv, so you have to recompile
telnet and everything.

There are some patches on UUNET.UU.NET (somewhere -- you'll need to poke
around) that make libresolv do the Right Thing.  The tricky part is
getting everything else to talk to the lovingly-provided daemon.

-Johnny Second-Hand Wisdom

-----------[000419][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30 Nov 89 01:08:18 PST
From:      melohn@Eng.Sun.COM (Bill Melohn)
To:        tcp-ip@nic.ddn.mil, cliff@wsu-eng.eng.wayne.edu comp.protocols.tcp-ip
Subject:   Re: yellow pages
In article <1989Nov29.165946.11033@brutus.cs.uiuc.edu>:
>cliff@WSU-ENG.ENG.WAYNE.EDU (Cliff Stallings) writes:
>
>>I wish to use the nameserver on my Sun-4 systems without using yellow pages.
>>I have been informed that this is not possible.  Can anyone help?
>> 
>>   cliff@wsu-eng.eng.wayne.edu
>
>As far as I can tell (I asked someone who knows) you just have to run BIND
>on the Sun. Of course, unless the code you want to do the looking-ups (i.e.
>the stuff that you want to _ask_ this name-server stuff) was compiled
>with libresolv  it will not ask the name-server. By default, software
>from Sun was not compiled with libresolv, so you have to recompile
>telnet and everything.
>
>There are some patches on UUNET.UU.NET (somewhere -- you'll need to poke
>around) that make libresolv do the Right Thing.  The tricky part is
>getting everything else to talk to the lovingly-provided daemon.
>
>-Johnny Second-Hand Wisdom


Binaries from the 4.8 bind distribution(+async zone transfer) are
included in SunOS 4.0.3.  A shared libc that includes the resolver
routines for SunOS 4.0.X on Sun3 and Sun4 architectures is available
in the sun-fixes directory on uunet.uu.net. Using these libraries will
allow you to use the DNS without requiring the use of the YP name
service. Installing the shared library will cause all dynamically
linked executables to use the resolver without recompilation.
-----------[000420][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Nov 89 20:24:36 SET
From:      "Vincenzo G. Capuano" <CAPUANO%ICNUCEVM.CNUCE.CNR.IT@CUNYVM.CUNY.EDU>
To:        TCP-IP List <tcp-ip@nic.ddn.mil>
Subject:   Western Digital address
Hi,
does someone know the address and the phone number of Western Digital ?
Is it also on Internet? At what address?

Thanks.
Vincenzo G. Capuano
Computer Science Dept.
University of Pisa, Italy
capuano@icnucevm.cnuce.cnr.it
-----------[000421][next][prev][last][first]----------------------------------------------------
Date:      29 Nov 89 21:51:47 GMT
From:      baker@VITAM6.UUCP (Fred Baker)
To:        comp.protocols.tcp-ip
Subject:   At your service...

RFC 1098                          SNMP                        April 1989


   single sub-tree of the object type name space.

   An element of the set { READ-ONLY, READ-WRITE } is called an SNMP
   access mode.

   A pairing of a SNMP access mode with a SNMP MIB view is called an
   SNMP community profile.  A SNMP community profile represents
   specified access privileges to variables in a specified MIB view. For
   every variable in the MIB view in a given SNMP community profile,
   access to that variable is represented by the profile according to
   the following conventions:

      (1)  if said variable is defined in the MIB with "Access:" of
           "none," it is unavailable as an operand for any operator;

      (2)  if said variable is defined in the MIB with "Access:" of
           "read-write" or "write-only" and the access mode of the
           given profile is READ-WRITE, that variable is available
           as an operand for the get, set, and trap operations;

      (3)  otherwise, the variable is available as an operand for
           the get and trap operations.

      (4)  In those cases where a "write-only" variable is an
           operand used for the get or trap operations, the value
           given for the variable is implementation-specific.

   A pairing of a SNMP community with a SNMP community profile is called
   a SNMP access policy. An access policy represents a specified
   community profile afforded by the SNMP agent of a specified SNMP
   community to other members of that community.  All administrative
   relationships among SNMP application entities are architecturally
   defined in terms of SNMP access policies.

   For every SNMP access policy, if the network element on which the
   SNMP agent for the specified SNMP community resides is not that to
   which the MIB view for the specified profile pertains, then that
   policy is called a SNMP proxy access policy. The SNMP agent
   associated with a proxy access policy is called a SNMP proxy agent.
   While careless definition of proxy access policies can result in
   management loops, prudent definition of proxy policies is useful in
   at least two ways:

      (1)  It permits the monitoring and control of network elements
           which are otherwise not addressable using the management
           protocol and the transport protocol.  That is, a proxy
           agent may provide a protocol conversion function allowing
           a management station to apply a consistent management



Case, Fedor, Schoffstall, & Davin                               [Page 8]

Fred Baker
baker@vitalink.com

-----------[000422][next][prev][last][first]----------------------------------------------------
Date:      29 Nov 89 21:58:08 GMT
From:      meggers@orion.oac.uci.edu (mark eggers)
To:        comp.protocols.tcp-ip
Subject:   tracing a route

I know this has been broadcast and asked before, but I didn't have a
Sun on my desk at the time . . . . .

Where can I get the source plus kernal mods necessary to run traceroute
on a Sparc??

I have some transient routing problems that I would like to solve . . .

thanks - /mde/

-----------[000423][next][prev][last][first]----------------------------------------------------
Date:      29 Nov 89 22:42:35 GMT
From:      haverty@BBN.COM (Jack Haverty)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP Fletcher Checksum Option

>Not to slam Postel and the whole IETF and everyone else who brought us the
>TCP/IP checksum algorithm, but the fact that it is not able to detect
>the transpostion of N (where N>=2 is an even number) octets in a datagram
>is of concern in some applications where ultra-reliable communication is
>essential.  Also, it has been pointed out by a number of hardware-types I
>have talked to that these sorts of errors can occur, for example, when
>DMAing bytes from an ethernet-controller to the main memory of a machine --
>i.e. after the ethernet CRC has already been checked. One case it to have
>a pair of 32-bit words go out over the bus in the wrong order under rare
>timing glitches....

I thought that the following snatch of history might be of interest.

I remember pretty clearly almost exactly this discussion at one of the
TCP working group meetings ten years ago.   There were two arguments
against having a more powerful checksum:

1/ I don't want to devote that much of my CPU to it (remember CPUs in
those days meant big, expensive, not-very-powerful timesharing systems)

2/ if we have to do complicated arithmetic (i.e., algorithms for which
the CPUs didn't have real good instructions available), it will make it
difficult to get high bandwidth

If I remember correctly, the telling argument was:

3/ People are working on new chips to do checksums in silicon.  We don't
want to adopt an algorithm that will preclude use of these chips.

The problem was that there was no obvious consensus to which chips would
hit the market when, and when computer manufacturers would put them into
their products.   This led to a basic plan which was:

Put in a rudimentary checksum now.   When CPU cycles become cheaper,
chips become available, and/or the drawbacks of the checksum become a
problem, select and standardize a new checksum.

If anybody else who was there remembers this differently, chime in!  

Maybe it's now the time....

Jack

-----------[000424][next][prev][last][first]----------------------------------------------------
Date:      29 Nov 89 23:11:32 GMT
From:      jml@tw-rnd.SanDiego.NCR.COM (Michael Lodman)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.periphs.printers
Subject:   Re: Anybody know of an enet/TCP printer?

>In article <1989Nov7.210143.26795@t2ns1.gcs.co.nz> brian@t2ns1.gcs.co.nz writes:
>Has anybody ever come across a printer hanging directly off a thick
>enet transceiver? We have a situation here where such a printer would
>be invaluable. Obviously it would need appropriate intelligence to
>handle addresses, domains etc. with it's card.

Talaris Systems in San Diego makes what they refer to as an 
Ethernet Printstation. It attaches directly to the ethernet.
They also support many different printer emulations such as HPPL, HPGL,
and Postscript.

Their phone number is : (619) 587-0787.

-----------[000425][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30 Nov 89 08:25:45 -0500
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        zweig@brutus.cs.uiuc.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   re: TCP Fletcher Checksum Option

Johnny:

    If you are seriously interested in seeing such an option become
available, it is pretty easy to get the process started to standardize it.

    Given this is a very simple thing to specify (it is a one page
RFC describing the option format) I suggest you write up the one page
RFC for a TCP checksum-type option sent in the SYN (I'd suggest allowing
other checksums besides Fletcher's to be specified).  Make sure that
when a host that doesn't recognize the option silently ignores it,
the TCP connection will continue to use the TCP checksum.

    Then send that draft to me and I'll arrange a meeting at the next
Internet Engineering Task Force meeting (in February) to review it.
If it's approved at that meeting, there's a good chance we can roll it out
as an "if you are going to do this, do it this way" option sometime in
mid-1990.

Craig Partridge
IETF Area Director, Host-Based and User Services

PS: IETF meetings are open to anyone who wants to attend.  The next
IETF meeting is in Tallahassee Florida in February.  To keep track of
what's up in IETF, I suggest you join the IETF list (ietf-request@isi.edu).
-----------[000426][next][prev][last][first]----------------------------------------------------
Date:      30 Nov 89 00:45:15 GMT
From:      baker@VITAM6.UUCP (Fred Baker)
To:        comp.protocols.tcp-ip
Subject:   TCP Fletcher Checksum Option

That's actually an interesting idea.  BUT, why not simply reuse the TCP
checksum field?  If the use of the new checksum has been negotiated, then
the standard checksum is useless except as a component of the Fletcher
Checksum, and any implementation which negotiates to use Fletch will by
definition understand the change.

I disagree, however, that TCP will only use this on folks known to support it.
I think it will always ask and sometimes get a positive response.  Otherwise,
you need some kind of extra-architectural configuration table.

Fred Baker
baker@vitalink.com

-----------[000427][next][prev][last][first]----------------------------------------------------
Date:      30 Nov 89 01:14:56 GMT
From:      avnish@ka.excelan.com (Avnish Aggarwal)
To:        comp.protocols.tcp-ip
Subject:   broadcast handling in presence of subnets


If you have an IP router that is connected to subnets (which
are all part of the same IP network), what is the router
supposed to do with an directed IP broadcast datagram?
(i.e. destination address is <net><-1>  where <net> is same
as the local net)

I had thought that the IP router would forward such
a datagram to all connected subnets. The SUN IP router does not do this.
I do not know what other routers do.

RFC 922 says that this should be possible (Section 6.2).
RFC 985 is not much help.

Any opinions?

Avnish Aggarwal
avnish@excelan.com

UUCP: {ames,sun,apple,mtxinu,cae780,sco}!excelan!avnish    Avnish Aggarwal
Internet: avnish@excelan.com 

-----------[000428][next][prev][last][first]----------------------------------------------------
Date:      30 Nov 89 03:24:32 GMT
From:      vaf@VALINOR.STANFORD.EDU (Vince Fuller)
To:        comp.protocols.tcp-ip
Subject:   traceroute on the PMAX (DECstation-3100)

Has anyone gotten this working? I had it working for a while by re-linking my
kernel with a 4.3 raw_ip.o, but this has recently stopped working for some
strange reason (after having the CPU board replaced, the system now crashes
whenever I run the modified kernel).

	Thanks,
	Vince Fuller, Stanford Networking

-----------[000429][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30 Nov 89 12:13:52 -0500
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        tcp-ip@nic.ddn.mil
Subject:   more on Fletcher

Hey folks -- let's not make using a different checksum harder than it
needs to be.  It is very simple to do.  A one-page RFC explaining how
is appended.

Please note I'm not endorsing the use of alternate checksums (although
it seems harmless enough).

Craig

Internet Engineering Task Force                           C. Partridge
Request for Comments: XXXX                                BBN

                     TCP Alternate Checksum Option

Status of This Memo

    This memo is a draft RFC that proposes a TCP option to allow
    use of alternate 16-bit checksums in the TCP header.
    Distribution of this memo is unlimited.

Introduction

    Some members of the networking community have expressed
    interest in using checksums with different error detection and
    correction properties than the standard TCP checksum.  This
    option makes use of such checksums feasible, provided the
    checksums are 16-bit quantities.

Definition of the Option

    This three-byte option may be sent in a SYN segment by a TCP
    to indicate that it is prepared to both and receive an
    alternate checksum.  The alternate checksum replaces the
    regular TCP checksum in the checksum field of the TCP header.
    It is computed over the same data as the regular TCP checksum.

    TCP Alternate Checksum Option:


             +---------+---------+---------+
             | Kind=X  |Length=3 |  cksum  |
             +---------+---------+---------+

    Here cksum is a number identifying the type of checksum
    to be used.  The currently defined values of cksum are:

		    0  -- TCP checksum
		    1  -- 16-bit Fletcher's checksum

    To use an alternate checksum, a TCP must both send and receive
    a SYN segment specifying that the same alternate checksum
    is to be used.  Note that SYN segments must always use the
    TCP checksum.

    If a TCP receives an option containing different checksum
    type value from the one it sent or does not receive an option
    from the remote TCP, it must use the TCP checksum on the connection.
    Observe that in practice this means that the initiating TCP
    determines whether an alternate checksum is used, and the
    listening TCP can only choose to accept or reject the
    proposed alternate checksum.

-----------[000430][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30 Nov 89 12:33:13 -0500
From:      "John A. Zinky" <jzinky@BBN.COM>
To:        tcp-ip@nic.ddn.mil
Cc:        jzinky@BBN.COM
Subject:   Traffic Sensitive SPF Routing is NOT too hard!
I would like to give my opinion on traffic sensitive routing from the
experience of running large over-subscribed networks, such as the 1987-88
ARPANET. (More details can be found in SIGCOM '89 and MILCOM '89 articles by
Khanna and Zinky)

Summary: 
GIVEN THE GLACIAL PROCUREMENT TIME FOR NEW EQUIPMENT, 
TRAFFIC SENSITIVE ROUTING IS MANDATORY FOR LARGE PACKET-SWITCHED NETWORKS.
Overall, traffic sensitive SPF routing is NOT HARD to implement once you
have the flooding mechanisms to handle failed equipment. Tuning the
algorithm is tricky, but it is less effort than fighting the fires
associated with over-subscribed lines.


In the good old days the ARPANET (pre-1985) had a peak-hour average
line utilization of less than 15% and everyone was happy. (Much like
the current NFSnet.) But due to the budgeting decision beyond the
control of techies, the 1987 ARPANET had an average line utilization
greater than 30% with some lines reaching 80%.  Also, traffic was
growing at a rate of 30% per year and no new bandwidth was scheduled.
Its nuts to run a packet network above 15%, unless you have heavy
controls in terms of dynamic routing and congestion control. We spent
a lot of effort coming up with reasonable schemes which are now
deployed in several large networks.

If you look at Capacity Management in terms of time-scale and
function, you can see that network design, routing, and congestion
control complement each other. Network design plans ahead and matches
expected traffic to available resources. It works on the time scale of
equipment procurement (months to years). Routing is an allocation
policy that maps traffic flows onto available resources. It works on
the time scale of network operations (minutes to days).  Congestion
control regulates user traffic so that resources are not
oversubscribed. It works on the time scale of a few round trip times.

Routing's goal is to make the best allocation of bandwidth given the
current user traffic. When the network is under-subscribed, minhop
routing is fine and all you have to worry about is equipment failure.
For over-subscribed networks, it is tempting to use routing to do some
load balancing.

The interpretation of the old delay-based SPF routing given in the above
papers shows that:

1) Traffic sensitive routing is possible in a network of 220+ nodes with
peak-hour average line utilizations in the 15%-40% range. 

2) Due to shifting traffic patterns and long lead-time for procuring
bandwidth, there WILL BE lines that are > 80% utilized during the entire
peak hour.  Traffic sensitive routing can shed some of this load to other
trunks. (The traffic flows that have only slightly longer alternate paths
will be shed first from the line. While the traffic with much longer alternate
paths will remain on the line.) The specific algorithm used in the
ARPANET/MILNET can handle individual over-subscribed lines with 100%-300%
offered minhop load.  (The extra traffic is moved to under-subscribed
lines).

3) Routing discussions in the time frame of 10 seconds is good enough
for load balancing aggregate traffic loads, but congestion control is still
needed to handle individual fluctuations.


RECOMMENDATIONS

1) If you can afford to run you network with peak resource
utilizations of less than 15%, then forget about traffic sensitive
routing, minhop is good enough.

2) If you plan to use any form of SPF routing on an over-subscribed network:

A) Allow for a "link" weight that has a granularity of at least a 1/10
of a hop. In the ARPANET, 25% of the traffic on a link has an
alternate path with the same number of hops. For example suppose that:
all the links report a weight of 1 and one link reports 1+epsilon,
then 25% of the link's traffic will be shed. It is important to spread
out this abrupt change in traffic allocation by having a finer
granularity in link metric and making sure that links are not all
reporting exactly the same value.

B) The range of the link weight should not go above 4 hops. For the ARPANET
topology and traffic pattern, if a line reports a weight of more than 4
hops, most/all of the traffic will be have an alternate path that will avoid
the line, i.e. no traffic will flow over the link!

C) If you cannot change the link weight automatically, at least let it be a
configurable parameter. But be prepared, it will be a full time job tuning
these link weights.

D) With a some effort, you can use the link weights to handle heterogeneous
link characteristics.



zinky
"Be careful, it's a real world out there"







-----------[000431][next][prev][last][first]----------------------------------------------------
Date:      30 Nov 89 04:22:31 GMT
From:      CAPUANO%ICNUCEVM.CNUCE.CNR.IT@CUNYVM.CUNY.EDU ("Vincenzo G. Capuano")
To:        comp.protocols.tcp-ip
Subject:   Western Digital address

Hi,
does someone know the address and the phone number of Western Digital ?
Is it also on Internet? At what address?

Thanks.
Vincenzo G. Capuano
Computer Science Dept.
University of Pisa, Italy
capuano@icnucevm.cnuce.cnr.it

-----------[000432][next][prev][last][first]----------------------------------------------------
Date:      30 Nov 89 08:26:04 GMT
From:      adnan@sgtech.UUCP (Adnan Yaqub)
To:        comp.sources.wanted,comp.protocols.tcp-ip
Subject:   Looking for New Telnet Client Code

Recently there was a posting that advertized the release of the new
Berkeley telnet code, including a telnet client.  It was available via
anonymous FTP.  I don't have FTP access and am looking for a copy.
Could someone send it to me or point me to a UUCP archive where I can
get it?
--
Adnan Yaqub
Star Gate Technologies, 29300 Aurora Rd., Solon, OH, USA, +1 216 349 1860
...cwjcc!ncoast!sgtech!adnan ...uunet!abvax!sgtech!adnan

-----------[000433][next][prev][last][first]----------------------------------------------------
Date:      30 Nov 89 10:20:15 GMT
From:      wisner@hayes.fai.alaska.edu (Bill Wisner)
To:        comp.protocols.tcp-ip
Subject:   Why do TCP connections hang?

I sent a message to this august assemblage recently complaining that FTP
on our entire campus has an unpleasant habit of hanging in the middle of
transfers. It now turns out that the problem is much more general. Any
TCP connection may hang under certain unknown circumstances.

Background: we have two subnets. The main subnet is populated by a VMS
machine (with TWG WINS TCP) and many PCs and Macs running NCSA Telnet.
It is connected with a Proteon router to the world at large. The other
subnet has a another VAX (with TWG) and a slew of Sun workstaions; it
is connected by a second Proteon router to the main subnet. TCP links
from any campus machine to any machine off campus are prone to failure.
(The same is true of connections from off-campus to on-.) 

I've used SunOS's etherfind utility to try to find the problem. I have
hex dumps of an rlogin connection and an FTP transfer, both of which
hung. (A certain message in my mailbox on a remote machine will cause my
connection to hang every time if I merely read it. It contains no 
obvious clues -- it's just another normal looking message.) I could find
nothing in the hex dumps. No packets were truncated; one packet arrived
and the next one didn't.

The hung connections seem to be data-specific. If I try transferring the
same file twice, both FTP connections are likely to hang at the same
point in the file. As an exercise, I took a file and split it into several
small chunks, then tried transferring it. The connection still hung at the
same point in the fragmented file.

I have come to believe that perhaps the problem resides in the Proteon
box that connects us to the Internet-at-large. It is, after all, the one
common factor shared by all campus machines. But I am at a loss to figure
out just what the problem might be.

Any ideas or suggestions would be greatly appreciated.

<wisner@hayes.fai.alaska.edu>

-----------[000434][next][prev][last][first]----------------------------------------------------
Date:      30 Nov 89 11:56:44 GMT
From:      gregb@dowjone.UUCP (Gregory S. Baber)
To:        comp.protocols.tcp-ip,comp.protocols.misc,comp.protocols.iso
Subject:   PD X.25 software from Unix ??

Hello,
	Does anyone have or know of someone who has Public Domain X.25
software written in C for a Unix box? I'm looking for software that imple-
ments the link and network levels of the CCITT X.25 stack. I'd even
consider low cost software as well.
						Thanks,   --gregb
-- 
Reply to: Gregory S. Baber		Voice:	(609) 520-5077
   Dow Jones & Co., Inc.		UUCP:	..princeton!dowjone!gregb
   Box 300				or	..uunet!warlock!gregb
   Princeton, N.J. 08543-0300		"So long, and thanks for all the fish"

-----------[000435][next][prev][last][first]----------------------------------------------------
Date:      30 Nov 89 13:25:45 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   re: TCP Fletcher Checksum Option


Johnny:

    If you are seriously interested in seeing such an option become
available, it is pretty easy to get the process started to standardize it.

    Given this is a very simple thing to specify (it is a one page
RFC describing the option format) I suggest you write up the one page
RFC for a TCP checksum-type option sent in the SYN (I'd suggest allowing
other checksums besides Fletcher's to be specified).  Make sure that
when a host that doesn't recognize the option silently ignores it,
the TCP connection will continue to use the TCP checksum.

    Then send that draft to me and I'll arrange a meeting at the next
Internet Engineering Task Force meeting (in February) to review it.
If it's approved at that meeting, there's a good chance we can roll it out
as an "if you are going to do this, do it this way" option sometime in
mid-1990.

Craig Partridge
IETF Area Director, Host-Based and User Services

PS: IETF meetings are open to anyone who wants to attend.  The next
IETF meeting is in Tallahassee Florida in February.  To keep track of
what's up in IETF, I suggest you join the IETF list (ietf-request@isi.edu).

-----------[000436][next][prev][last][first]----------------------------------------------------
Date:      30 Nov 89 15:03:56 GMT
From:      jas@proteon.com (John A. Shriver)
To:        comp.protocols.tcp-ip
Subject:   TCP Fletcher Checksum Option

Actually, rather than have to negotiate the TCP checksum type, one
could just assign a different IP protocol number to "TCP with
Fletcher".  If you get an ICMP protocol unreachable, then you go back
to the standard TCP.  Of course, then you might open a can of protocol
revision worms, like the window size to 32 bits...

Of course, this probably wouldn't work so great with the Berkeley
sockets programming interface.

-----------[000437][next][prev][last][first]----------------------------------------------------
Date:      30 Nov 89 16:32:31 GMT
From:      woody@SAIC.COM (Robert Allen Woodburn)
To:        comp.protocols.tcp-ip
Subject:   CapNet


I know this is not the appropriate place to post this, but I couldn't
think of a better place...

Does anyone know of the progress being made toward the realization of
CapNet since Nysernet won the contract?  Who can I contact regarding
getting a connection?

Thanks...

wood y

(woody@saic.com)

-----------[000438][next][prev][last][first]----------------------------------------------------
Date:      30 Nov 89 16:59:09 GMT
From:      neerma@cod.NOSC.MIL (Merle A. Neer)
To:        comp.protocols.tcp-ip
Subject:   TCP IP vendor selection

The Distributed Command and Control project (DC2) at
NOSC is an attempt to bring Naval command and control
systems into the networking arena by frontending them
with PC-ATs.  The microcomputers perform the TCP-IP
function transparently for the Naval systems.  This
project began strictly as an R&D laboratory experiment
but has now progressed to the point where shipboard
installations have begun.  The operational environment,
however, requires 'hardening' of the network frontends
(NIUs).  We have had a difficult time in achieving the
hardening of the NIUs.  The problems stem from the
poor quality of the commercial TCP-IP packages we have
tried.  In April 1988 our contractors were tasked to
evaluate several TCP-IP packages for use in the NIUs.
Their conclusion: none of the packages examined satisfy
the requirements of the NIU.  The problems identified:
1. inability to handle more than 2 or 3 connects per
socket 2. inability to close/reopen a connect 3. poor
and inaccurate documentation 3. violation of the TCP
window management specification 4. bugs in networking
code (usually results in hung or crashed system)
and almost UNIVERSALLY 5. lousy technical support.
The vendors examined during this study: Network
Research FUSION, Exelan, CMC and FTP Software.

We have reached a point of frustration.  Our current
strategy is to: 1. wait for CMC to fix a bug in their
ROM for their ether card (since the rest of their stuff
looks o.k. so far, 2. look at the public domain KA9Q
(advantage: sources), 3. wait for FTP Software to fix
their socket library 4. look at Woolongong (havent tried
them yet) 5. write our own?

Most of these packages work when run with the vendors
own applications (FTP, Telnet, etc.).  Most I believe
work if the PC wants to open one connection, send a 
little data, and that s all.  We program the PCs to be
network servers: must maintain multiple connections,
must recover from opening/closing connections, MUST
implement TCP window mechanism because our clients
often send much data to server, must provide a socket
interface (somewhat of a standard), MUST WORK!

If we could find a vendor with a product as described
we would anticipate buying more than a few packages as
the Navy has a lot of ships with lots of command and
control systems and soon to have lots of networks.
So far, however, we cant get any package out of the lab.

Does anyone want such a customer?

Merle Neer
neerma at nosc.mil
(619)553-3974

-----------[000439][next][prev][last][first]----------------------------------------------------
Date:      30 Nov 89 17:13:52 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   more on Fletcher


Hey folks -- let's not make using a different checksum harder than it
needs to be.  It is very simple to do.  A one-page RFC explaining how
is appended.

Please note I'm not endorsing the use of alternate checksums (although
it seems harmless enough).

Craig

Internet Engineering Task Force                           C. Partridge
Request for Comments: XXXX                                BBN

                     TCP Alternate Checksum Option

Status of This Memo

    This memo is a draft RFC that proposes a TCP option to allow
    use of alternate 16-bit checksums in the TCP header.
    Distribution of this memo is unlimited.

Introduction

    Some members of the networking community have expressed
    interest in using checksums with different error detection and
    correction properties than the standard TCP checksum.  This
    option makes use of such checksums feasible, provided the
    checksums are 16-bit quantities.

Definition of the Option

    This three-byte option may be sent in a SYN segment by a TCP
    to indicate that it is prepared to both and receive an
    alternate checksum.  The alternate checksum replaces the
    regular TCP checksum in the checksum field of the TCP header.
    It is computed over the same data as the regular TCP checksum.

    TCP Alternate Checksum Option:


             +---------+---------+---------+
             | Kind=X  |Length=3 |  cksum  |
             +---------+---------+---------+

    Here cksum is a number identifying the type of checksum
    to be used.  The currently defined values of cksum are:

		    0  -- TCP checksum
		    1  -- 16-bit Fletcher's checksum

    To use an alternate checksum, a TCP must both send and receive
    a SYN segment specifying that the same alternate checksum
    is to be used.  Note that SYN segments must always use the
    TCP checksum.

    If a TCP receives an option containing different checksum
    type value from the one it sent or does not receive an option
    from the remote TCP, it must use the TCP checksum on the connection.
    Observe that in practice this means that the initiating TCP
    determines whether an alternate checksum is used, and the
    listening TCP can only choose to accept or reject the
    proposed alternate checksum.

-----------[000440][next][prev][last][first]----------------------------------------------------
Date:      30 Nov 89 17:33:13 GMT
From:      jzinky@BBN.COM ("John A. Zinky")
To:        comp.protocols.tcp-ip
Subject:   Traffic Sensitive SPF Routing is NOT too hard!

I would like to give my opinion on traffic sensitive routing from the
experience of running large over-subscribed networks, such as the 1987-88
ARPANET. (More details can be found in SIGCOM '89 and MILCOM '89 articles by
Khanna and Zinky)

Summary: 
GIVEN THE GLACIAL PROCUREMENT TIME FOR NEW EQUIPMENT, 
TRAFFIC SENSITIVE ROUTING IS MANDATORY FOR LARGE PACKET-SWITCHED NETWORKS.
Overall, traffic sensitive SPF routing is NOT HARD to implement once you
have the flooding mechanisms to handle failed equipment. Tuning the
algorithm is tricky, but it is less effort than fighting the fires
associated with over-subscribed lines.


In the good old days the ARPANET (pre-1985) had a peak-hour average
line utilization of less than 15% and everyone was happy. (Much like
the current NFSnet.) But due to the budgeting decision beyond the
control of techies, the 1987 ARPANET had an average line utilization
greater than 30% with some lines reaching 80%.  Also, traffic was
growing at a rate of 30% per year and no new bandwidth was scheduled.
Its nuts to run a packet network above 15%, unless you have heavy
controls in terms of dynamic routing and congestion control. We spent
a lot of effort coming up with reasonable schemes which are now
deployed in several large networks.

If you look at Capacity Management in terms of time-scale and
function, you can see that network design, routing, and congestion
control complement each other. Network design plans ahead and matches
expected traffic to available resources. It works on the time scale of
equipment procurement (months to years). Routing is an allocation
policy that maps traffic flows onto available resources. It works on
the time scale of network operations (minutes to days).  Congestion
control regulates user traffic so that resources are not
oversubscribed. It works on the time scale of a few round trip times.

Routing's goal is to make the best allocation of bandwidth given the
current user traffic. When the network is under-subscribed, minhop
routing is fine and all you have to worry about is equipment failure.
For over-subscribed networks, it is tempting to use routing to do some
load balancing.

The interpretation of the old delay-based SPF routing given in the above
papers shows that:

1) Traffic sensitive routing is possible in a network of 220+ nodes with
peak-hour average line utilizations in the 15%-40% range. 

2) Due to shifting traffic patterns and long lead-time for procuring
bandwidth, there WILL BE lines that are > 80% utilized during the entire
peak hour.  Traffic sensitive routing can shed some of this load to other
trunks. (The traffic flows that have only slightly longer alternate paths
will be shed first from the line. While the traffic with much longer alternate
paths will remain on the line.) The specific algorithm used in the
ARPANET/MILNET can handle individual over-subscribed lines with 100%-300%
offered minhop load.  (The extra traffic is moved to under-subscribed
lines).

3) Routing discussions in the time frame of 10 seconds is good enough
for load balancing aggregate traffic loads, but congestion control is still
needed to handle individual fluctuations.


RECOMMENDATIONS

1) If you can afford to run you network with peak resource
utilizations of less than 15%, then forget about traffic sensitive
routing, minhop is good enough.

2) If you plan to use any form of SPF routing on an over-subscribed network:

A) Allow for a "link" weight that has a granularity of at least a 1/10
of a hop. In the ARPANET, 25% of the traffic on a link has an
alternate path with the same number of hops. For example suppose that:
all the links report a weight of 1 and one link reports 1+epsilon,
then 25% of the link's traffic will be shed. It is important to spread
out this abrupt change in traffic allocation by having a finer
granularity in link metric and making sure that links are not all
reporting exactly the same value.

B) The range of the link weight should not go above 4 hops. For the ARPANET
topology and traffic pattern, if a line reports a weight of more than 4
hops, most/all of the traffic will be have an alternate path that will avoid
the line, i.e. no traffic will flow over the link!

C) If you cannot change the link weight automatically, at least let it be a
configurable parameter. But be prepared, it will be a full time job tuning
these link weights.

D) With a some effort, you can use the link weights to handle heterogeneous
link characteristics.



zinky
"Be careful, it's a real world out there"

-----------[000441][next][prev][last][first]----------------------------------------------------
Date:      30 Nov 89 19:02:23 GMT
From:      roy@phri.nyu.edu (Roy Smith)
To:        comp.protocols.tcp-ip
Subject:   RFC-822 source routing


	I am considering either writing a minimalist mail transport agent
or (more probably) a sendmail.cf file which does not support RFC-822 source
routing.  Can anybody see any practical problem with that?
-- 
Roy Smith, Public Health Research Institute
455 First Avenue, New York, NY 10016
{att,philabs,cmcl2,rutgers,hombre}!phri!roy -or- roy@alanine.phri.nyu.edu
"The connector is the network"

-----------[000442][next][prev][last][first]----------------------------------------------------
Date:      30 Nov 89 19:10:16 GMT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   Ye Old Discard Protocol (WKS == 9)

Is there a IAB policy which might relate to the use of Well Known
Service (WKS) numbers or Internet ports for Relatively Unknown Services
(RUS) such as PC-NFS.  There is an IBM-PS/280 on our network that is
shipping 14 bytes of text in a UDP packet directed to WKS 9, the discard 
service.

Example data:

	PC-NFS04080B65
	PC-NFS0415AE76

What might these hosts be doing?  Would they like a reply?  I kind of
doubt it.

Phil Wood, cpw@lanl.gov

-----------[000443][next][prev][last][first]----------------------------------------------------
Date:      30 Nov 89 22:13:20 GMT
From:      dcrocker@DECWRL.DEC.COM (David Crocker)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP Fletcher Checksum Option

Jack,

I have always had the impression that the TCP and IP checksums were 
intended ONLY as a backstop for the link-level checksum.  The theory,
as I have understood it is:

If there is any interesting likelihood for data corruption, use strong,
hardware-based checksum and retransmission mechanisms.  This is best done
at the data-link layer.  For example, such corruption problems usually
involve noise and are localized to a given segment; use mechanisms specific
to that segment.  Further, you can get more immediate response, since you
do not incur the end-to-end delay before detecting and then retransmitting.

The TCP and IP-level mechanism then becomes the safety valve, to catch the
errors that slip in between the data-link interface cracks.

This, then, justifies the requirements that the TCP and IP checksums be
end-to-end and cheap in software.  

Hence, the question is how likely transposition is for these in-between
the cracks points of exposure?

Dave

END OF DOCUMENT